システム開発プロセス改革を3年間かけて行った結果 (2)

こんばんは、コンサルタント兼ITエンジニアの R & K です。
前回に続いて、システム開発プロセス改革に取り組んだ内容を書いていきます。

背景

前回の要求定義の改革に続いて、要件定義フェーズで要件定義書の見直しに取り組んでいくのですが、私がチームに加わった時は、要件定義も外部設計も、まともな仕様書がそもそも存在しない、あってもメンテされていないという悲惨な状況でした。

当然、要件定義で何書くの？という状況だったわけですが、その前にドキュメントの形を作り上げていくことから始めていきました。

システム仕様書"標準仕様" (笑)

ドキュメントに何を書くべきか、文書の体裁はどうするか、どうすれば作成がしやすいか、何のために作成するのかなるかなど、色々と検討事項が出てくるので以下の内容で標準化しました。

1. ドキュメントのフォーマットを新たに作成し、「システム仕様書」として標準化とする
2. ファイルは Microsoft Word で作成し、ファイル形式は .docx とする
3. 必ず目次と改訂履歴を入れる
4. 「システム仕様書」に、章立てで要件定義・外部設計・内部設計の内容を盛り込む

5. システムの納品時に、印刷してファインリングし、成果物のひとつとしてお客様に納品する

   補足

   1. 昭和の香りがするデザインとはおさらばして、それなりに見栄えする体裁・表紙にしました
   2. Excelの方が良いとの声もありましたが、方眼紙も含めて捨てました。Word がベストではないものの、正しく操作を覚えれば十分使えます。Excel のように表がずれないし、何より印刷がしやすい。
   3. しっかりした文書の体裁にこだわっています。
   4. それぞれを別の文書にするにもムダなので、ひとまとめにしました。
   5. 設計と文書化をしっかりやっていることを説明して、設計単価を上げるのが狙いです。

何のためにドキュメントを作成するのか

これを理解していないと、めんどくさいといった意見に負けてしまいます。
私の場合は確固たる意志を持って、次のように目的を定義しました。

1. エンジニアの頭の中にある設計を文書にアウトプットし、お客様と共に設計レビューを実施する。これにより仕様漏れを軽減できる。
2. 外注エンジニアにプログラミング工程を依頼する場合、ドキュメントをもって説明することで納品物の完成度を上げる。

3. 保守フェーズで、担当エンジニアが変わることを想定し、引継ぎの資料としてドキュメントを利用する。

   補足

   1. ソフトウェア品質の作りこみは、上流工程から。
   2. 今まではドキュメント作成ができなかった為、必ず内製で、口頭で仕様が伝えられるプログラマーに負担が掛かっていた。
   3. 大抵の場合、担当者の変更や、退職の度に大慌てしていた。

これらの取り組みにより、ようやくドキュメント（システム仕様書）を作成する下地ができました。次回は要件定義のドキュメント化について書いていきたいと思います。