ミスなくモレなく見やすい「要件定義書」の書き方：ユーザーの要件には「ウソ」がある？（1/3 ページ）

システム開発プロジェクトの成否を決めるといっても過言ではない「要件定義」。連載「エンジニアのためのビジネス文書作成術」、第2回目は「要件の洗い出し方」と、Wordの機能を駆使して「要件定義書」を見やすくするテクニックを伝授します。

[吉澤準特，＠IT]

連載「エンジニアのためのビジネス文書作成術」は、書籍「外資系コンサルのビジネス文書作成術」（吉澤準特著　東洋経済新報社）を基に、出版社の許可を得て、筆者自身が＠IT読者向けに再構成したものです。画像はWindows 7 + Word 2013上のものです。機能はWord 2013、2016のいずれでも使用できます

　連載「エンジニアのためのビジネス文書作成術」、第1回は「議事録」の書き方を学びました。第2回は、Wordで「要件定義書」を作ります。

　要件定義書は、ウオーターフォール開発モデルの要件定義フェーズで作成する成果物です。ウオーターフォール開発は、「計画→要件定義→設計→開発→テスト→移行、リリース」の順でフェーズが進みます。要件定義書は、ITシステムの機能設計の「前提」を網羅するため、明瞭簡潔で漏れがないように作ることが求められます。

「要件」とは何か

　「顧客が本当に必要だったもの」というパロディー絵があります。

図1　顧客が本当に必要だったもの（出典：顧客が本当に必要だったものとは （コキャクガホントウニヒツヨウダッタモノとは） [単語記事] - ニコニコ大百科）※クリックすると、拡大画像を表示します。以降同様

　「図1」の上列左端の「顧客が説明した要件」を文書にまとめたものが、要件定義書です。木の枝にくくりつけられた多段ブランコが描かれていますね。

　しかし、システム開発に関わる全員が要件について同じ理解をしていなければ、作るものがずれていきます。営業の表現がずれているのはいつものこととして、プロジェクトリーダーの理解、アナリストのデザインが要件とずれてしまったら、顧客（ユーザー）が期待する結果は得られません。

　では、ユーザーの言うことを忠実に文書にまとめればよいかといえば、それもまた違うのです。

　図1の下列右端に「顧客が本当に必要だったもの」として示された絵は、「顧客が説明した要件」と異なります。「ユーザーは自分が必要としているものを正しく認識できていない」ということは、システム開発の現場ではよく起こります。

要件だと言われたもの→本当に必要だったもの、の例

• 絶対に停止しないアプリ→再起動してやり直せればよいアプリ
• 多面的に分析できるBI機能→関数の入ったExcelシート
• 電動ドリル→5mmの穴
• ビグザムの量産→大量のドム

　「ユーザーが語る要件にはウソがある」というのは、よく知られたIT格言です。

「業務要件一覧」から「システム要件一覧」を作る

　システム開発でユーザーに「本当に必要なもの」に気付いてもらうためには2つのアプローチがあります。

　1つは「プロトタイプ」「モック」「POC」を見せて、ユーザーの認識を確かめる方法です。

　パッケージアプリケーション、Webアプリ、クラウドサービスなど、実際に触れる画面をすぐに用意できる場合に用いられます。しかし、スクラッチで作るオンプレミスのシステムではプロトタイプを用意すること自体がシステム開発になってしまいます。

　そうしたシステムに適したもう1つのアプローチが、「業務要件一覧」から「システム要件一覧」を作る方法です。

　業務要件一覧は、ユーザーからヒアリングした「やりたいこと」を整理したものです。業務単位でシステム化したいことを表形式でまとめます。例えば、Webサイトで商品を購入するショッピングカート機能を実現したいなら、業務要件には「商品購入」という項目が書かれます。

　システム要件一覧は、それら個々の項目をシステム上で実現するための機能を列挙したものです。「商品購入」という業務要件の隣の列に「カートに商品を追加」「カートから商品を削除」「カート内の商品数を変更」などの項目を列挙します。

　業務要件はシステムを利用するユーザーの目線で作りますが、システム要件はシステムを構築するエンジニアの目線で作ります。

　この作業を通して、ユーザーは実際の利用シーンを具体的に考えられるようになり、今までの想像で漏れていたことに気付けます。ショッピングカートに入れた商品を後で買いたいと思う人もいることに気付き、「カート内の商品を欲しいものリストに追加という機能を新たに追加する」などです。

　「システム要件一覧を作る」とは、「ユーザーの目に映っていない要件をエンジニアの目で照らし出す」ことなのです。