スクラムチームだけどエクセルで要件定義書を書くことにしました / Requirements-Specification-Document-in-Scrum

スクラムフェスタ大阪2024 三河トラック
発表資料

Transcript

1. © 2024 ESM, Inc. スクラムフェスタ大阪2024 三河トラック スクラムチームだけど エクセルで要件定義書を書くことにしました 1 2024年06月22日 永和システムマネジメント Agile Studio 岡本 卓也
2. © 2024 ESM, Inc. アジェンダ 1. 自己紹介 2. 私たちの課題 3. なぜ要件定義書なのか 4. スクラムの要件定義書 5. 作成した要件定義書 6. 私たちの変化 7. 本当の価値 8. 宿題 9. まとめ 2
3. © 2024 ESM, Inc. 3 自己紹介とプロジェクト説明
4. © 2024 ESM, Inc. 自己紹介 • 岡本 卓也 • EM＠AgileStudio • スクラムコーチ兼開発者 ◦ ガチWF ：15 年 ◦ 過渡期 ：5年 ◦ Agile ：5年 • アジャイル開発導入支援 WFからの移行支援 • X：@haraguro3 • note：https://note.com/haraguro3 • mail：takuya.okamoto@esm.co.jp 4
5. © 2024 ESM, Inc. 永和システムマネジメント 5 福井本社 WeWork 沖縄 • 金融、医療、組込み(自動車) • Web/Cloud、アジャイル開発 • 社員 210名エンジニア集団
6. © 2024 ESM, Inc. Agile Studioのサービス 6 組織をアジャイルにするための人づくり
7. © 2024 ESM, Inc. チームの紹介 7 PO DEVチーム SM
 SM補佐
 • チーム構成: 9名 ◦ 弊社2名、お客さん7名 • お客さんの開発経験 ◦ 手探り：5年くらい ◦ スクラム経験：ゼロ • 開発支援開始: 2023/06~ ◦ 内製化に挑戦 ◦ スクラムに挑戦 • 現在のステータス: ◦ スクラムイベントが定着 ◦ 定期的なデリバリーが可能
8. © 2024 ESM, Inc. 8 私たちの課題
9. © 2024 ESM, Inc. みなさんのスクラム開発、順調ですか？ 「スクラムチームを作った」 「スクラムの研修を受けた」 「ちゃんとスクラムイベントを開催している」 はずなのに「思ったほど上手く開発できてないな〜」と思うことはありませんか。 例えば • （思ったよりも）開発のスピードが出ない • （思ったよりも）品質が安定しない • （思ったよりも）リリースした機能がウケない 9
10. © 2024 ESM, Inc. 私たちのチームで起きたこと 開発支援を始めて半年が過ぎた頃… チームではスクラムイベントが定着し、定期的に製品をデリバリーできるようになり 順調に成長しているように見えるが、同時に不穏な気配も感じられるように。 • 「あれ、これってどうすることにしたんだっけ？」の会話が増える • 「最近、バーンダウンチャートが着地しないねえ」が常態化する • スプリントレビューで差し戻しが発生する 10
11. © 2024 ESM, Inc. 振り返りでの気づき 11
12. © 2024 ESM, Inc. 開発のスピードが出ない こんな状態だった • 正しい動作を考えながらコードを書いている • 書いた本人（考えた人）にしか正解がわからない実装になる その結果起きること • コードレビューしても意図がわからない • コードレビューしながら正解を考える • ここから議論して書き直し 12 これではスピードは出ない
13. © 2024 ESM, Inc. 開発の品質が悪い こんな状態だった • 正しい動作を考えながら試験仕様を書いている • 書いた本人（考えた人）にしか正解がわからない試験になる その結果起きること • 手順書をこなすだけの機械的な試験 • （不具合が発生したら） • 正しい動作を考えながら機能を直す • 正しい動作を考えながら試験仕様を直す 13 これでは品質は出ない
14. © 2024 ESM, Inc. スプリントレビューでNG こんな状態だった • デモで見せたものがPOの期待と異なる • ステークホルダの間でも期待が異なることが判明 その結果起きること • スプリントやり直し • リリーススケジュールの見直し • リリースする機能のドロップ スクラムではよく「フィードバックを回す」などとポジティブに表現されるが 「不確実性」ではなく「開発能力」のせいで起きてはダメ。 14
15. © 2024 ESM, Inc. 開発についての共通理解がなかった チームメンバの間で 「何を作ればいいのか」 「なぜそれが欲しいのか」 「どうやって作ればいいのか」 についての理解がバラバラだった 15 群盲象を撫でる方式の開発 

