部門横断プロジェクト推進における障壁とその対応

AIやIoTを始めとしたIT技術や、5Gといった通信技術など、ビジネスにも大きく関わるデジタルシフトの要素を目にするようになってしばらく経ちました。

当社もDX Labから定期的にブログを発信していますが、様々な業種の企業が全社規模での取り組みに邁進していることがわかります。

 

読者の皆様も、新製品開発や働き方改革、DXプロジェクトに代表されるような、横断的なプロジェクトに関わった経験が少なからずあるのではないでしょうか。

その際に自部門で取り組んできた考え方・手法が通じない場面に直面し、推進に対する悩みを抱えたこともあるのではないかと思います。

 

私もこれまでお客様支援を行う中で同様の状況を見てきていますが、何かしらの障壁にぶつかり、プロジェクト推進が思うようにいかなくなってしまった場面も目にしてきました。

では、そうなってしまう原因はどこにあるのでしょうか。

今回は企業内部に原因がある場合に着目していきますが、経験則としておおよそ下記の5つに分類できると考えています。

 

☑ 横断プロジェクトの目的が浸透していない

☑ 部門ごとのメリットに落とし込めていない

☑ プロジェクトに注力できる推進体制になっていない

☑ 企業独自の風習や制度により推進が阻まれている

☑ 過去の失敗からの悪いイメージを拭えていない

 

これらの項目について細かく見ていくとともに、少しでも横断プロジェクトをスムーズに推進していく方法を考えていきたいと思います。

 

 

横断プロジェクトの目的が浸透していない

特にプロジェクトの立上げ時期に見受けられますが、プロジェクト自体の目的がメンバー内に浸透しきれていないことがあります。それなりの予算が投じられ、経営層やプロジェクトオーナーが目的を提示しているにもかかわらず、実際は主役となるメンバーたちは、よく理解しないままスタートすることはよくあります。

目的が伝わらない理由としては、説明不足の場合と、当事者が課題のレベル感に追いつけていない場合が考えられます。(また、たまに、オーナー自身が理解していなくて自分の言葉で語れないときもありますが・・・)

実際に私が関わったプロジェクトでも、立上げ時点のメンバー各員の認識のズレをずっと引きずって、次のフェーズが長期に亘ったなかでも目的が理解されないまま、結果的に意識的な濃度が下がってしまうことがありました。

 

このような障壁にどう対応するかと言うと、推進に関わるすべての方々が、それぞれの立場で継続的に目的やメッセージを発信し続けるといった、基本的なことがやはり重要です。

言い続けていると、それぞれの立場で自分自身の意識が高まってくるものです。またプロジェクトが進むにつれて、見えてくるものもあり、「あ、こういうことだったのか」となれば、腹落ち感も変わってきます。

私もPM補佐の立場で関わった案件で、毎回の定例資料にプロジェクトの目的や体制図・役割を挿入したり、新規加入メンバーに対しても都度丁寧に説明することで、理解促進に時間をかけてうまくいったことがありました。

 

 

部門ごとのメリットに落とし込めていない

ある調査によると、部門間連携において最も障害に感じるのは「部門間の方針のズレ」だと言われているようです。

メンバーは一定の目的に沿ってプロジェクトに参画しているわけですが、立場によって参画メリットは異なって然るべきです。企画・開発・法務・デザイン・営業・広報などの関係部門、さらに海外拠点やマネジメント層等のステークホルダーにおいては、業務に対する攻守の姿勢や数字への認識が全く異なることを念頭に置く必要があります。

 

これに対しては、できるだけ早期に、プロジェクトに関わる部署・部門長へ“部門ごとの視点”での参画メリットを伝達し理解を促しておくことが重要になってきます。

本プロジェクトによって、どのような顧客体験が得られるのか、どのくらいのコスト削減が見込めるのか、自社のブランディングに繋がるのか、直接的/間接的にどのくらいの収益が見込めるのか等、立場ごとのメリットに沿った表現で説明し、味方に付けておくとスムーズな動き出しが期待できます。

 

私も以前、縦割りの風土が強い企業でのプロジェクト推進支援をした際に非常に難航したことがありました。そこで、関係部署への相互メリットを軸とした働きかけを試みたのですが、どう説明してもうまくいきません。苦しんでいるときにあるお客さんがヒントをくれました。「部門のメリットといっても、一般的な話だからピンときていないのではないか?」

