ソフト開発を成功させる1つの方法 株式会社ピーデー 川俣 晶 2001/10/20

---

20年前の言葉

　もう20年ぐらい前の話に遡る。筆者は、何かの本で驚くべき説を読んだ。経験豊富な大ベテランのプログラマが言うには、

「短いプログラムは無条件で正しい。なぜなら、短いプログラムは短いというだけで実行速度も速く、理解も容易であるからだ」

というのだ。経験も知識も乏しい筆者は、そんな馬鹿なと思った。使い勝手をよくしたり、プログラムの高速化を行うとプログラムは大きく膨らむのだから、プログラムサイズが増えることを否定しては、よいプログラムが生まれるわけがない。そもそも、プログラムの善しあしを、中身も見ないでサイズだけで論じることがおかしい。そのように、筆者は考えたのである。

　その後、さまざまなプログラムを書いた。言語もさまざまだ。その結果として、実体験から来る経験則のようなものができてきた。だが、よいプログラムとは何か、という問題と深刻に向き合うようになったのは、30歳を超えてからだ。つまり、30歳を超えてからは徐々に体力が低下していき、無茶をやって強引に辻褄を合わせることが難しくなってきたのだ。そして、35を過ぎたら、もう無駄のある方法論を体力で乗り切ることは、できなくなってしまった。よいプログラムというイメージを確定させ、寄り道せずにそこに直進する以外、選択肢がなくなってしまったのである。

　そして、たどり着いた結論は、よいプログラムは短いプログラムである、という20年前のベテランの言葉と同じものであった。短いプログラムは、すぐ作れるし、内容もすぐ理解できるし、バグもすぐに潰せるし、気に入らなくなったら書き直しても手間は掛からないし、起動も速いし、使い方を理解するのも容易、と、よいことばかりである。実はコーディングが汚くても短ければ解読は難しくない。例えば、goto文によるスパゲッティ状態といっても、本数が少なければ、混乱しないで対処できるのである。つまり、短ければ、短いというだけで、大抵の問題は解決してしまうのである。

CUIの復権とオブジェクト指向との別れ

　短いプログラムでは複雑な処理ができないではないか、と思う人もいるだろう。もちろん、そのとおりである。本当に必要な機能に絞り込んで短いプログラムに仕上げれば、単機能のプログラムになるのは必然である。しかし、プログラムはいつも単体で使わねばならないという決まりはない。複雑なことをやりたいときは、単機能のプログラムを集めて連携させればよいのである。最も手っ取り早くそれを実現する手段は、コマンドライン・ツールとしてプログラムを作り、バッチで組み合わせてしまう方法である。一見、時代遅れに見えるCUI（Character User Interface）の復権だが、実は慣れればCUIの方が遥かに強力であり、根強いファンも多い。実際に、筆者は多くの単機能のコマンドライン・ツールを開発しているが、どれもニーズがあって作ったものである（筆者が開発し、公開しているオンライン・ソフト一覧）。また、知らない人も多いが、Windows NT／2000のコマンドプロンプトは、MS-DOSのcommand.com時代から大幅に拡張されている。これはまさに、CUIへのニーズが本物であることの証拠といえるだろう。

　もちろん、コマンドライン・ツールなど使いこなせないという人が多数派であることは分かっている。だが、筆者の目的は、最小のエネルギーで、最大の効果を得ることである。この趣旨に賛同するなら、コマンドライン環境を学ぶべきだ。それにより、より少ない労力でより多くの成果を得られるようになる。

　一方、筆者が別れざるを得なくなったのがオブジェクト指向である。オブジェクト指向といえば、クラスの再利用性が重要といわれるが、筆者の経験からいえば、再利用を意識したクラスを作ると、当面必要のない機能まで書き込む必要が生じて、時間と手間を食う。しかも、手間を掛けてもそのまま再利用できるケースはほとんどない。そのうえ、使わない機能がソースコード上にあることで、ソースの分かりやすさは低下する。再利用を意識しても、結局よいことはあまりない。

　また、現実のモノになぞらえたモデリングを行うあまり、何重にもクラスの継承を重ねることもあるが、これも問題になる。このようなクラスは、メソッド呼び出し1つでも、いったいどのクラスのメソッドが呼び出されるのか分かりにくい。モノになぞらえるよりも、継承の数を減らした方が、ずっとソースコードが分かりやすくなる。1980年代には、goto文がプログラムを分かりにくくする悪とされたが、継承は21世紀のgoto文といえるかもしれない。

