top / index / prev / next / target / source

2005-06-15 diary: コンピュータ・ソフトウェアの本質 , SWTスクリーンセーバ

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

コンピュータ・ソフトウェアの本質 , SWTスクリーンセーバ

コンピュータ・ソフトウェア業界に職業として携わっていると、意外にもソフトウェアの本質が見えなくなりがちです。

コンピュータ・ソフトウェアの本質

私はコンピュータ・ソフトウェアに職業として携わっています。仕事としてソフトウェア開発に携わっていると、ふと本質を見失っていたりすることがあるので、とても危険です。ここで自戒の念を込めてソフトウェアの本質について立ち返って考察を行っておきます。

そもそも原則として、ソフトウェアは何かを実現するために存在します。ほとんどのソフトウェアは「何か」を実現するために存在しているはずです。ある場合は、何かハードウェアを駆動するために、そしてある場合は○○システムとかいうコンピュータで実現されるシステムそのものとして、ソフトウェアは必要になってきます。何かを実現するために、ソフトウェアは存在し、あるいは新規作成されたりするのです。(私の身近なところで説明をとどめています。私が知っているような世界以外にもコンピュータ・ソフトウェアの開発は存在していることについては、これ以上は触れません…)

コンピュータ・ソフトウェアは、そもそも開発しない方がよい

それら何かを実現するためのソフトウェアが必要になってきたときに、私たちは該当するソフトウェアを いずこからか手に入れるか、または新規に開発する必要が出てきます。ここで最初の重要なことなのですが、そもそもの原則として、私たちはソフトウェアを新規開発は行わないほうが良いのです。何かパッケージソフトを購入してきたら、必要な機能が全て実現可能で、しかも新規開発を行うよりもトータルとして安価である場合には、特別なバイアスがかからないかぎりパッケージソフトの購入および導入の方が不確定要素が少なく、リスクも少ない場合が多いです。最近では フリーソフトウェアやオープンソースといったものがあって、無料でパッケージソフト品質ものが手に入る時代になってきています。何かソフトウェアを新規開発したら各種試験を行わないと品質が維持できませんが、既存の適切に試験が行われたパッケージソフトであれば、今すぐに最終形の機能性・操作性を確認することができます。極端な話、新規開発のうちのコーディングを気合いで一瞬で完了したとしても、その後工程の試験が必要ですので余計に新規開発のコストを押し上げます。第一の本質は、「コンピュータ・ソフトウェアは新規開発しないにこしたことはない」というところにあります。既に存在して、無料またはそれに近い価格で、サポートが適切に受けられる、そんなソフトウェアが既に存在していれば、そちらを利用した方が良いのです。（むろん、営業的な都合とか政治的な都合など さまざまな理由によって、コンピュータ・ソフトウェアは新規作成された方が良い場合はたくさんありますし、だから私たちは生活していくことができています。）

コンピュータ・ソフトウェアは、規模が小さければ小さい方がよい

第一の本質という難関を突破したら、次にコンピュータ・ソフトウェアを開発するものとして気をつけなくてはならないのは、「原則として少ない規模 (多くの場合ソースコードの量) になるように開発した方がよい」という本質です。これを見失わないことは重要です。ものすごく単純化していえば、ソースコードの本数は少なければ少ない方が良いし、ソースコードのファイル数は少なければ少ない方が良いのです。関数・メソッドの数も、原則として少なければ少ない方が良いです。しかし一方で１つのソースコードあたりの行数も基本的に少ない方が良いです。また1つの関数・メソッドについても、ぱっと見て把握できる程度の行数にとどまっている方が良いです。とにかく人間が一度に把握できる何かリソースの規模というのは限られたものであるので、ソフトウェアの規模は可能な限り小さければ小さい方が良いのです。むろんソースコード・ファイルの数について無理に削減する必要は無いです。人間が理解しやすい粒度によって分割されているべきです。しかし本質論的には、そもそものソフトウェア規模は小さければ小さい方が良いし、一人の人間が把握しなくてはならないソフトウェア規模についても、同様に小さければ小さい方が良いのです。また、規模が大きくなればなるほど、ソフトウェアの試験が困難になることも見逃せません。規模に対して指数的に試験実施が難しくなる傾向もあるので、その点が深刻です。試験といえば、試験のためのソースコードも当然少なければ少ないにこしたことがないのです。そもそもとして、試験そのものも 実施しない あるいは少ない実施であっても品質が維持できるのであれば、なるべく試験はやらないにこしたことが無いのです。

コンピュータ・ソフトウェアは、なるべく単純である方がよい

ソフトウェアの複雑さについても、「原則として なるべく単純なように開発した方がよい」ということを見逃してはなりません。私の身近な職業的ソフトウェア開発においては、開発者と保守者とが別人になることがほとんどです。そのような中で、ソースコードを他人が読む・変更するコストなどの都合から、可能な限り単純な実装を行っていることが重要です。原則として、例えばオブジェクト指向言語であったならば、オブジェクトはなるべく導入しない方が良いです。デザインパターンについては、それを導入するのに見合う、よほどの複雑さでも無い限り、導入しない方が良いのです。オブジェクトにしてもデザインパターンにしても、それを導入するのに見合う複雑さがあって、それらをオブジェクトやデザインパターンが解決するというときに、初めて導入するかどうかの検討が加えられるべきようなものなのです。とにかくなるべくシンプルに、単純に、開発をするように心がけます。

コンピュータ・ソフトウェアは、なるべく純粋であった方がよい

