適切な仕様書でバグ発生を防ぐ(2ページ目)

仕様書がテスト仕様書になる

仕様書は、プログラマーだけでなくテストを行うテスターにも必要となります。できあがったプログラムが仕様通りに動いているかどうかテストしますが、大きなプロジェクトになると設計者ではなくテスターが行うからです。テスターはテスト計画書を作成してテストを行うとき、元となるのは仕様書です。テスターにも分かるように仕様書を記載しなければなりません。

日付チェックにうるう年計算をして入力チェックすると仕様書に記載されていれば、2月28日、2月29日を入力してテストを行う必要がでてきます。

仕様書で大切な事は常に最新の状態にすること。仕様はプロジェクトの進行と共に刻々と変化していきます。条件が複雑化していくとプログラミングの段階で仕様書の修正が発生することもよくあります。

「Aという状態になっている時、ボタンが押されたらXという画面を出す」「A以外の状態でボタンが押されたらこうする」と仕様書に記載しておいたところ、他のシステムの影響でたまたまAの状態になることがあり、設計者が想定していなかった事象が発生します。仕様から見なおさなければなりません。

多くのプロジェクトでは、開発におわれて仕様書のタイムリーな更新がなされません。テスト段階でテスターから設計者に「仕様書とプログラムの動きが違うのですが」と質問があがり、「仕様書はこうなっていますが、仕様変更しました」というやり取りが頻繁に発生することになります。

仕様変更になった場合は履歴が分かるように変更箇所を線で引き、余白などに変更内容を記載します。この時に日付も入れておきます。全体を清書して書き直すのは全てのテストが終わってプロジェクトが収束する段階で行います。

仕様書の更新を設計者まかせにしておくと、設計者によって対応がまちまちになってしまいます。プロジェクトマネージャーは定期的に仕様書のチェックをして整合性がとれているかチェックする必要がありますが、毎週月曜日の特定時間を仕様書修正時間として確保するなど設計者が守れるようにする工夫が必要です。

運用管理での仕様書変更が重要

開発プロジェクトが終わった段階で整合性がとれた仕様書になっていても、稼働後のシステム運用できちんとメンテナンスすることが大切です。運用開始後、根拠としていた法律が変わったり、お客さんからの意見などを元に会社方針を決定して業務に例外処理を付け加えたりすることでプログラムはどんどん変わっていきます。

きちんとテストを行いますが、どうしてもプログラム修正とテストが中心で仕様書のメンテナンスがおざなりになります。該当するプログラムを修正した歴代の担当者はドキュメント修正を守っていたのに、1人だけ修正を守らなくてもプログラムと仕様書に整合性がとれなくなります。

システム稼働から時間が経ち、いろいろと不具合が出始めるとシステム再構築を行います。現行システムがどうなっているか分析するために仕様書をまず確認し、念のためプログラムを確認します。この時、仕様書とプログラムに不整合を発見すると、現行システム分析に仕様書は使えません。1人だけが仕様書をメンテンナンスしていなかったとしても、そんなことは分析段階では分かりません。不整合を発見すると他の仕様書も同様と疑うしかなく、プログラムから現行システムを確認せざるをえなくなります。仕様書は参考にしかならず時間がかかる作業になってしまいます。

→　キーマン獲得がIT導入成功のカギ
→　プロジェクト・マネジメントの極意
→　システム開発の注意点
→　システムリリース前の注意点