はじめに

前回の記事で、DXは文字どおり変革であり、抽象度が増す変革プロジェクトにおいてスコープを設定し、部門横断で推進していくことに多くの企業が苦しんでいるという旨を述べました。その中で各社もコンサルティング会社に依頼し、プロジェクトを推進される企業も多いとよく聞きます。(かくいう我々も依頼を受けるコンサルティング会社の一つなのですが)

さて、企業変革のフレームワークとしてジョン・コッターの8段階の変革プロセスが有名です。

経営陣の危機意識の高まりから変革を進め、DXのような各変革テーマが動き出し、ビジョン・戦略の策定あたりのステップからコンサルティング会社が入りながら進めていくケースが多いかと思います。

一方で我々に寄せられる悩みとして「作った枠組みが機能しない」というものが多いのもまた事実です。特に聞かれるのが、「なかなか現場に浸透しない」という悩みです。

こちらも前回の記事で書いた内容ですが、「仕組みを作ること」と「仕組みを回し続けること」には大きな隔たりがあるのがここでも見て取れます。
ここでは、なぜ仕組みを作ることと、仕組みを回し実現することに隔たりがあるのか考察していきます。

総論賛成・各論反対の壁

いろいろなプロジェクトをご一緒する中で多いケースが、各現場が作った仕組みが自分事ととらえられていない、というケースです。変革という新しいことであるために、あまりピンとこないというのが正しいのかもしれません。大枠の戦略や全体方向性にはYesとはいうものの、それが具体性を増してきた際に突如Noと言われてしまうケースをよく見受けられます。

例えば我々コンサルティングが業務の主であるマーケティングに向けた場合、プロジェクトが始まり、「デジタルマーケティングを導入して新規開拓見込みのある顧客を増やす」や「新しくシステムを導入して営業を効率化する」のような大テーマに対しては、否定をする理由がないためNoとは言われません。しかし、「営業効率の中でシステムを導入する。そして正確な営業見込みを出すために、商談ステージを明確化しそれに沿って管理をする」と、より具体性が増してくると雲行きが怪しくなってしまいます。

最終的に「売上を伸ばすために、新規の見込み顧客の対応をする。営業はこれから25%をマーケが生んだ新規顧客のフォローに費やすので営業のスタイルを変えてほしい。既存案件も最適化するために新規システムを導入する。商談管理を厳格にするために、システムへの案件情報の入力を追加し、毎月更新してほしい。加えて、顧客データ可視化のために今ある名刺を全て提出して欲しい」など、より具体的な自身や自部署への影響が明確化すると、とたんに反対の声が増え、現場の協力を得られずにそのまま頓挫してしまうケースが増えてしまいます。

ここまで極端な例は少ないにしろ、似たようなケースは多く、我々は「総論賛成・各論反対の壁」と呼んでいます。

プロジェクトチームは雪だるま式に拡張する

経営共創基盤グループ会長 冨山和彦氏の著書リーダーの「挫折力」(PHP研究所)より下記のような一説があります。

“日本の組織の行動様式はシーソーに似ている。集団の調和を重視し、空気の支配の影響下にある日本人を中心とする組織は、一定以上の人数が宗旨替えを明らかにすると、あとは付和雷同的に同調する場合が少なくない。<中略>そして最初の何人かから始まる「宗旨替え」について、一回の劇的な演説や説明で一気に考えが変わるということも日本人の場合、めったにない。長期間にわたり、念仏のように何度もささやかれ、訴えられているうちに、「情」と「理」が絡まりあいながら腹に落ちていくというプロセスを踏む場合が多い。”

少しずつ仲間を増やしていきながら、どこかでカタンと倒れる瞬間をシーソーで例えられており、我々もこの考えは日々のプロジェクトの中で大きく実感しています。

