📝

【本の要約: 前編】はじめよう！要件定義〜ビギナーからベテランまで〜

2024/02/17に公開

本

要件定義

要約

idea

はじめに

最近はコードを書くことに加えて、上流工程にも積極的に携わりたいと思うことが増えてきました。

今回は「要件定義」について改めて勉強するため、「はじめよう！要件定義〜ビギナーからベテランまで〜」を読み直しました。

読んでいく中で要点を整理して、自分なりにまとめてみました。
※量が多くなってしまったため、本記事では Chapter-01~Chapter-12 までをまとめています。

内容的には要件定義の作業そのものよりも、要件定義をする前に必要な準備などを解説しています。

Chapter-01 要件定義=要件を定義すること

この章では、「要件定義」という普段聞き慣れない言葉を、依頼者やとコックさんというわかりやすい表現で説明しています。

要件定義とは？

要件を日常的な言葉に置き換えると、「注文」が妥当なものになります。
では注文とはなにかというと、以下のように説明できます。
作って欲しい人が
作る人に出す
依頼事項（リクエスト）

コックさんに「目玉焼きを作って」とリクエストするとなると、

作って欲しい人 ...目玉焼きを作って欲しい人
作る人 ...コックさん
依頼事項（リクエスト） ...「目玉焼きを作って」
となります。

なぜ要件定義が必要なのか

例えば作って欲しい人が、人参を食べられないのに、コックさんがニンジン料理を作っても、
「美味しい」とは感じないでしょう。
依頼主の「美味しい」と、コックさんの「美味しい」とでは、多かれ少なかれ違いがあります。

この認識の違いが、友達同士のやり取りでなく、自社の業務に直結しているソフトウェアを作るやりやり取りとなると、困ったでは済まされません。

このように、依頼事項がきちんと伝わらないと困るので、
依頼事項（リクエスト）を、明確に定まった形にして、作る側に伝える必要があります。

Chapter-02 要件定義の基本的な流れ

この章では、「要件定義」を行う流れを説明しています。

要件定義の基本的な流れは以下のようになります。

要望を出す
要望を要求にする
要求を検討する
代替案を考え、提案する
提案への検討から再要求を繰り返し、合意から要件へ

1つずつ見ていきます。

要望を出す

「要件」を作るには材料が必要です。
要件の材料とは、「こんなことできたらいいなぁ」「こんなのがほしいなぁ」という願望です。

そしてこの願望を色々と検討した結果、何かしらの求めるものが定まってくる。これが、「要望」。

要望を要求にする

「要望」の時点では、心のなかで望んでいるだけ。なのでこれを誰にでも分かる状態にする必要があります。
つまり、何らかの言葉や、書面にすること。これが「要求」です。

要求を検討する

「要求」をそのまま「要件」にすることはできません。
なぜなら、「要件」とは、「依頼主とそれを引き受ける側の間での相互の合意事項」だからです。

「目玉焼きを作って」という要求に対して、受け手側が目玉焼きを作れなかったり、卵を切らしていたりすると、受け手側は作ることができませんよね。

なので要求を受け手側で検討する必要があります。

代替案を考え、提案する

要求に対して、単に「できる」「できない」を検討するだけでなく、代替案を考えることが重要。

代替案とは、「そのままでは無理な場合に考えるもの」ではなく、そのままで可能であっても、
専門家の知見を加味したより良い方策を提示するべきです。

提案への検討から再要求を繰り返し、合意から要件へ

代替案を提示されると、依頼側は当初の要求とは別のことも考える必要が出てきます。
なので受け手側の提案をもらって更に検討を加えて新しい要求を出してくることもあります。

これらを繰り返すことで徐々に合意形成がされていき、それを明確に定めることで、要件が出来上がっていきます。

Chapter-03 定義すべき要件の内訳

この章では、「要件」とは何で構成されているかを説明しています。

「完成したソフトウェア」を作るためには必要な情報があります。
プログラマがソフトウェアを完成させるために必要な情報は次の3つです。

UI
機能
データ

Chapter-04 3つの要素の定め方

この章では、「要件」の要素を、どの順番で定めていくと良いかを説明しています。

「完成したソフトウェア」という成果を出すための要件を決めるには、

UI を決める
機能を決める
データを決める
という流れで進めていきます。

