鳥瞰的ストーリーを描くように説明するコツ:説明書を書く悩み解決相談室(2/2 ページ)
聞き慣れない用語を含む説明文の場合、人はその用語を理解しようとして全体の枠組みがなかなか頭に入ってきません。まずは大まかな構造を明示し、ストーリー仕立てにする必要があります。
大まかな構造とは?
では、詳しく見てみましょう。最初の「分析・設計・実装の三段階がある」というのが、大まかな構造です。これを原文ではどんなふうに書いていたかというと、次のような欠点がありました。
「実装」という用語は出てこない
「フェーズ」という概念に紐付けられているのは「分析」だけで、「設計」と「実装」も「フェーズ」であることが分かりにくい
原文と鳥瞰的ストーリー型説明文をもう一度見比べてみましょう。
(原文)デルタメソッドは、当初コンピュータプログラムの構造をデルタ型相互作用の関係として捉えてプログラムを書き表すデルタ指向プログラミングから始まっているが、その後、要求分析フェーズにおいて、開発しようとする対象領域のデルタ要素を抽出・定義していくデルタ指向分析、システムの動作や構造をデルタ的に記述するデルタ指向設計の技術としても広く発展・普及した。
鳥瞰的ストーリー型説明文
デルタメソッドの適用フェーズには分析・設計・実装の三段階がある。そして、歴史的には実装段階のデルタ指向プログラミングから始まり、設計段階のデルタ指向設計、分析段階のデルタ指向分析へとフェーズをさかのぼるように発達してきた。
コンピュータシステム開発の流れを熟知しているベテランなら「分析・設計・実装」という3段階があることを知っているため、原文のように分かりにくい書き方でも問題なく読めます。しかし、その知識が乏しい人にとっては、原文ではハードルが高いのです。
そこでそれを明示したのが、鳥瞰的ストーリー型説明文の「適用フェーズには分析・設計・実装の三段階」という最初のフレーズです。「大まかな構造」に当たるのがどんな情報かは、問題の分野によって違いますので、それを見極めてできるだけ早めに明示するように気を付けてください。
ストーリーとは?
ストーリーという言葉は、語源として「出来事を時間軸の順に語ったもの」という意味があります。例えば「History(歴史)」もその意味の派生語です。
時間軸の順に語るというのは、そこに原因と結果の関係が存在する場合が多いからです。原因と結果の関係が存在するなら、それは明示しておくべきですよね。
例えば「(A)気温が下がり(B)道路が凍結したため(C)バスのブレーキが効かず事故を起こした」という文は「Aが原因でBが発生し、Bが原因でCが起きた」というストーリーを語っています。
それを「(A)気温が下がり(C)バスのブレーキが効かず事故を起こした。(B)道路も凍結した」と書いたのでは意味不明です。つまり明確な理由があって、ある時間軸に沿って進行した事態を説明するなら、その時間軸を明示するように書くべきなのです。
これを踏まえて、鳥瞰的ストーリー型説明文を見てみると、
実装……(略)、設計……(略)、分析……(略)へとフェーズをさかのぼるように発達してきた。
と書いてあります。これが「明確な理由があって時間軸に沿って進行した事態」を明示するフレーズです。「さかのぼるように」と書かれていれば、まずは最終フェーズから始まってそれがだんだん前へと広まっていく姿をイメージできますよね。
これが原文の書き方だと、「実装」「分析」「設計」の順番に登場しているため、そのまま読むとその順番で世の中に出てきたのか? という誤ったイメージを持ちやすくなります。それを防ぐためにも、ストーリーがあるならそれを明示するように書くことは非常に大事なのです。
というわけで「鳥瞰的ストーリーを描くように説明する」ことを意識してみてください。
応用範囲の広い新技術といっても、一気にありとあらゆる分野に適用されることはまずありません。最初に使われる分野もあれば、なかなか進まない分野もあります。その順番の違いは、技術そのものの性格を理解する上で非常に重要な手掛かりになることが多いので、軽視せずに厳密に追及した方がいいんですね。そのためにも、鳥瞰的ストーリーを考える習慣は大事であり、分かりやすく書く上で効果的なのです。
当連載では、「分かりにくい説明書を改善したい」という相談を歓迎しております。「改善案のヒントがほしい」という例文があれば遠慮無く開米へお送りください(ask@ideacraft.jp)。今回のような連載での紹介は、許諾をいただいた場合のみ、必要に応じて内容を適宜編集したうえで行います。
当記事についてのご意見ご感想ご質問等は「twitter:@kmic67」宛でも受け付けております。中には記事では書ききれない情報もあります。物足りなく思った時はぜひ「twitter:@kmic67」宛に質問を飛ばしてみてください。
筆者:開米瑞浩(かいまい みずひろ)
IT技術者の業務経験を通して「読解力・図解力」スキルの再教育の必要性を認識し、2003年からその著述・教育業務を開始。2008年は、「専門知識を教える技術」をメインテーマにして研修・コンサルティングを実施中。近著に『ITの専門知識を素人に教える技』、
- 公式Webサイト:http://ideacraft.jp
- メールマガジン登録:http://ideacraft.jp/cms/mm.html
関連記事
- 筆者別記事一覧:開米瑞浩関連記事
- 会社の方針がはっきりしなくても――部下が喜ぶストーリーで方針を伝える方法
最近、主任研修や管理職層の研修などをやっていると特によく聞かれるのが「会社の方針がはっきりしない!」ということ。しかし、この不況下で一寸先も分からないわけですから、明確な方針がないのも分かります。とはいえ、そのぼんやりとした方針を伝える必要はあります。どうやって伝えたらいいでしょうか。 - ビジネスパーソンの臨時収入、公募で執筆の武者修行
ビジネスパーソンが会社以外に収入を許されているのは何だろうか? 株式を売買したり、ギャンブルに興ずることもあろうが、ちょっと気が引ける。文章力を高めるのであれば公募にチャレンジしてみてはいかがだろうか。 - 文章力を上げる“写経”訓練法の3つのポイント
ビジネスパーソンは、トーク力と文章力の有無で選択できる道の広さが大きく変わります。前回はトーク力の改善法を説明しましたので、今回は単純にして破壊力抜群の写経訓練法の3つのポイントを紹介しましょう。 - 「超」文章法の7ステップ
どうしたら文章が上手に書けるのでしょうか。長い文章を書く方法と、短いリストをまとめる方法はよく似ているものです。ここで挙げるリストを参考にしながらトライしてみましょう。 - 成功前から「私はビッグ」で行動
「転職したい」「独立したい」「離婚したい」など、目標は見えているのに行動に踏み出せないことはありませんか? あなたのセルフイメージや価値観などがブレーキになっているのかもしれません。アクセルに変えるには? - 説明書は分かりやすければいいってもんじゃあない
説明書と言っても、プレゼン用から教育用までさまざまあります。誰向けの説明書かによって、分かりやすさを調整していかねばなりません。なぜでしょうか? 例に沿ってその訳を解説します。 - 「説明書が書けない」悩みにお答えします!
本連載では「説明書を書かなければいけないのにうまくいかない、誰か助けてくれえ!」と悩みを抱える方の相談に、文書化能力向上コンサルタントの開米がお答えします。 - 文章がスラスラ書けるようになる5つのステップ
情報量が多い説明書などの文章を書く時、知っておくと役立つ問題解決法を5ステップで紹介します。これを知っていればスラスラ文章が書けるかも? - 新技術を説明する――素材→加工→用途のフローに分ける考え方
前回に続いて、誰かにちょっとした複雑なことを説明するための文書のうまい書き方を紹介。今回は文章を幾つかの部品に分けて考えてみます。 - 分かりやすい説明書の極意は「同種のものを真っすぐ並べる」
複数の名詞が混在する説明文を、すっきり分かりやすくまとめるには? ――今回の説明書を書く悩み相談者は、ある本を執筆中の男性です。 - 「構造→性質→用途」がポイント――文章に頼らず説明する
専門的な内容が多く含まれる説明書などは、内容がある程度理解できなけれ改良するのもば難しいもの。文章を構造としてとらえてうまく情報を整理することが大切です。
Copyright © ITmedia, Inc. All Rights Reserved.