ロフトワーク流、熱意と生産性を引き出すプロジェクトコミュニケーション術

ロフトワークは、世界標準のプロジェクトマネジメントの知識体系「PMBOK（ピンボック）」を導入し、プロジェクト実施のフレームワークづくりやリスクの軽減などに努めてきました。（Webの制作現場でも使えるような内容にまとめ2008年に出版した書籍『Webプロジェクトマネジメント標準』は現在全文無料ダウンロードできます）
そして現在のロフトワークでは、大小含めて年間約500件のプロジェクトが日々進められています。

プロジェクトの「ブレークスルー」や「新しい価値」は、それに関わるメンバーの知的好奇心と熱意によって引き出されるもので、それこそがプロジェクトの成否を決めると行っても過言では無いはず。
でも、そのための手法はPMBOKには書かれていないし、あまり言語化もされていない領域だと思います。
そこでこの記事では、ロフトワークのシニアディレクターの重松と、PMPホルダーでもあるディレクターの入谷のから聞いた知見をもとに、「プロジェクトマネジメントを行なう人（プロジェクトマネージャー）、またはプロジェクトを発注する立場の人」に向けて、さまざまな有形・無形の「新しい価値」を生み出すプロジェクトを多く手がけてきたロフトワークならではの、メンバー間のコミュニケーションをもっとうまくやる方法、プロジェクトをもっと楽しくデザインする方法のヒントをお伝えしていきます。

キックオフミーティング時からプロジェクトマネジメント計画書を用意するパターン

キックオフミーティング時に、すでに下記のような要件をまとめたプロジェクトマネジメント計画書（以下、PM計画書）を作り、その内容を確認しながらプロジェクトメンバーとの理解を深めていく方法があります。プロジェクトマネジメント計画書（PM計画書）とは、簡単に説明すれば「このプロジェクトは、こんなゴールでこんなメンバーでこんな感じで管理していきます」という計画を定義する資料です。このパターンはWebサイトの要件がはっきりしているなど、アウトプットが明確なものが適しています。

入谷が実際に作成したプロジェクトマネジメント計画書 （どんなドキュメントなのか想像できる程度の解像度です）

PM計画書は、プロジェクトのスコープや制約条件、ステークホルダー等をお互いに確認するのに良いフォーマットで、だいたい次のような内容を含めます。

• プロジェクトの背景・目的
• ターゲットユーザー
• プロジェクト前提条件
• プロジェクトスコープ（作業範囲）
• 品質計画（対象ブラウザなど）
• コスト
• スケジュール
• ステークホルダー
• コミュニケーション計画（コミュニケーションルールや、使用するコミュニケーションツールなど）

初対面の相手と「ここまでわかっているんですがこれで合っていますか？」「そうですね、でもここはこうですね」というのを確認しながら、抑えておかなきゃいけない要件を順番に確認していくのに非常な有用なツールとして使うことができます。
このPM計画書をベースに要件をヒアリングをした上で、さらにコミュニケーションして互いのプロジェクト理解を深めていきます。
最初からオフィシャル感あるドキュメントを使って必要事項を確認していくことで、確認事項を抜け漏れなく確認できる、話が脱線しにくい、そして同時にPM計画書もだいたい出来上がってしまって、非常に効果的です。

キックオフミーティングからスケジュールをひいてワイヤーフレームまでつくるパターン（期間が短いとき）

特にプロジェクト期間が短いプロジェクトでは、最初からキックオフミーティングの時間を半日とり、その場でお客さんと一緒にWBS（Work Breakdown Structure：作業分解構成図）をつくりながらスケジュールまで落とし込み、さらにワイヤーフレームの制作も行い重要なコンテンツの優先順位付けまで行う場合もあります。このパターンは、特にクライアントの確認時間が確保しにくいときに、スタートダッシュでプロジェクトのアウトプットを形にしながら一緒に作れることがポイントです。
ちなみにロフトワークでWBS・スケジュールを作成する場合は、ほとんどのメンバーがSmartSheetを用いています。

コンセプトマップ作成のワークショップは、キックオフミーティングの次のステップなどプロジェクトの初期に行うケース、かつチームビルディングのために行うことが多く、ロフトワークのプロジェクトでも「やって良かった」とクライアントからも毎回高評価です。

コンセプトマップとは、デザインとして視覚化される前の段階で言葉で共通認識をあわせるのに有用なツールで、これを作ることでプロジェクトメンバーがユーザーに提供する価値・体験・印象を言語化し、その関係性を視覚化できる効果があります。
例えば一口に「かっこいいデザイン」といっても人によってとらえ方は異なります。その解釈を合わせることができるだけでも、後のプロジェクトコミュニケーションを円滑にすることができますし、そこで可視化されたメンバーの「思考の癖」は、プロジェクトマネージャーにとっても有益な情報となります。
（ちなみに、コンセプトマップは、デザインコンセプトとは異なるものです）

準備：テーマを決める、テーマに沿った「モノ」を用意する

