図解言語入門：図解の技術を覚えよう

第2回　最初の一歩はマトリックスから

開米瑞浩（アイデアクラフト）
2004/4/9

話すこと、書くこと、そして思考を図に表して理解する。当たり前で簡単なようだが、意外と訓練していないとうまくいかない。では、それを習得した場合のメリットとは。それは、相手とコミュニケーションにおいて誤解が少なくなること、より理解できるようになること、伝えるための道具になること、といったことだ。ITエンジニアに必須のコミュニケーションスキルの土台を、言語を図解化することで理解しやすく構築しよう。

■マトリックスの意味

＜前回までのあらすじ＞ ぼく（清水敦史・25歳）が客先常駐のSEとして、クライアントへのシステム提案で悪戦苦闘していたときに出会ったのが、コンサルタントの加藤さんです。彼から図解言語を身に付ければ、クライアントの理解がアップし、提案力も付けることができるというので、現在図解言語と格闘しています。

　前回の連載では、早速加藤さんに以下の問題を出題されました（表1）。

	草原地帯	（A2）	森林地帯
気候的要因	（B1）降水量減少
人為的要因	（C1）家畜の過剰放牧	（C2）	（C3）
人為的要因のもたらした影響	（D1）	（D2）	（D3）
表1　前回の最後に出題した練習問題

清水　質問していいですか。図解言語といいますが、この問題は表にしているだけで、あまり“図解”といった感じには見えませんが……。

加藤　確かに、一見すると図解に見えないと思うよ。でも、こういうマトリックスを使うことには重要な意味があるんだ。それをちょっと説明してみようか。

　図1は、何かの情報を図解するときの活動を単純にモデル化してみたものだ。この図の上半分は、文字とか言葉、図形として表面に出た情報で、下半分は人間の頭の中を指していると思ってほしい。

図1　情報を図解するときの活動を単純にモデル化したもの

　すると、何かの情報の断片を基にしてそれを図解するときには、まず頭の中で「理解」しなくてはならない。これは、図1の（1）の工程だ。

　それによってきちんと理解すると、（2）に図解することができるはずだ。マトリックスは、この理解が正しいのかどうかをチェックする手段として、非常に便利なんだ。図でいう（3）の工程だね。

清水　チェックですか。

加藤　そう。実際、清水くんの答えを見てみようか。

■マトリックスは高速検査装置

清水　ぼくの答えはこれです（表2）。

	草原地帯	（A2）田畑地帯	森林地帯
気候的要因	（B1）降水量減少
人為的要因	（C1）家畜の過剰放牧	（C2）休耕期間の短縮	（C3）薪炭材の過剰採取
人為的要因のもたらした影響	（D1）地力の低下	（D2）地力の低下	（D3）不明
表2　清水くんの解答例

加藤　どれどれ。ああ、早速あるね。（D1）の「地力（ちりょく）の低下」だけど、地力は農耕地に使われる概念なんで、草原地帯に書くのはちょっとおかしいんだよ。

清水　でも、テキストには……。

加藤　元のテキストは、実はどちらにも読めるように書いてある。「などによる地力の低下」とある個所だけど、図2を見てごらん。解釈として、解釈1と解釈2の2つ、どちらにも読み取れる文になっている。最も自然な解釈は解釈2で、実際もそれが正しいけれど、清水くんは解釈1だと思ったわけだね。それも別に無理な解釈じゃない。要するにこれ、元の文章があいまいだから、理解もあいまいになる例なんだよ。

図2　文章では範囲を読み取りにくい

清水　元の文章を書いた人が悪いということですか。

加藤　いや、誰が悪いといった問題ではないんだよ。実際にクライアントにヒアリングしてるとき、あいまいな答えを返されることがあるだろう。書き手や話し手にとってはあいまいではないんだ。実際、「地力は農耕地の概念」だという知識があれば、この文は解釈2としかとりようがないからね。

清水　でも、地力という専門的な言葉は、普通知りませんよね。

加藤　確かに一般的な言葉ではないかもしれない。しかし、IT技術者がクライアントと話しているときにもよくあることだね。お互い、何が常識で何が非常識なのか知らずに、理解が行き違っちゃうのは、IT技術者にとって永遠の課題だろうからね。