16. © 2024 ESM, Inc. ゴールデンサークル 16 Why
 What
 How
 効果的なリーダーシップとマーケティングの枠組みを提供する。 Inside-Out（内側から外側へ）: 効果的なリーダーシップやマー ケティングは、外側から内側（What→How→Why）ではなく、内 側から外側（Why→How→What）にアプローチすべきだとしてい ます。 最も成功しているリーダーや企業は、「Why（なぜ）」から始 め、次に「How（どのように）」を説明し、最後に「What（何 を）」を伝えています。 Chat GPT-4oさんありがとう
17. © 2024 ESM, Inc. How: どうやって作る？ What: なにを作る？ チームに足りなかったもの 17 Why
 What
 How
 開発者はここに行きがち 本当に大事なのはこちら Why: なぜ欲しい？ 「何を作ればいいのか」 「なぜそれが欲しいのか」 「どうやって作ればいいのか」
18. © 2024 ESM, Inc. そうだ要件定義書を作ろう 18 私たちに必要だったもの 
 バラバラだった理解 
 How: どうやって作る？ What: なにを作る？ Why: なぜ欲しい？ 作るもの（What）と 理由（Why）を定義 したもの・・それって 要件定義書なのでは？
19. © 2024 ESM, Inc. 19 なぜ要件定義書なのか
20. © 2024 ESM, Inc. Q：どこから出てきた？ A：岡本の思いつき ガチWF時代は数十人規模のチームで1年以上かけて一つの開発をしていた。 暗黙知や以心伝心は通用せず、効率が悪くてもドキュメントが必要だった。 共通理解のために作る要件定義書の威力は熟知していた。 • 今の我々に足りていないのは共通理解 • ストレートに要件定義書がハマるはず • 今ならあの時の弊害もクリアできる 20 自然な流れ 要件定義書を書こう
21. © 2024 ESM, Inc. Q：要件定義書なんて書いてもいいの？ A：良いです スクラムガイドには要件定義書を作れとは書かれていない。 世の中にあるアジャイル開発のやり方を調べても出てこない。 中で使うプラクティスは自分たちで考える 21 だからといって書いてダメな理由はない
22. © 2024 ESM, Inc. A：あった • PBIチケットをリッチにする • ユーザーストーリーマッピング • リファインメント Q：他の選択肢はなかったのか？ 22 具体的なタスクや機能の管理 に焦点 全体像やコンテキストを 提供するには不十分 リッチなPBI 機能の流れや優先順位を理解 することに焦点 要件や制約条件を包括的 にカバーできない ユーザーストーリーマッピング 詳細を検討/具体化しPBIを Readyにするためのプロセス 情報を一元的に管理/参照 するには向かない リファインメント 分かりやすさ重視 <<手法>> <<document>> 要件定義書 <<責務>> 共通理解のために 要件を定義する それぞれ、本来の主たる目的を持っているため 別の目的を追加するとチームメンバが混乱する でも… でも… でも…
23. © 2024 ESM, Inc. 23 スクラムの要件定義書
24. © 2024 ESM, Inc. 要件定義書 24 ソフトウェア開発プロジェクトやシステム開発プロジェクトにおいて、シス テムやソフトウェアが満たすべき要件を詳細に記述した文書。 プロジェクトの成功に不可欠なドキュメントであり、開発チームやステーク ホルダー間の共通理解を促進し、開発プロセスを円滑に進めるために重要。
25. © 2024 ESM, Inc. スクラムの要件定義書 25 柔軟性と適応性を重視し、対話とコラボレーションを通じて進化します。価 値の提供を中心に据え、インクリメンタルに進化する要件を簡潔にまとめる ことが特徴。 ソフトウェア開発プロジェクトやシステム開発プロジェクトにおいて、シス テムやソフトウェアが満たすべき要件を詳細に記述した文書。 プロジェクトの成功に不可欠なドキュメントであり、開発チームやステーク ホルダー間の共通理解を促進し、開発プロセスを円滑に進めるために重要。 スクラムでは
26. © 2024 ESM, Inc. WF開発の要件定義書 SoR（System of Record）としての役割 1. 完全性と正確性： ◦ WF開発では、プロジェクトの初期段階で詳細な要件定義書を作成します。この文書は、プロジェクト全体の 指針となり、開発の各フェーズ（設計、実装、テスト、展開）における活動を明確にします。 ◦ 要件定義書は、すべての機能要件、非機能要件、制約条件を網羅し、詳細に記述する必要があります。 2. 変更管理： ◦ 要件定義書は、プロジェクトの公式記録として機能します。要件の変更が発生した場合、変更管理プロセス を通じて正式に文書を更新することが求められます。 ◦ 変更が発生すると、すべての関係者に通知され、影響分析が行われます。 3. 契約的役割： ◦ 要件定義書は、顧客と開発チームの間の契約的な文書として機能します。これに基づいて進捗を評価し、契 約上の義務を確認します。 4. トレーサビリティ： ◦ 各要件が設計、実装、テスト、そして最終的な製品にどのように反映されているかを追跡できるようにしま す。これにより、すべての要件が確実に満たされることを保証します。 26 Chat GPT-4oさんありがとう
27. © 2024 ESM, Inc. スクラムの要件定義書 SoE（System of Engagement）としての役割 1. 柔軟性と適応性： ◦ アジャイル開発では、要件は固定的なものではなく、プロジェクトの進行とともに進化することが前提で す。ユーザーストーリー形式で要件を表現し、プロダクトバックログに管理します。 ◦ 要件はスプリントごとに詳細化され、変更が容易です。 2. 対話とコラボレーション： ◦ 要件定義書そのものよりも、ステークホルダーとの対話やチーム内のコミュニケーションが重要視されま す。要件はミーティングやワークショップで具体化され、理解が深まります。 ◦ プロダクトオーナー、開発チーム、ステークホルダーが継続的に対話し、要件を精査し、優先順位を付けて いきます。 3. 価値の提供： ◦ アジャイルでは、要件定義書は価値を提供するための手段であり、完成品そのものではありません。重要な のは、要件定義を通じて価値のある成果物を継続的に提供することです。 ◦ ユーザーストーリーは、ユーザーや顧客にとっての価値を中心に構成され、優先順位が付けられます。 4. インクリメンタルな進化： ◦ 要件はスプリントごとに詳細化され、リリースごとに見直されます。これにより、プロジェクトの進行に合 わせて要件が進化し、顧客のニーズや市場の変化に迅速に対応できます。 27
28. © 2024 ESM, Inc. 要件定義書の構成要素 1. プロジェクト概要 2. ステークホルダーの要求 3. 機能要件 4. 非機能要件 5. システム要件 6. ユースケース 7. 制約事項 8. トレーサビリティ 28 SoRの4特性 1. 完全性と正確性： 2. 変更管理： 3. 契約的役割： 4. トレーサビリティ： WF開発の要件定義書
29. © 2024 ESM, Inc. スクラムの要件定義書の構成要素 1. プロジェクト概要 2. ステークホルダーの要求 3. 機能要件 4. 非機能要件 5. システム要件 6. ユースケース 7. 制約事項 8. トレーサビリティ 29 1. ステークホルダーの要求 2. 機能要件 3. 非機能要件 スクラムの要件定義書 1. 柔軟性と適応性： 2. 対話とコラボレーション： 3. 価値の提供： 4. インクリメンタルな進化： SoEの4特性
30. © 2024 ESM, Inc. 30 作成した要件定義書
31. © 2024 ESM, Inc. 私たちの要件定義書 31 Req-ID 要件 理由 1 １テナントでの1日あたりの出荷上限台数を設定できるようにしたい １テナントから大量の申請が出る場合、システムの出荷上限に到達してしまい、 他のテナントが申請できなくなる 2 全てのテナントに出荷上限台数を設定する必要はない 不要な設定コストをかけたくないため 3 出荷上限台数が設定されていないテナントは、無制限として扱う 不要な設定コストをかけたくないため 4 各テナントに対する出荷上限台数はシステムのUIから設定/参照したい CSチームが設定をしたいため 5 テナントの出荷上限台数を設定した結果、システム全体ではまだ余力があって も上限に到達したテナントからは申請できなくなるが問題ない 運用や開発を簡素化したいから 機能要件・非機能要件 ステークホルダの要求 要素は3つ
32. © 2024 ESM, Inc. 作成コストは最小限 最小コストで作る • エクセルで作る • 項目は「ID」「要件」「理由」の3つだけ • 全員で作る 32 Req-ID 要件 理由 1 １テナントでの1日あたりの出荷上限台数を設定できるようにしたい １テナントから大量の申請が出る場合、システムの出荷上限に到達してしまい、 他のテナントが申請できなくなる 2 全てのテナントに出荷上限台数を設定する必要はない 不要な設定コストをかけたくないため 3 出荷上限台数が設定されていないテナントは、無制限として扱う 不要な設定コストをかけたくないため 4 各テナントに対する出荷上限台数はシステムのUIから設定/参照したい CSチームが設定をしたいため 5 テナントの出荷上限台数を設定した結果、システム全体ではまだ余力があって も上限に到達したテナントからは申請できなくなるが問題ない 運用や開発を簡素化したいから
33. © 2024 ESM, Inc. 理由を書く 理由を明らかにする 33 Req-ID 要件 理由 1 １テナントでの1日あたりの出荷上限台数を設定できるようにしたい １テナントから大量の申請が出る場合、システムの出荷上限に到達してしまい、 他のテナントが申請できなくなる 2 全てのテナントに出荷上限台数を設定する必要はない 不要な設定コストをかけたくないため 3 出荷上限台数が設定されていないテナントは、無制限として扱う 不要な設定コストをかけたくないため 4 各テナントに対する出荷上限台数はシステムのUIから設定/参照したい CSチームが設定をしたいため 5 テナントの出荷上限台数を設定した結果、システム全体ではまだ余力があって も上限に到達したテナントからは申請できなくなるが問題ない 運用や開発を簡素化したいから Whyを書く What
34. © 2024 ESM, Inc. 完璧を目指さない ハードルを下げる • 網羅性は求めない • 正確性は求めない • 整合性は求めない 重要なのは対話と共通理解の促進であり、ドキュメントはそのきっかけ そのために作るのをためらう位ならない方が良い 34 （心の声）正直言えば欲しいけど 定義書なのに…
35. © 2024 ESM, Inc. 作成の単位はPBI 要件はスプリント毎に詳細化される 35 プロダクトバックログ スプリントバックログ 要件定義書 要件定義書 • 最初に全部作らず、スプリント毎に小さく作る • 「分割統治」と「関心事の分離」
36. © 2024 ESM, Inc. メンテナンスはしない ドキュメントで一番面倒なのはメンテナンス • 要件定義書は開発時点のスナップショット • 要件定義書の寿命は1スプリント • スプリントが終わればメンテ不要 36 ドキュメントなのに…
37. © 2024 ESM, Inc. 37 私たちの変化
38. © 2024 ESM, Inc. ステークホルダと会話するようになった Before • POは偉い人 • エンドユーザは遠い存在 • 要求は変えられない • 自分は要求を考える人ではない 38 After • POを問い詰める • CSと会話のチャンネルを作る • 要求の問題点を指摘する • 要求の代替案を提示する 元から過度な上下関係や組織の壁があった訳ではないが、自分たちの役割を勝手に線引きし て活動内容を制限していた。要求の「理由」を書こうとして初めて「あれ？何でだっけ？」 と知らなかったことに気づき、周囲のステークホルダと会話するようになった。
39. © 2024 ESM, Inc. ビジネスのことを考えるようになった Before • 言われたものを作る • 誰が使うのか？は気にしない • 何に使うのか？は気にしない • 使いやすいか？は気にしない 39 After • どんな機能？ • 誰がどんな場面で使う？ • どんな価値がある？ ビジネス 開発 PO DEV 　　越境 ビジネス 開発 PO DEV
40. © 2024 ESM, Inc. 品質が早く安定するようになった Before 1. 欲しいものを指示される 2. 期待（要件）を考えながら作る 3. 期待を満たす試験を作る 4. 期待通り動くか試験する 5. 欲しいものと違っている 40 After 1. 欲しいものを指示される 2. 期待（要件）を整理する 3. 期待を満たす試験を作る 4. 期待を満たすように作る 5. 期待通り動くか試験する 実装 試験 仕様 試験 要求 製品 試験仕様 製品 要件 実装 試験 要求
41. © 2024 ESM, Inc. 「理解した」のレベルと範囲 深く理解できるようになった 41 チームの誰かが 理解を書き出せる 他人に説明できる わかった気がする 自分で実装できる チームの全員が 理解を書き出せる 他人に説明できる わかった気がする 自分で実装できる レベル 範囲 要件定義書を書くことで ここに到達できる 今まではここで 開発していた
42. © 2024 ESM, Inc. 42 本当の価値
43. © 2024 ESM, Inc. 本当の価値 アジャイル開発における要件定義書は、柔軟性と適応性を重視し、対話とコラボレーション を通じて進化します。共通理解の促進を中心に据え、インクリメンタルに進化する要件を簡 潔にまとめることが特徴です。詳細な要件定義書は最小限に抑えられ、必要な情報はプロダ クトバックログやユーザーストーリーに含まれます。 43 私たちに必要だったもの 
 対話する場 そこで交わされる会話 対話とコラボレーション
