13. ペアプロやテストの疑問とか、ソフトウェアエンジニアの育成とか

話したネタ

ペアプロにおけるビギナーとベテランの組み合わせ3パターンについて
ビギナーとビギナーの組み合わせで効果はあまり期待できない（チームビルディングでは意味がある）
ベテランとベテランは、一番効果を発揮するペアである
意思決定をライブでできる重要性
設計上の妥協点をその場で合意できる
ビギナーとベテランで、ビギナーはナビゲーターをするのか？
コードを書いてるところを見てもらうのは大事なプラクティス
ベテランもプレッシャーを持ってコードを書ける
見られているだけでコードの質は高まる
リアルタイムでないコードレビューがあるだけで、コードの質は高まる
コードレビューのインフラに投資する
流しのペアプロ業をする中で、ドメイン知識がない状態でペアプロへ参加して価値をだせるか？
一番の学びは教えることから発生する
相手から、相手自身の学びを引き出す
チームの暗黙知を、暗黙知のまま伝える、強化していく
テストを書く場合に、RDBやKVSなどをどこまでモック/スタブするのか？
ノートPCにインストールできるものは本物を使い、入らないものはモック/スタブを使う
プライベート関数はテストするのか？
技術的には、プライベート関数のテストはパブリック関数からテストできる
プライベートの実装に基づいたテストは脆い、現状追認のテストになりがち
フロントエンドのテストはどこまで書けばいいのか？
書くけど、書きすぎない
画面の構造が変わっても、影響にされにくいものをテストする
ビジュアルリグレッションテスト
魑魅魍魎のUIの世界
テストのカバレッジ、どの程度まで書けばいいのか？
ユニットテストを含めて、グレーボックス・ブラックボックスの観点から書くのが望ましい
カバレッジは何らかの管理の道具にすると、うまく回らない
不具合は思い違いから発生する
カバレッジ100%は誤った安心感を与えがち
カバレッジツールは自分達の見落とし・過信を見つけるために使う
カバレッジを絶対値ではなく傾きでみる
CIではテストの成功/失敗だけではなく、カバレッジやコードの複雑度を取る
バグ収束曲線は、現代の開発ではFitしないことのが多い
品質指標の形骸化
外注が多く、内製が少ない組織で、ソフトウェアエンジニアをどうやって育てていけば良いのか？
内製にシフトするなら、技術者のhiringも必須
小さく始めて、大きく育てて勝つパターンを積み上げる
段階的に内製開発にシフトしていく
社内の特区、信頼貯金を使って展開していく
内製を全然していない会社が、内製にシフトするためには4-5年かかる
新人を育てるためにはどうしたらいいか？
配属ガチャ
技術力の高いエンジニア新人を孤立させない
事業部内に閉じた情報流通
全社Slackがないのはよくあるサイロ化
技術者の横のつながりを維持する、リアルタイムコミュニケーションのチャネルを作る
内製を始めるモードになったエンプラ企業はイメージ付けが必要
技術者が社名を背負ってアウトプット
大企業Hack
意思決定層にこれからのソフトウェア開発に認識を改めてもらう
組織やチームにノウハウをどうためて、育てていくのか？力を貯めるいいやり方？
再現可能にするのが大事
前提が違う、変動する中でソフトウェア企業としての強さを保つ
公開し検索可能にすることが大事
URL重要
心理的安全性の重要性
価値観から行動原則、品質基準を考えていく
経験していない場面にチェックリストは効かない
誤っていたこと、失敗は良いチャレンジとして評価されるように
社内でアンチパターンを共有できる組織は強い
社内FailCon