プロジェクトを成功させる魔法？あるいはブレようのない要件定義
こんにちは。ケンブリッジという会社でコンサルタントをしている白川です。プロジェクトを楽しく成功させるために、ファシリテーションを活用するノウハウをミッチリと書いていきます。よろしくおつきあい下さい。
★タネも仕掛けもある魔法
さて、最初のテーマは「プロジェクトを成功させる魔法はあるか？」ですが。
プロジェクトを成功させる魔法なんて、あるわけないじゃないですか。のっけから申し訳ないけれど。
でも、
「充分に洗練された技術は、魔法と区別がつかない」 A.C.クラーク
という言葉もあります。
11年前、ヒヨコSEだった僕が今の会社（ケンブリッジ・テクノロジー・パートナーズ）に転職し、研修を受けたときに思ったのも「ああ、この会社にあるのは、タネも仕掛けもある魔法なんだ」ということでした。
ちなみに、ケンブリッジはお客さまと一緒に、業務やシステムの変革プロジェクトを成功させることをミッションとしたコンサルティング会社です。
一例を挙げましょう。
プロジェクトで実行する改革施策や、開発するシステム機能をリストアップする、というのはプロジェクトの計画段階ではおなじみの仕事。「プロジェクト計画書」や「要件定義書」などの形で書いたことがある方もいると思います。
この時ケンブリッジが使うタネも仕掛けもある魔法は、
「やること、作る機能だけでなく、必ずやらないことも書く」
です。それだけ。単純明快。
でも、プロジェクトの中盤戦で「あれってやるんだけ？」「このシステム機能、作るの？」「これがないと、業務が回らないよ」と、もめることはよくあります。プロジェクトをやったことがある方なら、経験ありませんか？偉い人（プロジェクト・オーナーなど）が交替したら、ひっくり返ってしまったり。
だから、
・誰かがやった方がいい、と言ったけれど、優先順位が低い施策
・のどから手が出るほど欲しいけど、コストが高いのであきらめる機能
などなどを、理由付きで「今回、これは○○の理由のためやりません」と書いておくのです。
やらないこと、作らない機能まで含めて書いてはじめて「後でもめない、やること一覧」は完成する。
こう書いていくと、難しいことは何もないですし、明日からでも出来そう。でも、実際にやっている会社は少ないように見えます（僕のお客さまで、僕らとプロジェクトをやる前からやっていた会社はありません）。
他にも、
・関係者の巻き込み方
・戻りのない会議の仕方
・お客さまとリスクをシェアし、win-winになる契約の方法
・プロジェクトの隠れたリスクを察知する方法
などなど、プロジェクトを成功させるための、ありとあらゆるノウハウが既に完成されていたように見えたのでした。
まあ、実際にプロジェクトを始めてみると「既に完成」の部分は勘違いでした。毎回プロジェクトをやる度にウンウン言いながら創意工夫し、自分達で方法論を練り上げていく必要があったのですが、それもまた良い想い出。
★もっと多くのプロジェクトがHappyに
ところで、プロジェクトの成功率は低いですよね。例えばITプロジェクトの場合、日本国内の成功率は31%（日経コンピュータ2008年12月1日号より）。
これまでやったことのない、1回きりのチャレンジがプロジェクト。だから難しいのは当たり前。
プロジェクトに参加するメンバーも、疲れ切ってなんとかゴールにたどり着いたり、着かなかったり。プロジェクトに参加することは、必ずしも個人としてHappyなことではありません。
幸いにしてケンブリッジが関わるプロジェクトはほとんどが成功しています（成功率95.6%。成功の定義は、米国Standish Groupに準拠）。しかし、僕らがタッチできるプロジェクトは世の中のプロジェクトのうち、ごく一部。
「プロジェクトは失敗する」「プロジェクトはツライ」「プロジェクトマネージャーは損な役回り」といった、世のプロジェクトのスタンダードを変えたい。
これが僕らの大それた野望です。
そのために、僕らのノウハウをもっとOpenにしたい。ただし、こういった方法論は、教科書的にまとめるのが難しいものです。というのも「どういうタイミングでどの方法論を使うのか」というのが、一番難しい暗黙知だから。
そこで、第1弾として「本当にあったプロジェクトの体験談を赤裸々に書くことで伝えよう」と意気込み、一緒にプロジェクトをやった、クライアントの古河電工関さんと「プロジェクトファシリテーション ～クライアントとコンサルタントの幸福な物語」を2009年8月に出版しました。
このブログでは、この本↑に書ききれなかった方法論や、書いたけど説明不足だったノウハウ（実録ストーリーなので、あんまり方法論についてくどくど書くわけにもいかず・・）について、1回1テーマで書いていこうと思います。
僕が普段関わっているのは、大企業（1,000人～50,000人程度）の業務改革プロジェクトやシステム構築プロジェクトですので、そういった舞台で起こることに触れていくことになると思います。
僕は「お客さまの参謀としてのコンサルタント」ですので、ベンダーとしてプロジェクトに関わる目線よりは、プロジェクトの実行主体（お客さま）の目線での記述が多くなるでしょう。
取り上げる事例の背景など、わかりづらいことのご指摘や、疑問など、コメントいただけると嬉しいです。