第1回-01 成果物、報告書作成のポイント

顧客の経営陣をはじめステークホルダー(利害関係者)に課題やその原因を理解させ、こちらの提案に賛同してもらうことは容易ではない。
そういった中で、コンサルタントは論理的な分析で解決策を導き出し、顧客の賛同を勝ち取って行く。ビジネスの課題解決にITが多用される今日、アーキテクトもこういった実践的なテクニックの活用が求められている。

本投稿では、ビジネスマンにぜひ盗み取ってほしいコンサルタントの問題解決法テクニを伝授し、より顧客満足の高い成果を勝ち取ってもらいたい。

第1回-01 なぜ報告書は理解されないのか?

数年前のことだが、東京のとあるホテルで開催されたITフェアでの話しである。企業の情報システム関係者達が大ホールに招待され、さまざまな質問に対して手元の押しボタンで回答するという企画があった。その中で「情報システム投資の最も障害となっている事は何か?」という質問があった。その答えは、社員のITリテラシーでも、過去の資産の陳腐化でも、バックログの多さでも、システム投資額の高さでもなかった。圧倒的多数を得た回答は、なんと「稟議の内容を理解してもらう難しさ」であり、自社の経営陣に理解してもらうことの難しさであった。

多くの読者も、経営陣やステークホルダーに対する説明の難しさを感じたことがあるはずだ。プロジェクトの報告会などで、苦労した数ヶ月間の成果を報告書にまとめてプレゼンテーションする。課題の原因究明や解決策の提言などを行うが、調査の甘さを指摘されたり、分析のロジックにケチが付いたり、図表のわかりにくさや数値の誤りに固執される。ひどいケースでは最後の質疑応答で、それまで説明したことを再度聞かれ、同じ説明を繰り返す。今までの説明を全く理解していなかったのかと落胆する。真に伝えたいことが伝わらないとか、説明の途中で議論が紛糾し結論までたどり着かない。プロジェクトの報告会でよくある光景である。

こういった事態に陥る原因は、さまざまな事に起因しているように見えるが、実はある一つの問題を解決するだけで一変する。それが本日ご紹介するストーリーボード(報告書のシナリオ)である。報告書のシナリオだけで事態が一変すると言うと、いささかいかがわしいと思うだろうが、ぜひ騙されたと思ってここに書かれていることを一度試していただきたい。おそらく、その効果を実感していただけるはずである。