エンジニアからコンサルになるときのブレークスルーその２
おはようございます、水上裕介です。
前回は、伝えるべき相手についてコラムしました。
今回は、資料の整理方法についてコラムしようと思っていましたが、その前に伝えるべき相手のブレークスルーについて掘り下げてコラムしたいと思います。
■コンサルの壁（伝えるべき相手）を掘り下げる
前回を掘り下げ、伝えるべき相手の発見の仕方について考えてみます。
エンジニア視点では、体制図が明確に決められることが多いと思いますので、比較的容易に自分の立ち位置と役割を認識できるかと思います。体制図が定義されていない現場でも基本的には契約先のPMに対して報連相していれば大概は問題ないと思います。
一方でコンサル視点では、体制図が明確には定義されていないことが多いと感じます。理由は、コンサル自体つまりヒトの入れ替わりが激しい（コンサル自体が短期間で入れ替わる）ことが多いからです。※私の関わった案件の話ですが。。
コンサル視点で重要なのは、体制図より会社間のパワーマップを明確に認識することです。パワーマップとは会社間の力関係を表したワードです。パワーマップを認識した上で、業務観点・システム観点でそのときに応じた相手を発見する。（前回コラムで例に上げた）コンサルの仕事（価値）は、業務PMだったり、開発ベンダが価値のあるサービスをその先にいるエンドユーザに提供するための支援をすることにあります。パワーマップを正確に把握していくことはコンサルの仕事の源泉となりうるほど重要なものだと考えています。
そのためにスピーディな行動と高精度な成果物作成のスキルが求められます。
■スピーディな行動
まず、スピーディな行動についてです。
エンジニア視点では、納期を守るということが該当するかもしれませんが、
個々人に割り振られるタスクという意味では、モノを作るための見積をPMなどに報告してその期間にモノづくりをする。スピードという意味では、求められることが少なく、どちらかというと、汎用的にどのような状況にも対応できる柔軟な設計や実装力が求められる状況が多いと感じます。※当然日を吹いたプロジェクトなどではスピードが求められることがあります。
一方でコンサル視点では、個々人のタスクの期限が短期間（１D、長くて１W程度）であることが多く、どの相手にどういう成果を出すべきかをスピーディに把握することが求められます。
例えば、「あるチームの進捗状況を報告する」という成果を実現するために、ファクトを誰から収集し、どのように伝えるかを整理するシーンがあるとします。この場合の報告の意味としては、プロジェクトリスクを伝えることなどが主目的になりますが、リスクの解決案も同時に提案する必要がある。つまり、コンサルは、成果を出すために具体的に相手に行動してもらうことが命題となります。そのために行動を促進するプランをスピーディに実行していくメンタリティとバイタリティが重要ですが、命題を正確に理解しないとそれらを維持することは困難だと思います。
■高精度な成果物作成スキル
つぎに成果物作成についてです。
エンジニア視点は、明確です。業務フローや設計書などのドキュメントか、実際に動くモノつまりプログラムやテストコードです。
コンサル視点では、相手に行動してもらうための資料が成果物になります。資料は、エクセルやパワポで表現しますが、相手が外国人なら外国語で記載する場合もあるでしょう。この資料を作成する前提として、ロジカルシンキングやMECEなどのフレームワーク的なもので整理することが求められます。ただ、それは必要条件であって十分条件ではありません。相手に行動してもらうには、伝えるべき重要なメッセージを発見し、伝えることが最も重要です。
そのメッセージを伝えるために資料を作成するという順序を明確に認識することが大切です。コンサルになりたての頃は、その点の理解が不十分であったため、成果が出ませんでした。
■次回
次回は伝えるべきメッセージの発見方法、伝え方についてコラムしたいと思います。
最後までお読み頂きありがとうございます。