【初心者】要件定義のプロセスまとめ

前提①：システム開発の登場人物

立ち位置	役職	役割
ビジネスサイド	エンドユーザー	実際にサービスを利用する人々
ビジネスサイド	PM	ユーザーの要望を整理し、企画した上で、要件定義をする
開発サイド	SE	PMと協力してシステムの設計を行う。 また、プログラマーへのタスク分担を行う
開発サイド	プログラマー	設計書に沿ってシステムを実装する

☆PMとSEの打ち合わせをどのように進めるか？のイロハを解説していきます。

前提②:システム開発で起こりがちな失敗例

そもそも要件定義から、PMがSEに丸投げしてしまう

• システムが完成し始めた段階で問題が発覚するため、取り返しのつかない状態になりがち。

要望をすべて記載してしまう

• ユーザーの中でも矛盾は必ず発生してしまう。
• たとえば、業務効率化システムでは、経営者と現場で働く人の見え方は異なる。
• 要望をすべて記載することはせず、競合したものについては優先順位をつける姿勢が大切

「良いシステム」の定義が、立場によって違う

• ビジネスサイドは、「ユーザーが使いやすい」のが良いシステム
• 開発サイドは、「バグが発生しにくい」のが良いシステム

途中の仕様変更に対する見積もりが、ビジネスサイドで甘くなりがち

• 「ハンバーガーのピクルスを抜きにしてほしい」　程度ならば、後からでも変えられるが、「えびカツバーガー」に変えてほしい は不可能。そのレベルの変更要望が、開発では頻発する。
• 基本設計を作成した段階が、要件定義書のヌケモレを入念にチェックする最高のタイミング

その他

• プログラマーが、自己都合で機能を変更してしまう
  • 工数を減らすため
  • 興味本位で、使用したいライブラリを使用する
• 「システムは万能」という思い込み
• システム開発自体が目的になっている
  • DXなど、流行をもとに意思決定してしまっている
• このあたりの失敗例は、全員で共有しておくとよい
• 「品質」には、国際的な定義があるので覚えておくとよい　→ ISO25010

上流工程（要件定義・基本設計）はなぜ必要か？

結論： 登場人物４者が、システムについて共通認識をもつこと

• 解決したい課題
• 必要な機能
• いつ、誰が、何のために利用するか？

ゴール

• PM: 要件定義書を細かく記載し、開発サイドに欲しいシステムの内容をわかりやすく伝える
• SE: 基本設計書を細かく記載し、ビジネスサイドに作るシステムの内容をわかりやすく伝える

要件定義で必要なもの

• 要件定義書
  • 課題・背景
  • ゴール（いつまでに、どうしたいか）
• 機能一覧表
  • Excelなどで作成
• 業務フロー
  • PowerPointなど

要件定義のプロセス

1. 要望（PM）

ポイント：
① 実は、技術的な問題よりも、ビジネス的な課題の方が多いことを知る
② 要望は、希望度の高いものだけ記載する

• 事業の概要
• 業務プロセス（アクティビティ図などにまとめる）
• 現状の問題点
• 目指すゴール
• 解決すべき課題
• ヒアリング（システムに何を求めるか）

2. 要求（PM）

ポイント：ゴールを達成できる要求になっているか？よく確認する

• 達成すべきゴールを数値で明確化
• クリアすべき課題
• ゴールの達成条件を SMART に沿って整理
  • Specific（ゴールが具体的か？）
  • Measurable（進捗を数値で測れるか？）
  • Achievable（達成可能か？）
  • Relevant（当初の困りごとが解決するか？）
  • Time-bound（期限が明確か？）
• 再度、未来の業務プロセスのイメージを作成（アクティビティ図）
• Excelなどで、機能一覧表を作成

3. 検討（SE）

• 要求項目１つ１つに対し、返答する
  • OKならばよいが、難しい場合も、単に「できない」ではなく、予算がどの程度かかり難しいなど補足する
  • 何らかの代案を提案する
    • より実現しやすい、似たような機能
    • バージョン2で実装する
    • 要求項目は相互に順序づけがあるため、「項目◯◯の後で再検討する」などの提案
• バッファを含めた予算、期間を設定する

4. 提案（SE）

ポイント
ビジネスサイドは、変更が簡単であると思い込んでいることがあるため、変更にかかる金額を念押しして伝える
とはいえ、最初に全て決めるのはそもそも難しいため、その気持ちを汲みとり、バッファの提案や、アジャイル開発に生かす

• 検討した内容を提案する
  • 実装する機能
  • 実装しない機能←きちんと明記することで、トラブルを抑制できる
    -　やらないことによるユーザーへの影響を言語化しておく
• 企業からのフィードバックを受けて、ブラッシュアップする
• 認識のズレを防ぐコツは？
  • 言語化されていない、潜在的な要求を見越したスケジュール提案をする
  • 画面遷移図ワイヤー完成を確定タイミングとする
  • 機能をバージョンごとに分ける（アジャイルの意識）
• この段階で、画面遷移図はある程度作ってしまってもよい

5. 要件定義（PM・SE）

ポイント
ビジネスサイドは、変更が簡単であると思い込んでいることがあるため、変更にかかる金額を念押しして伝える
とはいえ、最初に全て決めるのはそもそも難しいため、その気持ちを汲みとり、バッファの提案や、アジャイル開発に生かす

• 明記する事項
  • 実装する機能
  • 実装する順序
  • 実装しない機能
  • 最新の業務フロー（アクティビティ図）
• もう一度、ユーザーのニーズから逸脱していないか、よく吟味する

☆以後の内容は、現在加筆中です。

• 気をつけるべきこと
• 非機能要件について
• ウォーターフォールとアジャイルそれぞれにおける応用