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