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

by 岡本卓也

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2024 ESM, Inc. 私たちのチームで起きたこと開発支援を始めて半年が過ぎた頃… チームではスクラムイベントが定着し、定期的に製品をデリバリーできるようになり順調に成長しているように見えるが、同時に不穏な気配も感じられるように。 ● 「あれ、これってどうすることにしたんだっけ？」の会話が増える ● 「最近、バーンダウンチャートが着地しないねえ」が常態化する ● スプリントレビューで差し戻しが発生する 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2024 ESM, Inc. スプリントレビューでNG こんな状態だった ● デモで見せたものがPOの期待と異なる ● ステークホルダの間でも期待が異なることが判明その結果起きること ● スプリントやり直し ● リリーススケジュールの見直し ● リリースする機能のドロップスクラムではよく「フィードバックを回す」などとポジティブに表現されるが「不確実性」ではなく「開発能力」のせいで起きてはダメ。 14

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© 2024 ESM, Inc. ゴールデンサークル 16 Why  What  How  効果的なリーダーシップとマーケティングの枠組みを提供する。 Inside-Out（内側から外側へ）: 効果的なリーダーシップやマーケティングは、外側から内側（What→How→Why）ではなく、内側から外側（Why→How→What）にアプローチすべきだとしています。最も成功しているリーダーや企業は、「Why（なぜ）」から始め、次に「How（どのように）」を説明し、最後に「What（何を）」を伝えています。 Chat GPT-4oさんありがとう

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 2024 ESM, Inc. Q：どこから出てきた？ A：岡本の思いつきガチWF時代は数十人規模のチームで1年以上かけて一つの開発をしていた。暗黙知や以心伝心は通用せず、効率が悪くてもドキュメントが必要だった。共通理解のために作る要件定義書の威力は熟知していた。 ● 今の我々に足りていないのは共通理解 ● ストレートに要件定義書がハマるはず ● 今ならあの時の弊害もクリアできる 20 自然な流れ要件定義書を書こう

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© 2024 ESM, Inc. A：あった ● PBIチケットをリッチにする ● ユーザーストーリーマッピング ● リファインメント Q：他の選択肢はなかったのか？ 22 具体的なタスクや機能の管理に焦点全体像やコンテキストを提供するには不十分リッチなPBI 機能の流れや優先順位を理解することに焦点要件や制約条件を包括的にカバーできないユーザーストーリーマッピング詳細を検討/具体化しPBIを Readyにするためのプロセス情報を一元的に管理/参照するには向かないリファインメント分かりやすさ重視 <<手法>> <> 要件定義書 <<責務>> 共通理解のために要件を定義するそれぞれ、本来の主たる目的を持っているため別の目的を追加するとチームメンバが混乱するでも… でも… でも…

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© 2024 ESM, Inc. スクラムの要件定義書 25 柔軟性と適応性を重視し、対話とコラボレーションを通じて進化します。価値の提供を中心に据え、インクリメンタルに進化する要件を簡潔にまとめることが特徴。ソフトウェア開発プロジェクトやシステム開発プロジェクトにおいて、システムやソフトウェアが満たすべき要件を詳細に記述した文書。プロジェクトの成功に不可欠なドキュメントであり、開発チームやステークホルダー間の共通理解を促進し、開発プロセスを円滑に進めるために重要。スクラムでは

Slide 26

Slide 26 text

© 2024 ESM, Inc. WF開発の要件定義書 SoR（System of Record）としての役割 1. 完全性と正確性： ○ WF開発では、プロジェクトの初期段階で詳細な要件定義書を作成します。この文書は、プロジェクト全体の指針となり、開発の各フェーズ（設計、実装、テスト、展開）における活動を明確にします。 ○ 要件定義書は、すべての機能要件、非機能要件、制約条件を網羅し、詳細に記述する必要があります。 2. 変更管理： ○ 要件定義書は、プロジェクトの公式記録として機能します。要件の変更が発生した場合、変更管理プロセスを通じて正式に文書を更新することが求められます。 ○ 変更が発生すると、すべての関係者に通知され、影響分析が行われます。 3. 契約的役割： ○ 要件定義書は、顧客と開発チームの間の契約的な文書として機能します。これに基づいて進捗を評価し、契約上の義務を確認します。 4. トレーサビリティ： ○ 各要件が設計、実装、テスト、そして最終的な製品にどのように反映されているかを追跡できるようにします。これにより、すべての要件が確実に満たされることを保証します。 26 Chat GPT-4oさんありがとう

