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

　いまamazonを見たら在庫切れでやんの、ちょっと意地悪な気分になる。

　本書のどのページにもヒントがある。PMな人も、リーダーな人も、ファシリテーターな人も、名前が違うだけで目的はいっしょ。読めば、あちこちに「それ知ってる・ジョーシキ」もしくは「言われて気づいた目からウロコ」のいずれかが埋まっていることだろう。

■シンプルにすると、本質が見える

　これをスゴい本だと感心だけでなく、かなり気に入っている。なぜなら、著者の考え方がものすごくシンプルだから。ひょっとすると、"rule#1 : Be Simple!"という標語が壁に大書きされているのかも、と思うぐらい。

　どれぐらいシンプルに考えているか、次の例で確かめてほしい。

• スケジュールを極限まで簡素化してみると、どのようなプロジェクトでも、その実施期間は、設計、実装、テスティングという3つの工程に分類できます（p.30）
• 極限までシンプルにした計画です。何を行う必要があるのか分からない場合、どうやって行うかを考えるには時期尚早なのです（p.51）

1. 何を行う必要があるのか、に答える→要求定義
2. どうやって行うのか、に答える→設計・仕様書作成
3. 実際に行う→実装

　実際のところ、上記の一つを専門的に取り上げている本が何冊も出ている。しかし、著者はそれぞれのフェーズについて深く学んだ後、全てを考え直している。だから傍目にはものすごく簡単に述べているようでいて、裏の厚みがスゴいのよ。アタリマエじゃん、というのは楽だけど、それをどれだけ基本動作としてやれているかは別物だろう。

　そうした本質的な議論が積み上げられている本として、スゴいのよ。

■正しい疑問を持つ

　ものすごく重要。何のためにプロジェクト計画を立てるのかというと、上で挙げた疑問に答えるため←これに気づいていない「プロジェクト計画書」がなんと多いことか。本質的な議論になっていないかを気づかせるために、正しい疑問はとても重要。いくつか例を引用する。

• 議論の対象となる顧客層をいくつか挙げることができるか? （例えばパッケージなら、学生、プロ、ホームユーザーとなり、業務システムなら、営業、受付、役員となる）彼らのニーズや振る舞いは、どのように違っているのか?
• 私たちは、こういったニーズを満足させ、問題の解決を行えるような、技術や専門知識を持っているのか?
• 洗い出したニーズを満足させ、問題解決を行う上で、私たちの技術や専門技術を活かすことができる、実現性のあるビジネスモデルは存在するのか? （また、利益は予測可能な期限内に投資コストを上回るか?）
• 競合他社は何を行っているのか? 彼らの戦略はどういったものであり、どのように戦っていくことができるのか?

　わたしの経験によると、たいていの場合、これらの疑問に答える時間なんてないし、予備調査もやってない。著者によると、それでもこうした疑問を振り向ける必要がるという。なぜか? その理由は2つあるという。時間がなくても、正しい疑問を呈するべきなのは、

• 優れた疑問の答えを推測するということは、何もやらないよりずっとまし。優れた疑問によって、正しい問題にエネルギーを振り向けられるようになる。推測する時間しか持ち合わせていない場合でも、正しい疑問に対する推測は、誤った疑問に対する推測よりもずっと価値があるから（←要するに、仮説思考）
• 優れた疑問に対する調査を実施していないという事実によって、リーダーやマネジメントに対して警告信号を出すことができるようになるから（←要するに、保険）

　特に2つめが響く。リプレース時に性能調査とリソースの再配分をしていなかったことがある。顧客から予測処理量が提示されていないこともあって、前とおんなじだろうと勝手に考えて見積もったのが運の尽き── 結果は恐ろしいものになった。そのシステムを使うことになる顧客層が増えていたのも関わらず、だ。同様の結果になったにせよ、優れた疑問をしていたならば、少なくとも「警告」を発することはできただろう。

■なぜビジョンが重要なのか

　メンバーが目にする仕様書やWBSよりも以前に作られている（はずの）ビジョンのドキュメントが重要。なぜなら、「なぜその作業が必要なのか」を理由付けているから。これが無いと、その作業が必要な理由を知るためのコストの方が、作業そのもののコストを上回ることになるかもしれない。あるいは、無関心の罠に陥るか。

　本書によると、

1. MRD（市場要求ドキュメント：Market Requirements Document）
2. ビジョンのドキュメント
3. 仕様書
4. 作業分割構成（WBS：Work Breakdown Structure）

　の順に計画レベル間でのフィードバックが働くという。前者が後者を裏づけ、位置づけている。言い換えると、前者をベースとして後者のドキュメントが作成される。最初のMRDはコンサルタントや営業かもしれないが、ビジョンのドキュメントを作るのはPMの役目だ。空疎で有名無実で幼稚な「このプロジェクトとの"びじょん"」は目にしたことがあるかもしれない。そのビジョンは次のどれかに当てはまっていないだろうか?

• 台所の流し台（何でも流せる）型：顧客の能力を最大限まで引き出し、作業を実行できるようにする
• 意味不明型：スケーラビリティのある、性能の高い、多様な顧客を全て満足させる戦略的知的管理ツール
• 超弱気型：最終的には、今までの方法よりも優れたものを考慮できるようになる
• 役員が言った型：役員のビジョンに沿えるよう、全てのリソースを使って実現に邁進する

　また、ビジョンは「見える化」されていなければならないという。スケッチ、モックアップ、チャート等を利用しても、どうしても最終結果をビジュアルなものにできない場合、そのビジョンそのもんが明確になっていない可能性を考えてみるべきだという。

　ビジョンなんて見たことも聞いたこともないよ、という方もいらっしゃるかと。それでも営業からでもコンサル資料でも漁ってみるといい。自分の今の作業につながっていなければ、上記のいずれかになっているかもね。