CI（Corporate Identity）プロジェクトにおけるプロジェクトデザインの勘どころ
株式会社MIMIGURIでデザインシンキング・コンサルをやっております矢口泰介（@yatomiccafe）です。かなり久しぶりのnoteになりました。
2020年後半から、CI(Corporate Identity)プロジェクトに関わることが多くなってきました。
リモートワークを余儀なくされる中で、組織の一体感や求心力が失われている、という課題感をよく耳にします。その関係もあるかもしれませんが、CIを見直そう、という機運を見せている企業も少なくないのではないかと思います。
今回は、CIのプロジェクトを組むにあたって、プロジェクトデザインという観点から、私の経験も踏まえてその勘どころを考えてみたいと思います。
CI(Corporate Identity)プロジェクトとは
その前にまず、CIの定義ですが、CIの定義自体がなかなか難しいというところもあります。
Corporate Identity という言葉が示すとおり、CIは
・理念：哲学
・組織活動（事業活動やマーケティング活動等含め）
・シンボル：ビジュアルデザイン
など、いろいろなレイヤーで語ることができます。
CIそのものについては、あらためて書いてみたいと思いますが、そのような性格上「CIプロジェクト」というズバリの名称で呼ばれることは少なく
・理念開発
・理念浸透
・企業ロゴリニューアル
・企業ブランディング
・事業コンセプト開発
などの切り出し方をされるケースが多いのではないかと思います。
ただし現場の感覚で言うと、CIとは何か、という「厳密な言語的な定義」よりも、なぜCIプロジェクトが発生するのか、という背後の文脈を正しく掴むほうが重要な場合が多いです。
そして往々にしてCIプロジェクトは、当初に切り出された認識よりプロジェクトの裾野が大きくなる傾向があり、その意味でもプロジェクトデザインの勘どころを持っておくことは重要だと言えます。
CIプロジェクトデザインの勘どころ① プロジェクトの必要性が発生した文脈を明らかにする
CI(Corporate Identity)プロジェクトが要請される背景には、必ずその必要性を求める文脈が存在します。私の経験でいうと、昨年から今年にかけてCIプロジェクトの入り口にあったのは「組織的な要請」か「事業的な要請」でした。
1. 組織的な要請
理想の組織像との乖離／現場の求心力の低下／離職率の高さ／人数が増えて経営と心が離れてしまった・・・など
2. 事業的な要請
売上が低下している／新規事業のアイディアが上がってこない／事業部同士の連携がなくサイロ化している・・・など
CIプロジェクトがどの文脈から、何を課題感として発生しているのか、は、プロジェクトの影響範囲を考慮する上で重要です。まず、なぜこのプロジェクトをやるのか、という組織的な必要性を（関わる関係者の間だけでも）明文化することがスタート地点になり得ます。
ただし各課題は原因と結果という観点で結びついており、課題を最初から1つに絞っていくのは難しい作業になるでしょう。
CIプロジェクトデザインの勘どころ② プロジェクトのコアメンバーを設計する
CIプロジェクトは組織メンバーを幅広に巻き込んでいくものになりますが、プロジェクトを運営するためのコアメンバーが必要になります。
当初のコアメンバーは、最初に認識されたプロジェクト（理念開発や企業ロゴ開発など）に沿って組成される場合が多いと思います。多くは経営企画や人事部、社長室直結の独立チームが多いと思います。
部署の役割・ミッションとCIプロジェクトのミッションがつながってくるからだと思われますが、コアメンバーを組成するときには
1. 適切な権限
2. 適切なミッション
が必要になるでしょう。
1. 適切な権限とは
たとえCIプロジェクトが経営側の要請で始まったとしても、コアメンバーは、単に経営側のメッセンジャーやタスク処理だけをすればよいわけではなく、プロジェクトのスコープを自ら定義し、必要なリソースを調達できることが必要です。
CIプロジェクトは前述したように、当初の見立てよりもカバーするべき影響範囲が広く組織全体におよぶ傾向があり、常にプロジェクトのスコープを再設計することが必要になります。
そのとき、コアメンバーが単に経営から言われたことをやるだけの調整役になってしまうと、プロジェクトが機能しなくなってしまうか、経営側が自らプロジェクトを遂行することになってしまいます。
2. 適切なミッション
前述したように、コアメンバーはCIプロジェクトを自律的に設計し、遂行していく必要があります。そのとき「なぜ自分たちはこのプロジェクトをするのか」というプロジェクトミッションを持っていると良いでしょう。
必然的に、メンバー選定の観点においても「ミッションドリブンに動けるかどうか」という基準が入ってきそうですね。
CIプロジェクトデザインの勘どころ③ 適切なパートナーを調達する
CIプロジェクトおいて、第三者を入れるのか、自社チームだけで行なうのかは、コアメンバーに求められる最初期の意思決定項目になるでしょう。
どちらを選ぶかに正解はなく、最終的にはプロジェクトの意思決定になります。また、プロジェクトのフェーズごとにパートナーを調達する、ということも可能です。ここではそれぞれのメリット・デメリットを参考までに記載します。
自社チームだけでプロジェクトを進める場合
自社チームだけで進めるメリットは、CIプロジェクトの性格上、絶えざるプロセスの変更に対し、柔軟でいられることです。また、メンバーが自発的にプロジェクトを進めることも良い点です。
第三者とパートナーを組む場合
第三者をパートナーとして迎えるメリットは、CIプロジェクトの運営に対し外部の知見を得られること、効率的にリソースを活用できる点にあります。
ただし、プロジェクトのスコープは前述の通り、常に変わっていく傾向があり、依頼スコープの変更に柔軟に対応してもらえるかどうか、は選定の基準の一つになるでしょう。
あるいは、プロジェクト定義のプロセス、アウトプットのプロセス、組織開発のプロセスなど、プロジェクトスコープごとに依頼するという方法もあります。ただしスコープを切り出すにせよ、CIプロジェクトに対する知見を持ち、全体の文脈を理解してもらえるかは、重要な選定ポイントになるでしょう。
CIプロジェクトデザインの勘どころ④ 組織の情報流通構造からアプローチ方法を検討する
CIプロジェクトにおいては、どのようにプロジェクトを進めるかについて、いくつかの選択肢があります。これは組織文化によります。
組織文化は、組織の中で情報がどのように流通しているか、という観点から考えることができます。情報がトップダウン的に下ろされているのか、現場での意思決定が可能なように情報流通がデザインされているのか、など、組織内の情報の対称性への意識によって、プロセスが変わってくるでしょう。
その文化の良し悪しはひとまず脇におきつつ、まずどのようにプロジェクトを進めるのか、についての見取り図をつくりましょう。
1. トップダウンアプローチ
2. ボトムアップアプローチ
3. トップ／ボトムのミックスアプローチ
1. トップダウンアプローチ
CIプロジェクトを、経営側の意思決定を中心に行っていく方法です。
「大事なことは経営側で決定し、決まった内容を下ろしていく」
という組織文化が強い場合、CIプロジェクトにおいても、まずは経営とのリレーションをいかに作っていくか、という優先度が高くなります。
ただし、CIが組織的な広がりを持つ以上、メンバーとのリレーションをすべて無視できるわけではありません。
2. ボトムアップアプローチ
組織に属するメンバーの合議を重要とするアプローチです。
メンバーの少ない時期のスタートアップなど、メンバーの意見が経営と同じくらい意思決定の重要度を有するなどの場合は、メンバー巻き込みの優先度が高くなります。
この場合のネックは、意思決定の質をどう高めるか、という点になります。後述する意思決定のプロセスを同時に設計することが重要になるでしょう。
3. トップ／ボトムのミックスアプローチ
アプローチ方法を便宜的に3つに分けたものの、結局のところは多くの場合が、トップ／ボトムのミックスアプローチを取ることになるだろうと思います。
トップの意思決定は重要でありつつ、組織内に存在する無意識的な文化性を無視したコンテクストは組織に浸透しないからです。
どのように組織を巻き込み、どのように進めると組織において妥当性を得られるかについては、プロジェクト初期に組織の情報流通構造をリサーチするとよいでしょう（リサーチの方法は機会あればまとめます）。
CIプロジェクトデザインの勘どころ⑤ 意思決定プロセスをデザインする
CIプロジェクトにおいては、「理念開発」や「事業コンセプト」など、組織的な重要項目を最終的に決定する、という段階があります。
そのため、プロセスの設計の中に「誰がどのように意思決定を行なうのか」という意思決定のデザインをしておくことも重要です。
たとえボトムアップアプローチで、メンバーに幅広に意見を求めるとしても、最終的な意思決定の質は経営的な妥当性をもって担保される必要があります。
プロセスの設計と、「誰がどのように」の意思決定のデザインは、意識的に分けてしておくとよいと思われます。
CIプロジェクトデザインの勘どころ⑥ 事業やマーケティング活動と連携することをあらかじめ加味しておく
CIが理念等のレイヤーで言語化すると、「言行一致」の必要が生じます。CIとして発信していることと、外に出ている活動とが一致しているかを内外から検証される状況に置かれる、ということになります。
その観点で、CIプロジェクトにおいて、事業やマーケティングとの接続が必ず必要になります。
しかし、CIプロジェクトにおいてまず明らかにされるのが「企業理念」といった抽象度の高いアウトプットの場合、事業目標や、短期的なマーケティング活動などと、目指すタイムラインや文法が異なる場合が多いでしょう。
その場合、単に「CIに沿って事業目標を見直してくれ」という依頼では物事が進まない、ということは想像に難くないと思います。例えば事業理念の問い直し、といったまず抽象的な議論が必要になるなど、プロセスのデザインが新たに必要になります。
CIプロジェクトとは組織を問い改善し続ける運動
うすうすお気づきの通り、CIプロジェクトは何かゴールを達成すれば終わり、というものではなく、「継続するもの」になります。
同時に、CIが関わる影響範囲があまりに広いため、組織／事業の課題感はあれど、いったいどこから手を付ければいいのか・・・と途方に暮れることも多いのではないでしょうか。
CIの運動の連続性は、まるで組織を一つのプロダクトと見立て、プロダクト開発をし続けるプロジェクトのようにも見えてきます。まず高い理想を持ちつつも、できる範囲からメンバーを巻き込み、少しずつ手を付けることで、少しずつ改善していく、というものです。
MIMIGURIでは、CCM（Creative Cultivation Model）という見取り図を用い、組織の創造性を、組織-チーム-個人のレイヤーで取り戻していく、という全体的なアプローチを試みています。
CIに関しては、あくまで私の経験に基づきながらですが、今後も現場の実践知をまとめていけたらいいなと思っております。