要件定義入門

なぜ要件定義をするのか

• ユーザーのニーズや要望を正確に把握するため
• システムの目的やスコープを明確にするため
• システムの開発や導入にかかるコストや期間を見積もるため
• システムの品質や信頼性を確保するため
• 開発プロセス全体の効率を上げるため
• 開発チームや関係者間のコミュニケーションを円滑にするため
• システムの将来的な拡張や改修のための基盤を作るため
• 開発過程での課題やリスクを事前に特定し、適切な対策を講じるため

登場人物

• ビジネスサイド
  • ユーザー
    • システムを利用する人
  • プロジェクトマネージャー（PM）
    • ユーザーと社内SEとのやりとりを調整
• エンジニアサイド
  • 社内SE
    • プロジェクトマネージャーとエンジニアのやり取りを調整
  • プログラマ
    • システムを作る人

システム開発が難しくなる要因

以下の要因がシステム開発を難しくしている

• ビジネスサイド
  • ユーザーの意見をすべて実現しようとしてしまっている
  • DX化やAIという技術への関心が先行して、期待値が高すぎる
• エンジニア
  • 意見をすべて実現しようとしてしまう
  • ビジネスサイドの業務フローを完全に理解できていない

要件定義のゴール

ビジネスサイドとエンジニアサイドの双方がプロジェクトへの共通認識ができる

• 共通認識
  • プロジェクトの目的
  • どんな希望が必要なのか
  • いつ、誰が、なんのためにシステムを利用するのか

基本設計のゴール

エンジニアサイドがどんなシステムを作るのかをビジネスサイドに伝わる

• どんなUIUXを作ればよさそうか
• 各画面でどんなことができればいいのか
• ビジネスロジックを再現するデータ構造はなにか
  • 概念の抽象度を上げるとわかりやすい
    • （抽象度低）みかん→果物→食べ物（抽象度高）

よくある失敗

• 目的意識がズレいていると失敗しやすい
  • エンジニア
    • 納期や工数などを具体的にきっちり決めてから開発に着手したい
  • ビジネス
    • 柔軟に決めながら進めて行きたい
• 「良いシステム」の基準がズレいていると失敗しやすい
  • エンジニア
    • 保守性
    • 効率性
    • 移植性
  • ビジネス
    • 機能性
    • 信頼性
    • 使用性

要件定義に必要なこと

• 要件定義の2W
  • Why：システムの開発目的は
  • What：どうやって課題を解決するのか
• 基本設計の1H
  • How：どんなシステムを作るのか

要件定義の手順

1. （Why）ビジネス側で以下を作成
   1. 現状で困っていること
   2. 目指すゴール
   3. 現状とゴールのギャップ（これが解決すべき課題）
2. （What）エンジニアに相談
   1. システム導入後の業務フロー
   2. システムに必要な機能一覧
   3. システムの使用感
3. （How）ビジネスサイドに提案
   1. 画面設計（UI/UX設計）
   2. 機能要件
   3. データ設計

実際に要件定義をしてみよう

要件定義は、以下の流れで進んでいきます。

1. 要望
2. 要求
3. 検討
4. 提案
5. 要件

要望フェーズ

概要

現状とゴールを比較して、そのギャップから「こんなシステムあったら良いな」のアイデアを出す（システム利用者へのヒアリングがメイン）

誰がやるのか

ビジネスサイドのPM

明確にすること

1. 現状の洗い出し
   1. 業務プロセス
   2. 現状の問題点
2. ゴール設定
   1. 本来あるべき状態もしくは、目指す状態
3. 現状とゴールのギャップを分析
   1. 解決すべき課題の洗い出し
4. ヒアリング
   1. システムに何を求めるのか

ポイント

• ヒアリングの前段階で「何を目的としたプロジェクトなのか、達成したいゴールとは何か」といった背景の目的を理解してもらうことが良い情報収集のポイント
• 要求を聞きすぎると、実装できなかった際に顰蹙を買う可能性があるので、聞く際はお互いがゴールを把握できているのか知っておく必要がある

要求フェーズ

概要

