図解の本質はここにあった ITエンジニアにも必要な国語力

図解の本質はここにあった
ITエンジニアにも必要な国語力

第16回 「骨組みのない注釈」に注意せよ

開米瑞浩(アイデアクラフト)
2007/1/17

コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。

 ITエンジニアも、システム化提案のときなどにプレゼンテーションをしなければいけないケースが増えている。その際、システムそのものの仕組みまで踏み込んだ理解を得なければならないことが多い。システム開発はユーザー部門も当事者として巻き込んで進めなければならないからだ。

 そのため、特にドキュメント作成について、単に承認を求めるためのプレゼンテーションのセオリーが通用しない場合があることに注意しよう。

「図解の研修をお願いしたいんですが……」

 昨年(2006年)後半のある日、私のところに1本の電話がかかってきた。ある会社の情報システム部門からの、図解研修をしてほしいという依頼だった。

 事情を聞くと、社内の非IT部門(ユーザーや経営者)に対して新たなシステム化の提案をするに当たって、技術を知らない聞き手に分かるように説明できるようにしたい、というのがそもそもの動機であるという。

開米「それはプレゼンテーションの研修ということではないんですか?」

依頼者「プレゼンテーションそのものよりも、その前の準備ですね。プレゼンテーションのための資料を作るときにうまく図解できるようにしたい、ということなんです」

 ……実はIT業界に限らず、このような依頼がこのところ多くなっている。普通の「プレゼンテーション研修」はどうしても本番での「話し方」が中心だ。しかし、「話し方だけでは足りない。話す内容をきちんと整理しておかなければ」ということに気が付いた会社からはこういう依頼が来るわけだ。

開米「なるほど、それで、説明する内容は、社内の業務システムに関する企画概要なんですね?」

依頼者「そうなんです。何のためにどんなシステムを作るのか説明しなければいけないんですが、『システムの仕組み』を分かるように説明するのが大変で……」

開米「そうですね、その説明は『しゃべり』だけでは無理ですからね」

 実はここに、一般的なプレゼンテーションのセオリーをIT業界に適用することの難しさがある。

声と文書のどちらが主体か?

 一般的には、プレゼンテーションは「しゃべりが命」であり、聞き手に直接面と向かって「自分の声で話す」のでなければ成立しない。例えば「資料を使わず、口頭説明だけで行うプレゼンテーション」がよくあるのに対して、その逆の「資料を見せるだけで、口頭説明を行わないプレゼンテーション」がほぼないことを考えれば分かるだろう。

 要するに通常のプレゼンテーションでは「しゃべりが主、文書は従」であり、図表はしゃべりを補う添えものである。

 ところが、「システム化の提案」では逆に「文書(図表)が主、しゃべりは従」ということがよくあるのだ。複雑なシステムの仕組みを「分かるように」説明しようとするとどうしても図表の方が主役になり、口頭説明はそれを補う役割になる。

 このことは、地図を使って人に道案内をするケースを考えれば分かる。道案内で「しゃべり」が主役になることは考えにくい。現実世界で人の歩く道筋を最もよく表現できるのは、やはり「地図」という図面である。口頭説明はあくまでもその地図を読むための「補助」であって、主役ではない。

 「システム化提案のプレゼンテーション」を行う場合も同じように、「システムの概要を表す図面」がきちんと書けていなければいけない。当然それはただの個条書きではダメだ。だが、ではどう書けばいいのかといったところで当てにできる「正解」は存在しない。

 それで悩んだ結果、図解研修の依頼をしてくる冒頭の依頼者のようなケースが増えているわけだ。この連載の読者には、似たような立場で似たような事情に悩む方が多いことと思う。そこで今回は、その研修の場で使った例題の1つを紹介しよう。

「要点のみの個条書き」に欠けているもの

 例文1は「デジタル化のメリット」を説明するためのプレゼンテーションの一節である。

 現代では当たり前のような話だが、ITの黎明期にはこのような資料を持って社内を説得した方もいることだろう。

