第２回 システム開発方法論を学ぶ
プロジェクトに参加していれば自然と設計方法やドキュメントの書き方などが次第に身について来ます。しかし、時々は、システム開発方法論について本を読んだり講習会に参加したりして、体系的に学ぶ機会があれば非常に有用です。
プログラム規約とガイドライン
幾ら立派なシステムの構想書や立派なプロジェクト計画書が存在しても、結局は、システムはプログラムで動いています。以下に述べるようなプログラムの規約やガイドラインがあるかどうかは、プロジェクト成功の一つのカギとなります。プロジェクト内にきちんと存在すれば、よく読んで参考にしましょう。もし、このようなガイドラインや規約が存在しないとすると、プロジェクト全体として改善する必要があります。しかし、もはや手遅れかもしれません。
いずれにしても、次に自分が参加するプロジェクトにも応用できるように、自分ならばどのように規約やガイドラインを作るか、構想を練っておくと良いでしょう。
1. プログラム構造
プログラムの種類（オンライン、オンライン遅延処理、バッチ処理、外部I/Fなど）毎に、プログラム構造のガイドラインや、処理の考え方が書かれていること（所謂アプリケーションアーキテクチャがしっかり定義されていること）。
たとえば、スキルレベルやバックグラウンドの異なるプログラマーが参加するプロジェクトでは、以下のようなことに言及している規約の存在は大変重要です。
-
プログラムの構造についての注意それぞれのプログラム種類ごとにメインプログラム、サブプログラムなどの構造が定義されており、雛型があることが理想的です。共通ライブラリが定義されていることも重要なことです。例えばエラーログを出力するライブラリや業務上の日付を取得するライブラリなどは共通ライブラリとして提供してしかるべきです。
-
その他の留意点
プログラムの再起動性について
途中で異常終了した場合に、その後、再起動されても処理が続行可能なようにプログラムを作っておく必要があります。勿論、プログラムそのもののバグやデータの異常の場合には再起動しても同じ箇所で異常終了するはずです。しかし、例えばサーバのダウンなどの場合には、サーバを再起動して（あるいはクラスタサーバの他方から）同じプログラムを再起動することが有ります。そのときに処理を最初から、あるいは途中からやり直せるようになっている必要があります。トランザクション途中でのネットワークI/O、あるいはターミナルI/Oの禁止
データベースなどの共有リソースをロックするトランザクションの途中では、ディスクファイル、メモリ以外のデバイスのI/Oは原則禁止です。入力待ちやリトライによりI/Oがいつ終了するか予測できず、共有リソースのロック時間が予想できないからです。
2. エラー処理の規約
エラーの認識方法について、つまり例外処理によりエラー処理を行うのか、それともファイルI/Oやシステム呼び出しのステータスを確認してエラーを認識するのかについて明記されていること。
また、OSが認識しないアプリケーションレベルの論理的なエラーが発生した場合に、どのように対処するかについて明記されていること。
さらに、エラー認識後のプログラムの処理（ログへの書き出し、外部の監視システムへの通知方式など）について明記されていること。
3. パフォーマンスに関する注意点
大きなトランザクション、大量データの抽出、更新処理など、CPU、メモリ、ディスク、ネットワークなどのリソースに大きな負荷を掛けるプログラムについて、何らかの制限事項や守るべき規約が書かれていること。例えばネットワークに異常な負荷をかけないように、端末（クライアント）側に返すデータ量が数十KBを超えないようにし、超える場合には数回に分ける、といったガイドラインがあること。
4. データベースアクセスや排他処理のガイドライン
データベースのトランザクションの開始と終了方法、デッドロック発生時のリトライ処理をどうするか、排他制御について書かれていること。更新時の排他制御のやり方は一般的に以下のようになります。
会話型の処理では画面に表示されたデータは静的であり、一方、データベース上のデータは動的で他のユーザや他のプログラムが更新していることがあります。従って、画面に表示されたデータを基にデータベースを更新する際には、画面に表示している間にデータベースに更新がなかったことを確認しなければなりません。
更新しようとする行に予めロックをかけると同時に読み取ります（データベースによってはトランザクション開始でテーブルロックを掛ける場合もあります）。読み取ったデータが画面に表示していたデータと同じであること（他で更新されていないこと）を確認し（一般的には最終更新時刻を比較し）、更新します。もし、他で更新されていたら、一般的には更新せず、アプリケーションレベルのエラーとして返します。
また、読み取りの一貫性を保つための方式についても規約が必要ですし、パフォーマンスのいいSQL文の書き方や、複雑なSQL文についての留意事項などは重要です。
5. 構造化手法
1970年代に提唱された構造化手法は、システムの機能を分析する手法ですが、設計からプログラミングまでの一貫性がないという欠点があります。しかし、その分かりやすさ、とっつき易さで、今でも手続き型言語の範囲のプログラム開発であれば、次のデータ指向アプローチと組み合わせて一般的に使われている手法ですので、一通り学んでおく必要があります。
ただしDFDだけではうまく表せない場合がありますので、適宜、文章、他の図面などで補ってやる必要があります。例えば、データだけでなく指示の流れも付け加えたり、状態と発生するイベントによりシステムがどう動くかを状態遷移図にしたりすると有効です。
データ指向アプローチ
データ指向アプローチは、1980年代に提唱されたデータの構造分析手法です。データ指向アプローチは、システム開発には欠かせない手法で、習得は必須です。ER図を使ってデータ構造を明確にして行きますが、これもやはりER図だけでは表現しづらい場合がありますので、適宜文章などで補いましょう。
データ指向アプローチは構造化手法と組み合わせてシステム開発の現場で使われて来ましたが、今では次のオブジェクト指向と組み合わせて使われる場合が多いのではないでしょうか。
データ指向開発
1980年代にオブジェクト指向が提唱されて最近までは、システム開発にあまり応用されてはこなかった、と言っても過言ではありませんでした。オブジェクト指向が理解しにくいのは、「プログラムとデータが一緒に隠蔽化されている」ことです。従来のシステム開発手法に慣れ親しんでいる人たちにとってみれば、もともとデータベースというデータの保管母体とプログラムは別ものであり、プログラムとデータを何故一緒に隠蔽化しなければならないのか理解しづらいところです。とは言うものの、多くの設計者は、あまり意識せずにオブジェクト指向的なものの捉え方をして今までシステム設計をしていました。例えば、一塊の機能や、関連する他のシステムをオブジェクトとみなして、オブジェクト指向的なシステム設計を行う人達はたくさんいました。
しかし、最近ではJAVAやオブジェクト指向、C言語、オブジェクト指向設計手法であるUMLがどんどん一般的になってきており、設計からプログラミングまで一貫してオブジェクト指向で通すシステム開発が行われて来ています。オブジェクト指向は、プログラムの設計からインプリメントまでを一貫した手法で行えるという特徴を備えています。つまり、設計の粒度を上げるとそのままプログラムになってしまうということです。
一方、いまだにデータベースはリレーショナルが主流でありオブジェクト指向ではありません。つまり、リレーショナルデータベースを使う以上、プログラムがデータベースと出会うところでデータはオブジェクト上ではなく、やはりデータベースにあることを認識させられることになります。
将来、オブジェクト指向開発を本当にサポートできるオブジェクト指向DBが台頭し、オブジェクト指向プログラムとDBとの間のギャップも無くなり、SQLという古臭いデータアクセス方法が過去のものとなる日が来るかも知れません。
勘と知恵
システム開発方法論をいろいろ知っていたとしても、最後に救ってくれるのは人間の勘と知恵です。設計中に「何か設計がおかしい、もっと単純化できないか」と思ったら、ほうっておかずにもう一度考えてみましょう。
手前味噌になりますが、私の経験では、一つのシステムに最低一つは「勘と知恵」で切り抜けたケースがありました。たとえば複数の接続先ごとにタイマー管理しなければならない仕様だったものを、検討して一つのタイマーで済むように変える、などといったことでした。この場合は単にシステムの一つのロジックに過ぎないのですが、このロジックの単純化のおかげで全体が複雑にならずに済みました。
皆さんも、「何かおかしい、納得できない」という自分の勘を大切にして、考えてください。きっと雲が晴れるようにすっきりする知恵が浮かんで来るはずです。