Slide 27

Slide 27 text

© 2024 ESM, Inc. スクラムの要件定義書 SoE（System of Engagement）としての役割 1. 柔軟性と適応性： ○ アジャイル開発では、要件は固定的なものではなく、プロジェクトの進行とともに進化することが前提です。ユーザーストーリー形式で要件を表現し、プロダクトバックログに管理します。 ○ 要件はスプリントごとに詳細化され、変更が容易です。 2. 対話とコラボレーション： ○ 要件定義書そのものよりも、ステークホルダーとの対話やチーム内のコミュニケーションが重要視されます。要件はミーティングやワークショップで具体化され、理解が深まります。 ○ プロダクトオーナー、開発チーム、ステークホルダーが継続的に対話し、要件を精査し、優先順位を付けていきます。 3. 価値の提供： ○ アジャイルでは、要件定義書は価値を提供するための手段であり、完成品そのものではありません。重要なのは、要件定義を通じて価値のある成果物を継続的に提供することです。 ○ ユーザーストーリーは、ユーザーや顧客にとっての価値を中心に構成され、優先順位が付けられます。 4. インクリメンタルな進化： ○ 要件はスプリントごとに詳細化され、リリースごとに見直されます。これにより、プロジェクトの進行に合わせて要件が進化し、顧客のニーズや市場の変化に迅速に対応できます。 27

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 2024 ESM, Inc. スクラムの要件定義書の構成要素 1. プロジェクト概要 2. ステークホルダーの要求 3. 機能要件 4. 非機能要件 5. システム要件 6. ユースケース 7. 制約事項 8. トレーサビリティ 29 1. ステークホルダーの要求 2. 機能要件 3. 非機能要件スクラムの要件定義書 1. 柔軟性と適応性： 2. 対話とコラボレーション： 3. 価値の提供： 4. インクリメンタルな進化： SoEの4特性

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 2024 ESM, Inc. 私たちの要件定義書 31 Req-ID 要件理由 1 １テナントでの1日あたりの出荷上限台数を設定できるようにしたい１テナントから大量の申請が出る場合、システムの出荷上限に到達してしまい、他のテナントが申請できなくなる 2 全てのテナントに出荷上限台数を設定する必要はない不要な設定コストをかけたくないため 3 出荷上限台数が設定されていないテナントは、無制限として扱う不要な設定コストをかけたくないため 4 各テナントに対する出荷上限台数はシステムのUIから設定/参照したい CSチームが設定をしたいため 5 テナントの出荷上限台数を設定した結果、システム全体ではまだ余力があっても上限に到達したテナントからは申請できなくなるが問題ない運用や開発を簡素化したいから機能要件・非機能要件ステークホルダの要求要素は3つ

Slide 32

Slide 32 text

© 2024 ESM, Inc. 作成コストは最小限最小コストで作る ● エクセルで作る ● 項目は「ID」「要件」「理由」の3つだけ ● 全員で作る 32 Req-ID 要件理由 1 １テナントでの1日あたりの出荷上限台数を設定できるようにしたい１テナントから大量の申請が出る場合、システムの出荷上限に到達してしまい、他のテナントが申請できなくなる 2 全てのテナントに出荷上限台数を設定する必要はない不要な設定コストをかけたくないため 3 出荷上限台数が設定されていないテナントは、無制限として扱う不要な設定コストをかけたくないため 4 各テナントに対する出荷上限台数はシステムのUIから設定/参照したい CSチームが設定をしたいため 5 テナントの出荷上限台数を設定した結果、システム全体ではまだ余力があっても上限に到達したテナントからは申請できなくなるが問題ない運用や開発を簡素化したいから

Slide 33

Slide 33 text

