コンサル的思考実験と読書メモブログ

ITコンサルタントが身を持って学んだこと、フレームワークの使い方、書評などを挙げていきます。IT企業や企業内IT部門の管理者やリーダ層の方、ITコンサルタントを目指す方に参考になる情報発信できればと思います。

コンサルとしての受注の秘訣

最近嬉しい事が二つありました。

 

一つは大型の官公庁案件が取れた事、もう一つは2年近くコンサルしていた企業の役員に直接話がしたいと言われた事。

 

特に二つ目は、いつもはIT組織の部門長とお話をしていましたが、

成果を報告後直接役員から2人で話したいとお言葉をいただきました。

 

直接話したいといってもらえるのは、話す事で何らかの気づきを得れると思っていただけだからかと思います。

 

実はこの二つの成果には共通点があり、特に受注につながる秘訣があると考えます。

 

それは、求められるであろう機能とは何かを理解する事だと思います。

 

コンサルを始めた頃、私はある小さなIT組織のコンサルに入りましたが、途中先方の部門長から「コンサルとしての資質を疑う」と痛烈な一言を言われた事があります。

 

当時の自分は、経験がとにかく浅いため、現状の問題点からあるべき姿を導き出すアプローチを取ってました。

 

このアプローチは現実解は出やすいですが、そもそもあるべき姿自体が既にシュリンクしており、ビジネスが求めるものに達していませんでした。

 

必ずしもこのアプローチが間違っているわけではないですが、この場合先方の部門長はコンサルに先生的な側面を求めており、取りまとめ役を求めていたわけではなかったと反省しています。一方で取りまとめ役、ファシリテーターを求められるケースもあります。

 

成熟度が高い組織ほど、コンサルに求めるのはファシリテーターで低い組織ほど先生的なコンサルティングな気がします。

 

私見ですが、コンサルファームでもこのコンサルティングと呼べるニーズに答えられる人は少なく、ほとんどがエンジニアリングの領域でしかないと感じます。

 

多くのケースでコンサルに求められる機能としては専門知識が挙がります。

 

先方がコンサルに期待する機能を如何に精度高く捉えるか、そして、その機能をいかに先方がそもそも実現したい事の中で必要性を高められるのか。

 

なんて事を考えたりしてます。

 

頼む側の立場にたってみれば、社内で発注する稟議などをあげるわけなので、会社を説得させる説明を担当の方からしてもらわないといけません。

 

機能として必要性を説く。

 

コンサルとしての求められる機能については専門知識以外にもあるので、その辺は次回お話したいと思います。