「アート・オブ・プロジェクトマネジメント」読書感想文(その4)いまamazonを見たら在庫切れでやんの、ちょっと意地悪な気分になる。本書のどのページにもヒントがある。PMな人も、リーダーな人も、ファシリテーターな人も、名前が違うだけで目的はいっしょ。読めば、あちこちに「それ知ってる・ジョーシキ」もしくは「言われて気づいた目からウロコ」のいずれかが埋まっていることだろう。■シンプルにすると、本質が見えるこれをスゴい本だと感心だけでなく、かなり気に入っている。著者の考え方がものすごくシンプルだから。Simple!"という標語が壁に大書きされているのかも、と思うぐらい。どれぐらいシンプルに考えているか、次の例で確かめてほしい。スケジュールを極限まで簡素化してみると、どのようなプロジェクトでも、その実施期間は、設計、実装、テスティングという3つの工程に分類できます(p.30)極限までシンプルにした計画です。実際のところ、上記の一つを専門的に取り上げている本が何冊も出ている。著者はそれぞれのフェーズについて深く学んだ後、全てを考え直している。傍目にはものすごく簡単に述べているようでいて、裏の厚みがスゴいのよ。アタリマエじゃん、というのは楽だけど、それをどれだけ基本動作としてやれているかは別物だろう。した本質的な議論が積み上げられている本として、スゴいのよ。■正しい疑問を持つものすごく重要。何のためにプロジェクト計画を立てるのかというと、上で挙げた疑問に答えるため←これに気づいていない「プロジェクト計画書」がなんと多いことか。本質的な議論になっていないかを気づかせるために、正しい疑問はとても重要。いくつか例を引用する。彼らの戦略はどういったものであり、どのように戦っていくことができるのか?わたしの経験によると、たいていの場合、これらの疑問に答える時間なんてないし、予備調査もやってない。著者によると、それでもこうした疑問を振り向ける必要がるという。その理由は2つあるという。優れた疑問の答えを推測するということは、何もやらないよりずっとまし。優れた疑問によって、正しい問題にエネルギーを振り向けられるようになる。推測する時間しか持ち合わせていない場合でも、正しい疑問に対する推測は、誤った疑問に対する推測よりもずっと価値があるから(←要するに、仮説思考)優れた疑問に対する調査を実施していないという事実によって、リーダーやマネジメントに対して警告信号を出すことができるようになるから(←要するに、保険)特に2つめが響く。リプレース時に性能調査とリソースの再配分をしていなかったことがある。結果は恐ろしいものになった。そのシステムを使うことになる顧客層が増えていたのも関わらず、だ。同様の結果になったにせよ、優れた疑問をしていたならば、少なくとも「警告」を発することはできただろう。■なぜビジョンが重要なのかメンバーが目にする仕様書やWBSよりも以前に作られている(はずの)ビジョンのドキュメントが重要。「なぜその作業が必要なのか」を理由付けているから。これが無いと、その作業が必要な理由を知るためのコストの方が、作業そのもののコストを上回ることになるかもしれない。Structure)の順に計画レベル間でのフィードバックが働くという。前者が後者を裏づけ、位置づけている。言い換えると、前者をベースとして後者のドキュメントが作成される。最初のMRDはコンサルタントや営業かもしれないが、ビジョンのドキュメントを作るのはPMの役目だ。空疎で有名無実で幼稚な「このプロジェクトとの"びじょん"」は目にしたことがあるかもしれない。そのビジョンは次のどれかに当てはまっていないだろうか?台所の流し台(何でも流せる)型:顧客の能力を最大限まで引き出し、作業を実行できるようにする意味不明型:スケーラビリティのある、性能の高い、多様な顧客を全て満足させる戦略的知的管理ツール超弱気型:最終的には、今までの方法よりも優れたものを考慮できるようになる役員が言った型:役員のビジョンに沿えるよう、全てのリソースを使って実現に邁進するまた、ビジョンは「見える化」されていなければならないという。スケッチ、モックアップ、チャート等を利用しても、どうしても最終結果をビジュアルなものにできない場合、そのビジョンそのもんが明確になっていない可能性を考えてみるべきだという。ビジョンなんて見たことも聞いたこともないよ、という方もいらっしゃるかと。それでも営業からでもコンサル資料でも漁ってみるといい。自分の今の作業につながっていなければ、上記のいずれかになっているかもね。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。