　これらのことを、筆者は、実体験の中から身体で理解させられた。その結果、再利用性を意識することはやめ、継承を減らすためにクラスも必要最小限度という方針転換して、やっとプログラムを円滑に組めるようになった。後で考えれてみれば、短いプログラムは正しいという原則どおりの結論といえる。

事例で見る常識の危うさ

　実際のコードで見てみよう。C++で書いたものだが、問題は行数だけなので、C++が読めない人も問題ないだろう。以下の2つのクラスを比較してほしい。まずは、実装をクラスの内部に隠し、メソッド経由でしかアクセスできないようにした例である。つまり、オブジェクト指向の特徴である隠蔽を活用した書き方である。

1:　class CSample1  2:　{  3:　    int m_sampleData;  4:　public:  5:　    int getSampleData（） {  6:　        return m_sampleData;  7:　    }  8:　    void setSampleData（ int value ） {  9:　        m_sampleData = value; 10:　    } 11:　    // 続く... 12:　};

　次は、実装を外部に見せてしまった、オブジェクト指向的には悪い例。

1:　class CSample2 2:　{ 3:　public: 4:　    int m_sampleData; 5:　    // 続く... 6:　};

　さて、オブジェクト指向的には、上の方が正しいのだが、短いプログラムは正しいという原則を適用すると、下の方が正しいということになってしまう。オブジェクト指向が上のコーディングを勧めるのは、インターフェイスを変えずに実装を変えられるからだ。万一実装が変更になったとき、その影響がプログラム全体に波及すると、たいへんなことになるので、インターフェイスと実装は分けておく方がよいのである。しかし、短いプログラムなら、全部捨てて書き直してもよいぐらい短いので、全面的な書き換えが発生しても、たいへんなことにはならない。それよりも、ソースコードを短くして、読みやすくする方が重要である。実装の変更は起こるかどうか分からない頻度の低い出来事だが、ソースコードはデバッグのために何度も見る羽目に陥るのだから、見やすさの方がはるかに重要である。

短いプログラムを支持するC#とWebサービス

　すでに、C#入門「第12回 インデクサとプロパティ」の「まとめ」で述べたことだが、C#で記述するとソースの長さが短くなる傾向にある。一方、Javaは、限られた小さな言語仕様が提供する基本的な機能の組み合わせてソースを記述するので、どうしてもコーディングが回りくどくなる。つまり、同じ内容を記述したとき、C#の方がJavaよりも短くなる傾向にある。これは、短いプログラムは正しいという原則に照らしてみれば、JavaよりもC#の方が開発を成功させやすい言語であるということになる。

　また、現在話題のWebサービスも、実は短いプログラムを支持している。Webサービスのコンセプトは、ネットワーク上に存在するWebサービスを集めて、簡単にアプリケーションソフトを実現しようということなので、個々のWebサービスは従来と比較してずっと短いプログラムになると考えられる。その短いプログラムを集めて使うというのは、コマンドライン・ツールをバッチで集めて使うのと発想は同じである。だが、Webサービスは、全世界に広がるインターネットを舞台に機能するため、コマンドラインよりも、はるかに強力なツールになるだろう。

これまでのネットワークサービス・アプリケーションとWebサービス時代のアプリケーション

従来のアプリケーションでは、たとえ内部的にはオブジェクト指向の流儀に従って開発しても、最終的に出来上がったものは1つの大きなプログラムになる。これに対しWebサービスでは、機能単位などで、互いに独立した複数のWebサービスが連携しながら、全体としての処理を進めるようになる。

注意点

　短いプログラムは正しいという原則は、筆者が正しいように思えると感じているだけで証明されたわけでもないし、正しいということを保証できないことは、明確にしておく。

　最後に1つだけ注意を述べよう。短いプログラムは正しいという原則は、ほとんどの職場では実践できない。なぜなら、プログラムの値段はステップ数や人月を基準に計算されることが多く、できるだけ大きなプログラムを作った方が売り上げがあがるからだ。それは、筆者が開発の現場から身を引いた理由の1つでもある。思いどおりにプログラムを書こうと思ったら、趣味でプログラムを書きながら技術解説屋をやるしかない、ということである。

---

川俣 晶（かわまた あきら）
　株式会社ピーデー代表取締役、日本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メールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）