図解即戦力 要件定義のセオリーと実践方法がこれ 1 冊でしっかりわかる教科書

システム開発における最初の関門である「要件定義」を、豊富なイラストや表、具体例を用いてわかりやすく解説しています。現場に立つうえでエンジニアが身につけておくべき知識が満載の一冊です。
1 章 要件定義の基礎知識
01 要件定義とは
02 要件定義の位置づけ 〜いつ決めるのか〜
03 要件定義への取り組み姿勢 〜誰が決めるのか〜
04 要件定義作業フェーズの全体像
05 下調べ・段取りフェーズの概要
06 分析・定義フェーズの概要
07 合意と承認・維持フェーズの概要

2 章 要件定義の下調べ・段取りフェーズ
08 下調べ・段取りフェーズの全体像
09 事業目標の共有
10 対象範囲の確認
11 ステークホルダーの識別
12 要件定義作業の進め方
13 ジャッジのための基準づくり
14 計画書の作成

3 章 業務要求の分析・定義フェーズ
15 業務要求の分析・定義フェーズの全体像
16 現行業務の調査
17 業務フローの分析・定義
18 ビジネス・ルールの分析・定義
19 入出力情報の分析・定義
20 業務要件の文書化
21 業務要件の検証
22 業務要件の妥当性確認

4 章 機能要求の分析・定義フェーズ
23 機能要求の分析・定義フェーズの全体像
24 現行システムの利用調査
25 システム機能に関する分析・定義
26 画面に関する分析・定義
27 帳票に関する分析・定義
28 データに関する分析・定義
29 外部接続に関する分析・定義
30 機能要件の文書化

5 章 非機能要求の分析・定義フェーズ
31 非機能要求の分析・定義フェーズの全体像
32 可用性に関する分析・定義
33 性能・拡張性に関する分析・定義
34 運用・保守性に関する分析・定義
35 移行性に関する分析・定義
36 セキュリティに関する分析・定義
37 システム環境・エコロジーに関する分析・定義
38 非機能要件の文書化

6 章 要件定義の合意と承認・維持フェーズ
39 合意と承認・維持フェーズの全体像
40 打合せ内容への合意
41 要件定義への承認
42 トレーサビリティの管理
43 要求のライフサイクル管理

『図解即戦力 要件定義のセオリーと実践方法がこれ 1 冊でしっかりわかる教科書』 (上村有子 著、技術評論社、2020 年 6 月刊) は、システム開発の最初の関門である要件定義を、イラストや表、具体例を使って順を追って解説する入門書です。版元は勧める読者として、はじめて要件定義を担当することになったエンジニアを挙げています。版元の著者紹介によると、上村有子氏はエディフィストラーニング株式会社で人材育成に従事し、ビジネスアナリシスとビジネスインテリジェンスを専門領域とする人物です。何から手を付ければよいか分からない状態から、要件定義の作業を段取りとして見通せるようになりたい人に向いた一冊です。

全 6 章の構成、基礎知識から合意と承認 / 維持フェーズまで

本書は全 6 章で、通し番号の付いた 43 の項目が並びます。第 1 章「要件定義の基礎知識」で要件定義をいつ決めるのか、誰が決めるのかという位置づけと、作業フェーズの全体像を示し、第 2 章以降はそのフェーズの順に進みます。第 2 章以降の章はどれも、そのフェーズの全体像を示す項目から始まります。第 2 章「要件定義の下調べ・段取りフェーズ」は事業目標の共有、対象範囲の確認、ステークホルダーの識別、判断の基準づくり、計画書の作成を扱います。

第 3 章「業務要求の分析・定義フェーズ」は現行業務の調査から業務フロー、ビジネス・ルール、入出力情報の分析と定義へ進み、業務要件の文書化と検証、妥当性確認までを扱います。第 4 章「機能要求の分析・定義フェーズ」は現行システムの利用調査に続いて、システム機能、画面、帳票、データ、外部接続を順に取り上げます。第 5 章「非機能要求の分析・定義フェーズ」は可用性、性能 / 拡張性、運用 / 保守性、移行性、セキュリティ、システム環境 / エコロジーの 6 つの観点を扱い、第 6 章「要件定義の合意と承認・維持フェーズ」は打合せ内容への合意と要件定義の承認、トレーサビリティの管理、要求のライフサイクル管理で締めくくられます。

要求を要件に変える工程が難しい理由

要件定義 が難しいのは、利用者や発注者が口にする要望をそのまま書き写す作業ではないからです。関係者が持つ要求は、立場によって食い違い、言葉にされないまま前提になっているものも多く含みます。それを事業の目標と対象範囲に照らして取捨選択し、開発する側と合意できる形に書き直したものが要件です。本書の目次でも、第 3 章から第 5 章の章題は要求の分析 / 定義となっており、各章の終わり近くに要件の文書化の項目が置かれています。

とりわけ抜けやすいのが非機能の側です。画面や帳票は利用者が具体的に思い描けますが、止まってよい時間や応答の速さ、移行の手順、セキュリティの水準は、問われない限り誰も言い出しません。こうした項目を決めずに開発へ進むと、テストや本番の直前になって手戻りが起きやすく、決めた可用性の目標は運用段階で SLA や SLO のような約束にもつながっていきます。さらに要求は合意した後も変わるため、どの要件がどの要求から来たのかをたどれるようにしておくことが、変更の影響を見積もる土台になります。

はじめて要件定義を担当するエンジニアに合う使い方

第 1 章で要件定義の位置づけから説明が始まるため、読み始めに必要なのは、システム開発が要件定義から設計、実装、テストへと進むという大まかな流れの理解程度です。一方で、目次にはユースケースのような特定の要求分析の手法の名前を冠した項目はないため、手法の記法や作法を深めたい人は、その手法を主題にした本を別に用意する必要があります。要件が固まった後の設計に関心が移ったら、設計やアーキテクチャの本の選び方 を参考に次の一冊を選ぶと流れがつながります。

裏返せば、上流工程を初めて任された開発者や、プログラマーから要件定義の担当へ役割が広がった人にとって、下調べから合意の後の維持までをフェーズの順に一覧できる本書は、自分の作業がいまどの段階にあり、次に何を決めるべきかを確かめる手元の地図になります。担当する案件の計画を立てる前に通読しておくと、抜けやすい論点に先回りしやすくなります。