依頼主が「完成したソフトウェア」ということを確認する方法は、
UI を通じてソフトウェアを操作すること
です。

「UI」がないと、いくら裏側で機能していても、操作ができないと完成しているのか確認することはできません。
また、UI ができていても、ボタンを押しても動かないなどの「機能」に問題があるとやはり納得できません。

UI、機能を決めてから、機能が必要とするデータを決める。という流れだと、
依頼主がわかりやすく、納得し易い順序になります。

Chapter-05 要件定義、その前に

Chapter-04までは、「要件定義とは何か」的な話でしたが、
ここからいよいよ要件定義という作業の詳細に入っていきます。

この章では、要件定義をするためには、まず材料が必要であるという説明をしています。

要件を決めるには、以下の順序で行うと説明していました。

UI を決める
機能を決める
データを決める

「定義された UI」、「定義された機能」、「定義されたデータ」には、
それぞれ材料が必要になります。

ここからしばらくは、要件定義を行うために必要な材料を揃える説明をしていきます。

Chapter-06 [準備編]企画を確認する

この章では、ソフトウェアを作成する企画を把握しておこうという説明をしています。

まずはソフトウェアを作る企画意図を確認します。
企画意図から外れた要件を定義してしまったら、依頼主から納得が得られにくいです。

企画書を作成するためにまとめる項目

ここは本来要件定義の前のプロジェクトマネジメントの問題です。
もしも「企画書が存在しない」、「確認できない」などの問題に直面したときに、
この程度はまとめておくべきという項目をあげています。

プロジェクトの名称
なぜ
- 目的
何を
- 目的達成のために作るもの
- 作るものの説明
- 作るものを利用する人
- 利用する人から得られる便益
どのように
- 作るための体制
- 期限

サンプルはこちら

要件定義で重要なのは、「企画を通すための企画書」ではなく、
「実施が決まった企画の決定報告書」が必要です。

Chapter-07 [準備編]全体像を描こう

この章では作成するソフトウェアが、利用者や他のサービスとどのような関係にあるのかを把握するための、全体像の描き方を説明しています。

全体像とは、先程の企画書の中の、特に「何を」を表現したものです。

主眼とすることは、「大枠の理解を共有すること」。
この枠を超えるような要件は、今回のプロジェクトのスコープ外ということをが伝わるものを描きます。

全体像を描く手順

全体像は以下の手順で書いていきます。

ソフトウェアを中心に書く
利用者を配置する
利用者が行うことを書く

3の時点で細かい機能詳細などを書き切ることは難しいです。
また、要件定義の作業を進めているうちに修正すべき点も出てくるのが大前提です。

ただ、全体像があまりにもずさんだと、合意形成が迷走しやすくなります。

全体像を描くときの注意点

上記3つの他に2つ、注意すべき点があります。

システム管理者を忘れずに書く
連携するシステムを書く(連携する内容も)

これらを含めると、このような全体像が出来上がります。

この全体像の枠内が、今回の要件定義のスコープです。
引き続きこの全体像を掘り下げて行きます。

Chapter-08 [準備編]大まかに区分けをしよう

この章では、全体像で描いたシステムをわかりやすくするために、機能ごとに区分けをしようという説明をしています。

作成するソフトウェアが大規模な場合、先ほど中心においたソフトウェアをいくつか区分けします。
たいていは、利用者がやることを、同じものについて大まかに括っていくことで収まるべきところに収まります。

Chapter-09 [準備編]実装技術を決めよう

この章では、サンプルアプリケーションを作成できる程度の実装技術を決めておくと良いということを説明しています。

要件を定義してからアーキテクチャを決めるべきという考え方もありますが、
実装の都合がわからないとソフトウェアの要件が決められないのも事実です。

ここでは最低限、ソフトウェアアーキテクチャを決めるということをやっていきます。

大きく2段階の手順で行います。

基本的なシステムアーキテクチャを決める

メインフレーム
2層クライアントサーバ型
Web ブラウザ型
モバイル端末 + Web サーバ型

各部の個別の実装技術を決定する

クライアント側
- ユーザアクションの検知方法は？マウス？タッチ？音声入力？
- 入力したデータの保持の方法は？
- データと画面上の項目との連携方法は？
- 画面遷移はどのように行うの？
- クライアント側のプログラミング言語は？
通信
　　 - 通信プロトコルは？
- 通信データのフォーマットは？
サーバ側
- データ変換の方法は？
- 使用するデータベースは何？
- どうやってデータベースを操作するのか？
- サーバ側のプログラミング言語はなにか？
- フレームワークは何か？

