ソフトの質はコード量に関係するか？ 株式会社ピーデー 川俣 晶 2001/11/17

---

前回に引き続き……

　前回の「ソフト開発を成功させる1つの方法」は珍しく大きな反響があったが、不幸にも記事の趣旨が分からない読者も多かったことが分かった。同意するか不同意かという以前に、分かってもらえないのでは、話が始まらない。前回が分かりにくかった理由は、3つ考えられる。1つ目は、文字数不足。残念ながら、このコーナーには無限の文字数が許されてはいないのだ。2つ目は、強く経験に依存すること。経験したことがない人には、そんなことが起きるなど、想像もつかないかもしれない。3つ目は、筆者の表現力不足。これは平に申し訳ないと思う。

　以上の点を反省して、今回はポイントを絞って分かりやすく書こうと思う。また、どこで読んだかも覚えていない格言ではなく、ソフトウェア開発手法の1つであるエクストリーム・プログラミング（以下XP）を基に話を進めてみたい。

　実は、XPとは何かについて、これまで筆者は誤解していたらしい。そのことに気付いて、『XPエクストリーム・プログラミング入門』（ケント・ベック著、ピアソン・エデュケーション発行）を買って一気に読み通した。こんなに胸熱く感動的な本を読んだのは久しぶりである。この本の著者は、きっと、筆者と同じような現場の泥沼を経験しているに違いない。

　では、XPとはいったい何なのか。XPは、複雑高度な理論を実現する重量級の手法ではなく、経験則を重視する軽量級の手法である。職場の環境の作り方、プロジェクト管理の方法、顧客との付き合い方などの方法論の集まりである。具体的なコーディングの方法を示すものではないが、コーディングを行うときの目指すべき方向性は示されている。また、複雑な理論に沿って使うものではないので、やり方さえ飲み込めば、高度なコンピュータサイエンスの知識なしに実践できる。

量と質の関係

　よく聞く意見として、「読みやすくするためならプログラムは長くなってもよい」「分かりやすければ、プログラムは長くてもよい」というものがある。それに対して、筆者が前回紹介したものは、この常識に真っ向から逆らう「短いプログラムの方がよい」という主張である。このことから、川俣ってのは気がふれた男に違いない、と思った人も多いかもしれないが、もし筆者の気がふれているというのなら、世の中には気がふれたプログラマがたくさんいるということになる。実は、XPでも、プログラムを短くすることを要求しているからだ。XPの実践者はみな同類ということになる。

　XPにおいては、具体的に2つの方法で、プログラムを短くすることを求めている。1つは、「クラスの数とメソッドの数が最低限になっている」ようにすること。これは、無理やりすべてのクラスを1個にまとめ、すべてのコードを1個のメソッドに記述せよ、ということではない。クラスやメソッドは普通に記述すればよいのである。そうではなく、そのプロジェクトでは不必要な機能や、重複した機能を削り落とすことを要求しているのである。これは、「クラスを作成するときには再利用を考えて、汎用的な設計にせよ」という教科書的な正しさに真っ向から逆らうものだ。XPでは、「明日できることは今日やるな」という原則があり、次のプロジェクトで使うかもしれないという理由で、現在のプロジェクトでは不必要なメソッドを追加することを禁じているのである。

　もう1つは、「スコープを削減する」と表現されている。より分かりやすくいえば、要求仕様の中から本質的にいらないもの、重要度が低いものを取り除け、という意味である。つまり、顧客に要求を変えさせるのである。これも、「そんなバカな」と感じる人が多いと思う。従来の常識からいえば、とんでもない話だろう。お客さまは神様で、欲しいというものは何でも作ってあげるべきなのだ。顧客が欲しがるものは、たとえ無意味でも作れば売り上げになるのだ。それを開発側が自ら切り捨てようとするなど、非常識に思えるかもしれない。

　ここまで読んで、XPは当たり前のことを述べているにすぎないと思う人もいれば、現実離れした非常識なことしかいっていないと思った人もいるだろう。おそらく、後者の人から見て、前者の人は気がふれているように見えるだろう。

経験則的な正しさとは？

