エンジニアリングマネージャーの仕事 プロジェクトって難しい
- マネージャは特に悪いときに説明責任を果たさなければならない
- 悪い状況を扱う能力によってマネージャの力量が試される
以下のことを見ていく
- サウロンの目
- 締め切りが近づくと会社全体があなたのチームを見ている感じる
- サウロンの目が見てきたときに何をすべきか
- サウロンの目が去った時に何をすべきか
- 自分の成功の犠牲者
- 組織が大きくなるにつれ、同じペースで仕事を終わらせるのが難しくなる
- それはなぜか？
- どう対処すればよいか？
- スコープ、リソース、時間：ピンチの時に3つのレバーを引ける
このような状況こそが、人を良いマネージャにする。精神的な準備をしておけば、戦時でもよい判断が下せるようになる。
11.1 サウロンの目
- いろんな方向からせっつかれている状態
- このような厳しい状態をチームにとってやりがいのある経験に変えることができる
- 適切に対処すれば、キャリアの成長が期待できる
- 対処がまずければ、次の重要プロジェクトは、他のチームに行ってしまうかも
11.1.1 警告のサイン
- ステークホルダーが、プロジェクトに一段と興味を示す。追い払う必要が出てきた。
- ビジネス上位層が、会うたびに状況を聞いてくる。これまで面識のない人も含まれる
- 上司や上司の上司が進捗に対して直接的で厳しい態度を取るようになる
- プロジェクトの内容が、社内、社外で誇張されていることに気が付く。
- ごく単純にすべてが炎上している。チケットがどんどん増えていく
プレッシャーが高まる時期には、状況に関わらず用心を怠らないようにする。
11.1.2 視線を浴びているとき
激しく困難な時期に役立つ原則がいくつか存在する。
- チームの足並みをそろえる
チームが周囲の期待を知らない場合は、きちんと状況を共有する。チームがゴールに向かうためのファシリテーションを行う。
- 過剰なまでのコミュニケーション
ステークホルダーに、週次(またはもっと頻繁に)状況報告を書くこと。
- 取り組んでいること
- 進捗状況
- 下した重要な決定
などを完全に明確にしておく。
- 反応やフィードバックを求める
ステークホルダーがコミュニケーションできるチャンネルを作る(チャットなど)
- 頻繁にリリースする
可能な限り頻繁にリリースすることで、ステークホルダーを最新のビルドに追随させる。
- リリースの頻度が低いと
- 巨大マージ
- ビックバンリリース
- などとなり、様々なバグを生むことになる。
どこで新しいビルドがみられるのかを伝えておく。パフォーマンスが高いチームは継続的にリリースをするもの。
- 現実的でいる
コードの品質や技術的負債については、一旦目をつぶりリリースを優先する必要があるかもしれない。理想に捕らわれず現実的な判断をすることも必要。その場合には、記録を取って置き、後に必ず対応する
- 正面からリードする
リーダーとして、メンバーに模範を示す。正面から仕事に向き合う。
11.1.3 視線がそれたとき
視線がそれたときにやることはチームの士気にとって極めて重要である。大変なプロジェクトを締めくくって、充電の時間を取るには、以下のようにする。
- お祝いをする
一番重要。ランチや飲み会、ケーキを届けるなど。チームが喜ぶものであればなんでも構わない。感謝を述べることを忘れないようにする。
- 技術的負債をきれいに片付ける
締め切りが近づくにつれて端折ったり、暫定対応したものを片付ける。
- 自分用のプロジェクトの時間を取る
数週間のあいだ、自己学習のための時間を取るのもあり。チームに実験と新しいことを学習する時間を与える。ペースと方向性を変えることで、プロジェクトの間に精神的な余裕が生まれる
- ふりかえる
レトロスペクティブミーティングを設定する。次回もっとうまくできることを議論する。
- 計画を立てて、気持ちを切り替える
次に何にどう取り組むのかの計画を立てて、わくわくする。
激しい時期の後には休息期が来るようにする。それができないような状況であれば、上司に交渉するものマネージャの仕事。
11.2 あなた自身の成功の犠牲者
「人月の神話」のブルックスの法則「遅れているソフトウェアプロジェクトへの追加要員は、プロジェクトをさらに遅らせるだけである」
- 知的労働は簡単には個別の作業に分解できない
- 常にコミュニケーションが必要
- 作業を終わらせるにはコミュニケーションの量を増やす必要がある
- 1つのプログラミングプロジェクトを2つに分割することはできない
この考えは、はるか昔からあるにも関わらず、いまだに何度も目にする
- 3倍の大きさになったのに、なぜ3倍の仕事をしないのか？
- 大きくなるにつれて、仕事が遅くなるのはなぜ？
11.2.1 人ではなく生産性
レガシーシステムや多くの人を抱えることによるコミュニケーションオーバーヘッドの増加に対処しなければならない。1人当たりの生産性の低下に対処しなければならない。
- 普段の仕事が大変になる：うまくやっていると仕事が増える。
- レガシーコードを扱う機会がさらに増える：昨日の新機能は今日の技術的負債。コードベースも増加し理解に時間がかかる。
- コミュニケーションとプロセスのオーバーヘッドが増え続ける：潜在的には人数(人数-1)/2のチャンネルがある。
それでもあなたができることは？
マネージャとして、チームに以下3つの振る舞いを促す
- 隠れた複雑性を明らかにする：実際に何が必要かを共有する
- 常に進捗を示す：常に何かを見たり聞いたり触ったりできるようにしておく
- ソフトウェアを実用主義で開発する
- ユーザに対して計測可能なインパクトを与えることにチームが集中できるようにすべき
- そうすることで、重要なこととそうでないことの判断をはやく下せるようになる
- キャンプ場のルールを推奨する
- 技術的負債の解消のための時間を取る(20%程度？)
- 機能の削除の検討(勇気をもって決断する)
要求や進捗、達成状況がビジネスの人たちにとって透明であるようする。そうすることで、間違った批判をうけることが回避できるようになる(建設的な議論ができるかも)。
11.3 スコープ、リリース、時間
品質、納期、コストは、2つは同時に満たせても、3つ同時に満たすことはできない。様々な部門から対立する意見が出てくることもある。プロジェクトの妥協点を見つけるための3つのレバーがある。
- スコープ：何を届けようとしているかの定義
- リソース；アサインするエンジニアの数
- 時間；取り組む期間
11.3.1 スコープ
バックログの優先順位付けに積極的に参加する。これにより後に発生する困難を軽減することができる。
- 機能を、Must,Should,Could,Won'tに分解する
- Must：必須
- Should：あるべき
- Could：あった方がよいがなくても
- Won't：何らかの事情でやらないと決めたもの
- ストレッチゴールを推奨する
- どの機能をどのマイルストーンに当てはめるか事前に検討しておく
- 事前に決定しておくことで、ストレスやパニックを軽減できる
- 遅れが出たときに調整が可能になる
事前に少し余計に考えておくことで、プロジェクトがスムーズに進むようになる。カテゴリを見直すことも可能かもしれない。
11.3.2 リソース
- タスクの並列性：並列にできるもの、直列にしかできないもの
- コードの近接性：コミットがコンフリクトを起こすのを避ける
- 技術的難易度：既存のいつもの追加か、新しい仕組みを考える必要があるか、調査に時間を使う必要があるか
遅いプロジェクトに人を追加すると、さらに遅くなる。このため作業を分類する必要がある。
大問題が発生したとしても、人を動かすのは最善のレバーではない。単に人を追加すればよいわけではないが、事前に作業をカテゴリ分けしておけば、人を追加することで効率化できる部分がわかる。
11.3.3 時間
- 締め切りを調べる
- 締め切りをずらすことが本当に意味することは何なのかを確認する
- 締め切りをずらすことで、実際に何が起こるのかを調べる
- 多くの場合、締め切りはずらせる
- 締め切りの延長が失敗した場合は、別のレバーを引く
- スコープを削る
- リソースを見直す
時間は作られることもなければ破壊されることもない、ただ割当てられるだけである。
11.3.4 レバーの透明性を保つ
こうしたアプローチをしておくことで、優先順位について質問を受けたときに、容易に答えられるようになる。自分の決定やその理由を部門内で見えるようにしておくことで、状況をチームが理解するのに役立つ。包み隠さず話せるようになるし、根拠ない批判から、どういったトレードオフを取るかの議論に変えることができる。
チーム間の協力関係も作れるかもしれない。
Discussion