その言葉にはっとして、その会社のその部門のことを、その会社の言葉で伝えないと伝わらないということが分かりました。そこで、その会社独自の市場の呼び方や顧客名称を具体的に挙げて説明すると、一気に「自分ごと」になっていったことがありました。

 

 

プロジェクトに注力できる推進体制になっていない

こちらは該当プロジェクトの注力度合いにもよるため一概に検討するのは難しいですが、やはり専任でプロジェクトを進められる形がベストです。

例えば、DXにおいては、花王やNECのように専門的なチームを発足し成功を収めている企業も見受けられます。

それを取り仕切るCDOやCMO、CIO等の責任者を象徴的に設けることでも、プロジェクトの全体像を掴みやすくするきっかけにできるかもしれません。

 

それに関連して、専任ではなく現業を抱えたまま参加する人が増えてしまい、それがネックになる場合もありました。心理学的には傍観者効果と言うようですが、メンバーの数が増えすぎて責任の所在が希薄になってしまい、それに伴って推進力が無くなってしまったというものです。

その際には実際に割ける時間を確認し、それを踏まえたタスク配分をすることでボトルネックになっていた部分を解消しましたが、やはり専任のコアメンバーとサブメンバーというように、きちんと時間を使える主体的な役割を置くことが望ましいでしょう。

 

 

企業独自の風習や制度により推進が阻まれている

どこの企業にお邪魔しても言われることがあります。「うちの会社は特殊だから」・・・。むつかしい課題にぶつかったときにこの言葉が出てくるときは要注意です。

業界や企業ごとの独自の風土や決まりによって推進が阻害されるケースは本当に多いと思います。

 

実際に私が経験した例を挙げると、要件や仕様のフェーズ移行プロセスが、従来型のウォーターフォール型前提になっており、どうしてもそれを適用せざるを得ないなかで、クラウドのスパイラルな開発に着手しなくてはいけないということがありました。タイプの違う案件であるにも関わらず、しくみを優先したことで、スピード感や柔軟性を無くてしまう、といったケースです。

これは非常に難解な問題です。慣習はそう簡単には変わらないですし、社内のしくみは作った人がいてそのときはきちんと狙いをもって手順を踏んで設計をしています。しかしDXというものが「新しいものだ」ということを全社的に理解促進することで、違うことをするのだから違う考え方・プロセスになる、ということをまず啓蒙することが重要でしょう。

 

過去の失敗から悪いイメージを引きずっている

失敗を引きずるというは、一見してシンプルですが、実は非常に厄介な問題です。というのも、既にチャレンジしたにも関わらず成果を出せなかったことから、当時と環境や状況が異なっているとしても負のイメージが纏わりついて踏み出せないケースが多いためです。

 

企業におけるトラウマに近いものであることから対策が難しいのですが、正攻法としては、過去の失敗の原因が何であったか、現在との比較の上で定量的成果を説明するというものでしょう。

もしくは、これも前述のケース同様に、以前の話と今の話を「全く別の話」にすることでしょうか。なかなか、ロジカルに問題解決をしても、犯人捜しをまたやるのか、という話にしかならないので、いっそ未来志向で考え直す方が、仕事全体が前向きになり、「失敗をしない」ということよりも、「成功して成果を出す」ということに目が向いて、全体の空気が変わるでしょう。

私がご支援したプロジェクトでも、どうしても失敗体験からネガティブ発言をされる方がいました。そのときは、それはそれ、これはこれ、という舵取りに苦労した記憶があります。ずっと努力をしていくうちに、前向きな空気に変わってきたことも覚えています。

 

 

 

さて、今回は、部門横断プロジェクト推進において直面する代表的なハードルに触れてきました。

実際にプロジェクト推進を担当する方もいれば、それに参画するだけの立場の方もいらっしゃるかと思いますが、通常業務とは異なる部分と、問題とその原因を再認識頂けたかと思います。

上記に挙げたように原因は複数考えられますが、プロジェクト推進のためのボトルネックがどこにあるのか、それを解消するための効果的なアプローチは何なのか、本記事が部門横断プロジェクトの推進を効果的に進める気付きに繋がれば幸いです。

 

(参考記事)

花王株式会社「DXのために花王が実践した具体的な体制づくりと取り組み」https://www.sbbit.jp/article/bitsp/36661

NEC「DX実現に向けたデジタルプラットフォームを体系化へ」https://cloud.watch.impress.co.jp/docs/news/1217030.html

パーソルラーニング株式会社「人材開発白書」
https://li.persol-group.co.jp/images/co_creation/images/fxli_wp2013.pdf

記事を書いた人

深澤 大輝