読書メモ。
- エレガントパズル ー エンジニアのマネジメントという難問にあなたはどう立ち向かうのか
- https://bookplus.nikkei.com/atcl/catalog/24/04/22/01364/
「人は会社を去るのではなくマネジャーのもとを去る」という言葉がある。マネジメントはあらゆる組織で重要だが、どうするべきか誰からも教わらないことが多く、構造化もされていない。複雑なマネジメントの課題に対してよい解決策を得られるか否かで、チームが満足するか不満を感じるかの違いが生まれる。そして最終的には、企業の成否を左右する。
チーム編成から、士気・成果向上、キャリア形成、プロダクト管理、文化醸成、技術継承、技術的負債、上層部との調整まで、エンジニアリングマネジメントのあらゆる課題について、よりよい解決策への道筋を示す。
目次 #
- 第１章：導入：重要なパズルを解くために
- 第２章：組織：機能する組織を作り、維持する
- 第３章：ツール：変化をマネジメントする手法
- 第４章：アプローチ：問題解決につなげる
- 第５章：文化：継続的に取り組んで育成する
- 第６章：キャリア：同僚と自分に対して責任を持つ
- 第７章：さらに先へ
第１章：導入：重要なパズルを解くために #
（省略）
第２章：組織：機能する組織を作り、維持する #
私のサポート対象が、チームからチームの集合である組織へと変わったとき、これまで考えたことのない新たな種類の問題に直面し始めた。チームをいくつ作るべきなのか？新しい取り組みのために新規にチームを作るべきか、それとも既存のチームに任せるべきか？
このような疑問が、組織デザインという捉えどころのない巧みな技への入り口だった。経験を積むにつれて、組織デザインの基礎的な課題はチームのサイズを決めることだと考えるようになった。
私は、チームのサイズを決める万能法則があるとの考えには懐疑的だが、しかし、繰り返し適用でき、課題の大半を解決できたフレームワークはある。すべての原則と同様、これはチームサイズの問題を検討するための枠組みであり、あらゆる例外を制限するものではない。それでも私は、例外の長期的コストは例外を選んだときに想定していたメリットを上回る、と考えている。
- 安定した状態のチームは６人から８人とする。
- 新しいチームを作り、そのチームが８人から 10 人に成長したら、４人または５人で構成される２つのチームに分割する
- 空っぽのチームは決して作らない。
- ９人以上をサポートするマネジャーを決してそのままにしない。
（４人未満の）小さなチームは、チームではない
チームの重要な要素のひとつは、個人が構成している複雑性（個人の特性や能力）がチーム単位で抽象化される点にある。４人未満のチームは抽象化に漏れが多く、個人で動く場合と見分けがつかない。小さなチームの成果を判断するには、オンコールのシフトや休暇、割り込みのそれぞれに対する考慮が必要だ。また小さなチームは壊れやすい。１人去るだけで、イノベーションを起こせる革新状態から、技術的負債をこれ以上増やさないためにトイルをこなす状態に陥る。
イノベーションと運用を同じチームで実施
既存のチームが運用で身動きが取れない一方で、イノベーションのために新しいチームを作るのはよくあるやり方だ。こうして新しいチームを作った経験は私にもある。しかし私は、このやり方から、既存のチームでイノベーションを起こす方法へと転換してきた。高い士気と学習する文化が得られ、イノベーターと運用者による２階層のシステムを作らなくて済む。
成長するチームの４段階
- 遅延：バックログが毎週伸びているのであれば、そのチームは遅延状態にある。
- 現状維持：重要な仕事は片付けているが、技術的負債の解消には取り組めていない。あるいは新規プロジェクトには取りかかれていない。
- 負債返済中：技術的負債の解消に取り組んでおり、負債を返済するごとにさらに返済するための時間が得られるといったように、恩恵をチームが受け始めている。
- 革新：技術的負債が少ない状態が続いている。チームは新しいプロジェクトに取り組むことができ、イノベーションを起こすことができる。
スコープの変更またはローテーションを実施する
「技術的負債を返済したら、余剰になったメンバーを他のチームに移したほうがいいんじゃないか？」という質問を多く受けた。
わたしは個人の再配置には懐疑的な立場だ。持続的な生産性は通常、ハイパフォーマンスなチームから生じる。チームが結束するには時間がかかる。こうしたチームから別のチームに人を移すと、チームの結束が初期化される可能性がある。チームで人を絶対に変えてはいけないというわけではない。チームを変えないことは停滞につながるからだ。しかし、結束している状態を守るためには、成長を控えめにする必要があるだろう。
チーム間でスコープを動かしながら、チーム自体は維持するのが良い。チームにゆとりがたっぷりあるなら、徐々に責務を動かしていく。そうするとそのチームは、拡大していくワークロードをチーム内で最適化し始める。チーム内のゆとりを保ちながらゆっくりやるのがいちばんだ。「人を急速に動かす」「スコープを急速に動かす」の２択から選ぶのであれば、後者のほうが効果的であり、かつ混乱が少ない。
第３章：ツール：変化をマネジメントする手法 #
（省略）
第４章：アプローチ：問題解決につなげる #
ポリシーに従う、例外に従わない #
組織の足並みを揃えることは、絶好調な時期であっても難しい。例外を認めてしまえば、足並みを揃えるための仕組みでもっとも強力な「一貫性」が損なわれてしまう。一方で組織は、流動的な環境に適応することで生き残れる。確立した習慣に固執する「変化」しない組織は、失敗に至る道を歩んでいる。
では、一貫性と変化をどのように調和させたらいいのだろう？
多くの場合、一見矛盾するように見えるゴールでも、時間を考えれば考えるほど、排他的ではなくなる。結果として、ポリシーに従う、例外に従わないというアプローチが浮かび上がってきた。
よいポリシーは制約をもたらす
あなたが作るポリシーは、小さな戦略である。ゴールを定めて、そのゴールと行動を一致させるための制約を特定することにより、ポリシーは構築される。具体例を見るのがいちばん分かりやすいだろう。
私が最近取り組んだ興味深いポリシーのひとつは、従業員の多くがリモートで働き、地理的に分散したオフィスがたくさんある企業で、誰がどのチームに参加できるかを決めたものだった。
１．すべてのオフィスを一次（first-tier）オフィスにする。（劣っていると思われがちな）二次のオフィス（second-tier）オフィスは設けない。
一次のオフィスには主要なプロジェクトが複数あり、他のオフィスからのサポートが進捗のボトルネックになってはいけない。加えて、密接に協力して働くメンバーは物理的にその場にいなければならない。
２．リモートで働くエンジニアは会社に不可欠であり、会社から十分にサポートを受けられるようにする。
ゴールが定まったら、次のステップは、ゴールに向かう行動の範囲を絞り込むために、いくつかの制約を明文化することだ。前述のケースでは、制約のリストは次のようになるだろう。
- チームは、最大でも、ひとつのオフィスに配置される（ここで「最大でも」と言っているのは、フルリモートのエンジニアだけで構成されたチームをサポートするためだ。）
- オフィスにいる従業員は、そのオフィスのチームのメンバーでなければならない。
- リモートで働く従業員は、どのチームで働いてもよい。
- オフィスへ 60 分以内に通勤できる従業員は、そのオフィスで働かなければならない。
これらは、許可される行動を定義しているので、よい制約である。
「オフィスに居る従業員は、そのオフィスのチームで働くのが好ましい」といったような主張が弱い制約も想像できるものの、そのような制約は行動を制限するにはあまり役に立たない。
ポリシーを作って維持する「固定費」は高くつくので、行動の明確化に役立たないポリシーを書いてはいけない。それは悪いポリシーだ。その代わり、拘束力のない推奨事項を書いた「規範」を書くことをお勧めする。規範には拘束力がないので、曖昧さや特殊なケースに対処するためのエスカレーションが発生しないためだ。
例外負債を負わない
ゴールにつながる制約を明確にできたら、後はその制約を一貫して守るだけだ。簡単ではあるが、一貫性の維持には少なからず勇気が必要になる。どんなに意思が強くても、自分の作ったポリシーに迷いが生じることは避けられないからだ。ポリシーを一貫して適用することが特に難しい理由は次の２つによる。
１．機会の範囲が狭まることを受け入れることになる。よい制約にはトレードオフが伴う。意図的に機会を狭めているからだ。魅力的な機会を損なうのは確かに難しい。（機会損失による）具体的な結果に直面してしまったときには、ポリシーに忠実であり続けるのはなおさら難しくなる。
２．局所的には次善策となる。全体制約を満たすと、必然的に局所的な非効率につながる。ときには、チームに直接恩恵がない広範なゴールを目指すために、困難な状況へチームを導くこともある。その状況を受け入れるよう、チーム全員に依頼するのは簡単ではない。困難さをチームに強いながら、ポリシーを守り続けるのはなおさら難しい。
重要な目標を達成するためには、あえて制約を慎重に設けることも必要だ。選択肢を絞り込むことで、局所的な効率の低下を受け入れる覚悟が求められる。勇気を奮い起こしてポリシーを維持できなければ、余計なコストを負担することになる。
ポリシーが成功するか否かは、例外となる要求をどう扱うかで決まる。例外を認めることにより、みんなの公平感が失われ、今後のポリシーを弱めてしまう前例となる。例外が日常化した環境では、自分たちで設計したポリシーに対する例外処理により、リーダーの時間の大部分が奪われてしまう。例外に多くの時間を費やしている組織は、「例外負債」を負うことになる。抜け出すには、例外処理をやめて、ポリシーに従うしかない。
ポリシーに従う
例外負債を負うことで、ポリシーを弱体化してはいけないことは理解できた。とはいえ、エスカレーションや例外への対応要望を単に無視するわけにもいかない。これらは、新たに作成したポリシーと既存ポリシーの間の非互換性を表していることが多い。無視する代わりに、制約を再検討するための先行事例として、すべてのエスカレーションを集めよう。
エスカレーションが十分に集まったら、制約を見直そう。過去のエスカレーションを新しいポリシーに取り入れて既存の制約を更新するか、例外をより効果的に処理するための新たな制約を作ろう。
このアプローチは強力だ。なぜなら、ポリシーの荒削りな部分に不満を持つチームのガス抜きができる（エスカレーションは依然として歓迎する）と同時に、全員が一貫性のある公平な環境で作業していることが確実になるからだ。エスカレーションはポリシーを更新するための入力として使われ、場当たり的に対処しなくて済む。
こうして定まったポリシーを実運用するときは、次回の更新時期を宣言しておこう。そうすることで、改訂を試みる前に新しいポリシーを十分に評価する時間を確保できる。よくできた効果的なポリシーが、一部の懸念により、効果を発揮する前に変更されてしまうのはよくある。ポリシーが頻繁に変更されると、例外との見分けがつかなくなってしまう。
一回限りの複雑な状況に対処する機会が発生したときには、すぐに解決しようとせず、一歩引いて問題を文書化してみよう。１か月後にポリシーを見直すと決めて、その間に発生したすべての例外要求を溜めておき、必要に応じて新しいポリシーに組み込もう。これにより、チームの時間が節約できるし、信頼も築ける。例外を都度処理するのではなく、ポリシーに取り組むようにしよう。
強い関係性はどんな問題にも勝る #
チーム内部の問題のほぼすべては、関係性の欠如や悪化に帰着し、すばらしい関係性があれば何でも一緒に解決できるだろう。技術的な意見の相違は、チームのみんなの学びの機会になる。失敗は、チームとして結束する機会をもたらしてくれる共有体験である。
数年前、一緒に働いていたリーダーの１人が私にこう述べた。「正しい人材がいれば、どんなプロセスでも機能する。間違った人材がいるなら、どんなプロセスも機能しない。」この発言はかなり正確だと私は考えている。
プロセスとは、協力しやすくするためのツールであり、チームが楽しんでいるプロセスこそが通常は正しいプロセスである。プロセスがどういうわけか失敗しているのであれば、別のプロセスに置き換える前に、どのように失敗しているかを掘り下げてみよう。
問題に迫っていくにつれ（自分自身が問題かも！）、別のプロセスで解決できるか、表面的な問題を解決しているだけか、正直に自問自答してみよう。私の経験上、別のプロセスはあなたが探している解決策ではないはずだ。
第５章：文化：継続的に取り組んで育成する #
（省略）
第６章：キャリア：同僚と自分に対して責任を持つ #
（省略）
第７章：さらに先へ #
（省略）