#02 「ドラフトデザイン」と「プロジェクトデザイン」の定義と役割

前回、理想のゴール像の仮説をドラフトとして提示すること、物事の理想の「終わり方」を思い描くことを「ドラフトデザイン」、そしてドラフトとして描いた理想のゴール像から、現在に向かって実現の道筋をプロジェクトとして組み立てることを「プロジェクトデザイン」と定義した。
今回はこの二つの概念について、もう少し掘り下げて考えていきたい。

理想のゴールを仮構する「ドラフトデザイン」

なぜゴールが描けると、前向きなエネルギーが生まれるのだろうか？
ゴールを描き「終わり」を設定することで、そこに至るまでの見通しや道筋を具体的に描けるようになり、それが歩を前に進める力となるから、というのが前回立てた仮説だ。

「今」は時間軸にある一点であり、それだけではどの方向に対しても何のベクトルも持たない。
しかし、理想のゴール（終わり方）をもう一つの点として置くことで、二つの点がつながって線となり、そこに浮かび上がる道筋が、「今」から「ゴール」へと向かうベクトルとして生まれるのだ。

しかし、そのゴールイメージが曖昧ではゴールへ向かうベクトルも弱々しいものになってしまう。
こうなったらいいな、という漠然としたイメージを抱えたまま、具体的なアクションを起こせずにいつの間にか何年も経ってしまった、という経験に思い当たる人は少なくないはずだ。
つまり、理想の実現に向かうエネルギーを生み出すには、漠然としたイメージではなく、その手触りを感じられるくらい具体的に、強固にゴールイメージを描く必要があるのだ。

もちろん、未来がどうなるかは誰にも分からない以上、確かなことは何もないし、具体的に描いたからといって必ずしもその通りになる保証はない。
いきなりそんなまだ見たこともない先のゴールを具体的に描けと言われても、何の手がかりもない、それこそ雲をつかむような話のように感じて手が止まってしまうかもしれない。

だがそれでいいのだと思う。たとえ無根拠で荒唐無稽でも、Day1から軽率にまずは「こうなりたい、こうあってほしい」と思う未来をForecasting（先を見据えて予測）して描いてみることが何より重要だ。
仮に突っ込みどころが満載で不格好なものでも、勇気を持ってまず先に理想のゴール像を仮構して提示してみることによって、それをドラフト（叩き台）として目線合わせができる。そしてドラフトを基準に目線合わせができれば、それを土台として建設的な議論を積み重ねていけるようになる。
最初のドラフトはある種の生け贄として、議論を重ねる中で原型を留めないほどに形を変えてしまうかもしれない。でも、「叩き台をつくる人が一番偉い」とも言われるように、そのドラフトがあるからこそ、それを中心に生じる議論が熱となり、物事を推し進める力を生むのだ。

ゴール実現の道筋を描く「プロジェクトデザイン」

ドラフトを起点に生まれた熱を、実現に向かう力に変えていくには、今度は描いた未来からBackcasting（さかのぼって逆算）して実効性のあるプロジェクトに描き直す必要がある。

仮にだとしてもゴール＝終わりを設定すると、現状とのギャップを測れるようになり、それによって道筋を逆算してマイルストーンを設計し、実現に向けたプロジェクトとして立ち上げることができるようになる。

しかし、当たり前だがプロジェクトは立ち上げただけでは自動的に実現するわけではない。
プロジェクトには、独自性・有期性の他に「複数人」という特徴もあり、大抵の場合、プロジェクトには、発注者と受注者、社員と外部パートナー、上司と部下など、様々なステークホルダーが存在する。
そんな立場も思惑もバラバラな人たちが寄り集まっただけでは、物事がスムーズに進まないことは想像に難くないだろう。

そんな様々なステークホルダーからなるプロジェクトチームを率いてゴールに向かうには、何か共通の目的を中心とした「共犯関係」を作ることが重要となる。
そこで共通の目的として機能するのが、まさにこの「ドラフトした理想のゴール像」だ。思惑や重視するポイントが多少異なっていたとしても、その最後のゴールイメージさえすり合っていれば、そこに向かって建設的な議論ができるようになる。
つまり、プロジェクトマネージャーなど、プロジェクトをリードする者の最大の仕事は、その共通の目的となる「プロジェクトの北極星のようなゴール＝終わり」を示すことと言っても過言ではない。
プロジェクトマネジメントは「プロジェクト開始後に進行管理するもの」ではなく、むしろプロジェクト化する前のプロジェクトデザインから始まっているのだ。

プロジェクトの設計図としてのWBS

プロジェクトの中で、ゴールから逆算した実行プランは一般的にWBS（Work Breakdown Structure）の形で示すことが多い。
WBSと聞くとガントチャートを思い浮かべる人もいるかもしれないが、日本語に訳すと「作業分解構成図」となる通り、原義的には作業を細分化して構造化したもので、スケジュールでもありタスクリストでもある、いわば「プロジェクトの設計図」とでも呼べるものだ。
したがって、WBSなしにプロジェクトを進めるのは、地図とコンパスを持たずに山に登るようなものだと言える。まあ山によってはなくても登れないこともないだろうが、少なくとも迷ったり遭難したりするリスクは跳ね上がるだろう。

ちなみに、WBSはウォーターフォール（上流過程から下流過程へと順番に進めていく手法）で使うもので、アジャイル（小さな単位でテストを繰り返しながら進めていく手法）では使えない、という声を聞くこともあるが、そもそもゴールが明確でなければ、イテレーションの中で何を作るのか、何を検証するのかも設計できない。一つひとつのイテレーションを小さなウォーターフォールのプロジェクト、そしてその繰り返しをアジャイルと捉えて、計画を更新すること自体を計画に組み込んでおけば、十分有効に使えるはずだ。

ここまでを整理すると、「ドラフトデザイン」と「プロジェクトデザイン」はそれぞれこのようにまとめることができるだろう。

次回は、この「ドラフトデザイン」と「プロジェクトデザイン」の二つの概念がどのように相補的に作用し合うのかについて掘り下げて考えてみたい。