第2回：開発モデルに共通するドキュメントをまとめる視点 (3/3)

テストは漏れなく、限られたリソースでの最低限の確認が求められる

ソフトウェアが完成したら、それを確認する作業、いわゆるテストになります。テストでは顧客向けドキュメントに対して漏れなく確認を実施することが大切です。加えて、暗黙的に備えていなければならない機能に対しても漏れなく確認しなければなりません。漏れが無いテストの実施をサポートするよう、ドキュメントを作成する必要があります。

また、テストには限られたリソースで最低限の確認をしなければならないという側面もあります。最近のソフトウェア開発は短納期化しており、テストに十分な工数が避けられないこともあります。ただでさえ厳しい納期に追い討ちをかけるように、前工程で発生した遅れのしわ寄せがすべてテスト工程にまわってきます。そのような状況でも必要十分なテストが行えるよう、ドキュメントを作成する必要があります。

図3：テスタ向けドキュメントに影響するもの

「テスタ」に対して「ソフトウェアをどのように確認すればよいか」を説明する

テスタが確認を漏れなく実施するためには、漏れの無い確認項目を作成することが必要です。確認項目は、顧客向けドキュメントの内容に対して漏れが無いように作成します。これは顧客向けドキュメントがきちんと作成されていればそれほど難しいことではありません。しかし、顧客向けドキュメントが不十分な内容の場合には、一転して困難な作業になります。開発の早期からテスト工程のことを考えておくことは重要であり、特に開発ドキュメントの作成は大切です。

また、暗黙的に備えていなければならない機能に対する確認項目も必要となります。ソフトウェア開発においては、顧客向けドキュメントで触れられていない「暗黙的に要求される機能（Webシステムにおけるセキュリティなど）」があります。テストでは、そのような機能についても確認する必要があるでしょう。これらはプログラマ向けドキュメントで検討されている場合もありますが、されていない場合はスキルのある開発者に考えてもらうか、社内で詳しい人を探して協力を仰いで作成することが必要です。

また、限られたリソースで最低限の確認をするためには、手順が重要になります。詳細な手順が書いてある操作マニュアルを用意できれば、テスタによらず一定のテストが実施できますが、人手や時間の問題で難しいのが現状です。そういう場合には、「確認の勘所」をまとめたドキュメントを作成しておくことが非常に役立ちます。ここでいう勘所とは、例えば「入力欄のテストでは、最大文字数とその+1文字を入力する（限界値チェック）」といったような簡単なものです。当たり前のことの漏れが原因で失敗するプロジェクトは山ほどありますので、基本的なことを記述しておくだけでも十分効果があります。また、このようなドキュメントは再利用が可能です。

今回は、ものづくりの流れにあてはめて、開発ドキュメントをまとめる視点いついて考えてみました。今回の内容は、開発の進め方によらず必要なものであると筆者は考えています。プロジェクトの内容に応じて開発モデルを変化させても、開発ドキュメントをまとめる基本的な視点は変わりません。

さて次回は、開発モデルのうちウォーターフォールモデルにフォーカスを当てます。 タイトルへ戻る