私が参考にしているサイトにこんなのがある。コンピュータネタ、目次へ
硬派!!ソフトウェアエンジニアとマネージャのためのホームページソフトウェアプロジェクト管理のコンサルタントのサイトなのであるが、非常に内容が充実している。ここまでコンサルタントの手の内を書いて飯のタネは大丈夫か？と人ごとながら心配になるほどだ。
書かれていることには「そんなにエネルギーをかけられないよ」と言いたくなることもあるが、非常に参考になる部分も多い。特に印象に残った二つをあげるなら
- 「詳細スケジュールで、３日以上続くプロセスはない。」
- （確かにそうだ。オンスケジュールといいながら、最後になって慌てるよりは、タスクを３日未満のものに分割し、遅れがその日のうちに分かるようにしておいた方がよい。）
- というのと
- 「従来の開発標準は、全て新規開発の標準である。実際には派生（修正、変更）開発が大半を占める。」 であろう。
２番目の指摘は実に痛い。報道されるシステムトラブルでも「前日のプログラム変更が原因で」というのが極めて多いのだ。これらのトラブル原因は大きくまとめれば「システム変更時の影響調査洩れ」である。これは派生（修正、変更）開発時に固有の問題である。
ではどうやってそれを防ぐか、というわけで派生（修正、変更）開発の場合に特有な開発手順を考えてみた。但し影響調査洩れを防ぐという目的に限ってである。特に開発手順に定められていなくとも、システムに変更を加える場合は、どこに影響があるかを洗い出すものである。これはシステム変更の依頼があってから開発の見積を行うまでの期間に行う。かくして影響調査洩れが生ずるのはこのフェーズがうまくいっていないからだ、というように見える。ならば、ここを改善するよう開発手順を定めるべきだ！
確かにそんな風に思える。しかし、ここを改善するのは困難である。また最善の手でもない。理由は次のとおり。前者については特に説明の必要も無かろう。問題は後者である。
- 多くの場合、見積に対して対価は支払われない。従って、このプロセスにかける工数はできるだけ削減したくなる。
- 開発フェーズの中でもっと影響調査を熱心に行っている部分がある。
自分がやってきたことを考えると、影響調査について最も思いを巡らしているのは、新規開発の設計フェーズではなかったかと思うのだ。ここで、将来考えられる変更に対して最も影響が少なくなるように、システムを設計しているのだ。
- 例えばこんな具合にだ。
- 「手数料体系が変更になったらどうする？−−−読み込みテーブルに体系コードを一つ入れておいて・・・当初は全部10でいいや・・・プログラムの中で体系コードをみて、別々の外部テーブルを読みに行くようにしよう。」
- 「今は月次バッチだからこれでいいけど、日次バッチになったらどうする？−−−前回実行日付を入れるエリアに月だけでなく日まで入れるようにしておこう。入力時の前回実行日チェック部分は、、、これはそのときに修正しないと仕方がないなあ。」
- 「今は部署コードが２桁だけど、支社を一括管理するようになると部署が増えて３桁必要になるかもしれないけどどうする？−−−部署コードの直後に予備エリアを１バイト空けておいてそれを使えるようにしよう。まあ予備というと入力データを作ってもらう方に説明がしにくいから、当初は枝番として定義しようか。」
ところが、修正のときはこれほど神経を使うわけではない。一つには作った人とは違う人間がメンテするからであろうし、一つには修正に多くの工数を割くわけにはいかないという事情が普通の組織にはあるからだろう。現実的には変更の要求をなんとかシステムに反映させて、ほっと安心、といったところだろうか。
ところが修正のときに神経を使わない理由はもう一つある。せっかく将来の変更に備えて設計したのに、それらがうまく伝わっているとは限らないからである。元々の設計者が何を考えたか、気にしようもないのだ。
例えば先ほどの最後の例、もし「部署コードが３桁になった場合は、枝番の１バイトをつぶして使う」という設計内容（というより設計時の思い）がドキュメント化されていなかったらどうだろう。多分部署コードを含む全ファイルを洗い出し、それらを読み書きする全プログラムを修正するという大手術になるだろう。せっかく手を打っておいたのが無駄になってしまうのだ。
従って、そういう、完成したシステムには直接には関係のないことであっても、設計書には残しておきたいものである。
あくまで設計時の思いだから、完成したシステムから見れば、どうでもいいことのように思われ、設計書に記載するのはふさわしくないように見えてしまうから実施は難しいけれども。ただし、ドキュメントに残したことが思わぬ悲劇を招くこともあり得る。
途中で部署コードに枝番が必要になったとする。（当初は部単位で管理すれば良かったのが、課単位の管理が必要となった場合などが考えられる。）修正した人間は当たり前のように既にある枝番のエリアを利用する。修正工数ゼロである。（まあテスト工数とデータの変換は必要かもしれないが、プログラムの修正は不要である。）
従ってドキュメントは残らない。（プログラムに手を加えないのにドキュメントだけ変更するというのは、著しく直感に反した行為である。）
更に修正が入る。今度は当初懸念したとおり部署コードが３桁になる。設計書を読んだＳＥは「この枝番のエリアを使えばいいんだな」とさっさと修正する。誰も間違ったことはしていない。
しかし結果は、課単位で管理していた部分がぐちゃぐちゃになり、トラブルとなる。原因は「影響調査洩れ」とされる。最後に修正したＳＥは「確かに自分が悪いのかもしれないけど、素直に反省できないなあ」という感想であろう。彼から見て悪いのは、当初設計時の修正に対するバッファーを食いつぶしたにも拘わらず、その記録を残さなかった前任者である。
こういう事象を完璧に押さえる技法はよく分からないが、まあ引き出せる教訓。
- システムの修正開発時には設計を変更するが、その際に「今後の拡張・修正に耐えられるような」設計も同時に変更されている。システム修正時には次のような事項を検討し、設計に含めること。
- 「この修正は、既存の設計が前提とした修正の範囲内か？」
- 「この修正は既存の設計が想定していない修正の可能性を作り込んでいないか？」
ここで残されたドキュメントが、次回の影響調査時の基本資料となるはずだ。
かっこよく決めたつもりだったが、よくみるとやはり新規開発の話になっていた。(^^;