そもそもコンピュータ・ソフトウェアには 上記のような本質があり、これは見失ってはなりません。(職業的な業務システムなどのソフトウェア開発の場合は特に)その上で これら本質からはそれるのだけれども 現実的な必要に駆られて道を踏み外していくのが現実的な開発なのです。その現実と理想とのバランスを取っていくことがとても大切です。現実的には ソフトウェアは そんなに単純ではないので、オブジェクトを仕方なく導入したり、あるいはデザインパターンをやむを得ず導入していくことになります。ここで重要なことは、それらが仕方なく、あるいはやむを得ず導入されるものであるという点です。ソフトウェアの本質とは逆行するのだけれども、それを導入しないことにより余計に複雑になったり、あるいは煩雑になるという場合にのみ、ソフトウェアの本質に反するもの (オブジェクト指向やデザインパターンなど) を導入するのです。つまり オブジェクトやデザインパターンとは基本的に 不純なものなのです。不純なものを導入して 全体としてはだけれども純粋に近づく、それらバランスを取りながら、不純なものを混ぜていくのです。○○フレームワークのたぐいにしたって、基本的には不純なものなのだけれども、導入しておかないと全体としては逆に不純になってしまう、だから導入するのでしょう。

そのようなことで コンピュータ・ソフトウェアの本質としては、それが存在しないことがもっとも純なものになるのでしょう。コンピュータ・ソフトウェアは存在しないほうが良いのです。なにかハードウェアだけでそれで全てが事足りるのであれば、ソフトウェアは登場しません。私たちは このように本質を求め続けて自己否定を行い続けるのでしょうかね…。この点は矛盾しているけれども、だけれども見失ってはならないことだし、常に考え続ける価値を感じます。

複雑さは、それに見合った複雑さを解決する場合にしか導入すべきでない

しかし本質論の全く逆のところにも本質があります。「Eclipseプラグイン開発環境」というものを見てみると別の考えを突きつけられます。EclipseプラグインはそれがEclipseの中で適切に動作するように、こってこてのデザインパターンが適用されています。デザインパターン 技のデパートといった勢いです。EclipseプラグインのAPIおよびそのために導入されているデザインパターンについては、あれらが導入されるのにふさわしい複雑さを兼ね備えています。そうなのです。業務システムのたぐいとは異なり、Eclipseプラグインのようなものには、どうしてもデザインパターンのようなものの導入が必要なのです。ああいう素晴らしいものが導入されていないと、私たちは毎回 Eclipseと同等の統合開発環境を開発しないかぎり、追加機能に相当する部分が開発および提供できなくなってしまいます。ソフトウェアを開発しないために、複雑さを許容して、結果としてソフトウェア開発規模を削減する、これもまた本質なのでしょう。EclipseプラグインAPIは そのデザインパターンの導入に見合うだけの複雑さがあり、それによってトータルとしてのソフトウェア開発規模の低減化に成功しているのです。

トータルとしてのバランス

いずれにしても、基本的には本質を見失わずに、それでいてトータルとしてバランスを取るということが重要なのでしょう。多くの場合 極端な部分最適化は全体の最適化をむしばんでしまうのです。ソフトウェア・システムの全体感、あるいは参加メンバなど、様々な要素についてバランスを取りながら、トータルとしての統一感・最適解を目指して 日々精進していくことが肝要なのでしょうね。バランスを取るためにもっとも良い方法は、各種成果物を (同じ仕事に従事している)他のメンバーにレビューしてもらうことです。特に直接関与する他のメンバーからの意見には多くの情報が詰まっています。意見が割れた場合には、多数決を取るのがもっとも良い方法です。特にバランスという観点では 意志決定の際には 関与するメンバーによる多数決というのは最適解である場合が多いからです。例えば、クラスの設計などの際には可能な限り他のメンバーのレビューを受け、意見が割れた際には多数決を採って選択肢を定めるということが、バランスのとれた最適解として十分に説得力があります。

関連するリソース

関連する日記

コンピュータ・ソフトウェア・エンジニアの本懐

それでいて、職業の話を抜きに考えたら コンピュータ・ソフトウェア・エンジニアの本懐としては、何でも自分で作りたくなる (開発したくなる) という側面を持っている人がいます。少なくとも私はそうです。私は私の守備範囲のものは 何でも自作開発しがちです。プロという立場を抜きにしたら、およそ何でも興味を持ったソフトウェアについては時間が許す限り自作し続けていることでしょう。やっぱり OSとかデバイスドライバとか 自作してみたいなぁ。そこのところあたりが本懐なのでしょうね。

関連する日記

SWTによるスクリーンセーバー (SwtScreenSaver) α版リリース

a-sanが SWT版の スクリーンセーバ (およびスクリーンセーバ開発キット) を作成されました。現在のステータスはα版とのこと。

マンデルブロートのスクリーンセーバは とてもキレイです。しばらく私の端末のスクリーンセーバとして活躍する予定です。

関連する日記

JavaのログをRSS

世の中には ものすごく刺激的なアイデアが存在するものです。

Log4jのXML出力について、私にとっては刺激的でしたが、今回は RSSへのロギングです。RSSリーダーで Javaアプリケーションのログを閲覧したりできて、何か今までで私には思いもつかなかったような利用の仕方が存在しそうです。

…それにしても RSSって流行りましたね。インフラとして定着した感があり、RSSを流行らせようとがんばっていた私 (2002年のテーマが RSSを流行らせることだった…)にとっては感無量です。

関連する日記

この日記について