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

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

なぜ仕様書・設計書と実装の整合性は取られないのか？

　なぜ開発現場ではこのような状況が改善されず、ずっと放置されているのでしょうか？

　1つには、動いているコードを重視する文化があります。緊急を要するメンテナンスの場合、とにかくコードの修正を優先し、ドキュメントの修正は後手にまわりがちです。そして次第にドキュメントとコードの整合性が失われていきます。

　また、「プログラムができさえすれば、設計書や仕様書はドキュメント生成ツールで生成すればいい」という考えのベンダーがおり、発注側も形式的なチェックしかできないという問題もあります。このようなケースでは、前後のつながりや設計目標や制約などの必要な情報が書かれていないドキュメントばかりが残されることになります。

　しかし、クラスやメソッド単位のドキュメントは自動生成できるとしても、プログラムの概要や動作の仕様書は生成できません。文章や図を交えて書き下さなければならないのです^（注2）。

　企業では、ベンダーが客先に社員を常駐させて、開発・保守・運用まで面倒を見ているところが少なくありません。このような体制の場合、ベンダー側の担当者が同じシステムを何年もメンテナンスしており、その作りや修正方法を熟知するようになります。担当者が変わらない限りは、ドキュメントの不備に関する問題が顕在化することはありません。発注者であるお客さまは、予算内で納期通りにちゃんと動くシステムができさえすれば、「設計書がちゃんとしているか、仕様書との整合性が取れているか」などということはチェックしないし、開発者もお客さまから与えられた情報から求められるシステムができたら目的達成であり、「仕様書や設計書にモレはないか」「設計書にどのような情報を残すべきか」などにはあまり注意を払わないのです。

　しかし、このような、「人に依存した」システム開発・保守・運用体制は、長い目で見ると、顧客にとってもベンダーにとってもよいことではありません。業務改革などでシステムの刷新が必要になったときに、システムの情報が足りないとか、ドキュメントの情報の信頼性や精度が低いとかいったことでつまずいてしまいます。より技術力が高く、コストパフォーマンスが高い他のベンダーにスイッチすることもできません。“ベンダーロックイン状態”です。ベンダーにとっても、工業化以前のようなビジネスモデルに甘んじて何年も過ごすことで、技術力・競争力の停滞を招きます。別の顧客のプロジェクトにアサインされても、全くキャッチアップできないなどという事態にもなりかねません。

　企業で使われる業務システムは、5年や10年のタイムスパンで運用・保守していくものがほとんどです。悪しき習慣を改善していくためには、その期間の保守のために必要なドキュメントを作成して維持することもシステムの保守に含まれるということをあらためて認識すべきではないでしょうか。

---

注2：　仕様書を変更するコストは実装してしまったプログラムを変更するコストより遙かに低いということをJoel Spolskyが指摘しています（Joel On Software 2004）。Joelによると仕様書の役割はプログラムをデザインすることです。最初にちゃんとデザインしてからコードを書くようにしましょう（もちろん、アーキテクチャや実現方式の検証など、仕様書を書く前にコードを書いて試さなければならない局面もあります）。