要件定義の進め方について、実践での学び

最近、要件定義プロセス中心に仕事を進めており、その中で学んだことのアウトプットです。LT登壇に使用したスライドでもあります。

Transcript

1. 要件定義の進め方について 実践での学び 2025/1/25 エンジニアの輪 Akitoshi Matsuda 1
2. 名前： 　Akitoshi Matsuda 経歴： 　新卒で建設業界へ、その後IT業界へ転身 　webエンジニア4年目 好きなこと： 　仕事、読書、筋トレ 最近の仕事： 　社内の業務改善システム開発、運用 自己紹介 2
3. 今回のテーマ - もくじ 1 前提：今取り組んでいるプロダクトと要件定義の位置付け 2 要件定義の要 点 3 まとめ ・仮説検証の1,000本ノック ・まずは大枠から考えていく ・ユーザー目線に立ったヒアリングの実施 3
4. 1. プロダクトと要件定義の位置付け 4
5. 1. プロダクトと要件定義の位置付け プロダクトの分類 目的 売上の向上、新規顧客の獲得、市場拡大 ターゲット 顧客や市場 提供価値 顧客への付加価値（新しい機能、便利な サービス） 収益を上げるプロダクト 目的 コスト削減、業務効率化、運用改善 ターゲット 企業内の業務や従業員 提供価値 プロセスの効率化や低コストでの運用 コストを削減するプロダクト 5
6. 1. プロダクトと要件定義の位置付け プロダクトの分類 目的 売上の向上、新規顧客の獲得、市場拡大 ターゲット 顧客や市場 提供価値 顧客への付加価値（新しい機能、便利な サービス） 収益を上げるプロダクト 目的 コスト削減、業務効率化、運用改善 ターゲット 企業内の業務や従業員 提供価値 プロセスの効率化や低コストでの運用 コストを削減するプロダクト 6
7. 1. プロダクトと要件定義の位置付け プロダクトの4階層 Core Why What How プロダクトの世界観、企業への貢献 誰をどんな状態にしたいか、なぜ自社がするのか ユーザー体験、ビジネスモデル、ロードマップ どのように実現するのか ※書籍「プロダクトマネジメントのすべて」より引用 7
8. 1. プロダクトと要件定義の位置付け プロダクトの4階層における、要件定義の位置付け Core Why What How プロダクトの世界観、企業への貢献 誰をどんな状態にしたいか、なぜ自社がするのか ユーザー体験、ビジネスモデル、ロードマップ どのように実現するのか 8
9. 2. 要件定義の要点 9
10. 2-1. 仮説検証の1,000本ノック 10
11. 2-1. 仮説検証の 1,000本ノック この仮説検証サイクルの繰り返し ・完璧な正解はない、誰も知らない 　→優秀な先輩に聞けば分かる、ということはない ・どれだけ考えても、最初から最善策は出せない 　→抱え込みは非効率、レビュー回数を増やす ・アイデア作成→検証→壊して再構築の繰り返し アイデア出し レビュー& ヒアリング 再検討 11
12. 2-1. 仮説検証の 1,000本ノック 仮説検証の際は紙とペン、ホワイトボードを使うことが多い 情報整理や記録のためにテキストを書くツールは使うが、 デザインツール(例 figma)や、具体的な実装時に使用するツールは後回し まずは抽象度の高い要素を用いて、最短で実現可能性をはかることを目指す 12
13. 2-1. 仮説検証の 1,000本ノック 13 実際に紙とペンで描いた例
14. 2-2. まずは大枠から考えていく 14
15. 2-2. まずは大枠から考えていく ・達成したいゴールから考える ・細かな仕様から考え出すと、解決策 を作ることが現実的に不可能 ・抽象度高い要素で仕様を考えていく 　→細かな仕様はあえて考えない ゴール 要素 要素 要素 子 子 子 子 子 子 15
16. 2-2. まずは大枠から考えていく （例） ゴール ＊＊の明細をシステム管理できる状態にする 大要素 会計システム、業務システム、全体の運用プ ロセス 小要素 会計APIの仕様、改修後の業務プロセス詳細 設計など ゴール 要素 要素 要素 子 子 子 子 子 子 16
17. 2-2. まずは大枠から考えていく ゴール 要素 要素 要素 子 子 子 子 子 子 17 （例） ゴール ＊＊の明細をシステム管理できる状態にする 大要素 会計システム、業務システム、全体の運用プ ロセス 小要素 会計APIの仕様、改修後の業務プロセス詳細 設計など
18. 2-3. ユーザー目線に立ったヒアリングの実施 18
19. 2-3. ユーザー目線に立ったヒアリングの実施 ・ヒアリングでユーザーの業務を正確に理解していくことが必要 ・ユーザーに直接何が欲しいかを聞くことは意味がない 　→業務を理解し、課題を自分で把握する ・「用語」と「抽象度」を合わせて会話を進行する 　→何について話しているかを会話の中で常に調整し、認識齟齬を生まないよう に進行する 19
20. 2-3. ユーザー目線に立ったヒアリングの実施 A = プロジェクト B = 原価と販管費 C = ID(=レコードのidカラム) D = システム(=今使っているもの) A = 案件 B = 原価 C = ID(=レコードのcodeカラム) D = システム(=新しく作るもの) 20
21. 2-3. ユーザー目線に立ったヒアリングの実施 A = プロジェクト B = 原価と販管費 C = ID(=レコードのidカラム) D = システム(=今使っているもの) A = プロジェクト B = 原価と販管費 C = ID(=レコードのidカラム) D = システム(=今使っているもの) 21
22. まとめ 22
23. プロダクト開発における要件定義プロセスについての話でした 私の要件定義プロセスを通しての学び ・仮説検証の1,000本ノック ・まずは大枠から考えていく ・ユーザー目線に立ったヒアリングの実施 要件定義に正解はない それぞれのチームや個人に最も合う方法を見つけることが大事だと考える まとめ 23
24. ご清聴ありがとうございました！ 24