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

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

コンサルタントの仕事術〜顧客との合意形成編〜

こんにちはatomです。

 

前回コンサルタントとは準備が大事だと話しました。

 

その続きです。

 

コンサルタントの仕事の仕方は基本顧客との合意形成の繰り返しです。

 

アプリケーションを開発する場合は、ケースにもよりますが、要件定義から基本設計くらいまで合意形成したら、後はテスト結果や成果物に対する合意形成といった形があると思います。

 

コンサルタントも問題抽出、原因分析、方針設計、施策の設計など、様々な工程で合意形成をします。

 

アプリケーションの機能性ほど明確でないケースがほとんどのため、また当初と変わったりするケースが多いため、合意形成をいかに取るかが非常に重要です。

 

その上でのポイントです。

 

まず顧客の要求は常に必ずしも目的に対する最適解ではないというのがあります。

 

それが如実に現れるのは、成果物のレベル感です。

 

分かりやすいが内容が薄いものと、内容は濃いがかなり理解に経験を要するもの、どちらが適切かは顧客の成果物を使う人の成熟度によって変わります。

 

リーダークラスと作り上げていても、リーダーの必要とする情報と現場の必要とする情報は異なるので、共に作るリーダーの声に答えるだけでは使えないものになってしまいます。

 

また、成熟度が低いから分かるように具体的に細かく決めて文書化して欲しいというニーズもありますが、成熟度が低い状況だとそもそも文書を見ないため、見やすい文書で慣れさせる事をまず実施した方が良いケースもあります。

 

また、細かく決めるには、相応の時間を要するため費用もかかります。

 

コンサルタントとして重要なのは、顧客の都度の判断時に影響を伝える事が重要です。

 

ここまで細かくするならば、当初予定のボリューム感から大きく超えるため、スケジュールに影響がでるが良いか。

 

この先の詳細化は、現場への浸透と共に見えてきた課題を踏まえた方が効率的であるが、それでも今の段階で、詳細化する形で良いか。

 

いずれも顧客に了解を取って進めています。

これは良い例だと思います。

 

一方で以下はあまり良くない例です。

 

もっと具体的に。。。了解しました。頑張ります。

 

上記の様な回答をして、納期に間に合わなかった場合、顧客は不満を表すでしょう。

 

そして、遅延をリカバリーするプランも求められたら、遅延を実際にキャッチアップしたりしつつ、さらに同様に顧客の要望に応えようとするあまり、結果応えられずトラブってしまう。負の循環。

 

これらは、よくよく話を聞くとコンサルタントが目の前の仕事に精一杯で、十分な計画がない中で、とっさの判断で答えてしまって、それがいつの間にか顧客との関係性において固定化され、言われた事をとにかくやる状態になってました。

 

合意形成とは、双方に責任が発生するものであり、特にコンサルタントとしては、起こり得る事態を想定して適切に情報提供できているか、専門家としての責務を果たしているかが重要だと考えます。

 

それと共に顧客側にも判断に対して責任を持つ必要があります。当初想定よりもやはり深掘りが必要であれば、スケジュールを伸ばす事を承認するなど。

 

ここら辺は相手の立場になれば、すぐに分かる事だったりします。

 

相手の立場を踏まえて、納得し得る選択肢を用意することがコンサルタントの合意形成かなと思います。

 

またの機会に顧客の視点を探る術について考えていきたいと思います。