シス開発：システム開発に役立つ様々な視点 |
どんな言語やツールでも、使い方を勉強するための書類が付いてくる。リファレンス・マニュアルではなく、ユーザーズガイドに相当するものだ。また、基本的な使い方を習得するために、チュートリアル用の書類が用意されることもある。どちらの書類でも、作成したサンプルが登場する。
問題なのは、用意されたサンプルの質である。システム開発で用いるツールの場合は、きちんとした作り方が求められる。しかし、説明に用いられたサンプルは、そんな点など何も考慮していない。機能を理解するのが主な目的のためか、システムなんて知らない素人が作ったようなレベルのものが多い。このような結論に達したのは、いろいろなツールのサンプルを見た経験からだ。
ちょっと古い話だが、一番最初に見付けた例を挙げてみよう。かなり以前（約15年前）に、IBM製の大型汎用機でオンライン・システムを開発していた。使用したツールは、CICS（Customer Information Control System：バッチ処理主体の汎用機上で、オンラインシステムを実現するためのミドルウェアのようなソフト）という日本で広く使われているものだ。メーカー製の説明書を読むと、簡単なサンプルが載っている。問題なのは、そのサンプルどおりに作ると、システムの柔軟性が低下し、処理内容も把握しにくくなる点。
もう少し具体的に説明しよう。端末に表示する画面データを用意し、プログラムから端末に送るような仕組みになっている。画面ごとに機能を分けて設計するので、プログラムと画面が１対１で対応したほうが、システムの構造をすっきりさせられる。しかし、CICSで発生するトランザクションは、画面を表示したら終了し、画面に入力し終わってから新たに発生する。このように画面表示とデータ受け取りが別なトランザクションとなるため、サンプルでは、あるプログラムが画面を表示して終了し、その画面に入力したデータを受け取るのは別なプログラムになっていた。画面とプログラムが１対１で対応しないので、システムとしては最悪の作り方である。
CICSの機能を調べると、あるプログラムから別なプログラムを呼び出す機能が見付かる。これを利用すれば、画面とプログラムが１対１で対応する作り方が可能だ。画面を表示したプログラムは、画面に入力した後も再び呼び出されるようにする。そのプログラムでは、入力された値を判断して、該当する別なプログラムを起動させればよい。新しく呼び出されたプログラムでも、対応する画面データを端末に送り、そのまま終了する。画面が入力し終わったら、表示したプログラムが再び呼び出されて、必要な時点で別なプログラムへと制御を受け渡す。すべてのプログラムを同様に設計すると、CICSのようなトランザクション発生の構造であっても、画面とプログラムを１対１で対応させられる。
この例のように、ツールやシステムが持つ機能を分析すると、最適なシステム設計のガイドラインが導き出せる。にもかかわらず、所属していた組織が構築した既存システムでは、勉強用のサンプルと同じ構造で設計されていた。結果として、システムの構造が美しくなく、メンテナンス性が非常に低い設計だった。メーカーから提示されたサンプルは勉強用でしかないのに、それを真似る人が実際にいるのだ。
勉強用のサンプルを真似る設計者は、それほど多くないだろうと思っていた。ところが、何年か後に大手のソフトハウスに派遣で行ったとき、サンプルと同じ形式で作っているのを知った。CICSではなく、オンライン部分で似たような機能を持つIMS DB/DCというツールでだが。業界では技術力が高いと言われてるソフトハウスでさえ、サンプルを真似て作ってしまうのだ。この時点で、サンプルの怖さと重要性を改めて感じた。
以上は大型汎用機での経験だが、それ以外の分野でも、似たような状況を何度か目撃している。たいていの開発者は、メーカーが提示する説明書どおりにシステムを設計する傾向が強いようだ。ツールや言語が持っている様々な機能を調べて、どのように組み合わせたら美しい構造で設計できるのか、検討してから使用する人は非常に少ない。結果として、メーカーから提示されたサンプルを真似ることになる。
メーカー側で勉強用の説明書を作ってるのは、システム設計の経験がない人だと推測する。また、メーカー全体としても、勉強用の書類なので、良い設計など気にしていないだろう。しかし、それを真似る人がいる以上、質の良いサンプルを採用しなければならない。それによって、余分な苦労をせずにシステムが構築でき、自社のツールの評判も上がるからだ。
良いサンプルを作るためには、設計ルールを導き出せる技術者が必要となる。もし社内にいないのなら、ツールを実際に使っているユーザー企業から探せばよい。利用者である優秀な開発者のほうが、使う上でのノウハウや設計術を持っているからだ。早い時期に資料やソフトを渡して、より良い使い方を設計してもらえば、遅くならずに良いサンプルが入手できる。最初の説明書から採用したいのであれば、かなり早い時期に資料だけで検討してもらう方法も考えられる。この種の作業は大変なので、当然のことだが、きちんと謝礼を払うべきである。頼む人が見付からない場合は、ユーザーに広く公募して、日頃から見付ける努力をしておきたい。
最初に登場した時点で良いサンプルを提示できないなら、注意書きを付けたほうがよい。たとえば、「この作り方はあくまで勉強用のサンプルなので、そのまま真似しないでください。実際にシステムを設計する際には、持っている機能を幅広く調べ、最適な設計方法の検討をお勧めします」などと。この記述だけだと不親切に思われてしまうので、「上手な設計方法は現在検討中で、○月頃に公開する予定です」と加えておく。もちろん、サンプルを提供する準備は万全にして。
良い設計例の紹介では、そうする理由をきちんと説明することが重要だ。どんな点を考慮し、対処するためにどのように設計するのか、論理的な解説を加える。そのような説明があれば、読んだ人の設計能力の向上も手助けし、別な設計方法を思い付く可能性もある。全体として、良い方向に進むわけだ。
メーカーが提供する勉強用のサンプル以外にも、真似てほしくない例をいくつか目にする。その代表例は、雑誌や単行本に掲載するサンプル・プログラムだ。一般ユーザーを読者としているならまだ許せるが、開発者を対象にしている場合は言い訳できない。
レベルの高い開発組織では、開発する様々な要素に関して、品質を維持するために標準化ルールを規定している。画面設計ルール、制御構造の設計ルール、データベースの構造やフィールド名のルール、プログラム名の命名ルールなどだ。もっとも重要度の高いのが、プログラムのコーディング・ルールで、変数名やクラス名の付け方、コメントによる各種説明の加え方、制御構造の明示、エラー処理の方法などを細かく規定している。こうすることによって、個人的な好みでコーディングされるのを防ぎ、処理内容が読み取りやすいので、メンテナンス性を向上させられる。同時に、コーディング上の問題点を発見しやすくするなど、品質の向上にも貢献する。
レベルの高いコーディング・ルールを知っている人ほど、雑誌や単行本に掲載されるサンプルは、素人が作ったように見えてしまう。この種のプログラムが普通に掲載される背景は、きちんとしたコーディング・ルールが知られていない現状がある。そんな状況が続いている大きな原因は、コーディング・ルールを紹介しない雑誌にあるだけに、かなり情けない状況といえるだろう。
コーディング・ルールは、言語の仕様に依存するため、言語ごとに作成しなければならない。また、ルールのレベルもピンからキリまであり、より優れたルールを知ったほうがよい。もうそろそろ、開発情報を扱う雑誌では、設計に関する各種標準化を取り上げてよい時期ではないだろうか。かなり遅すぎるのだが、今からでもやったほうが絶対によい。
少しだけ明るい材料もある。オブジェクト指向の世界では、デザインパターンを中心に、上手な設計方法が紹介されつつある。かなり体系化されていて、パターンの名称も標準的な用語として使えるレベルに達している。ただし、パターンを利用したサンプル・プログラムは、コーディング・ルールを知らない人が作っているようなので、かなり素人っぽい例となっている。この点だけは非常に残念だ。
当分の間は、雑誌や単行本で見るプログラムは、勉強用のサンプルとして限定しながら見たほうがよい。機能を理解するとか、限られた設計の仕方を知るといった目的に。
以上のような話を知って、説明に使われている各種サンプルの位置付けが理解できたと思う。たいていの場合、設計の良い例ではないのだ。システム開発に携わる人は、メーカー製や出版物のサンプルを全面的に信用しないほうがよい。
新しい言語やツールを使い始めるときは、それが持っている機能を全般的に調べて、設計ガイドラインを作る癖を付けよう。どのように設計したら、処理内容が把握できて、柔軟性が向上するかを検討する。もちろん、理想だけを追い求めるのではなく、実行速度や設計者の技術レベルも考慮し、現実的な範囲内で規定することが大切だ。
設計ガイドラインの作成は、一人でやるとかなり大変である。もし一緒に開発する仲間がいるなら、みんなで集まって良い設計方法を検討するよい。いろいろな視点での意見が聞けて、非常に勉強になるからだ。自分が勤めていたときも同僚と一緒に考え、いろいろな設計方法について語り合ったのを覚えている。
良質の設計ガイドラインが得られたら、その内容をメーカー知らせて、説明書を作り直させるのも良い方法だ。また、より良いシステム設計のために不足する機能や、改良して欲しい機能なども一緒に提案する。設計ガイドラインを提示できるユーザーと言うことで、相手も真剣に受け取るだろう。このようにしてメーカーを鍛えてあげれば、ソフトが現状よりも使いやすく改良される可能性が高まる。ツールを改良する材料は、そのツールを使う人が一番持っているのだから。
業界全体として見た場合、高度な機能を追い求める傾向は強いが、システム設計に信頼性や柔軟性を与えるとか、処理内容を把握するための機能を強化する傾向は弱い。そんな状況を改善するためには、実際にシステムを設計している人が、より良い視点や改善案を提示する必要がある。
（1999年３月25日）
勉強用のサンプルは低レベルなものが多い |