　筆者の過去の経験から考えると、XPが述べている方法論は、おそらく正しい。再利用を考えないことも、スコープを削減することも、表現に多少の差があるにせよ、前回筆者が述べたことである。しかしこれらは、過去に多くの人たちによって正しいやり方だと認められた経緯があるものだ。それを、どうして否定できてしまうのだろうか。

　最も簡単ないい方は「理論と実践は違う」というものだろう。しかし、この言葉は筆者の好みではない。このようないい方をされるのは、理論の使い方を間違ったか、理論の名に値しない単なる仮説が破れた場合が多いからだ。現実的な話をすれば、この世界には「銀の弾丸」つまり「絶対に成功する方法論」などというものはない。ということは、どんな理論であろうと、「ある条件で成功する確率を上げる」という以上のものではない。ここでポイントは「ある条件で」というところである。すべての個別の理論は同じ条件で有効というわけではない。それどころか、ある理論を実践することにより、別の理論の条件を壊してしまうこともある。つまり、「正しい理論や常識を集めても、全体が正しいとは限らない」ということである。

　例えば、「プログラムの読みやすさ」という価値基準でものを考えれば、読みやすさを最大化するために、長さに注文を付けるべきではないと考えるのが正しいだろう。しかし、処理の流れを追いやすいように同じ処理が繰り返し出てくるようなソースを書けば、バグが出たときの修正が面倒になる。同じような処理のどれにも同じバグが入っているなら、ソース上のすべての個所を修正する手間が必要だし、直し忘れが出る可能性もある。それを考えると、同じ処理は1カ所にまとめてあるソースの方が直しやすい、ということも正しい。どちらの正しさを優先すべきかは、何を目指すかにもよるのだが、少ない手間で最大の効果を求めるのなら、デバッグの都合を優先すべきだろう。何しろ、デバッグは時間もかかるし苦労も多い作業なのだ。つまり、多少読みやすさを減じるとしても、重複処理を取り除いて短くする方が望ましいといえるのである。

　もちろん、ここで述べたことは、ほんの一例であり、XPのヒトカケラにすぎない。これが短いプログラムを勧める理由のすべてではないし、今回述べたことがXPのすべてというわけでもない。XPに興味がある人は、上記の書籍や解説書を読むことをお勧めする。

とはいえ難しい

　実は結論は前回と同じだ。XPは優れた方法論だが、おそらく多くの組織では採用するのは難しいだろう。XPは決して難しくはないが、仕事のやり方を根底から覆される場合が多い。これまでうまくやってきたのに、その方法を捨ててXPをやるか？ といわれればしり込みする人が多数派だろう。

　例えば、XPではプログラマが2人で1台のパソコンを使ってコーディングするペアプログラミングを勧めているが、自分の後ろでだれかが自分のコードのアラを探すというのは耐え難いほど恥ずかしいかもしれない。本当は、バグを出して残業するぐらいなら、ペアに素早くバグに気付いてもらった方が定時で帰れてハッピーなのだが、「そういわれても……」という人は多いだろう。

　それでもXPは実に興味深い方法論であることに変わりはない。採用するしないに関係なく、勉強してみると面白いと思う。もし、実践するチャンスがあれば試してみるとよいだろう。きっと、プログラミングの別世界が見えると思う。

---

川俣 晶（かわまた あきら）
　株式会社ピーデー代表取締役、日本XMLユーザー・グループ代表、日本規格協会 次世代コンテンツの標準化に関する調査研究委員会 委員、日本規格協会XML関連標準化調査研究委員会 委員。1964年東京生まれ。東京農工大化学工学科卒。学生時代はENIXと契約して、ドラゴンクエスト2のMSXへの移植などの仕事を行う。卒業後はマイクロソフト株式会社に入社、Microsoft Windows 2.1〜3.0の日本語化に従事。退職後に株式会社ピーデーの代表取締役に就任し、ソフトウェア開発業を始めるとともに、パソコン雑誌などに技術解説などを執筆。Windows NT、Linux、FreeBSD、Java、XML、C#などの先進性をいち早く見抜き、率先して取り組んできている。代表的な著書は『パソコンにおける日本語処理/文字コードハンドブック』(技術評論社)。最近の代表作ソフトは、携帯用ゲーム機WonderSwanの一般向け開発キットであるWonderWitch用のプログラム言語『ワンべぇ』(小型BASICインタプリタ)。

「Insider.NET - Opinion」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）