　加藤さんの話を聞きながらぼくは身に覚えがあり過ぎて笑いそうになりました。確かに、ぼくの毎日はそんな行き違いばかりです。

加藤　例えば次のようなケースを考えてみよう。清水くんがクライアントにヒアリングをする。そのときにクライアントの発言を、図1でいうところの情報の断片を一字一句そのままメモ書きしたとする。そのメモをクライアントに見せれば、相手は「確かにそのとおりだ」というだろう。当人がいったままだから。それでお互い話は通じたと思ったが、本当に通じているのか。

清水　実際は、同じ文言のはずですが、ぼくは違う意味に理解していたことになりますね。しかも、お互いそれに気が付かないということですか。

加藤　まさにそういうことだ。分かりあっているつもりの2人の間に深い溝があるのは危ない。いつかドカーンと爆発して、修羅場になる（笑）。

清水　全然笑えませんよ。

加藤　ところが、マトリックスにするとその行き違いが一発で分かるようになる。

清水　なるほど、そうですね。

加藤　そういうわけだ。文章の読解力とか表現力を鍛えればいいという話もあるが、文章はそもそも微妙に意味をコントロールするような表現をするのには向いてないと思う。マトリックスの方がずっと簡単に使えるんだから、最初からこっちにすればいい。これなら、文章力のない人でも使えるからね。

清水　はい。とてもありがたいです。

加藤　それにマトリックスを使い込んでいくと、文章力も上がっていくよ、間違いない。どうしてかというと、マトリックスを使っていると、言葉の微妙な意味の差に敏感になるからなんだ。それが普通の文章を書くときにも生きてくるわけだ。

　ぼくは大きくうなずきました。率直な話、文章力にも読解力にもそんな自信はなかったのです。加藤さんの言葉はそんなぼくに安心と希望の光をともしてくれました。

加藤　要するに、マトリックスは理解の高速検査装置と理解すればいい。これを使って人に話を聞いて回ると、誤解を素早くチェックでき、どんどん修正していけるようになる。

清水　なるほど。

加藤　しかし、マトリックスは、さらに宝探しの地図的用途にもなるんだな。

■マトリックスは宝探しの地図

加藤　例えば表2の（D3）が空白になってるのはどうしてだい？

清水　元のテキストに書いていなかったので、そのままにしました。

加藤　書いていない。だったら調べようとは思わなかった？

清水　えっ？ 不明のままでいいって……。

加藤　この問題の範囲ではね。でもこれが仕事だったらどうする？ これがクライアントのヒアリングシートで、目立つ空白があったとしてもそのままにしておくかい？

清水　そのときは質問します。

加藤　じゃあ、そのときはどう聞く？

清水　この場合だと……。森林地帯で薪炭材を過剰採取することは、砂漠化現象にどういう影響を与えるのですか、でしょうか。

加藤　なかなかいい質問だと思うよ。

　ここであらためて考えてほしいんだが、いま清水くんがした質問は、コミュニケーションのプロセス（図3）のうちの「聞き出し」に該当するね。質問する、というのは、聞き出すための働き掛けだからね。

図3　図解はすべての過程を改善する

清水　そうですね。

加藤　それで、どうやったら質問ができるかを考えよう。そうすると、そこには2つの工程があることが分かる。それは、

（A）質問するべきことを見つける
（B）それを具体的な質問文にする

の2つだ。

　その観点で清水くんが表2を作成するまでを振り返ってみよう。まず、空白部分を見つけてからマトリックスのタテ／ヨコ方向を眺める。そして見つかったキーワードをつなげて質問文を作ったはずだ。

清水　そっか。簡単ですね、これ。

加藤　簡単なんだよ。これが元のテキストだけ渡されて、何か質問しろ、といわれたら、できたと思うかい？

清水　それはだいぶ難しかっただろうと思います。

加藤　そうだろう。だからマトリックスを使うと次から次へといい質問が出せるようになる。そうしているうちに思いがけないところで思いがけないことが分かったりすることもある。いままで誰も考えてなかったようなところを掘り起こしてみるとね。それが何か宝探しに似ていると思ったので、ぼくはマトリックスを宝探しの地図と呼んでいるんだ。

■隠れマトリックスが図解のレイアウトを決める

