« 2006年9月24日 - 2006年9月30日 | トップページ | 2006年10月8日 - 2006年10月14日 »

「アート・オブ・プロジェクトマネジメント」読書感想文(その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)。自分のプロジェクトにあてはめて考えるといいかも。

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

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

| | コメント (0) | トラックバック (0)

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

アート・オブ・プロジェクトマネジメント これは、いわゆるHow to本ではない。プログラミングやテストと同様に、「こんなときは」→「こうする」なんて一問一答形式で答えられるような代物ではない。著者が、マイクロソフトInternet Explorerの開発プロジェクトで直面した問題と、それにどう取り組んできたかが書いてある。まさに宝の山

■PMにとっての最重要ツール

 プロジェクトは常に一度きりのもので、過去に類似プロジェクトはあっても、同じものは無い。やるたびに変化する不思議のダンジョンのようなものに、どのように取り組んでいけばよいのか ―― 誰もがブチあたるこの難題に対し、著者はとてもシンプルな方法で考える。同様に、本書を著す際に、この方法を適用している。つまり、

  1. 「重要な話題」に、焦点をあてる
  2. 「重要な順」に、実行する

 この方法・順番で本書は構成されている。重要な話題から順を追って説明されている。なんだあたりまえじゃないかというツッコミは、わたしも同意。しかし、本書ではこの方法にいたるまでずいぶん考え抜いたことが分かる。

 激しく突き詰めると、PMにとって最重要ツールは優先順位が書かれたホワイトボードだ、と言い切ってもいい。ただ、そのツールにノイズが入ったり、ツールしか見なくなったり、ツールを上手く使えなかったりすることが問題なんだろう。ちょいと飛ぶが、13章でとても重要なことを言っている。

 優先順位づけによって、ものごとが成し遂げられる。特に、あなたが「ノー」という時に、ものごとが成し遂げられる

 おっと先走りすぎた。ここでは、「PMって何なの?」という観点から書かれた1章に絞る。

■アート ―― 技芸と呼ぶ理由

 お題の「アート・オブ・プロジェクトマネジメント」から察するに、なんだかテクニカルな話なんだろうなぁ… と思っていたが、あにはからんや、想像を大幅に裏切ってくれた。「プロジェクトマネジメントは芸術である」(p.13)という理由は、プロジェクトマネージャは"適切な状況下で適切な態度をとる本能"を求められるからだという。

 その具体的な態度を、トム・ピーターズ「完璧なプロジェクトマネージャの追及」/"Pursuing the Perfect Project Manager"[参照]から引いている。


  • エゴ/非エゴ
  • 独裁/委譲
  • 曖昧さの寛容/完全性の追求
  • 口頭/文書
  • 複雑さの容認/簡潔さの支持
  • 焦り/忍耐
  • 勇気/恐れ
  • 信者/懐疑論者

 状況に応じこれらの"態度"を使い分けるのがミソで、このバランスを上手くとるには、直感や経験が必要だという。確かに。わたしなんざ「相手」によってこれらを使い分けている。気に入った相手や、(その行動を採っても)許される相手、ひどい場合はその日の気分によって態度を変えている(←これは、悪い例なのでマネしないように)。

 メンバーとの距離ではなく、状況に応じて最適な"態度"を採る、こりゃ確かに「技芸」の域だね。ただ、安心してほしいのは、こうしたバランスの取れた人材が見つかることはめったにないそうな。それでも自分の"態度"を一歩引いた観点で観察し、フィードバックすることの重要性は薄れないだろう。

■ホワイトボード地獄

 プロジェクトの極意は、優先順位リストを作成し、ひとつひとつ消していくことだ、ということは大昔どこかで聞きかじった。たぶんWBSのことを指していたんだと思う。

 そのサルマネの結果、お題の地獄に陥ったことがある。つまり、作業リスト、成果物リスト、課題リスト、バグリスト、プロセスチャートをホワイトボードに緻密に書き出し、リストに埋め尽くされた「作戦室」にこもっていたんだ。著者もInternet Explorer 4.0のプロジェクトで似たようなことをやっていたらしい。ただ、彼はわたしよりも優れたボスに恵まれていたようだ。

 最初のうちはプロジェクトが順調に進んでいたため、上司は私が何をやっているのか気付いていませんでした。しかし、私がチームよりもチェックリストとプロセスに時間を割いていることを知った時、大きな赤旗(警告サイン)を振ったのです。

 ある日、彼は私の部屋に入り、室内のすべての壁に貼られた、滑稽なほど巨大なチェックリストと表を見た後、私を座らせてドアを閉めました。そして、「スコット君、こういったものも悪くないが、君のプロジェクトってーのは君のチームそのものなんだよ。チェックリストではなくチームをマネジメントするんだ。このチェックリストがチームのマネジメントに役立つなら、それは素晴らしいことだ。しかし、君のやり方ではすぐにチェックリストのマネジメントをするために君のチームを使うことになるだろう」と言ったのです

 PMはプロセスや方法論に注力するのではなく、チームに注力するべき ── わたしを含め、プロジェクトに関わる全員に太文字でこの事実を伝えたいですな。ある開発プロセスの甲乙をケンケンゴウゴウと議論していた自分が情けない。ついでに○○という手法が一番などと放言していた自分も恥ずかしい。XPでもRUPでもagileでもwaterfallでも、何だって一緒、何のためのプロセスか? を考えなしに適用することは恐ろしい。この観点に立って、著者が根本から考えた結果は10章「メンバーの邪魔をしない方法」にある。そのうちここでも考察しよう。

| | コメント (0) | トラックバック (1)

« 2006年9月24日 - 2006年9月30日 | トップページ | 2006年10月8日 - 2006年10月14日 »