これらを決めることで利用者による最低限のインタラクションを実現するための構成がわかりますし、
サンプルアプリケーションを作ることもできます。

要件定義の前に1つのインタラクションすら実装できないと、どれだけ精緻に要件を定義しても実現が心もとないものになります。

なので基本的な実装の裏付けはこの時点で用意しておくべきです。

Chapter-10[準備編]実現したいことを整理整頓しよう

この章では、このプロジェクトで実現したいことを、しっかりと明文化しておこうということを説明しています。

ここまでで、以下の3つが揃いました。

企画書
全体像
実装手段

この後の要件定義の段階で、どこを見ても具体的な要求が書かれていないとなると、
何を目指して実現すればいいか分からなくなるので、文書化して共有できるようにしておきます。

これも要件定義の前の段階である「企画工程」の課題であって、要件定義工程の課題ではありません。
しかし、この時点で要求を整理しておくことで、「実はこういうことを実現したかった・すべきだった」という
ちゃぶ台返しを食らうような状態を、完全ではなくとも回避することができます。

Chapter-11[助走編]利用者の行動シナリオを書こう

この章では、利用者がなぜ新システムを使うのか、どのタイミングで使うのか、システムを使うことで何を得られるのかをスイムレーンに乗せて可視化することについて説明しています。

ここまでで以下のものが揃っています。

企画書
全体像
実装手段
実現したいこと一覧

ここからは要件定義そのものではなく、その手前の助走について説明していきます。

行動シナリオ

行動シナリオとは、一般的にはビジネスプロセスフローや、プロセスマップ、ユーザーシナリオ、ユースケースなどと呼ばれています。

映画や芝居で例えるなら、

行動シナリオ ... 役者の台本
ソフトウェアの要件 ... 台本を活かすための大道具や小道具などの仕様を決めること
となります。

「顧客が商品を注文する」という台本があるから、「商品注文画面」という小道具が必要になります。

ソフトウェアはそれを使ってもらうことで利用者の行動・便益を支えるためにあります。
なので、利用者の行動をどのように想定・設定することができていないと、要件を定義することはできません。

行動シナリオから得たいものは以下の3つです

ソフトウェアを利用するタイミング
- 例: ほしいと思ったときに
ソフトウェアを利用する理由
- 例: ほしいと思った商品を手に入れるために
ソフトウェアを利用することで利用者が具体的に達成する仕事
- 例: ほしい商品を注文する

行動シナリオをどう書くか

重要なのは、 UI の出現場所です。
それが明確になれば、要件定義を行うための行動シナリオとしては十分です。

上記の行動シナリオだと、こんな感じの情報が得られるかと思います。

ソフトウェアを利用するタイミング
- 購入先に送る発注書を作成するとき
- 納期を記録するときに
ソフトウェアを利用する理由
- 発注書を作成するために
- 発注情報を記録するために
- 納期を記録するために
ソフトウェアを利用することで利用者が具体的に達成する仕事
- 購入先へ送る発注書を出力することができる
- 購入先からの納期を記録することができる

Chapter-12[助走編]概念データモデルを作る

この章では、簡単な概念データモデルを作成する理由と、その書き方を説明しています。

本来であれば、この後の要件定義の段階で詳細に実施します。
しかし、要件定義をする人がシステム開発に染まっている場合、要件定義の初期段階で、
「どのようなデータを保持するのか」というのに手が止まってしまいがちです。

なので、要件定義をする際の補助線となるように、「こんなデータを使いますよ」くらいのメモ書きくらいの意味合いで概念データモデルを作ります。

概念データモデルは、ER 図をかければそれでも構いませんが、
厳密な正規化や、リレーションシップを結ぶ必要もありません。

正規化するなどの作業はあとからやることになるので、ここで頑張る必要なありません。

ここまでで、

企画書
全体像
利用する実装技術
実現したいこと一覧
行動シナリオ
概念データモデル

が揃いました。
これらを材料として、要件定義に突入します。

後編の宣伝

本記事ではここまでの説明で終わります。
Chapter-13以降はこちらで説明しています。