まずはテーマを決めます。テーマは「かっこいいデザイン」のように抽象度の高いものでも構いません。プロジェクトにおいて何を作ろうとしているのかをテーマとすると良いでしょう。そして、テーマに沿った「モノ」を持ってくるようにチームメンバーに頼みましょう。もし「かっこいいデザイン」がテーマであれば、各自がかっこいいと思うデザインのモノをミーティングに実際に持ってきてもらうように依頼します。モノの数は１人あたり２つくらいが丁度良いです。「モノ」があったほうが触れるしその良さが理解できます。お互い理解することがワークの目的なので、できるだけもってきてもらうようにしましょう。

WORKSHOP1.ワークシートに記載する

メンバーが集まり、ワークシートにそれぞれが「自分が考えるテーマに沿ったモノ」「そのモノを使いたくなる理由」「使うことによって起こる感情や行動の変化」を記載します。ワークシートに記載する時間は１シートあたり５分程度です。

WORKSHOP2.それぞれ発表し、それをポストイットに書き出す

チームメンバーが1人1人順番に、上記で書き出した内容を発表していきます。同時にファシリテーター役の人（多くの場合はプロジェクトマネージャーが兼任します）が、発表の際に出てきた言葉をキーワードとして次々とポストイットに書き溜めておきます。１回の発表にあたり５枚以上のキーワードがポストイットに書けると充分です。
発表は1人2回行います。例えば6人のチームで1人2回発表があり、毎回の発表で５枚以上のキーワードがポストイットに書き留められた場合、発表後のキーワードポストイットの数は60枚以上となります。

WORKSHOP3.ポストイットを整理する

チームメンバー全員が発表を終えたら、ファシリテーターが書き溜めたポストイットを整理していきます。近い意味のキーワード同士でグループを作り、グループ名をつけていきます。１つのグループのポストイットは５〜７枚程度が目安となります。

WORKSHOP4.整理した内容を「原因と結果」に分けていく

60枚のキーワードポストイットがある場合、グループの数はおそらく10前後になるでしょう。次は10のグループを「原因と結果」に分けていきます。模造紙を用意し中心に縦線を引きます。模造紙に左側のエリアと右側のエリアを作りましょう。そして左側のエリアに大きく「原因」、右側のエリアに大きく「結果」と書きます。10あるキーワードグループの中でも「原因」となりえるキーワード群を左側のエリアに、「結果」となりえるキーワード群を右側のエリアに配置していきます。例えばキーワードグループに「作り手のこだわりが感じられる」「個性が際立つ」などのグループ名がある場合、「作り手のこだわりが感じられる」から「個性が際立つ」という因果関係が見られます。その場合は「作り手のこだわりが感じられる」を左側の原因エリアに、「個性が際立つ」を右側の結果エリアに配置してください。

WORKSHOP5.さらに整理していく

大きく「原因と結果」に分けることができたら細かく整理をしていきます。左側の原因エリアと右側の結果エリアのそれぞれの中心に縦線を追加します。模造紙上に合計で縦線が３つ並んでいる状態です。原因エリアの中でも「より気軽な原因」を左端に、結果エリアの中でも「より本質的な結果」を右端に整理していきます。私たちのこれまでの経験上、多くの場合、左端（より気軽な原因）には「見た目が好き」「持った感じが丁度良い」など初回のタッチポイントにおける印象がきます。そして右端（より本質的な結果）には「自己肯定感が増す」「前向きな気持ちになる」など、個人の気持ちに影響を及ぼすものが多くなります。

WORKSHOP6.「つながり」を示していく

最後の作業です。それぞれのグループのつながりを示す線を模造紙上に書いていきます。左側にある原因がどのように右側の結果につながるのか。関係性を示す線を書いていきます。関係性の線が模造紙上に書ければ、後はそれを清書したものがコンセプトマップとなります。

ワークショップは、プロジェクトメンバーの意思をまとめて合意形成を導く有用な手段です。「プロジェクトに関わるメンバーを一同に集めて、集中的に議論し物事を決める場と時間」の設計や呼称は「ワークショップ」でも「合宿」でも良いですし、昨今ではGoogleが提唱する、デザイン上の問題を解決するために、高速にプロトタイピングと検証を行う方法論（フレームワーク）である「デザインスプリント※」が注目を集めています。

とにかく意思決定者が参加し決定できる場になれば、その方法が「ワークショップ」でも「合宿」でも、「デザインスプリント」でもなんでも構わないのです。仮にデザインスプリントに必要な5日間（40時間）意思決定者を拘束することができれば、ほとんどのことはそこで決めることができると言っても過言ではありません。

いかに、そのワークショップ（またはデザインスプリント、または合宿）が、プロジェクトにおける重要なプロセスであり、その場にいないとプロジェクトの重要な決定事項が決まらない（もしくは勝手に決まってしまう）というような「舞台」をつくり、いかに意思決定者を拘束することができるか。とにかく重要なのはその場に意思決定者を必ず巻き込むことで、いわゆるステークホルダーマネージメントの一環であるとも言えます。