© 2024 ESM, Inc. 理由を書く理由を明らかにする 33 Req-ID 要件理由 1 １テナントでの1日あたりの出荷上限台数を設定できるようにしたい１テナントから大量の申請が出る場合、システムの出荷上限に到達してしまい、他のテナントが申請できなくなる 2 全てのテナントに出荷上限台数を設定する必要はない不要な設定コストをかけたくないため 3 出荷上限台数が設定されていないテナントは、無制限として扱う不要な設定コストをかけたくないため 4 各テナントに対する出荷上限台数はシステムのUIから設定/参照したい CSチームが設定をしたいため 5 テナントの出荷上限台数を設定した結果、システム全体ではまだ余力があっても上限に到達したテナントからは申請できなくなるが問題ない運用や開発を簡素化したいから Whyを書く What

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 2024 ESM, Inc. ステークホルダと会話するようになった Before ● POは偉い人 ● エンドユーザは遠い存在 ● 要求は変えられない ● 自分は要求を考える人ではない 38 After ● POを問い詰める ● CSと会話のチャンネルを作る ● 要求の問題点を指摘する ● 要求の代替案を提示する元から過度な上下関係や組織の壁があった訳ではないが、自分たちの役割を勝手に線引きして活動内容を制限していた。要求の「理由」を書こうとして初めて「あれ？何でだっけ？」と知らなかったことに気づき、周囲のステークホルダと会話するようになった。

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© 2024 ESM, Inc. 品質が早く安定するようになった Before 1. 欲しいものを指示される 2. 期待（要件）を考えながら作る 3. 期待を満たす試験を作る 4. 期待通り動くか試験する 5. 欲しいものと違っている 40 After 1. 欲しいものを指示される 2. 期待（要件）を整理する 3. 期待を満たす試験を作る 4. 期待を満たすように作る 5. 期待通り動くか試験する実装試験仕様試験要求製品試験仕様製品要件実装試験要求

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© 2024 ESM, Inc. 本当の価値アジャイル開発における要件定義書は、柔軟性と適応性を重視し、対話とコラボレーションを通じて進化します。共通理解の促進を中心に据え、インクリメンタルに進化する要件を簡潔にまとめることが特徴です。詳細な要件定義書は最小限に抑えられ、必要な情報はプロダクトバックログやユーザーストーリーに含まれます。 43 私たちに必要だったもの   対話する場そこで交わされる会話対話とコラボレーション

Slide 44

Slide 44 text

Slide 45

Slide 45 text

© 2024 ESM, Inc. 行動を誘発する 45 Req-ID 要件理由 1 １テナントでの1日あたりの出荷上限台数を設定できるようにしたい１テナントから大量の申請が出る場合、システムの出荷上限に到達してしまい、他のテナントが申請できなくなる 2 全てのテナントに出荷上限台数を設定する必要はない不要な設定コストをかけたくないため 3 出荷上限台数が設定されていないテナントは、無制限として扱う不要な設定コストをかけたくないため 4 各テナントに対する出荷上限台数はシステムのUIから設定/参照したい CSチームが設定をしたいため 5 テナントの出荷上限台数を設定した結果、システム全体ではまだ余力があっても上限に到達したテナントからは申請できなくなるが問題ない運用や開発を簡素化したいから利用者の真の要求を理解しチームのメンバー内で共有するために「会話」を誘発する

Slide 46

Slide 46 text

Slide 47

Slide 47 text

© 2024 ESM, Inc. いい事ばかりではなかった要件定義書を書くのは難しい ● 誰にでも書ける訳ではない ● 「要求」と「要件」と「仕様」の区別が難しい ● 本当に開発スピードが速くなっているか疑問特にWF開発を経験していないアジャイルネイティブ世代と呼ばれる人たちにとって要件定義という行為そのものが難しい。ロストテクノロジーになる前に次の世代に継承していくのがWF世代エンジニアの責務。 47 布教と改善を

Slide 48

Slide 48 text

Slide 49

Slide 49 text

© 2024 ESM, Inc. まとめ今日お話ししたこと ● スクラムはフレームワーク、中身は自分たちで考える ● 開発で一番大事なことはWhyの共通理解 ● Whyを全員で理解するために要件定義書を書いてみた ● スクラムの要件定義書はシンプルで良い ● 要件定義書は作成する過程自体に価値がある ● 要件定義書を書くことでチームに良い変化が起きた ● 本当の価値は会話の誘発 ● この取り組みはまだ未完成、旅は続きます 49