技術系の組織改革に技術コンサルタントを使ってもうまく行かない？！
最先端の知見、他社や他業界などの知見、特定分野の専門性などを期待して技術コンサルタントを依頼したことがあるが、良い成果には結びつかなかった。良いコンサルタントを選べていないのか、あるいは使い方に問題があるのか、成果に結びつく方法を知りたい。
コンサルを必要とする企業には、必要とする理由、背景があるはずですが、せっかくお金を払ってコンサルを使うわけですから、払ったお金以上の成果を勝ち取っていただきたいと思っています。
もちろん能力不足のコンサルを選べば期待した成果は得られませんし、また、能力のあるコンサルを選んでいても、企業側の問題で成果を出せないケースも散見されます。
企業側の責任者としての経験、及び自身でコンサルタントビジネスをやってきた長年の経験から、企業とコンサルがWin-winとなって企業が大きな成果を挙げるためのコンサルタントの選び方、活用方法をお伝えします。
本記事の内容
コンサル活用で失敗するケース
コンサルタントを使う目的というのは企業によってマチマチではあるものの、究極的には収益が改善する、収益状況が良い方向に向かうということが達成されることが企業側にとっての成功ということだと思います。
組織単位でみると、究極の目的を意識しながら組織ごとの中間目的を設定する場合もあります。
いずれの場合も、目的を達成できなければコンサルを使った意味がなくなり、失敗ということになってしまいます。
まずは、ありがちな失敗のパターンを見ていきたいと思います。
期待値ギャップを残したまま進めるケース
意外に多いのが、企業側の期待値をコンサル側がきちんと把握できていないケースです。
コンサル側の責任が大きいとは思いますが、企業側もプロジェクト開始前にゴールをしっかりと設定せずに雰囲気的な合意だけで進めてしまうケースがあります。
プロジェクトマネージメントの知識体系であるPMBOK（Project Management Body of Knowledge）などを修得しているコンサルティング会社やコンサルタントであれば、プロジェクト開始前にSOW（Statement of Work）というドキュメントにプロジェクトの定義をしっかりと文書化して、双方が合意の上でプロジェクトを始めるのですが、こういう事前の文書確認をせずに進めることで、企業側の期待値とずれたプロジェクト進行をしていって、プロジェクトが進んだ段階でこんなはずではなかった、ということが発生するケースがあります。
なかにはSOWを取り交わしているのに、企業側がSOWをしっかりと読まないで、誤解を残したまま進めるケースがあります。
欧米系企業（コンサルファームなど）は、この辺はしっかりとしているのですが、以前、米系企業に在籍していたときに経験したのは、コンサル側がしっかりとSOWを書いて（英語で）日本企業に提示し、企業側もそれにサインしているのに、結局は企業側がSOWをしっかりと理解していなくて（読んでなくて）プロジェクト終盤でトラブルになることがあります。
アメリカは契約文化が強いとも言われますが、SOWにはプロジェクトの範囲が明確に記載されます。特にコンサル側がやらないこと、つまりプロジェクトの範囲外であることは、非常に丁寧に記載します。なので通常、SOWは後で文句が言えないくらいの文書になっています。
双方の誤解を防ぐためには、プロジェクト開始前にプロジェクトの定義（例えばSOW）やゴール設定について双方で深く議論すべきなのですが、日本人的な”やりながら考えましょう”というスタンスが失敗につながることがあります。
上記の例はコンサル側がきちんとプロジェクトの定義を文書化しているケースですが、コンサル側がプロジェクト定義をおろそかにするケースもあります。
契約前の段階でコンサル側からの良いことばかりの話を聞いて、双方で理解したようなつもりでプロジェクトを始めてしまうケースです。
コンサル側の資質の問題でもありますが、企業側もコンサルを使って失敗しないための防衛策として、しっかりとプロジェクトの定義、あるいはゴール設定をする必要があります。
現場任せ、コンサル任せにしてしまうケース
特に階層の深い大企業で起こりやすいのは、改革活動を現場とコンサルタント任せにしてトップマネージメントや中間マネージャーが傍観者になってしまい成功を勝ち取れないケースがあります。
高いお金を払って依頼しているのだから、成果を出すのはコンサルの責任という考えかもしれません。
確かにコンサル側には企業を成功に導く責任はありますが、会社を変革させるわけですから、現場の一部とコンサルだけで一生懸命にやっても、トップや中間マネージャーの協力がなければ本当の成果には繋がりません。
企業の改革は、組織戦略として取り組むべきで、企業側のトップダウンの施策として組織全体を動かして初めて成果に繋がっていくのです。
良くある例としては、中間マネージャーが既存事業のオペレーションでアップアップ状態になっていて、トップから改革を進めるように指示があると、若手の改革チームを作ってコンサルタントに改革の進捗を丸投げしてしまうケースです。
改革チームは、組織の問題を分析し、世の中の成功事例を学び、自社の改革プランを立てて士気が上がるのですが、組織全体が既存事業を守ることを第一優先としてしまい、かつ折角、改革チームで立てたプランの実行が中間マネージャーより上に繋がっていかずに、計画が実行されないままになってしまうケースです。
コンサルを入れた組織改革は、トップレベルとコンサルタントとの相互のコミットメント、トップの支援の下での中間マネージャーの役割、そして現場のモチベーションと行動力の3点セットで進めていただきたいと思います。
フレームワークや手法に頼り本質を見ないコンサルティング
一つの手法やフレームワークを前面に出しているコンサル会社で時々あるのは、手法やフレームワークを実行することだけを指導してお終いにするコンサルです。
あくまでも手法を教えることがコンサルの役割であって、実践するのは企業側という考え方です。
最初に挙げた期待値ギャップにもつながるのですが、最初の段階でプロジェクトの定義やゴール設定とともに、双方の役割と責任を明確化していないために、こんなはずではなかった、ということが起きることがあります。
大手のコンサル会社を批判するつもりは全くないのですが、規模の大きな会社には多数のコンサルタントがいます。
多くのコンサルタントがいれば、人の資質にはバラつきがあるのは当然ですね。
しかし、コンサル会社としてはクライアントに対する貢献で、コンサルの人による差は出したくないわけです。
そうすると、人によって差が出ないように、コンサルの進め方を標準化します。要するに型にはめようとします。
フレームワークが固定化され、フレームワークによって導かれる結果に大きく依存しようとして、コンサルタントによっては現場の事情よりも型にはめていくことを優先してしまう場合が見受けられます。
企業が独自で改革を進める場合でも、手法や成功事例として組織の形態、プロセスをそのまま展開するなど、形に拘り過ぎて失敗するケースがたくさんあります。
組織問題や課題の本質を見ないで、成功例を単純に当てはめてしまうケースなのですが、コンサルが入っても同じようなことをやってしまう場合があります。
自社の課題を捉えた自社独自の改革を進めるためには、手法やフレームワークの本質と現場の真の課題の両方をしっかりと捉えなければなりません。
改革を実践できないコンサルタント
企業にとって、コンサルタントの資質を見抜くことは最も重要なことですね。
上記に示した失敗するケースも、コンサルタントが優秀であれば防げるものもあります。もちろん、企業側でやるべきことをやった上での話ではあります。
人というのは印象が大事ではありますが、よく言われるのは口のうまい人なので信用したけど、結果が付いてこなかったということです。
ある意味、人を指導したり、ヒントを与える仕事なので、口がうまくないとコミュニケーション力でいい仕事が出来ないことになりますが、口はうまいけど中身がない人というのも中にはいるものです。
美辞麗句には気をつけたいものです。
コンサルタントも人間ですから、長い経験の中で成功体験だけでなく、失敗したりうまく行かなかったりした経験もあるはずです。
失敗から学んできたことも必ずその人の知恵になっていると思います。
理論を実践に変えて現場で本当の成功をつかみ取るためには、失敗から学んだ経験の方が役に立つ場合もあります。
失敗やうまく行かなかった経験は、理論と現実とのギャップに原因がある場合が多いからです。
優秀なコンサルタントは、現場実践が出来る人であって、現場実践で成功できる人は、成功体験だけでなく適度な失敗経験も持っているのだと思います。
技術コンサルで成功する条件
成功の定義、ゴール設定
技術コンサルに何かを託すということは、自分では解決できない悩みがあるからです。
どんな悩みがあるかは千差万別ではあるものの、究極的には収益が伸び悩んでいるという悩みが根本にあると思います。
どんな改革を進めるにしても、収益の改善につながらないものは、部分最適で終わってしまうというのが最初のメッセージです。
さらに、収益改善に繋げる組織ごとの課題解決に対しても、コンサルとの共同プロジェクトとしてのゴール設定が必要です。
失敗するケースの一番目で示したように、企業側とコンサル側とで期待値ギャップが生じないように、プロジェクト開始前に入念にゴールを確認します。
SOW（Statememnt of Work）などで文書化することが本来は望ましいです。
SOWの項目例
- プロジェクトの背景・目的
- プロジェクト実行の基本方針
- プロジェクトの範囲（Scope）
- 成果物の定義
- 成果物の受け入れ基準（＝成功基準）
- 除外項目（やらないこと）
- スケジュール
- 双方の役割と責任（リソース情報含む）
- 問題発生時のコミュニケーション・パス
文書としての完璧を目指す必要はありませんが、出来るだけプロジェクト前に双方で合意しておきたいことです。
特に成果物の定義と受け入れ基準（＝成功基準）は非常に重要です。プロジェクトの目的と合わせてODSC（Objective、Deliverables、Sucess Criteria）などと言われ、この３つだけでも最低限は定義しておくと、相互の期待値ギャップなどが生まれにくくなります。
トップと中間マネージャーの介入
コンサルが優秀でも、企業側のマネージメントが積極的に介入しなければ改革プロジェクトは成功しません。
トップの強い支援、中間マネージャーによる組織全体への拡散、現場の高いモチベーションの３つが揃うことでプロジェクトは成功確率を飛躍的に高めます。
弊社が推奨しているプロジェクト実行中の体制は、
- ステアリング会議の設定・・・トップとの進捗確認と施策展開、PDCA
- 中間マネージャー層への教育・・・組織への展開方法の周知
- 現場改革チーム活動・・・若手中心の改革チーム
３つを並行して走らせることで、組織全体の改革を進めます。
優秀なコンサルタントを見分ける
最も重要で最も難しいことかもしれませんが、改革プロジェクトを成功させるためには優秀なコンサルタントを採用したいものです。
優秀かどうかの見分け方ですが、かなり私見が入りますが、まず、コンサルとしての実績だけを見ないことが大事です。
特に大手のコンサル会社の場合は、企業としての実績と、担当するコンサル個人の能力は別のものと考えた方がいいと思います。
個人の能力の見分け方として、見た目の印象や話し方なども無視はできませんが、出来るだけ事実ベースで判断したいところです。
事実から見るコンサルタントのポテンシャル
- コンサル経験＋現場責任者としての経験
- 何社くらいの企業の実態を知っているか
- 成功事例と失敗事例のバランス
- 手法やフレームワークを何種類くらい知っているか
- 多様な課題に対応する武器が何種類あるか
- 理論の偏りがないことをチェック
- ロジカルシンキング力
- 経験のない事業、技術領域の内容を話だけでどこまで理解できるか
- 質問力、企業側の話にどれくらい深く突っ込みを入れられるか
指導方法、改革の進め方を習得する
組織改革は継続的な活動です。
一つの課題をクリアしたら、また次の課題にチャレンジいていき、改革は継続していくものです。
自社にない知識や知恵を獲得するためにコンサルを雇うわけですが、出来れば自社だけで改革を進められるようになった方がいいですよね。（弊社的としては、継続して使っていただきたいですが）
ですので改革プロジェクトをコンサルを入れて進めながら、手法や理論の指導方法、改革の進め方をコンサルから吸収すべきだと思います。
全員が吸収できるわけでもないので、中間マネージャーあたりで適任者を決めて、意識的にコンサルのワザを盗むことを使命として与えることだと思います。
盗むべきワザのポイントは、ファシリテーションのワザです。
（参考記事：「ファシリテーション力は鍛えられる」「ファシリテーションスキルを向上させる方法」）
手法や理論をどのように伝えるか、演習などの作り方、実施のコツなど、会議の進め方、メンバーの意見を取りまとめるワザなどをしっかりと真似できるように習得することで、次は自分たちで改革を進められるように準備します。
フューチャーシップのコンサルティング
弊社（フューチャーシップ）のコンサルティング・サービスの特徴は、
- 理論を現場の実情に合わせて実践すること
- 戦略的なアプローチで、根本の問題の発見をベースにすること
- 強力なファシリテーション力で改革チームをまとめる力
- 多数の成功事例とうまく行かなかったことを含めた現場実績
などとなります。
まずは、会話をしてみることで、使えるコンサルタントかどうかの判断をしてみてください。
ご興味があれば、下記フォームよりご連絡ください。
連絡をいただいた後、こちらからコンタクトさせていただきます。
この記事を気に入ってくれたら、下の”いいね”ボタンをお願いします！！
