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

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