「はじめよう！要件定義」を読んで、要件定義はじめてみた
要件定義未経験エンジニアが、「はじめよう！要件定義 ～ビギナーからベテランまで」 を読んでアウトプットしてみた記事です。
要件定義することになった未来の自分（やアナタ）がフレームワークとして活用できる内容になっていればいいなあとおもいますが、そぎ落としてしまっている内容の中にも大事な考え方が多々含まれているので、気になった方はぜひ読んでみてください。
要件定義ってなに
要件とは「システムを作ってほしい人と作る人の間での、何を作るか定めた合意内容」です。
それを定義する要件定義は、システム開発プロセスにおけるイチ工程であり、「後続の設計/開発（＝どうやって作るかを考える作業/実際に作る作業）で必要な情報を揃える作業」になります。
本の中では「目玉焼き」を例に説明されてますが、ここでは個人的に作ってみたいアプリを題材に、よりシステム開発目線で考えてみます。
要件定義の準備
要件定義フェーズでの最終的な成果物として、下記の3つを揃えたいです。
UI
機能
データ
まずはこれらを揃えるために、下記材料を準備していきます。
ゴールの定義
「何のためにどんなものを作りたいのか」が、ざっくり明確に分かる資料。
【例】
プロジェクト名称：PFC記録アプリ
目的：日々の食習慣をPFC（タンパク質、脂質、炭水化物）ベースで記録し可視化することで、
カロリーに囚われず栄養バランスのとれた食への意識改善・健康増進につなげたい！
目的達成のために作るもの：・摂取PFC記録機能
・記録したPFCを日別に閲覧する機能
・任意の食品のPFCを登録する機能
・デフォルトの食品データ
（・ユーザー情報管理機能）
作るものの説明：後日
利用者：わたし（いずれは一般利用者）
利用者が得られる便益：食習慣への意識改善・健康増進
作るための体制：わたし
期限：気長に
全体像
「どんなものができあがる予定なのか」の大枠がわかる図。
ソフトウェアを中心に据え、利用者および利用者が行うことを書き出します。
システム管理者が行うことがある場合や外部システムとの連携がある場合も必ずここで書き出します。
【例】
実装技術
最低限のアーキテクチャを決定します。
細かい部分は設計フェーズで詰めるとしても、要件定義フェーズでこれを用意しておくと、後工程で困ることが減りそうです。
【例】
手軽に入力したいので、モバイルアプリケーションが理想。
いったんはandroidのみ対応とし、Kotlinでの開発を行う。
アーキテクチャはAndroidデベロッパーガイド記載の推奨アーキテクチャに従う。
(https://developer.android.com/topic/architecture?hl=ja#recommended-app-arch)
（細かいところは図にするの時間かかりそうなので割愛）
要求一覧
そもそも何を実現したいか、という気持ちや願望を、要求として全て洗い出しておきます。
そこから要求を再度整理・分析して、ほんとうに実現すべきことが何かを検討します。
【例】
・食べたものをPFCベースで記録したい
→ 一番やりたいこと。やりましょう
・手軽に入力したい
→ 実装技術に考慮を盛り込み実現
・記録したPFCをグラフで見れるようにしたい
→ 必要？本質的な要求は？
→ 整理
・減らす/増やすべき食材をユーザーごとにレコメンドしたい
→ ロジックの中身は？
→ 詳細を検討
→ 要件に落とし込み
→ 場合によっては初回リリースのスコープには含めないなどの判断
といった作業がここでできます。
あとあとで実現したいことが変わってくることを可能な限り防ぐ、リスクヘッジとしての意味合いが強い作業であり、もっと後工程になってからの手戻りを減らせると解釈。
要件定義の助走
ここまでで、下記材料が揃いました。
ゴールの定義
全体像
実装技術
要求一覧
プラスもう2つ材料があるとよいそうです。
行動シナリオ
これから作るソフトウェアによって、利用者がどのように行動するようになるか、誰が何のためにソフトウェアを必要とするのか、を書き出したものです。業務フローとかユーザーストーリーとも呼ばれたりするそうです。
細かいところは本来は業務要件の定義とか業務設計と呼ばれる工程でやるべきことですが、ここではソフトウェアの要件定義に必要十分な行動シナリオ（＝UIの出現箇所の手がかりになるもの）を作成します。
【例】
概念データモデル
行動シナリオを材料に要素を抽出した、「こんなデータを扱いますよ」が分かる程度の図。
詳細な内容は後工程で詰めることにはなるので、イメージや目安くらいのものと考えてざっくり作成します。
【例】
要件定義の成果物
ここまでで、下記材料が揃いました。
ゴールの定義
全体像
実装技術
要求一覧
行動シナリオ
概念データモデル
大事なのは、ここまでは「ソフトウェアを使って実現したいこと」を考えることに徹底的にフォーカスしているということです。
ここからやっと要件定義です。「どういうソフトウェアを作ることによって、実現したいことを実現するのか」を考えていきます。
ここまでで用意した材料をもとに、先にも述べた要件定義フェーズでの最終的な成果物として、下記の3つを揃えていきます。
UI
機能
データ
1つずつ見ていきます。
UI
利用者が直接触ることができる＝システムの良し悪しを判断できるほぼ唯一の材料であるUIを構成するのが、以下3つの基本要素です。
データ項目
操作項目
レイアウト
行動シナリオで描いたUI出現箇所1つずつについて、定義をすすめます。
【例】
まずはラフイメージを作成します。
そしてラフイメージをもとに、すべての項目を列挙します。
※画像データ（ユーザーアイコンとか商品の画像とか）の表示が必要な場合も、ここに列挙しておきます。
この流れで、行動シナリオで描いたUI出現箇所すべてに対してラフイメージと項目を作成していきます。
ときには、画面の分割が必要になることもあるかもしれません。
【例】
ラフイメージと項目が出揃ったら、画面遷移を考えます。
まずは導線を考え、その線に操作（イベントトリガー）や機能（処理）を織り込んでいきます。
機能
次に考えるのは、ソフトウェアが行う処理の具体的な中身です。
ここでもプログラミング的に考えることはせず、「コンピューターが行う仕事」として考えていきます。
流れとしては、まず処理（＝仕事）を一つピックアップし、何を成果とするか、何がUIを実現するために求められるのかを出力として定義します。
【例】
出力を決めたら、それをつくるために何を行えばよいのか、またその過程で必要な材料として何が入力されるべきか考えます。
材料の導出元としては下記が考えられると思います。
・前画面での表示項目
・ユーザーの入力値
・データベースに登録されている値
上記例だと、アプリ起動直後の画面で、既に登録されているデータを表示することになりそうです。
概念データモデルでリストアップしたドラム缶を使って、ここでデータをひっぱってくることも記載しておきます。
作るにあたってのイメージがかなりしやすくなってきました！
これを、データの登録が必要なところも含めて、すべての機能に対して定めていきます。
データ
実はここまでで必要なデータは書き出せているのですが、それらをどうやって区分けして入れ物に入れておくかも考えておきます。
まずはUIの定義をしたときに洗い出した項目を全部書き出し、それらを分類するための器（エンティティ）を用意します。（概念データモデルで書いたドラム缶と同じようなものになるので、用意できている場合は割愛します）
エンティティはイベント系とリソース系で決めていくことができます。
イベント系：「○○する」のような動詞で考えられるもの。これは行動シナリオからも導き出すことができます。
【例】「注文する」「予約する」 → 「注文」「予約」
リソース系：上記の動詞の目的語となったりするような、名詞で考えられるもの。
【例】「商品」「施設」
今回定義してきたものでいうと、下記エンティティが考えられそうです。
「食品」「入力履歴」
エンティティを用意したら、洗い出した項目を振り分けていきます。
重複や繰り返しとなるデータを避けるため、正規化を行ってもよいです。
今回の例だとあまり参考にならないですが、この後にテーブル同士のリレーションシップを考えていきます。
特定の項目同士で紐づけができるテーブルを、線で結びます。
一般的にER図と呼ばれるものができあがります。
仕上げ
ここまでの作業で、下記成果物ができあがりました。
ラフイメージ
項目の説明
画面遷移図
機能の入出力定義
機能の処理定義
ER図
最後に、あとあとの手戻りを少しでも防ぐために、足りない定義がないか、検討が不十分なところがないかチェックしていきます。
【具体的にできること】
・CRUDマトリクス作成
→ 足りないデータライフサイクルを埋めるために、行動シナリオから見直しができる
・パーミッション表作成
→ ユーザーによってできることが異なる場合はあったほうがよく、これも見落としがあれば行動シナリオに反映する
・非機能要件の検討
→ セキュリティや性能などで、要件に落とし込むべきものがないかチェック
ここまでできたら、関係各位への伝達資料を作成して、要件定義フェーズでの成果をリリースしましょう！
感想
「機能とは仕事である」
人がやる仕事を考える業務設計も、コンピューターにやらせる仕事を考えるシステム設計も、本質的にはおなじことであり、要件定義を考える＝「仕事」について考える ことなのだなとおもいました。
普段コードに触れている時間が長いとシステムありきで考えそうになるけど、要件定義フェーズでは「どうやって実現するか」から考えずに「何を実現したいか」をまずは徹底的に検討する。
工程の途中で何か綻びが生じたら、手前の作業に戻る。この綻びを後工程に持ち込まないのが要件定義での使命だなと思いました。
反面、要件定義段階でここまで終わってることってなかなかなくて、そもそも工程の区分けはプロジェクトによっても異なるのと、一部は平行で進んでいったり後続の設計工程でやっていることも多々あると思います。
ただ本に書かれているスコープまで要件定義段階で終わっていれば、後工程だいぶ楽になりそうなことは明白ですね。
わたしが先送りにした仕事は誰かにしわ寄せがいっていると考えて、後工程の人が困らないような仕事を常々心掛けていきたいと思いました！
参考文献
羽生章洋 （2015）. はじめよう！要件定義 ～ビギナーからベテランまで 技術評論社
Discussion