ここから本文です

ミスなくモレなく見やすい「要件定義書」の書き方――ビジネス文書作成術

5/17(水) 7:10配信

@IT

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

【目次自動作成機能の例】

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

●「要件」とは何か

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●「要件定義書」を作る理由

 業務要件一覧とシステム要件一覧があれば、システム設計のインプットとなる要件はそろったといえます。これで要件定義の作業は完了でしょうか。

 いえ、これでは十分ではありません。確かに材料はそろいましたが、その材料を「どうやって」システム設計に組み込むかを説明するものが必要です。

 玉子と油とフライパンを与えて「さあ料理してください」と伝えたら、ある人は目玉焼きを作りますし、別の人はスクランブルエッグを作るかもしれません。材料をそろえるだけでは、ユーザーが本当に必要としているものを生み出せません。

 業務要件一覧とシステム要件一覧を1つの文書にまとめたものが要件定義書です。そして、この要件定義書を作るのに適しているのがWordなのです。

●要件定義書の「目次」を作成する

 これまでに整理した要件一覧は、業務を実現するシステム機能を設計するためのインプットでした。

 しかし、システムに含まれるのはそれだけではありません。「稼働後の運用方法」「情報セキュリティの観点で守るべきこと」「データ構造やシステム間連携のルール」など、システムの都合ではなく組織全体の都合で守らなければならないこともあります。

 要件定義書では、そうしたものを含めた「システム全体の実装方針」を明確にします。総務省が公開している「標準ガイドライン」では、システム要件として「機能要件」と「非機能要件」を示すことを推奨しています。

機能要件

a 機能に関する事項
b 画面に関する事項
c 帳票に関する事項
d 情報・データに関する事項
e 外部インタフェースに関する事項

非機能要件

a ユーザビリティ及びアクセシビリティに関する事項
b システム方式に関する事項
c 規模に関する事項
d 性能に関する事項
e 信頼性に関する事項
f 拡張性に関する事項
g 上位互換性に関する事項
h 中立性に関する事項
i 継続性に関する事項
j 情報セキュリティに関する事項
k 情報システム稼働環境に関する事項
l テストに関する事項
m 移行に関する事項
n 引継ぎに関する事項
o 教育に関する事項
p 運用に関する事項
q 保守に関する事項

 これらのコンテンツの前に下記を加えれば、要件定義書の目次が完成します。

・システム導入の目的と目標
・システムの概要/システムの構想

 システムの規模や重要度に応じて、これらの中から過剰と思われる部分を間引いてもいいでしょう。

●「目次」と「インデント」を駆使して、見やすい要件定義書を作る

 Wordの「目次」や「インデント」機能を使いこなすと、見やすい要件定義書を作成できます。

目次を自動作成する

 目次の自動作成手順を説明します。

 メニューの「参考資料」タブから「目次」領域にある「目次」ボタンを押します。すると、本文中の「見出し」から目次を機械的に作成してくれます。メニューの「ホーム」から「スタイル」領域にある「見出しスタイル」を適用させると、目次を自動作成するときの「見出し階層」を設定できます。

余白を調整する

 Wordの「インデント」を使うと、文字の開始位置をコントロールできます。

 インデントは、「1 最初の行」「2 行の左右」「3 行間」「4 段落」の4種類の前後を変更できます。段落始まりを1字空けるときは、「1 最初の行」で「字下げ」、幅を「1字」と指定します。

さらに見やすく

 Wordの「スタイル」をカスタマイズすると、目次機能とインデントをさらに活用できます。

 スタイルとは、書式設定をグループ化したものです。「文字の大きさ」「フォントタイプ」「色」「文章開始位置」「行/段落間スペース」「箇条書き記号」など、さまざまな装飾項目を一まとめで定義できる、書式パターンのかたまりです。

 スタイルの種類によって、設定できる項目が異なります。

 スタイルはWordの書式設定を分かりづらくしている原因でもありますが、使い方を理解すれば、書きやすさと読みやすさを兼ね備えた文書を作れます。

 要件定義書の書き方を「項目の洗い出し方」と「Wordの使い方」の両面で解説しました。次回(5月22日掲載)は、「提案依頼書(RFP)」の書き方を説明します。

書籍
外資系コンサルのビジネス文書作成術
吉澤準特著 東洋経済新報社 1944円(税込み)
大手コンサルティングファームでドキュメンテーションスキルを指導する著者が、ロジックの組み立てと効果的な表現をWord上で思い通りに実現するテクニックを解説する。
※書籍では、本記事の内容をで図解しています。是非ご覧ください。

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

筆者
吉澤準特
ITコンサルタント
外資系コンサルティングファーム勤務。ビジネスからシステムまで幅広くコンサルティングを行う。専門分野はシステム運用改善をはじめとするインフラ領域だが、クライアントとの折衝経験も多く、ファシリテーションやコーチングにも造詣が深い。
著書『資料作成の基本』『フレームワーク使いこなしブック』(以上、日本能率協会マネジメントセンター)『外資系コンサルの仕事を片づける技術』(ダイヤモンド社)など。

最終更新:5/17(水) 7:10
@IT