#目次
- はじめに
- 配属されたプロジェクトについて
- 心に刻んでおきたい言葉【要件定義編】
- 1.目的と手段がごっちゃになってない？
- 2.業務フローは明確になってる？
- 3.リリース後の運用のことも検討してある？
- 4.制約と前提条件の区別できてる？
- 5.プロジェクトが成功するかは要件定義にかかってる。
- おわりに
- 参考資料
#はじめに
こんにちは。某スマホアプリのバックエンド開発をしているアラサーエンジニアです。
以前配属されていたプロジェクトに、かなりできるPLの方（Hさん）がいました。
当時の私はプレイングマネージャーとして、Hさんの下で開発チームのリーダーをやっていて、
Hさんからビシバシありがたいご指導をいただいていました。
そのおかげもあって、人間的にもエンジニアとしてもかなり成長できたと思うので、
その際に言われたことを忘れないように、つらつら書いていこうと思います。
今回は要件定義編となります！
■これまでに書いた関連する記事↓↓
** ●１つ目の記事**
過去にPLから言われた心に刻んでおきたい５つの言葉【要件定義編】←今ココ★
** ●２つ目の記事**
過去にPLから言われた心に刻んでおきたい５つの言葉【進捗管理編】
** ●３つ目の記事**
過去にPLから言われた心に刻んでおきたい６つの言葉
#配属されていたプロジェクトの概要
心に刻んでおきたい言葉の前に、配属されていたプロジェクトをざっくり紹介します。
プロジェクト：toB向けのヘルスケア系ASPサービスの開発
開発スタイル：ウォーターフォール
わたしの担当：要件定義〜リリース・運用保守までの全工程
リリース日だけは明確に決まっておりマストですが、要件の中身は全然決まっていない。。
みたいな感じのプロジェクトでした。笑（あるあるですね。）
心に刻んでおきたい言葉【要件定義編】
##1. 目的と手段がごっちゃになってない？
自分が要件定義で何を決めるべきなのかを理解せずにドキュメントを作成して、
レビューを受けたときに言われた言葉です。
ざっくり言うと、要件定義は**「顧客が現在抱えている問題（要件の背景）」**と
**「本来あるべき理想の姿（業務要件）」**を明確にするフェーズです。
抱えている問題を実際に解決する方法（手段）までは一旦考えなくて良いです。
問題を解決する手段は一つではなく複数あり、そこについては
「顧客が現在抱えている問題（要件の背景）」と「本来あるべき理想の姿（業務要件）」が
明確になった後に考えるべきだからです。
この「顧客が現在抱えている問題」と「本来あるべき理想の姿」がブレたまま開発を進めていくと、出来上がったモノが顧客の欲しかったモノと違っていたり、作っても誰も使わないモノが生み出されてしまうことになります。
例えば、顧客から「ユーザの購入履歴をシステムで保管できるようにしたい」という要求を出してきたとします。これをそのまま顧客要件としていてはダメです。
「ユーザの購入履歴をシステムで保管できるようにする」のは手段であって、目的ではありません。要件定義でまず決めることは、上記を行う目的です。
**「なぜユーザの購入履歴を保管しておきたいのか」**を要件定義のタイミングで明確にしていくのです。
ここを明確にしていくことで自ずと、「顧客が現在抱えている問題」と「本来あるべき理想の姿」がハッキリ見えてきます。
（それは「追々、購入履歴からリコメンド機能を作りたい」だったり「トラブルがあった時のために証拠を残しておきたい」だったり様々あるかと思います。それによって解決のための手段も変わってきます。）
##2.業務フローは明確になってる？
次は業務フローについてです。
業務フローの重要性についても、ことあるごとに教えていただきました。
要件定義フェーズでは、ユーザの業務フローも明確にしておかなければなりません。
業務フローを明確にすることで、どんな機能が必要なのかが明確になってきます。
要件定義フェーズで業務フローを明確にしておかないと、総合テストで実施すべき内容も不明瞭になってしまいますし、必要な機能の抜け漏れにも気づけなくなってしまいます。
結果的にリリースした後や、プロジェクトの終了間際になって**「必要な機能が足りなかった！」**とドタバタすることなります。
業務フローを作る上で、注意すべき・よく指摘されたポイントは以下になります。
・各業務フローの開始条件・終了条件が明確になっているか。
・アクター間でやりとりが発生する場合の連絡手段・連携手段が明確になっているか。
・機能化する部分と運用（手作業）で対応する部分が明確になっているか。
・業務フローの粒度は適切か。
※粒度が荒すぎのも、細かすぎるのもいけません。
（この塩梅を未だに自分は分かっていません。）
どんな目的の成果物で、誰が読む資料なのかを考えると適切な粒度が
分かって来ると思います。
##3.リリース後の運用のことも検討してある？
「エンジニアは開発する機能のことばかりに意識がいってしまって、リリース後の運用のことを考えていない。」
私は、上記のような指摘を何回もされてきました。笑
当然のことですが、システムは完成してリリースしたら終わりではなく、
リリースしたら次は運用していかなければなりません。
問題なく運用が回せるように、業務フローで明確にした「運用で対応する作業」についての
設計（手順書・チェックシートの作成等）をする必要があります。
要件定義で運用設計まで行う必要はありません。
実際に開発チームでどこまで対応するのかは、プロジェクトによって様々かもしれませんが、
運用設計をする工数はリリースまでに必ず必要です。
要件定義でどのような運用が必要になるのかを事前に明確にしたら、
関係のある他チームに事前に共有し役割を明確にしておくことが重要となります。
##4.制約条件と前提条件の区別できてる？
皆さんは制約条件と前提条件の区別をちゃんとできていますか？
自分はできていませんでした。笑
制約条件：変更できない条件のことです。
絶対に動かせない納期、顧客の予算、法律や国が定めている制度などがあります。
前提条件：プロジェクトを進めていくにあたって仮決めした条件のことです。
要件定義の段階では、不確実なことが多すぎて設計に移るには情報が足りません。
それでも納期は待ってくれないので仮定や推測で進めていくしかありません。
この際に決めた条件が前提条件です。
前提条件は自分たちで仮決めした条件なので、顧客と必ず合意を取る必要があります。
顧客も忙しく、すぐ打ち合わせして前提条件の合意が取れるわけではないので、
一旦は自分たちで仮決めした条件で突き進む必要があります。
そのため、絶妙な（顧客も納得してくれる）前提条件を定義する必要があります。
（少ない情報から上記を決めるのが非常に難しいです。。）
また制約条件と前提条件を明確にしておくことが後々、
プロジェクトが遅延した際などに役に立ちます。
制約条件はマストなので必ず達成しないといけませんが、
前提条件は仮決めした条件なので交渉次第で何とかできる可能性があるためです。
##5.プロジェクトが成功するかは要件定義にかかってる。
これも耳にタコができるほど聞かされた言葉です。
プロジェクトの失敗原因の約7割は、要件定義が不十分なことだと言われています。
これまで本記事にも記載してきた通り、要件定義でこれから作るモノのことを明確にし、
設計・製造に入る前に準備しておかないと、後工程になるにつれて打てる手も少なくなり、
スケジュールが遅延し、残業地獄になってしまうことでしょう。。
#おわりに
以上が、**「過去にPLから言われた心に刻んでおきたい５つの言葉【要件定義編】」**です。
改めて読み返すと、「おっしゃる通り。。」という内容ばかりですが、
ただ業務をこなしているだけでは、中々理解するのが難しい部分かと思います。
自分は教えていただける機会が運良くあったので、これらの言葉を忘れずに
これからも良いモノを作り続けていきたいと思います。
#参考資料
・画像：顧客が本当に必要だったもの（出典：https://atmarkit.itmedia.co.jp/ait/articles/1705/15/news018.html）
・画像：全ての問題には悩む必要がない（出典：https://www.edrawsoft.com/jp/fun-flowchart.html）