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

第3回　マトリックスの課題をレビューする

開米瑞浩（アイデアクラフト）
2004/5/28

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

■模範解答例と評価ポイント

　前回「第3回　最初の一歩はマトリックスから」で出題した問題について、総勢30名以上の方からご応募をいただきました（下の「問題文」と「質問」を参照ください）。本当にありがとうございました。

問題文

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

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

質問

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

　それでは早速レビューを始めましょう。総計31の応募の中で、私がほぼ正解と思うものが3名、あと1歩、というのが14名ほどでした。まずは、模範解答例を見てみましょう。

（A1）プラクティス （A2）どんな方法か？ （A3）メリットは？ （B1）シンプル設計 （B2）使うかもしれないものは、作らない （B3） （C1）ペアプログラミング （C2）2人で一緒に同じプログラムを書く （C3）ノウハウ伝承。問題を発見しやすい （D1）テストファースト （D2）先にテストプログラムを作る （D3）仕様の明確化。進ちょく管理 （E1）自動テスト （E2）テストを自動化する （E3）テスト工数削減。品質向上 （F）XPの根本思想：仕様変更を積極的に推進すること （G）質問：シンプル設計のメリットは何ですか？

表1　XPのプラクティスの方法と効果

　 主な評価ポイントは以下の3点です。

（1）横軸で「方法」と「メリット」を分離できていること
（2）縦軸に「プラクティス」を列挙すること
（3）「テストファースト」と「自動テスト」を別項目として分離できていること

　なお、縦と横は逆になっていても構いません。

　（1）と（2）ができていれば、「シンプル設計」のメリット（B3）が空白なこと（書かれていない）に気が付きます。すると自然にそれを疑問に思うため、（G）のような質問になるわけです。

　（F）の項では「XPの根本思想」について書いてあります。XPのこれらのプラクティスが全体として目指しているものであることを示すために、総まとめのようにして最下行に1行使っていますが、この（F）はマトリックスの外に出しても構いません。要はほかの個々のプラクティスとは別枠扱いになっていればよいわけです。

■よくある間違い例とその原因

　よくある間違いとしては、まず（1）ができていないものがあります。方法とメリットを分離していないと、（B2）と（B3）が一緒になってしまうため、（B3）の空白に気が付きません。

　次に（3）ができていない解答も目立ちました。問題文では「テストファースト」と「自動テスト」ははっきり区別して書かれているのですが、これを同じ1項目に交ぜて書いている例がかなりありました。これを交ぜてしまうと、（D2）と（D3）、（E2）と（E3）の対応関係があいまいになってしまいます。

　ではどうしてそのような間違いをしてしまうのでしょうか。まず「方法」と「メリット」の区別については、原文にこの2つの単語がないことが大きな理由と思われます（表2）。

（A1）プラクティス

（A2）どんな方法か？

（A3）メリットは？

　マトリックスの見出しである上記3つの概念が、原文でははっきりと提示されていません。それどころか、「常識を覆すような方法（プラクティス）がいくつも提唱されている」という一文があるため、「方法」と「プラクティス」を同一の意味で使っています。この辺りも誤解を招く要因になっています。

　次にテストファーストと自動テストについては、どちらも同じ「テスト」という単語が付いていることから、同一視してしまったものと思われます。これはうっかりミスのようなものですが、人間の意識がいかに「似た名前」に惑わされやすいかを示しています。だからこそネーミングは重要です。似た名前を見つけたら特に注意してその意味を検証するようにしてください。

■全体の文脈を考える

　さて、次に少し大きな視点でこの問題の全体の文脈を考えてみましょう。

　実はこの問題文の中には2種類の異なる文脈が存在します。図にすると下記のようになります。

図1　問題文に存在する2種類の異なる文脈

　つまり、（S）従来型方法論とXPとの比較、（T）XPについてのみの検討、の2種類です。原文はこのうち主として（T）の方に大半の比重があり、（S）は部分的に記載されています。

　このため、マトリックス化するとき、（S）と（T）を両方書くか、それとも（T）だけにするかが問題になりますが、この問題の場合はどちらでも大差ありません。Sの方は情報量が少ないためほとんど空白になってしまいますが、それを覚悟のうえで書く分には（S）と（T）を両方併記しても構いません。

　模範解答例は（T）だけを書いてあります。これは（S）の情報量が少ないので省略し、必要だったらそのときに別な表を書こう、という方針で、十分現実的なものです。

