プロジェクトの成否はどこで分かれるのか？あるいはQCD教から離脱しませんか

プロジェクトの成功や失敗とは何だろうか？

これは僕にとって実に今更な問いだ。
会社のアイデンティティが「プロジェクトの成功請負人」というだけでなく、これまで本や講演などで幾度となく「世の中のプロジェクト成功率は驚くほど低い」「それでもプロジェクトを成功させるためには？」みたいなことを話してきたからだ。

プロジェクト成功率って低いものだよ、という話をしばしばするのは、非プロジェクト（定常業務とかルーティンワークと言ったりもする）とプロジェクトとでは、仕事の常識が全く違うからだ。これを認識しないと、そもそもスタートラインに立てない。
ごく簡単に言えば、「初めてやる難しい仕事」がプロジェクトなので、同じことを何度も繰り返す仕事（例えば毎月の給与計算や四半期ごとの決算や棚卸しなど）と同じようなスタンスで臨むととんでもないことになる。

プロジェクトの成功率が低いという話でよく引用する日経コンピュータの調査を初めとして、世間で語られるプロジェクトの成功の定義はだいたい以下のようになる。

「あらかじめ決められたQCD（Quality,Cost,Delivery＝品質、コスト、納期）のすべてを満たしてプロジェクトを実行できたら、成功とみなす」

これは日本に限らず、広く使われている定義だ。僕自身も、プロジェクトの成功失敗を気にし始めた四半世紀前から、疑問を抱かずにこの定義を使ってきた。この定義に異議を唱えている人もあまり見ない。
このブログを読んでいる人の多くも、「QCDを満たせば成功、どれかを満たせなければ失敗。当たり前でしょ」と考えていることだろう。


だが僕はこの10年くらいで、この定義を見直すべき時が来たのではないか？という疑念を持つに至った。その理由を以下でなんとか説明してみたい。


僕が違和感を持っていたとしても、「QCDを満たせば成功」というのは、成否を判定する基準としては、かなりよくできているのは間違いない。
あらかじめ決めたコストや納期を守ることは確かに大事だ。会社組織だから、予定どおりに仕事が進むことの価値は高い。
そしてコストや納期が達成されたとしても、成果がグダグダ（作ったソフトウェアがバグだらけとか、プロジェクト関係者が怒り心頭とか）であれば、意味がない。
つまり、QCDは大事、ということだ。だから反論しにくい。

ただ、なんというか、QCDを満たすかどうか、という基準は狭すぎるというか、近視眼的というか、そういう気がしているのだ。


例えば僕自身が「あのプロジェクトはうまくいったなぁ」と思い起こすプロジェクトは、QCDがある程度満足行くものなのはもちろんだが、それ以上に
・プロジェクトを通じて、顧客の組織能力が著しく向上した
・当初考えていなかった価値が、プロジェクトをやったことでもたらされた
・プロジェクトに参加したメンバー（顧客かコンサルティング会社かITベンダーか業務アウトソーサーかを問わず）がプロジェクトを通じて成長した
・メンバー個々人が後々まで思い出すような、貴重な体験になった
みたいな要素がかなり含まれている。
これらはQCDには表現されていない。（強いて言えばQの一部ではあるが、無視されていると言っても良いと思う）


こういう要素が、思っているより組織にインパクトがあるのでは？と思うようになったのは、QCDを超えた成功を達成したプロジェクトに自分が関わった経験が大きいが、別のきっかけもある。

ウチの会社ではプロジェクトが終了し、数年たったお客さんへのインタビューをすることがある。5年後とか10年後とか。
そういう時に当時プロジェクトの中心メンバーだった方々は、「あのプロジェクトはコストが予算に収まって良かった」みたいな話は語らない。

そんなことよりも、
・あの時に一緒に立ち上げたビジネスが今ではすっかり我が社の屋台骨となっている。あのプロジェクトがなかったら、ウチの会社どうなっていたんでしょうね（苦笑）
・プロジェクト立上げ合宿で議論したビジョン通りに、いま社員たちが仕事をしていますよ。議論した当時はまだ漠然としていましたが、今となってこういうことか、と。
・一元化されたデータを元にビジネスが回っています。実現して初めて、大事さを理解しました。
・グループ全体が共通の業務ルール、共通のシステムインフラに乗っていることが経営の柔軟性のベースになっています。
・プロジェクトを成功させるために手段として使っていたファシリテーション技法が組織に定着しています。
・そもそも仕事について立場を超えて意見を言い合う文化があまりなかったのですが、いまでは全く違います。
・あれ以降も変革プロジェクトをやる際は、ケンブリッジに習ったやり方でやってます
みたいなことだ。

こういった手応えの多くは、プロジェクトゴールとして掲げられていなかった。または大雑把なお題目としては挙がっていたのだが、実現して初めて、関係者が真の価値を理解したり。
これらはざっくり言えば「組織能力が著しく向上する」ということなのだが、こういった効果はプロジェクトを始める際に経営陣に約束しにくいし、絶望的に金額換算しにくい。もちろん目標としてのQCDにも表現されていない。
表現されていないが、もちろん重要だ。10年単位でその会社に大きなインパクトを残す。
つまりプロジェクトを成し遂げ、5年後10年後に振り返って初めて見えてくるプロジェクトの価値というものがあるのだ。


