制限事項に負い目を感じるべからず

　制限事項があると、ユーザーに悪いような気がしてしまう「人のよいエンジニア」がまれにいますが、制限があるのは決して悪いことではありません。要件を満たしていれば、TOOMUCHな実装するより、いらない機能はそぎ落とし、シンプルな設計にしたほうがよいのです。

　例えば残高集計がバッチ処理だとしても、顧客の業務がそれで十分運用できるのであれば、無理にオンライン処理にして日中サーバに負荷をかけたり、開発予算超過の心配をしたりするよりは、断然よいと割り切るべきです。

　しかし後で問題にならないよう、ユーザーに納得してもらう手続きが必要です。通常、要件定義時にもある程度説明済みだとは思いますが、顧客というものは大抵、われわれが覚えていてほしいことに限って、なぜか忘れてしまうものです。

　また、設計を進めていく上で新たに出てくる機能上の制限もあります。したがって、基本設計の段階でこのようなドキュメントを用いて、あらためて確認しておくことが大切なのです。

よい設計は量ではない

　品質の鍵は、まずは上流工程のコミュニケーションにかかっています。特に基本設計フェーズでは2つの方向に濃厚なコミュニケーションをとる必要があるため（図3）、それを手助けするツールとしてDUNGEONテンプレートの概要説明を紹介しました。

　特徴としては、顧客への説明と詳細設計以降を担当するSEに対する説明を、たった1枚で簡潔に行うことを意識して作成している点です。ボリュームある基本設計書の内容を、まずはサマリーとして全体像を把握してもらうことで、後の本文の理解を手助けします。

　また、「第1回：要件と機能の関連を保つテンプレート（http://www.thinkit.co.jp/article/140/1/）」で説明したトレーサビリティも「要件NO」や「機能NO」の項目として備えているため、その機能を実装する要件の背景までを、顧客に再確認したり詳細設計担当者に伝達したりすることができ、情報の量と質を劣化させません。このフェーズでプロジェクト参加者の「温度差」を最小限に縮めておくことが後工程での品質確保につながるのです。

　概要説明のテンプレートの「わかりやすく伝える」というコンセプトは、開発ドキュメント作成全般において、常に意識するべきものです。開発ドキュメントは細かく記載されていて量が多いのがよいと思われがちです。確かに漏れなく細かく正確に記載することは必要ですが、いくら一生懸命に記載しても、それが伝わらなければ意味がありません。開発ドキュメントには正確さに加え、わかりやすさも同時に求められるということを覚えておきましょう。

　今回で上流工程のドキュメントは終了とし、次回は「単体テスト仕様書兼報告書」を紹介します。