「システム開発地図」でトレーサビリティーを導入しよう！ 第1回：もう迷わないシステム開発（3/5 ページ）

[今田忠博, 近藤正裕，ITmedia]

仕様書・設計書の不備・不整合は非常に危険

　システム開発の現場では、

• システムはあるのに仕様書や設計書がない！
• 設計書はあるが、システムに変更を加えた後に設計書を直しておらず整合性が取れていない！

ということがよくあります。

　これらは、この業界が「工業化以前」とやゆされるゆえんでもあります。このまま開発・保守作業を進めると、確実にデスマーチに突入です。予算も人員も限られているのに、ドキュメントの不足や不整合のおかげで現行システムの仕様調査や確認などに想定以上の工数がかかります。そうなると、リリース時期が遅延したり、赤字プロジェクトになったりしてしまうのです。

　新規開発の場合は、途中でメンバーが抜けたりせずに最後まで同じメンバーで開発できれば、うまくいくこともあります。仕様書や設計書がなくても、メンバーの頭の中に情報があるからです。

　しかし、システム変更の際に必ず問題が発生します。業務要件が変わってシステムの仕様を変更しなければならない場合、ソースコード、データベース、設計書において修正が必要になる部分（影響範囲）を洗い出し、設計・実装・テストを行う必要があります。開発時のメンバーが残っていたとしても、システム開発時の詳細な記憶は残っていないことでしょうから、ドキュメントが残っていないと見積もりにも時間がかかり、その根拠もあやふやになります。実際に改修作業に入ってから問題が顕在化することが多々あります。

　新規開発に携わったメンバーがほとんど残っていない場合、事態は悲惨です。まず、変更の影響範囲はまったく分かりません。ゼロから業務とシステムを理解し、影響範囲を調査するための作業が必要になります。調査してもヌケ・モレが発生する可能性が高くなり、工数を読み間違える可能性も高くなります。今の機能が何のためにあるのか分からないと、「変更してもいいのか？」「不要なので削ってしまってもいいのか？」ということも分からず、影響範囲が正確に分からなければ、デグレード（現行のシステムでできていたことができなくなること）する可能性も高くなります。

　また、各作業の担当者が、「何をやったらいいか分からない」とか「何を元に何を作り出せばいいか分からない」という状況になってしまいます。担当者に指示すべき責任者にも分からないのです。「何を元に何を作り出せばいいか分からない」というのが積み重なって、最初にやりたかったことができるはずがありません。

コラム:　テストの自動化の話

　仕様書がきちんとあったとしても、テストの自動化は別途取り組んでおく必要があります。

　自動テストが仕様書替わりということもあるでしょう。

• 機能を修正します　→　デグレードしていないか確認するテストを（人が）やり直すので、10人日かかります

　こんな状態では、テスト工数ばかり膨らんでしまいます。

　自動テストにはいくつかレベルがありますが、なるべく頻繁に自動的にテストを行って、期待と異なる差分を早めに検知することが重要です。

　例えば筆者の参加しているプロジェクトでは以下のようにしています。

• JavaならJUnitによるメソッド単位の自動テストをソース修正のたびに行う
• WebアプリならSeleniumによるブラウザの自動操作で毎晩ユーザー業務と同等のテストを行う

　テストの確認内容にもレベルがありますが、メソッドの戻り値だけではなく、DBの値や画面のHTMLが期待値とずれていないかまで確認することもあります。こういう場合は、期待値を作るのが大変にならないような工夫もしています。

　この話は別途どこかでお話ししたいと思います。