駆け出しエンジニアはPMFの夢を見るか?

駆け出しエンジニアの記録

『熊とワルツを リスクを愉しむプロジェクト管理』を読んだ

bookplus.nikkei.com

ソフトウェア開発におけるリスク管理について書かれた本。リスクの定義からリスクを定量化をしてどう管理していくかが書かれている。この本が出版されたのが2003年、アジャイルソフトウェア開発宣言が出されたのが2001年ということを踏まえて、アジャイルという考えが今ほどは広くは受け入れらていなかった時代に書かれた本だと想像して、本書を読むと良さそう1

在職中のことではあるが、実績に基づいて見積もりを出したにも関わらず、根拠なしに半分の時間でできるでしょ?と言われ押し切られた結果2、残業前提で業務に取り組まざるを得ない状況が多々あった。納期に間に合わないこともリスクの一つなのかなと考えていたので、今更ではあるが自分に何かできることはあったのかなと思い読んでみた。

リスク管理には成熟さが求められ、ソフトウェア業界の多くがリスク管理ができていない未熟な組織が多いと本書では主張されている。13章ではソフトウェア・プロジェクトに共通のリスクが挙げられており、「内在的なスケジュールの欠陥」・「要求の増大(変更)」・「人員の離脱」・「仕様の崩壊」・「生産性の低迷」の5つがある。「内在的なスケジュールの欠陥」とは「時間と労力について予定を立てるプロセスに欠陥があるか、あるいは完全に破綻しているために生じるものである」とある。

無理なスケジュールを押し切られてしまった自分にとっては耳が痛い話であったし、ただリスク管理ができておらず未熟であることが分かってしまった。また、読み始めたきっかけの問題は自分だけで解決できる問題ではなく、組織で取り組んでいかないといけない問題であることがわかり、ボトムアップでやっていくことは難しそうだなと感じた。

一方で、「きのうの問題は今日のリスクである。」(p.71)と書いてあるように、チームの振り返りなどを使ってリスクを列挙していく作業をしておけば、組織としてリスク管理ができるくらいに成熟してきた時に、すぐに行動に移せる準備ができたのかもなと思ったりなどもした。

ひどい欠陥のあるスケジュールを約束したり、引き受けたりするマネージャーは、ろくな仕事をしていない。大事な点は、プロジェクトが予定より遅れた場合、それは開発者がきちんと仕事をしていないせいではないということだ。(p.123)

ソフトウェア開発のプロセス以外の要因が列挙されていたり、リスク発見手法が記載されており、今後プロジェクトマネジメントをしたときに、上長とのコミュニケーションに使えそうである(こういう不確定要素があるから今は断言できないとか、幅を持たせた上でしか回答できないなど。そのような情報込みで話せば、建設的な議論ができるかもしれない)。リスク発見手法やリスクの数値化などは業務の中で実践していく必要がありそうで、今回は軽めに読む形で終わらせてしまった。復職したら折に触れて読み直したいと思う本だった。


  1. 13章にあらゆるソフトウェア・プロジェクトに共通のリスクの記載がある。その1つが「要求の増大(要求の変更)」であるが、これはアジャイルの開発手法を採用すれば、リスクを軽減できているはずなので、スクラム開発している人からするとピンと来ないのかな?などと思ったりした。
  2. 下っ端のポジションだったので、反論しても聞き入れられる余地がなかった。