『デッドライン』を読んだ
目次
少し前にTwitterで紹介されていて気になっていた1トム デマルコの『デッドライン』を読んだ。新品で売ってるところが見つからなかったのでAmazonで中古を購入した。2
プロジェクトマネジメントをするたびにその難しさを痛感しているので知見が得られたり思考が整理できたりすることを期待して読んだ。
同著者の本だと『ピープルウエア』が有名だがそちらは未読。『ゆとりの法則』とかも面白そうなのでいつか読みたい。
というわけで参考になったところを紹介していく。（なお(P84)のような数字はページ数を示す。）
生産性の向上(P84)#
短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。
（本筋ではないが）まずこれを読んだときに手作業の自動化のためのCI/CDを整備したら短期的に生産性はあがるのでは？と思った。
が、ここでの生産性は「期間あたりのアウトプット」のことを指していて、「期間あたりのアウトカム」を指しているわけではないのかもしれないと解釈してひとまず納得した。（そもそもそんなに細かい話はしていない、またはCI/CDのような比較的すぐにできて明らかに生産性に寄与する施策はすでに実施済み、という前提はあるのかもしれない。）
なので「生産性を大きく向上させるためには長期的な投資が重要なことが多い」くらいに捉えてみる。
たしかに長期目線でチームの生産性を大きく向上させるにはチームとしての練度を向上させたり、リアーキテクティングをはじめとした技術的負債を解消したり、スキルアップを図ったりといったことが必要になることが多いように思うのでその意味では同意できる文だった。
スタートアップではリソースが限られる中で短期的にマストでやらなければいけないことをこなす必要があったりするので長期的な施策への投資バランスが本当に難しい。（とはいえ少しでも時間を見つけて長期的な施策を少しずつでも進めていくしかないか）
リスク管理(P84)#
リスクを管理することによってプロジェクトを管理せよ。
それぞれのリスクの実現する確率と予想コストを評価せよ
プロジェクトマネジメントをしていると「どう不確実性を取り扱うか」というのが難しく、かつ一番重要度が高いように感じる。
プロジェクト（以下PJと表記）を進めていると様々な不確実性によってスケジュール遅延が発生し、品質が落ちたり、計画を変更してPJ期間を延ばしたり、スコープを削ったり、あるいは人員を追加したりというアクションが必要になる。（場合によっては残業が増えたりもする）
そして何より、当初の見積もりを超過するとエンジニア当人が感じるプレッシャーが増えたりモチベーションが下がったりする。（自分だけかもしれないが）
なので可能な限り見積もりからのズレを減らしたくなる。（見積もりのズレが減って悲しい人はいないはず）
今のところは可能な限り見積もりからのズレを減らすためにはこのあたりのことを意識してみている。
- 見積もりがズレたらその原因を分析して次回以降に活かす
- そもそも見積もりという行為自体が不確実性をはらんでいることを理解する
- 不確実性を早期に削減することでPJ後半に手戻りや遅延が発生する確率を下げる
1.に関しては組織、人によってまちまちだと思うが最近自分が発見したズレの要因はこのあたり。
- （プロマネと実装を兼任する場合に）プロマネタスクのための時間を確保し忘れていた
- 設計をチームに共有するための資料等の準備時間やレビュワーからもらったフィードバックを反映する時間を見積もりに含めていなかった
特にプロマネと実装者を兼務している場合、状況が変わった際のスケジュールの組み直し、タスク実行順をどうするかの検討、ステークホルダーへの報告や相談などのプロマネタスクに意外と時間がかかることを直近のPJで学んだ。
2.への対策としては2点見積もり、3点見積もりのような手法を用いたり、見積もりをレンジで表現したりすることが考えられそう。（e.g. 「7月1日にリリースできそうです」と伝えるのではなく「7月前半にリリースできそうです」のように範囲で伝える。）
PJが進むに連れて不確実性が下がっていき、見積もりの精度も上がっていくはずなので徐々にレンジも狭くなっていくはず。なのでステークホルダーに一度伝えて終わり、というよりはチェックポイントごとに最新の見積もりを伝えるのが良さそうに思う。
3.については不確実性コーンに従って不確実性が下がっていくようにPJ初期の要件定義や設計の段階で大きな不確実性を潰しておくことが重要そう。
人材管理の智将(P94)#
プロジェクトの初期にむだにする一日も、末期にむだにする一日も等しく打撃になる。
一日をむだにする方法はいくらでもある…しかし、一日を取り戻す方法は一つもない。
真理みがある。真理過ぎてあまり書くことがない。
これを見て小学校のころのサッカーのコーチの「そのリフティングの1回はもう帰ってこないよ（だから集中して取り組もう）」という言葉を思い出した。
プレッシャーの効果(P200)#
- プレッシャーをかけても思考は速くならない。
- 一時的なプレッシャーや残業は、人びとの焦点を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。
自分もプレッシャーが大きすぎるとパフォーマンスが落ちるタイプなのでとてもわかりみがあった。
振り返ってみると特に明示的でないプレッシャーがあるとパフォーマンスが落ちやすい気がした。「xx月yy日までにリリースしたい」のようなものではなく「なんか上司から圧を感じる。今のままだとダメな気がする…」みたいな状態。要求（の理解）が明瞭ではないので目標が定まらず、辛い感じになりがち。（今思えば上司とコミュニケーションをとって明確にするのがよさそうではある）
- 残業時間を増やすのは、生産性を落とす方法である。
残業が常態化し「あとで残業すればいっか〜」というマインドになってしまうと結局日中の生産性は落ちてしまい無駄が増えてしまうので気をつけたい。
一方で昼夜問わず猛烈にコミットして成果を出しまくっている人も身の回りに複数いるので必ずしも残業が悪とまではいえない気持ちにもなっている。（あくまで今の自分がそう感じるというだけ人/時期によっては残業しないことの重要度が高まることは普通にあるとは思う）
そういえば残業の話は『世界一流エンジニアの思考法』にも書いてあったなーと思い出した。
ここでの示唆は、業務だけに自分の時間を使ってしまうと
- 学習によって自分の生産性を向上させることがしずらい
- 残業前提で成果を出すため再現性が低い
ということだと思う。残業しすぎないことで学習の時間を確保したり、開発プロセスの改善やスコープの調整によってうまく成果を出せるようにできていることが重要なのだと思う。
スタッフの人数(P259)#
- 初期に人数が多すぎると、プロジェクトは重要な設計作業を省略せざるをえない（全員に仕事を与えるため）。設計が完成する前に大勢に仕事を割り当てると、人や作業グループの間のインタフェースを最小化できない。
- このため、相互依存性が高まり、会議が増え、やり直しが増え、フラストレーションがたまる。
チームの人数が多すぎる場合、設計段階で全員にタスクをふろうとすると対象ソフトウェアへの理解が不十分な段階で人為的にソフトウェアを部分に切り分けて担当をアサインすることになる。
そのため人と人とのインターフェースが無駄に複雑化してしまい、コミュニケーションコストが増大する、ということを言っていると理解した。
そのため設計段階までは少人数で進めてタスクを切り分けられる段階まできたら人数も増やしてもよいのではないか、ということが書かれていた。
ここで得られる示唆としては
- 対象ソフトウェアへの理解が曖昧な状態では正しく切り分けることができない（マイクロサービス化にもいえそう）
- チームの人数をいたずらに増やすべきではない
というようなことかなと思った。（生産性以外にも様々な事情があるケースもあるとは思うので一概には言えないが）
まとめ#
プロジェクトマネジメントについていろいろと示唆を得られてよかった。
物語調だったので隙間時間にサクサク読みやすかった。
数冊の積読があるので年内に消化できるようにやっていきたい…。（k8s本3とかネットワークの本4とか）