清水　ところで加藤さん。図1に戻って質問したいのですが、（4）の矢印は何ですか？

加藤　今度こそ、いい質問だね。実はこれ、「隠れマトリックス」を意図して書いたんだ。

　さっき清水くんは、表2はただの表で、図解のように見えないっていってたけど、図1はその点で図解に見えるでしょう。

清水　そうですね、図1は図解に見えます。

加藤　でも図1も実はマトリックスなんだよ。

清水　えっ？ でも、そういわれてみれば、タテ／ヨコにきれいに切り分けて配置してあるから、そんなふうにも見えますね。

加藤　実は、いかにも図解のように見える図にするときも、こんなふうにマトリックスを意識して配置することが非常に多いんだよ。だからまず、マトリックスを作ることによって、最後にできる図解レイアウトを決めることになるケースがかなりある。だから結局、図1の（2）よりも（3）（4）の工程をたどって図解に至ることが多いんだね。

清水　では加藤さん、マトリックスを最初にやるといいというのは、そんなふうに簡単で応用範囲が広いから、ですか？

加藤　おっ、またまたいい質問だね。それも理由の1つだ。が、実は人間の考える工程そのものにかかわる理由がもう1つあって……。あ、いけない。

清水　ど、どうしたんですか。

加藤　今日はもう時間がないんだよ。残念だが、もう帰らなければいけない。マトリックスについてはほかにもいろんな話があるんだよね。要約のラインダンスとか、開拓のフロントラインとか、え、名前が変だって？ 大丈夫、中身はまじめだから。

　そういい残して加藤さんはバタバタと去っていきました。が、ふと手元に1枚の紙が！ 加藤さん、忘れていったのかな。いったい何だろう。その紙を開いて見ると……。

読者への挑戦状

さて、読者諸君。 今回、清水くんの姿を陰ながら見守ったことで、諸君はすでにある程度のマトリックス感覚を身に付けたことだろう。そこで、挑戦状である。以下のテキストを基に、清水くんのようにマトリックスを作って分析をしてほしい。 では、また会おう！

　下記の文章を読んで、書かれていることをマトリックスで整理したうえで、質問に答えてください。

問題文

近ごろ、システム開発現場でXP（eXtreme Programming）と呼ばれるライトウェイトな方法論が普及し始めていることを、多くの方がご存じだろう。XPでは、これまでの開発の常識を覆すような方法（プラクティス）がいくつも提唱されている。 　例えば、シンプル設計というプラクティスは、「いずれ使うかもしれないものは、作らない」という原則を意味している。これまでの方法論では「将来予想される変化にあらかじめ対応できるように設計に幅を持たせる」ことが常識だったのに比べると大きな違いである。 　また、開発メンバー同士でのノウハウの伝承や、リアルタイムのレビューによる早期の問題発見という効果を得るために、ペアプログラミングが推奨されている。これなども、2人で一緒に同じプログラムを書くわけだから一見無駄な作業に思われがちだが、実際には生産性が高まる。 　テスト工程についての違いも見逃せない。XPの原則はテストファースト。先にテストプログラムを書いてから、ビジネスロジックを書くわけだ。テストプログラムを先に書くことで細かい仕様を明確にすることができ、進ちょく管理も行いやすい。 　さらには、テストプログラムによってテストを自動化することで、テスト工数の削減と品質向上を同時に達成することができるという。 　ほかにもいくつものプラクティスがあるが、その根本を流れる思想は「仕様変更を積極的に推進しよう」というものだ。従来型方法論が仕様変更を嫌っていたのに対して180度異なる考え方であり、その結果こうした革命的なプラクティスが考案されたのである。

質問

マトリックスですから、タテとヨコの「軸」にどんな見出しがくるのかを考える必要があります。何行・何列になるかも含めて考えてください。 ただし、問題文に書かれていることだけを利用して考えてください。XPに関してあなたが上記の文章とは違う意見や、書かれていない情報を持っていたとしても、それはマトリックスには含めないでください。 マトリックスができたら、聞きたいことが出てくると思います。もともとの文章には、この文脈であれば当然書かれていてもよかったはずの、ある説明が抜けているのです。それは一体なんでしょうか。それを聞き出すための質問を作ってみてください。