【随時更新】【自分用メモ】要件定義ガイド

Last updated at 2024-05-13Posted at 2024-04-19

はじめに

■この記事は何か
ITのバックグラウンドを持つ私が、今までの要件定義の経験で受けたFBや知見を主観的に整理したもの。

■対象読者

要件定義の進め方・抑えるべきポイントの一例を知りたい方
この資料にFBしてくださる親切な方

■ねらい

本資料が要件定義を行う際の指針となること。（特に自分にとって）
読者からFBをいただき、よりよいガイドにアップデートするためのInputを得ること。

前提

要件定義の目的

発注者の要望をシステム設計が可能な状態まで整理・言語化すること。

開発の一連の流れにおける要件定義の位置付け

発注者の要望からシステム運用に至るまでの大まかな流れは以下の通り。

余談ですが、私は「設計」~「運用」まではそれなりに経験してきており自信はあるのですが、最近「要件定義」に挑戦し始めて苦戦中の身です笑
なのでこれ以降の内容は暖かい目で読んでいただけると助かります。

要件定義の進め方

概要

「発注者の要望」を要求にまで落とし込む「ビジネス要件定義」を行い、
更に「ビジネス要件」をシステムが満たすべき事項にまで落とし込む「システム要件定義」を行う。

ビジネス要件定義

やるべきこと

AsIsとToBeを整理する。
- AsIs と ToBe(=要望) のギャップが要求(=達成すべきこと)になる。
  - ただし、AsIsはノイズでゼロベースでToBeを検討すべき時は、AsIsはあえて書かないこともあり。（Appendixにでも置いておけばいい。）
「要求」を 5W1H で整理する。
- まず「What」「Who」「Why」を整理し、その後で残りのWHを整理するのがやりやすい。
- シーンに応じて解釈を変えていいが(なんならシーンに合った解釈を都度すべきだが)、個人的にしっくりきている和訳は以下の通り。
  - What：達成したいこと
  - Who：達成者
  - Why：達成したいことの理由
  - When：達成したいことの期限・期間
  - Where:達成箇所（＊多くの場合、アプリケーションやシステムを指すと思う。）
  - How:達成方法
- 5W1Hで明瞭に書けないものがあれば発注者にヒアリングする。
  - すぐ答えが返ってこない場合は、そこがビジネス要件の論点となる。
論点を整理して発注者と結論を出す
- 聞き手の理解度や目線に応じて伝え方を使い分ける。
  - 理解度が高く・目線が高い人向けには、結論サマリとして1~3枚のスライドで説明し切る。それだけで議論できるようにする。
  - 理解度の低い・物事を突き詰めて考えたい人向けには、結論サマリをおくとそこで議論が巻き起こって説明が十分にできないケースがある。思考の順を追って、それぞれ説明していく。
    - 突き詰めて風呂敷を広げすぎると思考の収集がつかなくなる。検討の範囲が大きい場合はHowでもいいので範囲を絞るところを最初に持っていくとよい。
- 一度に全ての論点を突き詰めるのではなく、検討すべき順序で少しずつ短期サイクルで発注者に当てていくのが良い。不要な案の検討に時間をかけなくてすむし、発注者の理解も追いつきやすい。
- 発注者の関心ごと(セキュリティやコストなど)については、完全に疑問を潰せるように資料で全て表現しきる。疑問を潰すために、具体的なシステム要件や運用方法などに踏み込む必要があれば踏み込んでしまう。

抑えるべきポイント

システムの話は必要以上に盛り込まない。
- システムの裏側を全く理解していない目線で、要望だけをInputにビジネス要件を整理する。
- 例えば「●●ロールでAPI利用権限を制御する」ではなく、「○○の情報を取得できる者は、▲▲の組織に所属している人間のみとする」とか。言い換える。
- 必要に応じて聞き手の理解度に合わせたシステム的な用語を使うこともありだけど、常にシステム目線になりすぎないことを意識する。

システム要件定義

やるべきこと

ビジネス要件の概要を示す。
- 「背景」「機能の目的」「ユーザストーリー」を明確にする。
「機能要件」を整理する。
- 入出力
- UI/UXデザイン
  - 「設計」の工程に落としても良い。
  - ただし、システム構成図や入出力だけでは発注者がシステムのイメージがつききらないケースがあるため、システム要件定義の段階でUI/UXイメージのすり合わせはしておいてもよいと思う。ここで機能の漏れを拾えるケースがある。
  - ユーザビリティを最大限に意識する。多くの場合で発注者が一番気にするポイント。
「非機能要件」を整理する。
- IPAの非機能要求グレードを参考にする。
- 以下の項目別に整理する。
  - 可用性
  - 性能/拡張性
  - 運用/保守性
  - 移行性
  - セキュリティ
  - システム環境/エコロジー
論点を整理して発注者と結論を出す
- システムとして許容できる・できないの線引きを明確にする。
  - 許容できる内側はビジネス要件で判断。
  - ビジネス要件で判断できない場合は、決裁者の関心を軸に比較する。
    - 以下は例。
      - 影響
        
        利用者影響
        
        (特に利用者体験が毀損する可能性は漏らさずに。)
        
        システム影響
      - コスト
        
        開発コスト
        
        運用コスト
      - セキュリティリスク

抑えるべきポイント

積極的に推奨案を提示する。
- 発注者がシステム理解度が低いケースもあるため、こちらから推奨案を示す。理由も明確にする。
実装だけでなく、運用まで考慮する。
- 保守性や運用性の低いシステムは、その後大きなコストがかかり続ける。

Outputの仕方

資料作成

抑えるべきポイント

伝える相手に相談したいポイント・決定してほしいポイントをそれぞれ明確に示す。
案の比較は以下に注意する。
- 案の粒度を合わせる。
- 比較はなるべく定量で示す。
図や表を使う場合は読み手の視線移動が少なくなるように考慮する。
以下は資料の構成例。
- 概要
  - 資料の目的
  - スケジュール・マイルストン
  - 全体像
    - (検討すべき事項の全体像と、この資料で論じているスコープを明確にする。)
- 前提
  - (検討に必要な知識を説明)
- 論点
- Next Action
- Appendix
  - (聞き手の理解度を加味して、論点を論じる上で過剰な情報は全てAppendixへ。)

資料説明

抑えるべきポイント

はじめに以下を伝える。
- ゴール
  - 実現したいこと
  - 期限
  - etc
- ゴールに対する現在地
- 資料の完成度（まだ6割の状態ですが、一度当てさせていただき目的・方向性のズレがないか見てください、とか。）
- MTGの目的
- 今後の段取り（いつまでに何を決めたい）
続いて内容の説明に入る。
- 目次ベースで資料構成を説明
- 不明点などなければ資料の内容に入っていく。
MTG終了5分前になったらラップアップとNext Actionの整理をして終了。

あとがき

この記事を書くにあたり自分の経験と一般論のズレがないか気になり、「要件定義の進め方」とか「5W1H 要件定義」とか色々ググりました。
思いのほか粒度も観点もページによってまちまちで自分にしっくりくるものも見つからなかったので、今回整理してよかったかなと思っています。
かなり主観で書いているので、一例として参考程度に思ってください。

もしここに書かれていない抑えるべきポイントがあったり、もっといい進め方を知っている方がいましたら、是非コメントで教えてください。
最後まで読んでくださりありがとうございました！
（また知見が増えたら加筆・修正していきます。）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up