「与えられたプロジェクト」を「自らのプロジェクト」に変える、プ譜制作ワークショップ

盟友、後藤洋平さんとの共著『予定通り進まないプロジェクトの進め方』のアカデミーウィークが終了しました。
6月20日に代官山蔦屋書店で。　

6月28日に六本木アカデミーヒルズで。

ライブラリにも本を置いて頂きました。

このような場所でワークショップを開催する機会を頂いた関係者の皆様に感謝申し上げます。

後藤と前田のユニットワークショップも、香川と乾、いや位置関係でいえば、長谷部が後方のCBの間に降りてビルドアップし、柴崎が前方に残ってゲームを組み立てて日本の攻撃をオーガナイズしたように、回を重ねるごとに精度が上がって参りました。

時間にして120～180minのプログラムは、概ね以下のように構成されています。

1. 後藤さんによるプロジェクトがうまく進まないことの概説
2. 前田によるプ譜の説明
3. 参加者のみなさんによるプ譜制作ワークショップ
4. 2～3人一組になり、制作したプ譜の感想戦を実施
   （※感想戦とは、互いのプ譜について説明と質問を行う時間）
5. 制作したプ譜に対する後藤、前田からのフィードバック
6. まとめ、Q&A

後藤さんによる概説は、プロジェクトが進まない理由をプロジェクト工学の三原則や、戦争論、孫子の兵法など古今東西の叡智を範に取りながら解説していきます。
プ譜をつくる過程で、頭の中で考えていたプロジェクトの漏れ・抜けやツジツマの整合性に気づき、感想戦を行うことで自分一人では得られなかったアイデアや気づきを得る、という内容です。
（人数やテーマによって多少内容は変わります）

このワークショップに来られる方々の目的、課題は様々です。
差し支えない範囲で紹介しましょう。

• いくつかのプロジェクトに関わっているが、そのどれもが中途半端にしかやれていない。
• 上層部の肝いりで始まったプロジェクトだが、上層部が見える形でフィードバックをしてくれない。この進め方で良いのか不安。
• 新規事業のプロジェクトマネージャーを務めているが、経営者のやりたいことと、現場メンバーのやりたいことが噛み合っていない。
• ルーティンの経理業務をやっていたが、社内の業務改善プロジェクトのメンバーに選ばれてしまい、自分に何ができるのかよくわかっていない。
• 地方を舞台に、グループ横断型の新サービス開発を行っているが、地域住民の価値観や習慣を変えることが難しく、思うように進んでいない。
• ブランドのリニューアルを行い、新しいユーザーを獲得するプロジェクトにアサインされたが、誰も仕切る人がいなくてプロジェクトが進んでいない。
• 自治体の施設運営代行業務を長くやってきたが、ノウハウのない施設の代行業務を受けることになり、どのようなクオリティで業務を行っていけばいいかわからない。
• マーケティング主導で始まった顧客データの収集＆解析プロジェクトが、運用段階で現場からの強硬な反対に遭い、3ヶ月で終わる見込みが、半年経っても終わっていない。
• 本社で行っている事業を出向先のグループ会社に導入するプロジェクトを行っているが、誰一人としてその事業に関するノウハウを持っていない。一人で進めるような状態で困っている。

私たちは本書でルーティンではない仕事はすべてプロジェクトである、と定義しています。ルーティンは明日も同じことを行います。だから、カイゼン活動ができる（しなければならない）。

一方、プロジェクトは未知を含みます。未知ゆえに、ノウハウがない。評価基準がない。進め方が正しいかどうかがわからない。

なので、事例を探しにいきます。
事例には参考となりそうなマーケティング手法、KPI、新しい役職といったものや、ソリューションとして提供されている各種ツールが出てきます。しかし、事例というものは個別具体的な状況に癒着したものです。そんな事例に登場するそれらのモノゴトを、そっくりそのまま自らのケースに当て嵌めることはできません。

となると、自分たちのプロジェクトに正しい進め方などはなく、進め方も評価基準も、自分たちで決めなければなりません。
何をもってそのプロジェクトを成功とするのか。この「勝利条件」は、自らが設定する必要があります。

上図、①が勝利条件

そして、この勝利条件を最初から正しく設定することもまた難しい。最初に立てる勝利条件は、プロジェクトを進めるまではわからなかったことなどによって、間違っている可能性が高く、そのため、プロジェクトの勝利条件は更新していかなければなりません。

ワークショップで最も難しいのがこの勝利条件の設定です。

新製品の売上という定量的な表現を行う方もいれば、新製品によって変わるユーザーの価値観やライフスタイルといった定性的な表現を行う方もいます。

どちらが適切かはそのプロジェクトの内容やステージによって変わりますが、プロジェクト開始前、やスタート段階にある場合。そして、プロジェクトが行き詰っている時は、数値目標よりも、「そもそもを問う」ことをお勧めしています。

なぜ、このプロジェクトをやりたいのか。やりたかったのか。やることになっているのか。

これを自分やプロジェクトメンバーや上層部に問うことで、具体的な数値というもによって狭まっている視点を拡げることができます。

そうして、一度自分自身がプロジェクトの「そもそもを問う」ことによって、「与えられたプロジェクト」を「自らのプロジェクト」に変えていく。

プロジェクトを与えられたものから自らのものに変えられた時、人は与えられたプロジェクトの中のいくつかの項目を、制約の範囲内で変化させるとができるようになります。

プロジェクトに正しい進め方が存在しない以上、そのプロセスをどのように設計するかは本人の自由ですが、そこに事例に出てくるKPIやツールがあるとそれをそのまま使いたくなってしまいます。
そうなると、そのツールを使うこと自体が目的にすり替わってしまうことがあり、それによってプロジェクトが自らの状況とのツジツマが合わなくなってくる。これがプロジェクトという問題を与えられたもののままにしている人の陥りやすいケースです。

プロジェクトを自らのものにした人は、、当面の事態の中で、自分なりに新しいプロセスを設計してみて、それを達成するためにはどうしたらよいかと考えることができる。自分自身で設定し直したプロセスを進めていく中で、状況が含む様々な事態に対する対応が、「そういう場合はこうやればいい」という関係として見えてきます。
これをわかりやすく可視化したツールがプ譜であり、ワークショップではこの勝利条件の設定と、自身のリソースや諸施策のツジツマが合っているかどうかの体験をして頂いています。

この意味で、プロジェクトとは「こんなふうになったらいいなぁ」という願望が詰まった夢日記ではなく、そのプロセスとツジツマを描く設計行為なのです。

この他、「最悪の事態の想定シナリオ」のプ譜を書いてみることや、過去の失敗プロジェクトをプ譜にすることもプロジェクトのケーススタディとしては有益なものです。

プ譜をつくってみたいなぁと思って頂いた方は、手始めに本書をお手に取って頂き、ガッツリ体験して後藤・前田からフィードバックも受けてみたいと思って頂いた方は、コンタクト頂ければ幸いです。