「アート・オブ・プロジェクトマネジメント」読書感想文（その3）

■何のための開発プロセスか?

　ソフトウェア開発のプロジェクトマネジメントの話になると、まちがいなく開発プロセスの話になる。そして、（わたしを含めて）みんな好きなんだよなー、今のプロジェクトに適用されていない開発プロセスの話をするのが。曰く、RADのメリット、XPの罠、FDDの将来性… 云々、隣の芝生はナントカというが、少なくとも今よりはマシという希望を味わいたいらしい。

　しかし、本書は個々のプロセス論に拘泥しない。「○○を知りたかったら、△△の書籍・サイトを見るべし」で済ませている（←またその参照先が秀逸なのよ）。著者自身、さまざまな開発プロセスを修得→実践に適用してきた結果、誰もが知っているこの結論に達したからだろう→「銀の弾丸なんて無い」。高価な本に載っていたとか、有名なグルが誉めていたから、という理由だけで、うまく機能しない手続きに盲従しても、最悪の結果しか生み出さないという。わたし自身何度も痛い目にあっているので、激しく同意できる。「○○が最高、他は全部カス」とのたまう某グルを思い浮かべて微笑する。

　著者は、もっと本質的な質問を自分に投げかけている→「何のための開発プロセスか?」。そして、シンプルにこう答えている→「いい仕事ができるよう、チームをサポートし、勇気づけ、手助けするものでなければならない」。そして、スケジュールに影響を与える要素を検証しながら、2章では以下の考察をしている。

• なぜスケジュール通りにすすまないのか
• スケジュールとは確率なり
• 優れた見積もりは優れた設計から生み出される
• スケジュールを機能させるためにすべきこと

　大きくうなずいたのは3つ目、わたしにも似た経験（というかテクニック）を使っているから。まず「優れた見積もりは優れた設計から生み出される」ことは自明だろう。ゴミのような仕様、意味不明な要求が書きなぐられたホワイトボードに基づいて適切な数値を見積もるよう求められた場合、アウトプットを信頼せよというほうが間違っている。ほら、アレだよ、"Garbage In, Garbage Out"というやつ。

　優れた見積もりをするための注意点は7つあげられている（p.41）が、最重要はこれだろう。

　見積もり作業に対してプログラマが消極的である場合、「君が自信を持って見積もりを出せるようになるには、私はどういった質問に答えたらいいんだろうか?」と尋ねるテクニックがあります。彼に具体的な質問を考えさせることにより、彼が感じている恐れや不安に取り組む機会を与え、問題解決の手助けをするわけです

　○○の問題に取り組んでもらうとき、「○○の解決ために、どんな質問がいいだろうか?」という質問をするのは、ものすごく使えるテクニック。「逆に（わたしに）教えて欲しい」というやつ。わたしの場合は、次のとおり。

■見積もり確度を上げる2つの質問

　より正確なスケジューリングの方法として、わたしが使う「質問」をご紹介。作業の見積もりの際、次の「質問」を自分につぶやいたり、メンバーに投げかけたりする。

1. この（暫定的な）見積もりを、もっと確度の高いものにしたい。もう一度見積もってもらうとして、どれぐらいの時間がかかるだろうか?
2. そのために必要な作業、足りない情報はあるだろうか

　ひとつ目の質問の答えが○時間だろうと△日だろうと無問題。着目するべきは、ブレ（プラスマイナス○日）の方。また、そのブレに対し、ふたつ目の質問の答えが大きく影響するなら、その見積もりを信頼するタイミングじゃないってこと。

　このとき、ブレの幅を気にかける。どれぐらいブレの範囲を狭めることができるか? によって、見積もりの確からしさを推定することができるからだ。

　例えば、2～3週間かかります、といっていたのが、14日（±2日）まで確度が上がるのか。あるいは、見積もり作業を再度行っても、たいしてブレが縮めることができないのか。「だいたい～かかります」の「だいたい」がどれぐらい正確な「だいたい」なのかを推し量るわけ。

　そして、最終的に「見積もりやってるよりは実際に作ったほうが早い」という返事が帰ってくるようなら、そこが現時点で最も確度の高い見積もりとなる。ひょっとすると、この返事は、次のような表現になるかもしれない。

　「見積もり作業に時間をかけるよりは、

• 実作業に着手したほうが、確度をあげることができる、
• 実作業からのフィードバックによって、ブレ（±2日）が変わってくる、
• 着手前に分かっている不確定要素は、すべてブレに反映してある、

だから、着手したほうが良い見積もりが得られる」

　一連の「見積もり→計画→実施」の流れだと、1回だけ見積もりになってしまう。見積もりの実施時期にもよるが、1回だけ見積もりでスケジューリングするのは危険な香りが。

　だから、わたしは、上の流れの続きで「実施（一部）→チェック→最初の見積もりへのフィードバック」を行っている。この時点でスケジューリングの差異があったのしても、確度が上がるだけだろう。仮に、一部実施により（スケジュールに影響を与える）リスクが発見できたなら、その時点で見つかったことを喜んだ上で、リスケジュールすればいい。

■スケジュールを機能させるためにするべき8つのこと

　「スケジュールとは確率なり」と喝破されている。たとえば、マイルストーンまでたどり着くために次の二つの作業があり、

　作業Aが期限内に終わらせられる確率：90％
　作業Bが期限内に終わらせられる確率：90％

であれば、確率は90％ではなく、81％になるということ。つまり、作業が積みあがれば積みあがるほど、期限内に終わらせられる確率はドンドン低くなってくる。

　じゃぁどうすればよいか? 著者は「スケジュールを機能させるためにすべきこと」で答えている（p.47）。自分のプロジェクトにあてはめて考えるといいかも。

• マイルストーンの長さはプロジェクトの不安定さに見合ったものとする
• ビジョンに対しては楽観的に、スケジュールに対しては懐疑的に
• 設計に力を注ぐ
• 追加/削除を議論するためのチェックポイントを計画しておく
• 計画の哲学をチームに伝えておく
• 問題領域におけるチームの経験を見極める
• 共同作業に対するチームの自信と経験を測る
• リスクへの取り組みは早目に行う

　あえて「お題」だけ並べてみた。立ち読みでもいいから説明を読めば、自分の経験と照らし合わせて考え始めることができるはず。