システム概要や、欲しい機能を整理して、エンジニアに「こんなシステムを作りたい」を提案依頼する

誰がやるのか

ビジネスサイドのPM

明確にすること

1. 開発の目的のブラッシュアップ
   1. 達成するゴールを数値で明確化
   2. クリアすべき課題に分解
2. ゴールの達成条件を明文化
   1. ※SMARTの法則に沿ってチェック
3. 開発後の業務フロー
   1. ビジネスフローとシステムの関係性
4. システムに実装したいこと
   1. 機能一覧
   2. 非機能要求

ポイント

• 要望フェーズで議論が発散したり、関係者同士で意見が食い違うケースが多いので、それらを集約することがPMに求められます。
• 開発後にユーザーのイメージと違うとならないように、要求フェーズでSMARTに立ち返って考えることが重要

補足

• SMARTとは
  • Specific（ゴールが具体的か？）
  • Measurable（進捗を数値で測れるか？）
  • Achievable（達成可能か？）
  • Relevant（当初の困りごとが解決するか？）
  • Time-bound（期限が明確か？）

検討フェーズ

概要

IT目線で企画の実現性を検討する
この機能は本当に必要なのか、こっちの代替案の方がいいのではないかなど

誰がやるのか

社内SE

明確にすること

1. ゴール達成できそうか
   1. 必要な機能が揃っているか
   2. 利便性を下げる余計な要素がないか
2. 技術的にどこまで可能か
   1. AIなどの流行により、クライアントから過度な期待がかかるので、そこを調整する
   2. 代替案の検討
3. 予算はどの程度必要か
   1. エンジニアの単価x工数
4. 納期はいつごろになるのか
   1. 設計〜実装〜テスト〜リリース

ポイント

• 開発目的、予算、納期のバランスを踏まえつつ、開発スタートの道筋を作る
• 他社事例・技術トレンドを踏まえつつ、別案や追加案をアドバイス
• 開発スピード。予算の都合を見ながら目的を満たす妥協案を用意
• 言われたことをそのまま実装するのではなく、違和感や改善箇所があれば随時確認していく

提案フェーズ

概要

企画の実現ラインをフィードバック（機能、予算、納期）

誰がやるのか

社内SE

明確にすること

1. ビジネス要求のフィードバック
   1. 要求からの変更点
   2. 代替案の提示
2. 実装する希望・実装しない機能
   1. やらないことも明記するのがポイント
   2. あくまでも提案なので、変動する
3. 開発コスト・期間
   1. バッファを含めて提示
   2. 予算調整で開発内容が変更されるケースもある

ポイント

• 「〜これが整えば可能」「代替案はこれ」といった目的意識が大事
  • 初期リリースには間に合わないので、第二弾で対応するのはどうか
  • 予算がたりないので、代替案のBではどうかなど
• ビジネス側は後で柔軟に変えられると思っている
  • 言語化されていな要求を防ぐ方法
    • 基本設計の段階で画面設計図をみせてイメージしやすくしてあげる
    • 開発のスパンを短くして細かくリリースする

要件フェーズ

概要

ビジネス側とエンジニア側で協議した決定事項を整理して、システム完成後に「これでOK」と双方が納得できる共通認識を作っておく

だれがやるのか

• 社内SE
• ビジネスサイドのPM

明確にすること

1. やると決めたこと
   1. 開発する機能一覧
   2. 開発の順番（追加機能のリリース順番）
2. やらないと決めたこと
   1. 重要度の低い開発要求
3. 業務フローの最新版
   1. 要求整理のタイミングから更新する

ポイント

• 「実装する機能」だけ説明すると、あとからトラブルになるので「やらないこと」、「変更したこと」を明確にしておく
• 簡単なイメージ画面を作るだけでも、潜在的なニーズを拾えるのでおすすめ
• 要件定義が机上の空論にならなうように、業務フローに落とし込んで考えるようにする

最後に

要件定義を改めて体系的に学ぶことで、よりよい開発ができると思いました。
上流工程は人間にしかできない仕事だからこそ、今最も需要があると思ってます。