■読者解答レビュー

　さて、それでは読者の解答の中から目立ったものをレビューしていきます。

　次の表2は、Jさんの解答の一部です。

設計 プラクティス シンプル設計 内容 将来の変更を考えずに設計する

表2　読者（Jさん）の解答の一部

　この解答で問題なのは、シンプル設計について原文では「いずれ使うかもしれないものは、作らない」と書いてある個所を「将来の変更を考えずに設計する」と書き換えてしまっていることです。

　同じことではないか、と思われるかもしれませんが、同じではありません。これはXPについてある程度知識がないと分からないことですが、XPの「シンプル設計」というプラクティスは、「将来の変更を簡単にできるようにするためにシンプルな設計を維持する」ことが真の意図です。つまりXPでは「将来の変更」を非常に重視しているわけです。それを、「将来の変更を考えずに」と書いてしまうと、「将来の変更を重視しない」というニュアンスを与えてしまいます。そのため、この書き換えは不適切です。

　このケースでは書き換えによって意味が歪んでしまいましたが、書き換えを全面禁止するのは現実的ではありません。書き換えによって意味が明解になるケースも非常に多いものです。

　現実的には、間違った書き換えをしてもそれにすぐ気が付いたらすぐに修正すればいいと割り切って、どんどんやるべきでしょう。マトリックスで整理すると、人にチェックしてもらうのも非常に早くできますから、心配しないでやりましょう。コミュニケーションは人を救います。そしてマトリックスはコミュニケーションのための道具なのです。

　次にFさんの解答の一部です。

シンプル設計 ペアプログラミング テストファースト 原則 いずれ使うものは作らない 2人で同時に同じプログラムを書く テストプログラムを書いてからビジネスロジックを書く 期待する効果 不明 問題の早期発見 仕様の明確化により進ちょく管理が容易 開発に対する影響 不明 生産性の向上 生産性の向上 テスト工数削減と品質向上

表3　読者のFさんの解答の一部

　この解答ですと、左端の列に「効果」と「影響」がありますが、効果と影響にはどんな違いがあるのかがはっきりしません。例えば「生産性の向上」は「期待する効果」として考えてもおかしくないはずです。マトリックスを使うとき、このようにタテ・ヨコの位置がずれても通じてしまうような項目（見出し）の切り方はよくないので注意してください。マトリックスをいったん書いたら、個々のセルの中をタテヨコにずらしてみてチェックしてください。もしずらしても意味が通じるようなら危険信号です。

　次はOさんの例です。

シンプル設計 ペアプログラミング テストファースト テストプログラミング 生産性 高 品質 挙がる 進ちょく 管理 できる 情報共有 できる 問題発見 早期発見 早期発見 仕様変更 積極的 積極的 積極的 積極的

読者のOさんの解答例

　これも縦軸の項目がおかしいですね。その結果、全体として空白の多い表になっています。こんなに空白が多くなったら、項目の切り方が間違っている可能性が高いと判断し、一度ゼロから考え直した方がよいでしょう。

■原文が良くない

　さて、ここまで読んだら、もう一度原文を読み返してみてください。

　これは果たして良い文章でしょうか。「文章」としては悪くないかもしれません。例えば技術雑誌の評論記事としては自然に読めることと思いますし、専門書でもこのような解説文はよく見掛けます。

　しかし、「読ませる」文章としての長所が同時に「理解させる」文章としては短所になっていることには注意するべきです。

　1つの大きな問題は、文章化するために余計なレトリックを駆使していることです。もし分かりやすく書くとすれば、「○○○○というプラクティスは、＊＊＊＊という方法であり、これには＊＊＊＊というメリットがある」というフォーマットを守って書くべきです。しかし、実際はそうなっていません。「ペアプログラミングが推奨されている」「XPの原則はテストファースト」「テストを自動化することで」などのように、プラクティスについての言い回しだけでも何種類も使われていて、これらをすべて解読しないと、元のマトリックスを再現できないわけです。

　こうしたレトリックは文学的な「文章」をすいすい読ませるためには有益ですが、コミュニケーション用の「文書」では使うべきではないのです。

　文章にはこうした「一見読みやすいが実は分かりにくい」ものが非常に多いです。それらからマトリックス構造を解読するためには、日常的にマトリックス感覚を身に付けておくことが重要です。