<例文1:デジタル化の多様なメリット>

1.さまざまな情報を統合的に編集し再利用することができる
2.情報の圧縮や保存がしやすい
3.情報を伝達や複製しても品質が落ちない
4.デジタル情報はさまざまなメディアやネットワークで伝達できる
5.大量の情報を蓄積しておいて、必要に応じて検索しやすい
6.定型的なデータ処理をプログラム化して自動的に行える

 プレゼンテーションは何かを「提案する」ために行われる場合が多く、それには当然「理由」が必要になる。その理由を「提案のメリット」として個条書きで書いておく方法はよく使われる。

 「要点のみの簡単な個条書き」はプレゼンテーションでは定番中の定番といえる手法であり、通常はそれで十分だ。何しろ「しゃべりが主、文書は従」がプレゼンテーションのセオリーなので、文書は単にキーワードを並べているだけというケースも珍しくない。

 だが、本当にいついかなるときもそれでよいのだろうか? 当然、実際にはそれでは足りないケースもあるわけだ。

 ここで、図1のA・B、2つの地図を見ていただこう。A・Bともに、同じ場所への道案内をするための地図である。ただし、A図は経路のポイントとなる場所だけを書いてあるのに対して、B図ではポイント以外についても書かれている(なお、今後の説明の都合上、A・B両図をいずれも上段と下段に分けて、上段を骨組みパート、下段を注釈パートと呼ぶことにする)。

 さて、どちらが地図としてより役に立つだろうか?

図1 2種類の道案内

 もちろん、役に立つのはB図の方である。A図もB図も「要点」を構成する「K証券ビル」「F百貨店」「D」の位置関係は同じように書いている。違うのは、B図にはその要点以外のこまごまとした建物も書き込んであることと、1〜3の道案内の注釈を、地図上の位置に対応付けてレイアウトしてあることの2点である。

 B図を見れば、ヨコ方向に大通りが1本、タテ方向に小道が2本あることが一瞬で読み取れるし、それらの通りとK・F・Dといったランドマークとの位置関係も明確だ。

 一方、A図は非常にシンプルだ。通常のプレゼンテーションのセオリーである「文書は要点のみ個条書き」というスタイルはこのA図のような方式だといえる。しかも骨組みを書かずに注釈パートのみを書いているのが普通である。

 骨組みが簡単なものであるか、または聞き手が骨組みを知らなくてもよい場合はそれでいい。だが、その条件が成り立たない場合は「注釈パートのみ」ではうまくいかない。B図方式で骨組みをきちんと書く必要がある。そして「システム化の提案」のようなプレゼンテーションではその「骨組み」を分かりやすく書かなければいけないケースが多いのだ。

「デジタル化のメリット」の骨組みを考える

 ここでもう一度、「デジタル化のメリット」について書いた例文1を見ていただきたい。まさにA図方式、しかも注釈パートのみを書いていて骨組みを語っていない、そんな文面だった。このやり方ではうまくいかないとしたら、どうすればよいのだろうか。

 問題は、「デジタル化のメリット」の話の「骨組み」とは一体何かである。たいていの場合、注釈はあくまで骨組みあってのものであって、注釈そのものには骨組みに関する直接の情報は書かれていない。「デジタル化のメリット」の例文1もやはり同じである。

 そこで、骨組みを見つけるために文面をよく読んでみよう。こういう場合、

情報を短文個条書きからさらに単語レベルにまで分解し、同じ種類の単語をそろえて一直線に並べてみる

のが常とう手段である。今回は「同じ種類の単語」として取りあえず「動詞になるもの」と「それ以外」の2つに分けてみる。

動詞になるもの
  デジタル化、編集・再利用、圧縮・保存、伝達・複製、蓄積・検索、データ処理

それ以外
  さまざま、情報、統合的、品質、落ちない、自動的

 さらに「一直線に並べる」ことを考える。今回は動詞を並べてみよう。

