シス開発：システム開発に必要な技術の概要 |
プログラミングの工程は、設計内容を現実のソフトウェアへと変換する作業である。決められた言語やツールを使い、仕様書に記述された処理内容のプログラムを作成する。見付かったバグを解消するまで作成作業は続く。一般的に、単体テストだけはプログラムの作成者が行い、それ以上のテストは別な担当者が実施する。テストでバグが見付かると、プログラムの作成者が直し、この繰り返しが開発の最後まで続く。
仕事で作成する（＝プロの）プログラムは、趣味で作る（＝アマチュアの）場合と大きく違う。信頼性はもちろんのこと、変更しやすい柔軟性に加えて、処理内容が分かりやすい把握性も求められる。また、対象となる分野によっては、処理速度を限界まで向上させなければならない。このうちどれを重視すべきかは設計段階で考慮され、個々のモジュールごとに明示する。
プログラムに要求される特性のうち、アマチュアともっとも違うのは、柔軟性と把握性である。機能変更に応じて修正しながら使い続けるので、柔軟性の高いプログラミングが絶対に必要だからだ。また、システムをチームで開発するため、作成者とは別な人が修正する場合もかなり多い。そのときの負荷を軽減する意味から、誰が見ても分かるような、つまり把握性の高いプログラムを作らなければならない。
実は、信頼性を高めるのにも、柔軟性や把握性が大きく影響する。プロにとっての信頼性には、システムを修正し続けた状態でも高く保つことまで含まれる。柔軟性や把握性が劣ると、修正によって信頼性が低下し、目標とする品質を維持できない。本当の信頼性とは、修正し続ける途中の状態も含んでおり、システムの使いはじめから使い終わるまでの全期間で評価すべきなのだ。
以上のような要求に耐えられるものを作れるのが、本当のプロといえる。これからの時代、柔軟性と把握性の確保はプロにとって非常に重要なので、もう少し説明しよう。
システムやプログラムの柔軟性を高める努力は、以前から行われていた。プログラムに関係する方法では、適切な機能に分けたモジュール分割、構造化プログラミングなどが有名だ。劇的な改善はできなかったものの、ある程度の成果は得られた。
最近の主流となっているのは、何といってもオブジェクト指向技術である。開発環境やツールが充実してきて、ようやく恩恵を受けられるようになった。新しいOSでは、オブジェクト指向のAPIを最初から搭載しているほどだ。
オブジェクト指向技術は、プログラミングだけでなく、システム設計にも大きく役立つ。両方に適用すると最大の効果を得られるので、設計段階から用いる。もっと本格的に活用する場合には、分析の工程から利用する。
オブジェクト指向技術の最近の中心は、フレームワークとデザインパターンである。フレームワークは、GUIを中心とした開発ツールが装備し、プログラミング作業の負荷を軽減する。デザインパターンは、クラスの良い設計例として参考にし、フレームワーク以外のクラスを作成するときに用いる。
フレームワークのほうは、GUI中心の開発ツールに付いているものなら、かなり簡単に使える。初心者からベテランまで、幅広く役立つ技術だ。ユーザーインターフェース部分だけなら、フレームワークによって簡単に作れる。ところが、対象分野ごとの独自機能に関しては、クラスから設計しなければならない。このときに、デザインパターンを利用する。大きな機能はシステム設計レベルで用い、小さな機能はプログラムレベルで用いる。そのためプログラマーは、デザインパターンを理解して、良い構造で作らなければならない。
デザインパターンを知っていたとしても、クラス設計は、高い設計能力を要求する。この点が、フレームワークと大きく異なる点だ。設計能力というより、設計のセンスという表現のほうが適切かも知れない。ともあれ、力ずくでは良い構造で設計できないのだ。つまり、ツールが進歩して柔軟性を高められるが、そのためには設計者にもプログラマーにも高い設計能力が必要となる。
把握性を高める工夫は、柔軟性のようにシステム設計に大きく関わるのとは異なり、プログラミングのほうに大きく関係する。プログラムの処理内容を理解しやすく作るのが目的で、変数名やコメントなどの付け方を標準化することで実現する。規定した標準化ルールを守ることで、プログラムの読みやすさを一定レベルに保つ。
もっとも基本的なルールは、変数名の付け方だ。構造体を含むデータ型、データ自体かポインタかハンドルか、グローバルかローカルかなどが、変数名を見ただけで分かるようにする。変数名だけでなく、クラス名、メソッド名、関数名なども同じ考え方でルール化する。
工夫の中で一番重要なのは、全体の制御構造を明確に伝えること。クラス間やメソッド間の関連なども含め、どんな構造になっているのか、素早く読みとれるように作る。メソッド名や変数名の付け方に加え、派手なコメントを上手に用いる。また、命令の並び順を工夫する方法も効果がある。
コメントの付け方では、説明対象の範囲を明確に示すようにルールを決める。対象が１行なのか、複数行なのか、１ブロックなのかでコメントの書式を変える。逆に、１行の命令に複数のコメントを付けることもあるので、このケースもルールに含める。
モジュールごとの機能や変更経歴なども、コメントとして先頭に明記する。また、開発途中での段階を区別して、ソースコードの管理を手助けする。最初のプログラミング段階、単体テストを終了した段階、開発が終了した段階などを区別できれば、同じ名前のソースコードが複数出てきたとき混乱が生じにくい。
これら以外にも工夫があり、アイデアしだいで把握性を向上できる。どの程度までやっているかは、組織によって大きく異なる。基本である変数名の標準化は、多く実施されているほうに入る。逆に、もっとも重要である全体の制御構造の明確な表現は、めったにルール化されていない。
実際の開発現場を見ると、仕事で作成するプログラムのすべてが、プロのレベルを要求されるとは限らない。それどころか、そのような作り方すら知らないでプログラミングしている組織のほうが、現状ではかなり多い。その原因には、いろいろなことが考えられる。いくつか挙げてみよう。
プログラミングを勉強するとき、雑誌や単行本の解説を参考にする。そこに載っているサンプルでは、非常に残念なことだが、プロのレベルで作られたものを滅多に見かけない。基本中の基本である変数名の付け方すら、まったく気にしないで作られている。こんな具合なので、プロのレベルには達していない。柔軟性に関する記事や本は、良いものをたまに見かける。しかし、把握性に関する記事や本は皆無に近く、あってもレベルがかなり低い。
もう１つ問題なのは、OSや開発ツールを作っている会社も、把握性に関しては理解していない点だ。OSが提供するAPI、開発ツールが提供するフレームワーク、両者が提供するサンプルのどれを見ても、把握性を考慮しているとは思えないものばかりである。ここでも、基本中の基本である変数名の付け方すら、プロのレベルに達していない。また、コメントの付け方もプロレベルには遠い。
このような例ばかり見ていたら、多くのプログラマーは同じように作って当然だ。プロレベルの作り方を知らないから、そう作らないのである。もし知っていれば、意識して作る人は確実に増える。逆に、プロレベルの作り方を採用している組織で働いた経験のある人は、その方法を強制的にマスターさせられ、言われなくてもきちんと作る癖が付く。そのような組織は非常に少ないので、全体としては少数派になる。なにしろ、OSや開発ツールを作っている企業ですら、プロのレベルを満たしていないのだから。つまり、本当の問題は、把握性を重視した作り方が広く知られていない点なのだ。
この状況を改善するには、把握性を向上させる具体的な工夫に関して、情報を広めるしかない。その際には、できるだけ良い内容を提供すべきである。アイデアしだいで工夫のレベルが高まるので、アイデアを徹底的に絞り出せば、良い標準化ルールが出来上がる。近い将来の話だが、このテーマで単行本を書こうと考えている。もし出版社が決まり、出版までたどり着けたら、本ウェブページで紹介するつもりだ。それまでの道のりは、近いか、遠いか．．．。
（1998年５月14日）
プログラミング：プロの作り方が求められる実現工程 |