変革のビジョン・ゴールを実現するためのマスタープランはもちろん変えません。しかし、必要な各要素＝モジュールとそのアプローチに関して変更していきながらプロジェクト設計をすることが多いです。絵に描いた餅で終わらせないように、ステークホルダーに理解・納得いただきながら、実現可能なものにすり合わせしていくことが非常に重要になるためです。(合間に何度も説明会を繰り返すこともしばしばあります)。

これは、プロジェクトの初期段階では、CRMへの入力、営業ルールの変更による工数の増大など、「やらなければならないこと」は明確にわかります。一方で、その効果はすぐには出ず、組織全体にとっては良いことでも自部門に限ると良いことが無いように見えるケースもあるためです（例：営業組織にとってのパイプラインの見える化）。これらのメリットに対して、個別の現場にきちんと提示説得することが必要となり、この作業を行わないとプロジェクトは急速にスピードダウンしてしまいます。

これらを考えると、上で取り上げた8段階のプロセスの2つ目に「変革推進チームを結束」があります。プロジェクト体制図としては当初から存在するかもしれませんが、結束後にきちんと機能していくためには、段階式にステークホルダーに「真の意味で腹落ちしてもらう」必要があります。時には自部門にとっては必ずしもプラスにならない事案が出てくるかもしれません。

そんなときでも、自部門・組織を代表したプロジェクトメンバーが、所属部門に戻って説得できるだけの腹落ち、理解が必要になってきます。そのため、真の意味で自分事としてプロジェクトに参加してくれる「仲間」は徐々にしか増えていかないのが実情です。ある意味、雪だるまのように進みながら大きくなっていく、というケースが多いのです。

PoCでは結果だけでなく意義づけが重要

上でモジュールと書きましたが、例えばその内数にはSFAの導入、インサイドセールスの導入など必要性の中で様々なものが出てくるかと思います。これらをPoCという形で進めていくのが一般的なケースのように思います。

前回引用した経済産業省のレポートにも、PoCという便利な言葉の裏で、PoC地獄に陥り前に進まないという苦悩が多く見受けられ、前章のように進めながらプロジェクトを組み変えていくと同じ現象が起こってしまうことがあります。それを打開するにはどうすればよいのでしょうか。

コンサルティングの業務の中ではアウトプットという言葉がよく使われますが、アウトプットというのは実施した結果に近いイメージとなります。

一方で我々が重視しているのはアウトカム＝成果の部分です。言葉を変えると、「全体の中でPoCがどんな意義をもっているか」になるかと考えます。

新しいことを実施していく上では、失敗という結果が出てくる場合もあります。しかし別の見方をすると、「機能しないことがわかった」「情報がないことがわかった」ということもある意味では主要な成果となり得ます。変革のビジョン・ゴール・実現するためのマスタープランといった全体感の中でそのPoCの結果がどのような意義をもっているか、これを絶えずに意識し続けることが重要になるのです。

我々もPMOという形で伴走させていただきますが、四半期等の報告資料には必ずと言っていいほど、「本施策の意義」や「本四半期の取り組みの意義」というページが含まれます。関係者からの批判を恐れて、「この範囲ならPoCをやってもいいよ」という消去法で設計をしてしまうと、PoCで出たアウトカムが全体のプロジェクトの中で意義を持たなくなります。この状況はまさに経済産業省が述べている次のアクションにつながらない事例のような状況になってしまいます。

全体のまとめ

これまでの内容をまとめると、

1. 全体設計をする(ビジョン・マスタープラン等)
2. PoCで意義づけしながらステークホルダーに腹落ちさせる
3. 結果を全体設計に反映させる

というサイクルをいかに作り、そして回し続けることでプロジェクトを動かし、ゴールを達成することがポイントになってきます。昔クライアント様から「日系の製造業は仕組みと勝ちパターンができてしまえば、回すのはお手の物」という言葉をいただきましたが、まさに全社協力していかにここまで持ち込めるのかが勝負、とも言えるでしょう。

その上で、「どこから手を付けていいのだろう」と苦労されるお悩みをよく聞きます。そこで次回は第一歩となる全体設計の進め方に関しての記事を書いていこうと思います。