※デザインスプリントとは、デザイン思考とハッカーの考え方をうまく組み合わせたワークショップ手法で、5日間という短時間でプロトタイプ作成から顧客インタビューまでを行う短距離走（スプリント）を行い、そのスプリントを何度も回すことにより、迅速にプロダクトやサービスの問題を改善していくというものです。

ロフトワークのとあるプロジェクトで行われたワークショップ資料の一部です。不満（＝課題）を出し合い、それに対しての解決方法を考えるなど、どんなユーザ向けに、どんなニーズ を満たすためには、どんなサービスカテゴリがあるかを一緒に考えて、共有しました。

ワークショップのほか、インタビューという形でステークホルダーの時間をしっかり抑えじっくり話を聞くという方法もロフトワークではプロジェクトの有効なプロセスであると考えています。

各ステークホルダーに対しそれぞれインタビューを行ない、その後インタビュー内容をまとめながらインサイトの発見を行うプロセスは時間もリソースもかかるし大変です。だけどやればやるほどの意味があります。サイトリニューアルのプロジェクトならば、関係者1人1人に、どんな目的でサイトをリニューアルしたいのか、どんなコンテンツが欲しいと思っているのか、どう運用していきたいか…といったことを、個別にインタビューを重ねていくことで、誰が何を考えているのかが明確になる上に、ステークホルダーとの関係性もより強くすることができます。
そしてインタビュー内容をまとめ報告書として提出しておしまいにするだけではなく、インタビューのあとに「プロトタイプ」をアウトプットし続けるという方法がおすすめです。
たとえばウェブサイトやアプリを作る場合の典型的なプロトタイプの形は「ワイヤーフレーム」。手書きでもアプリなどで作ったものでも良いですが、画面に配置する要素、情報構成、見出しなどを、ワイヤーフレーム上に配置し、インタビュー後、できるだけすぐにそのステークホルダーに確認していきます。画面構成に仮置きした言葉や、情報のまとめ方などが「目に見える」形になることで、議論が建設的に進み、気づいていなかった誤認識の発見にも繋がります。

大事なことはそのプロトタイプが「間違っているかも」というリスクを承知で、少し踏み込んだ「つくるプロセス」にどんどん踏み込んでいくということです。せっかく作ったプロトタイプも、間違っている可能性もあるし「やぶへび」で怒られることだってあるかもしれません。それでも、要求をあいまいに受け取っていた結果、プロジェクトの終盤になって「やっぱり全然違う」となっては手遅れです。

プロジェクトのごく初期に行う徹底したインタビュー・ヒアリングを行い、早い段階でプロトタイプを見せて失敗するなら失敗し、早い段階でコンフリクト（衝突）を生み出し、それを解決してプロジェクト計画を正しい軌道に乗せるのが、プロジェクト成功の秘訣です。

またステークホルダーのインタビューを重ねた上でプロトタイプをブラッシュアップしていけば「（社内の重要人物である）◎◎さんの意見を反映している」のか、そうでないのかで、提案の説得力が格段に変わります。

上記のコミュニケーション手法はあくまで一例で、全てがロフトワークで行われる標準パターンというわけではありません。プロジェクトの数だけコミュニケーション手法が存在します。（そして毎回試行錯誤を繰り返しています）

しかし通して言えることは、そのプロジェクトの目的は何か、成果物は何か、ユーザーへどのような体験を提供したいのかといったプロジェクトの「意義」を詰めていくことは当然大切ですが、チームメンバーの考え方や、視点、文化を確認し合って、意識を合わせることも絶対に怠ってはいけません。特にキックオフミーティングでは、最初から答えを決めるのではなく、プロジェクトが向かうべき方向性を決めることを大事にし、そしてメンバー全員が同じ方向を目指すこと。それが良いチームを作るためのスタート地点になります。

そして、プロジェクトには、毎回外部のクリエイターや有識者を入れるのもロフトワーク流です。もともとロフトワークはディレクター集団で、社内には手を動かすインハウスデザイナーやエンジニアはいません。プロジェクトに合わせて、デザイナーやイラストレーター、建築家、エンジニア…など、適材適所なメンバーを集め最適なチームを組成しています。

「発注側（クライアント）」「受注側（ロフトワーク）」という関係性に、外部性をもたらすことは特定のバイアスを外すことにつながり、その結果として新しい価値を発見しやすくなります。言い換えれば外部性をもたすことで、「クライアントのためのデザイン」ではなく「ユーザーのためのデザイン」を考えることができます。これは、ユーザー視点の「体験のデザイン」を一緒に創っていく上で、重要なファクター。

外部のクリエイターもクライアントもロフトワークも、受発注の関係性を超えて「戦友」になることで、コミュニケーションが良くなりプロジェクトチームとしての一体感が生まれ、結果として良いプロジェクトにつながります。