アート・オブ・プロジェクトマネジメント (その四) / Scott Berkun

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 Scott Berkun 村上 雅章 オライリー・ジャパン 2006-09-07 売り上げランキング : 2838 おすすめ平均 Amazonで詳しく見る by G-Tools

前回のエントリから、大層遅れてしまいましたが、第四回目です。いやー、ちょっと同時進行でプロジェクト続行中なものでして(w


第7章「優れた仕様書の記述」
　えーっと、ここはですね。私、実際、タイミングよいことに新規プロジェクトに携わることがあって、本当にこの本のこの章を読み直しながら、仕様書を書いていました。
　P159にある「仕様書に記述すること」のリスト、そして警句である「Visioやフローチャートとは恋に落ちない」ということを肝に銘じて作っていました。
　仕様書によって満たすべき条件とそこまでにいたるマイルストーンが決まるわけですから、書かないわけにはいきません。それでもできればシンプルにしたい。ここ数年試行錯誤の連続でしたが、今回結論から言うと、すごくシンプルに纏まりましたね。
　仕様書といっても、自分自身もしくは数人が参照するレベルですが、その場合に大変助かりましたし、作っている最中も何度も仕様書を見入っていました。
　仕様書を書くことにより、それまで洗い出していた問題点以外の問題点が見つかるときがあります(つまり細かい選択分岐を書く段階になって、あれ?あのアイデアじゃ網羅できないんじゃ？ってやつですね)。その逆もあるのですが。
　単純にページを埋めるだけの文章じゃダメですよ。というのも、実際に私が見聞したケース(流石にボカして書きますが)の話です。
　ある仕様書･･･結構多額の予算が動く仕事でした･･･というのを見ましたが、ある程度かじった自分の目から見ても支離滅裂でした。担当技術者(もしくはありがちな話ですが、技術者ではなく営業が書いてしまうケースもあります)がおそらく類似の仕様書から要所要所をもってきたのでしょう。肝心要のところには何もうたってないのです。これで仕様書なら随分と救われた話です。単なる紙の束にしか過ぎないのですから。
　無論営業担当者の言い分もあり、なまじ仕様書で肝心なところを書いてしまうと身動きが取れなくなってしまうことを恐れて、というケースもあるわけですがね。
　まぁ、上のケースは対客先ということで百歩退いてもいいですが、社内内部でこんな感じの仕様書見たときは流石にめまいがしたものです。その仕事を引き継いだ人は大変だったでしょうねー(遠い目)。


第8章「優れた意思決定の行い方」
　仕事にはルーティン・ワークと非ルーティン・ワークがあって、仕事は常にこの二つのせめぎ合いですね。システム作成やプロジェクト管理も同様です。決まりきった(つまり、手順が固定化されている)仕事のステップを管理するプロジェクトであっても。その逆、つまり、新しい未知なる仕事を管理するプロジェクトであればなおさら、何か発生する問題に対して、意思決定を行い解決する必要があります。
　この章で特に感心したのは、「何もしない」という選択肢をいれること、そして「振り返る」ということです。
　戦闘機パイロットの訓練のあとはデブリーフィングと呼ばれる訓練後検討会があります。仕事だって普通はあってしかるべきなんでしょうが、箸にも棒にもかからないチンケな報告書で済ませてませんか？　恥ずかしながら自分がいるところはそのケースです。肝心な報告書は誰も読みませんから、ナレッジとして周知徹底されることはありません。トヨタなどの一流企業はさすがにこういうナレッジなどの周知徹底が染み付いていますから、次は同じミスはしないわけです。いやはや、困った話です。少なくとも自分が携わる仕事に関しては時間のやりくりをして「しっかりと」メンバー全員を集めてデブリーフィングをしよう。と心に誓いました。今までは立ち話とかで済ませてたんですがね。