#14 スコープ、コスト、スケジュール、品質が描く四角形

誰だって「多く、安く、早く、いいもの」がほしい

突然だが、プロジェクトデザインはどこから始まるのだろうか？
それは、プロジェクトを開始する前の提案やプロデュースの段階に他ならない。クライアントとの最初のコミュニケーションであるこのフェーズで期待値のすれ違いや認識の齟齬を抱えたままスタートしてしまっては、いくらプロジェクト開始後に軌道修正をしようとしても正しいゴールにたどり着くことは難しいからだ。

だからこそ、この提案やプロデュースのフェーズは繊細な駆け引きと真剣な交渉の場にもなりやすく、クライアントからの要望と折り合いをつけるのに苦労するという人もいるかもしれない。

それもそうだろう。貴重な利益の中から身を削るようにして捻出した予算を、社運をかけたプロジェクトに投じるクライアントからしたら、できるだけ範囲は広く、コストは低く、スケジュールは短く、品質は高くしてほしいと思うのは当然のことだ。
逆の立場になればその気持ちは痛いほど分かるし、受ける側としても可能な限りその思いには応えたいというのが人情というものだ。

プロジェクトは「多く、安く、早く、いいもの」と真逆の営み

しかし、「多く、安く、早く、いいもの」を提供できるのは、精緻に設計されたものを大量に作ってスケールメリットを出すとか、作り込まれたマニュアルに沿って複数ラインで効率化するなどといった、ある条件を満たした一部の場合に限られる。
分かりやすく言えば、工場やチェーン店のやり方、つまり「ルーティーン化されたオペレーション」にする必要があるのだ。

ここでプロジェクトの定義を思い出してほしい。

“PMBOK®（Project Management Body of Knowledge：プロジェクトマネジメントの知識体系）において、プロジェクトは「独自のプロダクト、サービス、所産を創造するために実施される有期的な業務である」と定義されているように、プロジェクトの一つの特徴は「独自性」だ。”

#01 はじめに

そう、プロジェクトは「ルーティーン化されたオペレーション」とは真逆の営みなのだ。

毎回全く違う条件や内容のオーダーメイドのプロジェクトで、クライアントから要望されるがままに「多く、安く、早く、いいもの」を実現しようとすると、プロジェクトメンバーの誰かが（あるいは全員が）どこかで（あるいは全工程で）無理をしなければならなくなってしまうことは想像に難くない。

大前提として、健康を害するほどの無理を強要するのもされるのもアウトだが、もし仮にそうして束の間の「安く、早く、いいものを、多く」を実現できたとしても、それでは継続的に価値提供し続けることはできないし、その歪みは必ずどこかで大きなリスクとして返ってくることになる。
その結果としてプロジェクトの成功を毀損することになっては、クライアントにとっても元も子もない話だろう。

プロジェクトデザインとはトレードオフのバランスを設計すること

「ルーティーン化されたオペレーション」ではないプロジェクトでは、「多く、安く、早く、いいもの」を実現することは難しい。
それは、プロジェクトにおいて、スコープ、コスト、スケジュール、品質は、それぞれ一つを立てれば他を下げるしかないトレードオフの関係にあるからだ。

スコープは一番分かりやすいだろう。より多くの範囲を対象にしたいなら、その分コストはかさむし、スケジュールは延びる。それが無理なら、品質を落として量にリソースを割くことになる。
同様に、コストを下げたいのなら、少なくとも適切なスケジュールを確保する必要があるし、品質は優先順位を付けて妥協しないといけない部分も出てくるだろう。
スケジュールを早めたいなら、コストを積んでリソースを追加したり、拙速に目をつぶる必要が出てくるかもしれない。もちろんどちらもスコープを絞るのが一番手っ取り早い。
品質を高めたいなら、それが可能な人材や設備の確保にコストをかけ、クオリティを追求できるだけの時間を確保しなければならないし、量を絞って品質向上にリソースを投下するという選択もある。

様々な制約の中で、スコープ、コスト、スケジュール、品質という、互いに引っ張り合う4つの点を結んだ面積＝プロジェクトの成果、パフォーマンスをいかに最大化するか。
それこそがプロジェクトリーダー、プロジェクトマネージャーの腕の見せどころであり、プロジェクトデザインとはこのバランスをデザインすることと言っても過言ではない。

最も取り返しがつかないものは「時間」

ちなみに、スコープ、コスト、スケジュール、品質の中で個人的に最も重視するのはスケジュールだ。
なぜならば、極論を言えば、最悪スコープとお金は後から追加することもできるし、品質も満足いくまで作り直せばいいが、時間だけは後から取り返しがつかないからだ。

工場のラインとは異なり、ごく一部のパーツ量産やオペレーショナルな作業を除けば、デザイナーやエンジニアを2倍に増員したとしても、デザインやコーディングが2倍の速さで進むわけではない。
むしろ、前提や背景のキャッチアップ、増えたメンバー間の情報共有やチェックなどのコミュニケーションコストの増加を踏まえると、かえってスピードが遅くなることさえあり得る。

何より、#11でも言及したチームビルディング理論のタックマンモデルからも分かる通り、いいものをつくれるチームのグルーヴと心理的安全性を醸成するのにはそれなりのプロセスと時間を必要とする。

タックマンの集団発達モデル

もちろん、いわゆる火事場の馬鹿力や文化祭直前のような「祭り感」がプロジェクトをドライブさせる大きなエネルギーになることもあるが、やはりチームで試行錯誤しクリエイティブディスカバリーの探索ができる時間を取れないプロジェクトでは、必然的に到達できるトップラインも限られてしまう。
漫然と時間を浪費するのは論外だが、少なくともクライアントやユーザーと腰を据えて対話できるプロジェクト期間は確保したい。

そのためにも、単にクライアントの「多く、安く、早く、いいものを」という要望に対して、単純にNOを返すのではなく、スコープ、コスト、スケジュール、品質が描く四角形の力学と重要性を対話の中で伝えていく必要があるのだと思う。