PR

要件と機能を簡潔に伝えるテンプレート

2008年10月9日(木)
山口 智也

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

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

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

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

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

よい設計は量ではない

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

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

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

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

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

株式会社システムインテグレータ
国産WebERPパッケージ「GRANDIT」の開発に参画。ファーストバージョンリリース後、経験を生かして多数のERP導入プロジェクトを担当。カスタマイズ開発案件のプロジェクトマネジメントやERP導入コンサルとして活躍中。生の顧客要望を製品に反映する改善活動にも尽力している。http://www.sint.co.jp/

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています