Bossに「このDocumentを読んでまとめてくれ」と頼まれたら、どんなまとめ方をしますか?
私たちがProblem-solverとしてまとめるとしたら、どんな方法が良いのでしょうか?どんなことに留意すれば良いのでしょうか?
それを考えるには、目的を考える必要があります。
当然ですが、私たちコンサルタントの仕事は、問題を解決することです。
ものすごく簡単に説明すると、クライアントヒアリングをまとめるときやリサーチをする際、問題をはっきりさせ、その原因を特定し、そこにAddressするようなSolutionを提示する。この構造を取れば、Actionable(実効性が高い) になります。
単に(例えば)時間軸でまとめたReportに比べ、読み手は行動を起こしやすいです。つまり、Actionableです。
つまり、それぞれのロジック・リンク(下記の絵の中の矢印)が正しければ(Reasonableなら)、問題は解決されるはずです。が、どれかが間違っていれば問題が解決されていないです。
ロジック・リンクが正しければ、あなたのReportを読んだ人は、そこに書かれているSolutionを実行すれば良いし、間違っていればそれぞれのElement(ProblemやCauseなどの)を分析し直すことになります。
私たちProblem-solver(コンサルタント)のミッションは、クライアントの問題解決なので、私たちが作ったOutputは、上記のように問題解決にUsefulな情報である必要があります。
ActionableなReportを書く際には、以下のように2つのStepを踏むと作業が進めやすいと思います。
インタビューにしても書類にしても、クライアントから得られる情報はきれいにOrganizeされているとは限りません。きっと混とんとしていることの方が多いでしょう。
クライアントの中には、「自分でも何か問題か分からない」、「ましてや原因の特定なんて到底無理」という方もめずらしくありません。このため、クライアントからの情報を収集する際にも、頭の中でこのようなProblem-solvingのフォーマットを置きながら進めると早めに全体像がつかめるし仮説も立てやすくなります。
簡単な具体事例で説明しましょう。
クライアント:「うちの会社、赤字なんです」
あなた: 「なぜですか?」
クライアント:「消費者が我が社の新製品を全く買ってくれないんです」
あなた: 「それで、どうするつもりですか?」
クライアント:「おそらく、あたらしい製品開発責任者を雇う必要があるでしょう」
おおまかなProblem-Causeの関係はつかめましたね。ただ、お客さんが新製品を買ってくれないからと言って、いきない現開発責任者をクビにするのも、あまりイタダケない打ち手です。そうですね。Causeをもう少し分解する必要がありそうです。
そうです。製品のどのAttribute(属性)に問題があったかを知りたいところです。値段が高すぎた?品質の問題?デザインが悪い?消費者に良く知られていない?そもそもショップの場所が悪い?
Businessで起こる事柄のほぼ全てがProblem solvingです。ですので、このFormatは広く使うことができます。
実は、こうしたFormatは、英語でのChat(雑談)にも応用できます。非常に効き目があります。是非、試してみて下さい!
ご質問やコメントなど、お持ちでしたらどうぞお気軽に!
Copyright © 2025 | MH Magazine WordPress Theme by MH Themes