計画に対する別の考え方を顧客に説明する必要がある。それは、容易なことではない。この本が、我々の手元に届く前ならば。

「えっと今日は、進捗報告のために、WBSを更新しなきゃ。」

作業がこと細かく書かれた、そのWBSを更新するために、
毎週1日は、徹夜する必要がある。そのWBSの長大さを紙に
収めることは不可能。印刷物として、顧客に提示することは
できない。
こと細かく、タスクが書かれているが、当初から、洗い出されて
いたわけではない。むしろ、徹夜の原因は、日々明らかになる
漏れているタスクを、このWBSに挿入していく作業にある。
WBSは充実していくが、肝心の、成果物が出来上がるのか
疑わしくなってくる。
計画の当初は、不透明だった、もろもろのことが明らかに
なった以上、計画を変更したいところだが、
PMOがそれに強固に反対する。
さて、この徹夜は、誰かの幸せに繋がっているのだろうか。

似たような話は、誰にでもあるのではないでしょうか。
開発の現場に、蔓延る、「計画の変更は悪」という考え方。
計画変更にディフェンシブなお客様。
それは、エンドユーザ部門より、ソフトウェア開発を取り仕切る
情報システム部門や、お客様が雇い入れた、PMOコンサルタントに
多く見られるように感じる。
これは致し方ないことなのだ。
プロジェクトだけを管理する立場と、ソフトウェアで何を作るか
考える立場が、分かれてしまっている場合に、起こりうる事態。
ソフトウェアに対するコンテキストが共有できていないために、
結果のスナップショットでしか、物事を判断できない。
拠り所とするのは、計画と進捗。その計画を変更するなんて、
拠り所を失うのと同じこと。ディフェンシブにならざるを得ない。

さて、当初計画を守り続けてさえいれば、顧客への価値の提供に
繋がるのだろうか。勿論、そうではない。
そうではない上に、誰も理解できない進捗資料を作るために
徹夜することに、どれだけの意味があるというのだろうか。

今後とも、この努力がいかに不毛であるかということと、
計画に対する別の考え方を顧客に説明する必要がある。
それは、容易なことではない。
この本が、我々の手元に届く前ならば。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

見積もりと計画づくりについての実践的な一冊。
規模の見積もり、見積もりから期間への変換、優先順位の付け方、
計画づくり、バッファコントロール(CCPM)、計画のトラッキング…。
この本は、(顧客も含めた)開発の現場にあらわれた、強力なメンター。
「秘密兵器」は伊達じゃない。

この本の最初に、良いまとめがある*1。

計画よりも計画づくりを重視する。

紙に印刷できないようなWBSではなく、壁に貼った、
かんばんと、バーンダウンチャートで、顧客とスタンドアップ
進捗ミーティングを行う日は遠くない。
この本を翻訳された、角谷さんと、安井さんのお二人に感謝します。

*1:第1章 3節