(記事) 開発組織マネジメントのコツ

naoya ito 氏による、 VPoE 的な職務のコツについて。

CTO については、 define CTO を読むと良いらしい。

1. 注力するべきは、質の高い問題を発見し、そこに組織をフォーカスさせること。
   • 参考: イシューから始めよ
2. 開発組織のアナロジーとしては、スポーツチームのマネジメント。
3. 組織構造で重要なこと: チーム学習の結果が、チームに蓄積されること。
   • 個々人の意識はコントロールできない
   • 構造はコントロールできる
   • ただし、いじりすぎると学習結果が失われかねないので、あくまで、チームの学習結果の総量の増加を目指す
4. 心理的安全性と責任(チーム学習には、両方必要)
   • 各チームが置かれている場所は、どっちが足りていない?
   • 責任: ミッションないしロードマップを要求
   • 心理的安全性: チームビルディングなど
5. ヒューマンマネジメント
   • 開発の問題とは、9割方、組織の問題
   • フレーミング
     • 「学習の場」としてフレーミング。
     • 仕事をアサインする最初に期待値調整(超重要) aka あなたに期待していること、チャレンジ、やりがい、 etc.
     • コツ: 対話と調整
   • 1 on 1
     • 効用: 組織の課題発見
     • リフレーミングの機会
     • コツ: お願いごとは、相手の不満が空になってから
6. プログラマー風林火山
   • プログラマーとしてのコンピテンシー的な能力を風林火山で説明
   • これを良い感じに組み合わせるとシナジーがでる
7. アンチパターン
   • 文化改革症候群
     • 意思決定の仕方 が要因で、 文化 は結果
     • 変えるなら、意思決定の仕方
   • 現状否定
     • 未来志向で逆算して、変化の必要性を訴える。
   • マイクロマネジメント
   • サーバント方リーダーシップの罠
     • きちんと方向性を示すべし。
   • エンジニア幸せ向上委員会
     • 良いプロダクトとは、必ずしも関係ない。
   • みんなが同じことを考える!
     • 価値観はコントロール不可。
     • コントロール可能 == ゴール設定とその捉え方