動詞を一直線に並べてみる
  デジタル化→保存→検索→伝達→利用

 一直線に並べた場合、それを順番に読み上げていって意味の通る文を作れるかどうかが、その並び順が適切かどうかを判断する鍵である。例えばこんな文面を作ってみる。

順番に読み上げて文を作る
  「情報をデジタル化して保存しておくと、検索しやすくなり、(さまざまなメディアで)伝達して利用できます」

 このイメージは、例えばインターネットの検索エンジンを考えてもらえばよい。GoogleやYahoo!のような検索サイトを使うと情報を「検索」でき、検索結果から見つけたデータは、インターネットを介して「伝達」させて手元に引き寄せ、「利用」することができる。それができるのも「デジタル化」して「保存」してあるからなので、上記のような一直線の並び順が成立するわけだ。

 一方、地図を使った道案内で両端が「スタート〜ゴール」であるように、一直線の並びを考える場合は両端に何を置くかが極めて重要だ。「デジタル化」と「利用」でいいのだろうか?

 通常、「動詞」は「名詞と名詞の間の関係」を表すことが多い。ということは、動詞の並びの両端にも「名詞」がくる方が自然である。例えばこういうことである。

動詞は名詞と名詞の間の関係を表すことが多いので、
動詞の並びの両端に置ける名詞を考える
名詞
動詞
名詞
情報ソース
(アナログ)
デジタルプロセス
(デジタル化→保存→検索→伝達→利用)
利用者
図2 名詞〜動詞〜名詞の関係付け

 「情報ソース」というのは音声・文字・映像などいずれにしてもアナログな情報である。それをデジタル化すると、デジタルプロセスに載せて利用者が使うことができる(デジタルプロセスとは、先ほど考えた一連の動詞をひと言で表すために付けた名前)。

 だんだん「骨組み」ができてきた。後は注釈を付けながら微調整をしていけばよい。

 例えば、「さまざまな情報を統合的に編集できる」というのは情報ソースに音声・文字・映像などが混在していてもデジタル化すれば一括して扱えるという意味で、「情報ソース」の部分への注釈になる。

 「品質が落ちない」というのは「保存→伝達→利用」あたりへの注釈である。「さまざまなメディアやネットワーク」というのは「伝達」への注釈と考えていい。

 これらの整理を加えた最終形は図3のようになる。

図3 骨組みをベースに注釈をレイアウトする

 図3は「アナログ情報」から「利用者」へ続く一連部分が「骨組み」であり、その周囲に付記したテキストは「注釈」である(なお、図2までの検討と微妙に異なる文言が使われていることの説明は省略する)。

 ここでもう一度、例文1を見てほしい。例文1のような個条書きを見ても図3の「骨組み」は分からない。となると、「デジタル化」といわれてもピンとこない聞き手にとっては、例文1を見せられても「骨組みが分からないまま注釈を聞かされている」状態になる。地図なしに電話口で道案内を聞くようなものだ。これでは「分かった!」と思えるはずがないのである。

 骨組みが分かるようにするためにはどうしても図面が必要であり、その図面は図2のBのように、メリハリは必要だが骨組みが分かる程度に細部まで書き込まれていなければ役に立たない。これが一般的なプレゼンテーションのセオリーとは大いに違うところなのだ。

「骨組み」も「注釈」も必要

 現代のITエンジニアは、「素人への説明」を求められるケースが非常に多い。あなたの説明は「骨組み」と「注釈」が適切に構成されているだろうか? 「注釈」だけの説明、「骨組み」だけの説明ではうまくいかないだろう。

 ITのシステム化提案では特に「骨組みを図解しなければ注釈も理解されない」というケースが非常に多い。ところが、通常のプレゼンテーションのセオリーは「注釈重視」の傾向があり、骨組みの説明が軽視されている場合が少なくないのだ。くれぐれもご注意いただきたい。

 説明は「骨抜き」ではいけないのである。

自分戦略研究所、フォーラム化のお知らせ

@IT自分戦略研究所は2014年2月、@ITのフォーラムになりました。

現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。

これからも、@IT自分戦略研究所をよろしくお願いいたします。