要件定義書というシロモノについて

システムを作る際に、要件定義として何かしらドキュメントを書きますが様々なタイプがありますよね?
筆者が社内SEやってたときは、メイン読者は誰なのかを特に意識して書いてきました。それによってドキュメントの目的が違ってくるからです。それに読む人が理解できないものを書いてもしょうがないじゃないですか?
よく見かける「要件定義書」を成果物と設定し、ドキュメントそのものが目的物になっている場合って、何かピンとこないことが多いように思うんですが、ドキュメントって全ての読者向けに書いた、もしくはターゲットを特定しない場合は、ページ数が多くて読む気もならなかったり、ちょっとの誤字脱字を発見して読む気なくしたりして、誰にも伝わらない、もしくは各自の思いで解釈し後で痛い目にあうというなんて事も多々あるように思います。
という事でメイン読者を軸にすると主に4タイプに分類できるかなと思います。
1.経営者向け
 あまり書く機会は無かったけど、この場合の目的はビジネスがどう変わるか、予算がどのくらいかかりそうかが焦点かと。
 とにかく簡潔に少ないページ数でまとめる。図を多く使ってパワポで書く。
2.利用者(利用部門)向け
 この場合の目的は、業務がどう変わるか、システム化される範囲としない範囲の指定なんで、具体的な対象物の明記が必要。
 概要説明と解りやすそうな業務フロー(UML的に書いても理解されない可能性が高いです)
 また、外部設計を後でやるかやらないかにもよりますが、画面・帳票設計に近いもの付け加える。
3.開発者向け
 開発工数を見積もるという目的がメインと考えます。
 どういうレベルの工数見積もりを期待するかで、たくさん書くこともあれば、ちょっとの時もあり・・
 開発者の理解レベル次第では、2と同じにする事も多々あり・・
4.運用管理者向け
 この場合の目的は、どう構築して、その後維持管理していくかなんで上記とは別物ですね。いわゆる非機能要件に分類される内容がメインになると思われます。

現在の筆者のスタンスでは、自分では要件定義書的なものを書きません。
だって見積もりもしなければ、別の開発者に伝える必要もほとんどないし・・・
開発者という立場の場合、見積もりしない限り、手間が掛かるだけで必要性を見いだせないからです。
よく開発ベンダーに要件定義書を任せるというスタンスの所もあります。開発規模次第という面もありますが、出来ればしない方がいいですね。あれもこれもといろいろ盛られて、見積もり見てびっくりします。

カテゴリー: 徒然草   作成者: bokusui パーマリンク

bokusui について

ソフトウェアハウスでのPG・SEから始まり、10年近く勤めた金融系企業の社内SEを数年前にやめ、フリーランス時代を経たのち法人成りしました。システム開発の全工程をこじんまりとやり続けています。