要件定義のやり方【準備編】
要件定義をするにあたって
要件定義は依頼主と制作主のお互いの納品条件の明確化をする
- 依頼主と制作主側で作るもののギャップや受け取り方のちがいを無くす
- お互いに気持ちの良い仕事ができるようにするためのもの
揃える道具
- 企画書
- 全体像（オーバービュー）
- 実装手段
- やりたいこと一覧（バックログやアイスボックス的なやつ）
基本的な流れ
- 依頼主の要望を引き出す
- 引き出した要望を制作主に要望として伝える
- 制作主は要望を見て検討する
- 検討を経て、より良い提案をする
- またはこれは実現が難しいので、こうしたらどうでしょうと代替案を出す
- 依頼主はそれらを読み、聞き、検討する
- そうしてまた2に戻り、繰り返す
企画書を作成する
- プロジェクト名
- なぜ
- 目的
- 何を
- 目的達成のために
- 作るものの説明
- 作るものを利用する人
- 利用する人が得られる利益
- どのように
- 作るための体制
- 期限
- 費用
企画書は「通す為のものではなく」「メンバーが理解できるもの」を作成すること。
企画書を書くときの注意
- 制作を依頼する側の関係者や関わりが薄い人でも理解できるもの
- わかりやすくするための細かい解説は別の補助資料にまとめる
関わるメンバーが走るべき目標を記述する
- 各々の頭のなかで管理をしていると、時間が立つにつれ目標がずれるため。
プロジェクトで得られる利益
- この企画を経て得られる利益を明記
利用者たちが実現したいことを図にする（オーバービュー）
- システムを真ん中において、システムの利用者を洗い出す
- 利用者各々でシステムで利用したいことを書き連ねる
- すべて洗い出しすることが目的ではないので、大まかなで良い
注意 - アドミン機能も忘れず書くこと - 外部システムとの連携がある場合は外部システムに渡すべき必要な情報を書く
図ができたらきれいな見た目やXDなどで軽いUIを作って提出する - あくまで他者が見て理解しやすくわかりやすいものを書く - 文章の説明より、図や写真をつかった方がイメージが伝わる
実装手段の選定・技術選定
システムの利用環境
- WEBシステムなのか
- スタンドアローンのようなシステムなのか
- WEBは使わないのか（インターネットがなくても使えるものなのか）
インタラクションアーキテクチャにおける検討項目
システムの流れを実現させるために何を使うのかを明文化させる
やりたいこと・実現したいことリストをつくる
!!これは本来企画書前に完璧に完成させておく必要がある!!
実現したいことをとにかく羅列する
- 粒度の大きなでも詳細なものでも良い
- とにかく書き出す
- 決まりきったことでなくてもよい
要求の洗い出しする
- 明文化する、させることによって相手の要求を共有できる
- 要求は変更されるに決まっているという前提を理解する
やりたいこと・実現したいこと一覧を整理する
- 実現したいこと一覧のなかに矛盾などがあるので、その解消をする
- 実現したい内容があまりにもかけ離れている場合は、その解消をする
完成した後に依頼主の期待が全く反映されていないという事件を回避する為に必ず時間をかけて分析・整理を行う必要がある これを要件定義工程に入る前にやり終えなければ必ず炎上する or 期待に添えないものをつくることになる
