プロジェクトデザイナーの役割とフレームワークの考察
プロジェクトデザイナーという職業を広めようと、自ら領域を定義してフレームワークを開発し、様々なプロジェクトに関わってきました。
プロジェクトデザイナーは何をする仕事か?
プロジェクトデザイナーはプロジェクトをデザインする。文字通りデザイナーなので「目に見えるアウトプット」が価値。
最初に考えたプロジェクトデザイナーの役割(コンセプト)
プロジェクトの初期段階で、多様な関係者間で”様々なことがズレている”とうまく行きません。そのズレを限りなく小さくする役割がプロジェクトデザイナー。
このコンセプトを常に意識してプロジェクトを進めていると、それなりにレベルアップしてくる実感があります。言葉にしたことで常に振り返りができ、いろいろと行動の補正ができるんですよね。
ただ、最近は”言葉にしていない”スキルや経験値によってプロジェクトを進めている部分が多いと自己反省。言葉を定義していないと何が正しかったのか?間違っていたのか?を正しく振り返れません。更にプロジェクトデザイナーを職種として広める企みも進まなくなります。
そんな危機感から数年ぶりに腰を据えて「言葉にしよう!」と書いたのが本日の記事となります。「言葉にできない」ことは、「考えていない」のと同じである。という言葉が強く心に刻まれています。
進化するプロジェクトデザイナー
プロジェクトデザイナーの役割は「プロジェクトの初期段階において、経営と現場の"様々なズレ"をなくす」だけじゃなかった。多数のプロジェクトに関わることで見えてきた、進化するプロジェクトデザイナー。
社長の隣に、プロジェクトデザイナーを
「社長の横に、アートディレクターを」佐々木宏さんのこのコピーは強烈だ。私にも強く響いている。
では「社長の隣に、プロジェクトデザイナーを」
何ができれば成立するのか?こんなことをもう何年も考えている。
「社長の隣に、プロジェクトデザイナーを」とは何か?
経営者は常に少ない情報で短期間での決断を迫られている。
私自身は経営者なったことはありませんが、経営企画室に所属していた経験もあり、現在は取締役が直接のオーナーである複数のプロジェクトをプロジェクトマネージャーとして動かしています。これが結構大変。また経営者の友人も結構います。
常々感じていることは「経営者は常に少ない情報で短期間での決断を迫られている」ということ。ならばこの決断を助けるのがプロジェクトデザイナーの役割ではないか。
どのプロジェクトを行うべきか?優先順位は何か?この”問い”に対して、経営者が決断することに集中してもらうアウトプットを用意する役割ではないか?
プロジェクトデザイナーのフレームワーク
暗黙知から形式知へ。「言葉にできない」ことは、「考えていない」のと同じである。という厳しい言葉を胸に秘めて、試行錯誤を繰り返しているフレームワークを言語化します。
【Step1】組織が目指している方向を理解する、外にでている情報で理解する
サイトなどに書いているミッション・ビジョン・バリューを確認し、組織の向かいたい方向、組織のありたい姿、解決したい課題を理解する。ブログ・書籍・SNSなども確認する。
【Step2】聴くことで正しく理解する
現状の組織を「正しく理解する」ためにマネジメント層、スタッフ層、職種別などいろいろな人に話を聴く。そこで働く人が何を思っているのか?
特にプロジェクトの進め方は念入りに。アイデアの出し方、会議の仕方、コミュニケーションの方法、進捗管理の方法、チーム体制、問題が起こった場合の対応方針などを聴きます。
【Step3】組織の強み/優位性を”文章と構造化モデル”で整理
"組織の強みや優位性"とはケイパビリティのこと。「企業全体の組織的能力、他社より優位な強み」のこと。ただケイパビリティという言葉がなじまない人も多いので"組織の強みや優位性"を用いています。
ケイパビリティに関してはこちらの本を参考にしています。
"組織の強みや優位性"について、マネジメント層、スタッフ層、職種別などいろいろな人たちの認識が一致するとは限りません。認識を合わせていくのは対話しかありません。
”文章と構造化モデル”をつくる目的は、対話が促進するためたたき台となることです。
メインは文章形式、構造化モデルは補完がよいのではないか?というのが最近の実感です。
文章形式にする理由
Amazonの会議の話しをヒントにしています。Amazonの会議資料は「文章(ナレーティブ)形式で書く」というルールがある。そして箇条書きやパワーポイントが禁止。
その理由は「誰でも」「いつでも」「正しくわかる」資料を書くと言うこと。もし箇条書きだと、行間を読むことで、人によって解釈の違いが生じやすい。また発表者も行間に様々な思いや考察を埋め込んで説明することが多いので、後日それらを思い出そうとしても非常に難しいからです。
以下もヒントになっています。
Amazonは資料を会議前もしくは会議時に配布される。参加者は必ずしも前もって読み込んでくることは期待されていません。なぜならば「その場で読んですぐに理解できる文章を書く」ことが資料作成の必須条件となっているからです。
忙しい経営者にとってここは非常に大事なポイントです。
構造化モデルの制作
デザインの力でどう表現すべきかは最も難しい部分です。膨大な情報を極力劣化しないように一つ一つの要素をつなぎ合わせて整理する。複雑にしないように、100%網羅することも考えず、極力シンプルに。A4で1枚から3枚程度の分量にまとめます。
構造化モデルの参考にしているのは、システム思考について書かれた「学習する組織」です。
【Step4】共通のルールに基づきプロジェクト毎の評価を行う
プロジェクトの価値を3つの評価軸で整理します。
事業インパクト
プロジェクトが実現したことによる事業への効果の大きさを評価する軸。獲得できる顧客はどの程度か?
プロジェクトが対象としているユーザーにどの程度受け入れられるか?どの程度の規模か?。
また競合が多くレッドオーシャンでも力業で刈り取れる力があれば人数は多くなる。ブルーオーシャンでもニッチすぎれば人数は少ない。プロジェクト難易度
プロジェクトを進めるための難易度はどの程度か?を評価する軸。
それぞれ3段階で評価を行います。
【Step5】プロジェクト一覧の作成と優先順位の仮案
プロジェクトを”組織の強み / 優位性をいかしているか?”を縦軸にして一覧にまとめます。
ここに”使える能力、動かせるリソース”の情報を加え優先順位(仮案)を用意します。色が付いていない部分が優先順位が高く、濃い灰色は優先順位が低い。
ケンブリッジテクノロジーパートナーズから伝授されたファンクショナリティーマトリックスを応用しています。
【Step6】プロジェクトを実行するとどう変化するのか?
Step3で作成した”現在の組織の強み/優位性"、これに起案されているプロジェクトが実行されたらどう変化するのか?をまとめます。
優先順位の高いプロジェクトごとに
「プロジェクトAは、私たちの組織のこの部分の強みをいかせる領域で、更に過去成功したプロジェクトのフレームワークを用いているため、売上げXXが見込まれ、強み/優位性は強化される」。
「プロジェクトCは、私たちの組織の課題を解決するプロジェクト。今年度の事業への影響はないが、2年後の法改正への対応を早めに着手しておきたい」。
【Step7】今やることを決断、プロジェクトを決める
どのプロジェクトを行うべきか?優先順位は何か?この”問い”に対して、「優先順位を加えたプロジェクト一覧」と、「現在の"組織の強み/優位性"を、プロジェクトが実行されるとどう変化するか?」、この2つを経営者に説明を行い、どのプロジェクトを行うべきか?優先順位は何か?の決断をしてもらいます。
まとめとして、決まったプロジェクトが実行された後の「未来の組織の強み/優位性を”文章と構造化モデル”」を整理します。
社長の隣に、プロジェクトデザイナーを
経営者は常に少ない情報で短期間での決断を迫られている。
この決断を助けるのがプロジェクトデザイナーの役割の1つではないか。
どのプロジェクトを行うべきか?優先順位は何か?この”問い”に対して、経営者が決断することに集中してもらうアウトプットを用意する役割ではないか?
2022年は経営陣とのプロジェクトがほぼ100%。言語化したこのフレームワークを実践を通して磨いていくことにしよう。
Photo by Jessy Smith on Unsplash
アレとソレを組合せてみたらコノ課題を解決できるソリューションができるよね?と言うパズルをやるような思考回路です。サポートして頂いた費用は、プロジェクト関連の書籍購入やセミナー参加の資金にします。