さらに個人レベルに目線を落とすと、「成長」が重要なキーワードになってくる。
失敗したプロジェクトではメンバーが病んでしまったり会社を辞めたりするが、成功したプロジェクトは多くのメンバーにとってブレイクスルーのきっかけになり、それ以降の仕事で大活躍しているケースが多い。（僕はこれを良質な修羅場と呼んでいる）
組織の中核メンバーの仕事の質が1段も2段も上がるのは、単なる生産性向上なんかと比べ物にならないくらいのインパクトをもたらす。（1人の生産性が30%上がってもたかが知れているが、1人のリーダーが生まれることで、30億円のビジネスが生まれることもあるだろうし、10人分の無駄な仕事をなくせるかもしれない）

これもプロジェクトゴールとして謳いにくいし、もちろん金額換算できない。
こういう10年単位での成果に比べると「あの時QCDを守れたのか？」という基準はいかにもスケールの小さな話に見えてくる（もちろん当時はQCDを守るのに必死だったのだが・・）


そもそも「予定されたQCDを守る」って、プロジェクト成否の基準になるくらい重要なのか？という、身も蓋もない論点もある。
これを言うと怒る人がいるかもしれないが、僕が気になるのは「予定された」というところだ。
つまり「あー、このプロジェクトはだいたい5億くらいかかるかなー」という場合、なんとか経営陣を説得して、10億の予算を確保するのが成功への近道ということになる。
結果として8億でシステムが完成した場合、QCDのCに関しては大成功だ。納期や品質も似たようなもので、「予定されたQCDを満たしているか否か」という基準を採用している限り、大幅にゆとりをもったスケジュールを立てて、成果をあらかじめぼんやりとしか約束しなければ、成功が見えてくる。
なんだかなぁ、と思いません？


こんなことをつらつら考えた末に、プロジェクトの成否について、新しい定義を考えてみた。

a)どんな形であれ、ゴール（システム稼働など）にたどり着けなかったプロジェクトは失敗
b)5年後くらいに振り返って、総合的に判断して、やるべきでなかったとしか言いようがないプロジェクトは失敗
c)それ以外は「概ね成功したプロジェクト」と言える
d)上記c)のうち、関係者が大幅に成長したり、組織能力が著しく向上した場合、大成功プロジェクトと言ってよい

b)は少し補足が必要かもしれない。
先に述べたように、成し遂げてしばらく経ってから組織全体へ与える影響が見えてくることが多いので「5年後くらいに振り返って」という時間軸を設定した。
そして万一QCDのどれかが達成していなかったとしても、総合的に判断して「やってよかった」と思えるならば、成功と言っちゃいませんか？という余地を残している。

例えば20年前に僕が参加し、処女作「反常識の業務改革ドキュメント」に書いた古河電工のプロジェクトは、QCDという観点からすると、褒められたものではなかった。一部のシステム機能は（予定と違って）最初の稼働に間に合わせることができなかった。そもそも古河電工本体の稼働も当初の予定には間に合っていない（代わりに関係会社の1社を最初に稼働させた）。
稼働直後は不具合が発生して関係者にご迷惑をおかけすることも多かった。

だがあのプロジェクトを失敗と言う関係者（経営者含め）は1人もいないと思う。20年経ってもというか、経ったからこそ、あのプロジェクトの価値はよりはっきりしている。
グループ全体を支える経営基盤としてしっかりしたインフラを作ることができたし（システムも未だに使い続けている）、シェアードサービスセンターは今でもグループ各社の業務を請け負っている（そのお陰でグループ各社は専門的な事務から解放されている）。そして今でも業務改善をし続けている。
つまり、価値を金額換算するのがバカバカしいほどに、グループ経営の前提となっている。


どうだろうか。
僕が掲げた基準に対しては、「5年後くらいに振り返って、総合的に判断」というのが恣意的とか測定できないという反対意見が出そうだ。だが、上記に上げたような「後から振り返ると分かる経営上の価値」や「プロジェクトに参加した組織や人々の変化」を踏まえると、機械的に判断するなんて、どうせできない。
※良いプロジェクトゴールの基準として良く言われる"測定可能"は狭い観点（つまり測定可能な価値だけを求めがち）をもたらすので、個人的には好きではない

なので「あのプロジェクトによって、総合的に会社は良くなったのか？」は最後は経営者の判断になる。そういう、一律に判定できない難しい判断をするために経営者は存在しているのだ。


さらに言えば、QCD派の人からすると、甘い定義だと思われるかもしれない。「コストや納期がオーバーして一発アウト」みたいな事にならないので。
ただし、判断の時間軸を長くしたり、成果を総合的に見れば評価が甘くなる、という訳ではない。残念ながら、世の中には期待外れのプロジェクトも多い。例えばシステムが稼働後数年たって使われなくなったら、この基準では失敗だ（いくら当初のQCDを守ったように見えていたとしても）。
もちろんコストが想定外にかかりすぎて、「成果は出ているけれども、10億かけてしまったので、どう考えても元は取れないよね」というケースもあるだろう。


ただ繰り返すが、変革プロジェクトが組織全体に与える広範囲で長期的な影響を考えると、従来のQCD観点よりもこちらの定義の方が、本質的な基準だと思う。
QCDだけを基準とするのが狭すぎる、近視眼的すぎるのだ。