44. © 2024 ESM, Inc. 行動を誘発する 44 私が書いたヨ
45. © 2024 ESM, Inc. 行動を誘発する 45 Req-ID 要件 理由 1 １テナントでの1日あたりの出荷上限台数を設定できるようにしたい １テナントから大量の申請が出る場合、システムの出荷上限に到達してしま い、他のテナントが申請できなくなる 2 全てのテナントに出荷上限台数を設定する必要はない 不要な設定コストをかけたくないため 3 出荷上限台数が設定されていないテナントは、無制限として扱う 不要な設定コストをかけたくないため 4 各テナントに対する出荷上限台数はシステムのUIから設定/参照したい CSチームが設定をしたいため 5 テナントの出荷上限台数を設定した結果、システム全体ではまだ余力があっても 上限に到達したテナントからは申請できなくなるが問題ない 運用や開発を簡素化したいから 利用者の真の要求を理解しチームのメンバー内で共有するために 「会話」を誘発する
46. © 2024 ESM, Inc. 宿題 46
47. © 2024 ESM, Inc. いい事ばかりではなかった 要件定義書を書くのは難しい • 誰にでも書ける訳ではない • 「要求」と「要件」と「仕様」の区別が難しい • 本当に開発スピードが速くなっているか疑問 特にWF開発を経験していないアジャイル ネイティブ世代と呼ばれる人たちにとって 要件定義という行為そのものが難しい。 ロストテクノロジーになる前に次の世代に 継承していくのがWF世代エンジニアの責務。 47 布教と改善を
48. © 2024 ESM, Inc. 48 まとめ
49. © 2024 ESM, Inc. まとめ 今日お話ししたこと • スクラムはフレームワーク、中身は自分たちで考える • 開発で一番大事なことはWhyの共通理解 • Whyを全員で理解するために要件定義書を書いてみた • スクラムの要件定義書はシンプルで良い • 要件定義書は作成する過程自体に価値がある • 要件定義書を書くことでチームに良い変化が起きた • 本当の価値は会話の誘発 • この取り組みはまだ未完成、旅は続きます 49
50. © 2024 ESM, Inc. 50 ありがとうございました
51. © ESM, Inc. アジャイルアンギャ 島根・福井・福岡開催決定！
52. © 2024 ESM, Inc. 永和システムマネジメント 52 福井本社 WeWork 沖縄 • 金融、医療、組込み(自動車) • Web/Cloud、アジャイル開発 • 社員 210名エンジニア集団 We’re hiring!