問題解決には“ベース構造”を踏まえた説明が必要：説明書を書く悩み解決相談室（2/2 ページ）

[開米瑞浩，Business Media 誠]

問題の原因はベース構造の中にある

　当たり前のことを言っているようですが、実はこれが意外に難しいものです。ベース構造の中には、例えば「東京神戸間は約500キロ」のように長期間変わらないものがあります。そういうものは普段いちいち説明していないので、関係者でも忘れていたり、マニュアルに沿った仕事をしているだけの担当者はそもそも知らない、というケースがよくあります。

　マニュアルが通用する平常時ならベース構造を忘れていても仕事が出来ますが、問題が起きた時はそういうわけにはいきません。問題解決には、ベース構造を踏まえて現実的な策を考える必要があります。例えば図1のケースでも、輸送先が仙台と神戸だから難しいので、もし大阪と神戸だったら両方の荷物を積んで一度に運べるかもしれませんし、もし池袋と新宿だったら2回に分けて運べば済むかもしれません。

　問題を解決するには、ベース構造を認識する必要があります。解決策を考えるために、そして関係者の合意を取るためには、ベース構造を踏まえて問題を説明する必要があります。

　そのために推奨したい方法の1つが、図1のように、ベース構造と問題、解決策の3つを分けて書くことです。

　問題だけを書いていても解決策は出てきません。解決策はベース構造を踏まえた形でなければ出てこないのです。ところが、もう一度書きますが「関係者全員がベース構造を正しく認識する」のは意外に難しいことです。人に言われた仕事をしているだけの人などは大抵分かっていません。だから、それが分かるように説明をする必要があります。説明するためには、「分けて書いておく」ことが必要なんですね。

　なお、このパターンにはいくつかのバリエーションがあります。

図2

　ごらんの通り「ベース構造」「問題」「解決策」が基本型ですが、問題の代わりに目標、解決策の代わりに対策や政策と呼んでも本質は同じです。また、政策であれ解決策であれ、策を立てるとそれにともなって「解決しようとした問題とは別の悪影響」が出ることがあります。それは当初認識された問題とは別に書く方がいいので、副作用と呼んだりします。

　いずれにしても、ベース構造、問題、解決策が基本のパターンです。解決が難しい複雑な問題はベース構造自体が複雑な場合が多いので、その分、それをしっかり把握する必要があります。

　次回は、いま社会的関心が高い電力問題をこの方法で整理してみる予定です。ぜひご期待ください。

---

　当連載では、「分かりにくい説明書を改善したい」相談を歓迎しております。「改善案のヒントがほしい」例文があれば遠慮なく開米へお送りください（[e-mail] ）。今回のような連載での紹介は、許諾をいただいた場合のみ、必要に応じて内容を適宜編集したうえで行います。

　当記事についてのご意見ご感想ご質問等は「twitter:＠kmic67」宛でも受け付けております。中には記事では書ききれない情報もあります。物足りなく思った時はぜひ「twitter:＠kmic67」宛に質問を飛ばしてみてください。

筆者：開米瑞浩（かいまい　みずひろ）

　IT技術者の業務経験を通して「読解力・図解力」スキルの再教育の必要性を認識し、2003年からその著述・教育業務を開始。2008年は、「専門知識を教える技術」をメインテーマにして研修・コンサルティングを実施中。近著に『ITの専門知識を素人に教える技』、『図解　大人の「説明力！」』、『頭のいい「教え方」　すごいコツ！』

• 公式Webサイト：http://ideacraft.jp
• メールマガジン登録：http://ideacraft.jp/cms/index.php/mail-magazine