Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

岡本卓也

June 22, 2024
Tweet

More Decks by 岡本卓也

Other Decks in Technology

Transcript

  1. © 2024 ESM, Inc. アジェンダ 1. 自己紹介 2. 私たちの課題 3.

    なぜ要件定義書なのか 4. スクラムの要件定義書 5. 作成した要件定義書 6. 私たちの変化 7. 本当の価値 8. 宿題 9. まとめ 2
  2. © 2024 ESM, Inc. 自己紹介 • 岡本 卓也 • EM@AgileStudio

    • スクラムコーチ兼開発者 ◦ ガチWF :15 年 ◦ 過渡期 :5年 ◦ Agile :5年 • アジャイル開発導入支援 WFからの移行支援 • X:@haraguro3 • note:https://note.com/haraguro3 • mail:[email protected] 4
  3. © 2024 ESM, Inc. 永和システムマネジメント 5 福井本社 WeWork 沖縄 •

    金融、医療、組込み(自動車) • Web/Cloud、アジャイル開発 • 社員 210名エンジニア集団
  4. © 2024 ESM, Inc. チームの紹介 7 PO DEVチーム SM
 SM補佐


    • チーム構成: 9名 ◦ 弊社2名、お客さん7名 • お客さんの開発経験 ◦ 手探り:5年くらい ◦ スクラム経験:ゼロ • 開発支援開始: 2023/06~ ◦ 内製化に挑戦 ◦ スクラムに挑戦 • 現在のステータス: ◦ スクラムイベントが定着 ◦ 定期的なデリバリーが可能
  5. © 2024 ESM, Inc. 開発のスピードが出ない こんな状態だった • 正しい動作を考えながらコードを書いている • 書いた本人(考えた人)にしか正解がわからない実装になる

    その結果起きること • コードレビューしても意図がわからない • コードレビューしながら正解を考える • ここから議論して書き直し 12 これではスピードは出ない
  6. © 2024 ESM, Inc. 開発の品質が悪い こんな状態だった • 正しい動作を考えながら試験仕様を書いている • 書いた本人(考えた人)にしか正解がわからない試験になる

    その結果起きること • 手順書をこなすだけの機械的な試験 • (不具合が発生したら) • 正しい動作を考えながら機能を直す • 正しい動作を考えながら試験仕様を直す 13 これでは品質は出ない
  7. © 2024 ESM, Inc. スプリントレビューでNG こんな状態だった • デモで見せたものがPOの期待と異なる • ステークホルダの間でも期待が異なることが判明

    その結果起きること • スプリントやり直し • リリーススケジュールの見直し • リリースする機能のドロップ スクラムではよく「フィードバックを回す」などとポジティブに表現されるが 「不確実性」ではなく「開発能力」のせいで起きてはダメ。 14
  8. © 2024 ESM, Inc. ゴールデンサークル 16 Why
 What
 How
 効果的なリーダーシップとマーケティングの枠組みを提供する。

    Inside-Out(内側から外側へ): 効果的なリーダーシップやマー ケティングは、外側から内側(What→How→Why)ではなく、内 側から外側(Why→How→What)にアプローチすべきだとしてい ます。 最も成功しているリーダーや企業は、「Why(なぜ)」から始 め、次に「How(どのように)」を説明し、最後に「What(何 を)」を伝えています。 Chat GPT-4oさんありがとう
  9. © 2024 ESM, Inc. How: どうやって作る? What: なにを作る? チームに足りなかったもの 17

    Why
 What
 How
 開発者はここに行きがち 本当に大事なのはこちら Why: なぜ欲しい? 「何を作ればいいのか」 「なぜそれが欲しいのか」 「どうやって作ればいいのか」
  10. © 2024 ESM, Inc. そうだ要件定義書を作ろう 18 私たちに必要だったもの 
 バラバラだった理解 


    How: どうやって作る? What: なにを作る? Why: なぜ欲しい? 作るもの(What)と 理由(Why)を定義 したもの・・それって 要件定義書なのでは?
  11. © 2024 ESM, Inc. A:あった • PBIチケットをリッチにする • ユーザーストーリーマッピング •

    リファインメント Q:他の選択肢はなかったのか? 22 具体的なタスクや機能の管理 に焦点 全体像やコンテキストを 提供するには不十分 リッチなPBI 機能の流れや優先順位を理解 することに焦点 要件や制約条件を包括的 にカバーできない ユーザーストーリーマッピング 詳細を検討/具体化しPBIを Readyにするためのプロセス 情報を一元的に管理/参照 するには向かない リファインメント 分かりやすさ重視 <<手法>> <<document>> 要件定義書 <<責務>> 共通理解のために 要件を定義する それぞれ、本来の主たる目的を持っているため 別の目的を追加するとチームメンバが混乱する でも… でも… でも…
  12. © 2024 ESM, Inc. スクラムの要件定義書 25 柔軟性と適応性を重視し、対話とコラボレーションを通じて進化します。価 値の提供を中心に据え、インクリメンタルに進化する要件を簡潔にまとめる ことが特徴。 ソフトウェア開発プロジェクトやシステム開発プロジェクトにおいて、シス

    テムやソフトウェアが満たすべき要件を詳細に記述した文書。 プロジェクトの成功に不可欠なドキュメントであり、開発チームやステーク ホルダー間の共通理解を促進し、開発プロセスを円滑に進めるために重要。 スクラムでは
  13. © 2024 ESM, Inc. WF開発の要件定義書 SoR(System of Record)としての役割 1. 完全性と正確性:

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

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

    機能要件 4. 非機能要件 5. システム要件 6. ユースケース 7. 制約事項 8. トレーサビリティ 28 SoRの4特性 1. 完全性と正確性: 2. 変更管理: 3. 契約的役割: 4. トレーサビリティ: WF開発の要件定義書
  16. © 2024 ESM, Inc. スクラムの要件定義書の構成要素 1. プロジェクト概要 2. ステークホルダーの要求 3.

    機能要件 4. 非機能要件 5. システム要件 6. ユースケース 7. 制約事項 8. トレーサビリティ 29 1. ステークホルダーの要求 2. 機能要件 3. 非機能要件 スクラムの要件定義書 1. 柔軟性と適応性: 2. 対話とコラボレーション: 3. 価値の提供: 4. インクリメンタルな進化: SoEの4特性
  17. © 2024 ESM, Inc. 私たちの要件定義書 31 Req-ID 要件 理由 1

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

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

    1 1テナントでの1日あたりの出荷上限台数を設定できるようにしたい 1テナントから大量の申請が出る場合、システムの出荷上限に到達してしまい、 他のテナントが申請できなくなる 2 全てのテナントに出荷上限台数を設定する必要はない 不要な設定コストをかけたくないため 3 出荷上限台数が設定されていないテナントは、無制限として扱う 不要な設定コストをかけたくないため 4 各テナントに対する出荷上限台数はシステムのUIから設定/参照したい CSチームが設定をしたいため 5 テナントの出荷上限台数を設定した結果、システム全体ではまだ余力があって も上限に到達したテナントからは申請できなくなるが問題ない 運用や開発を簡素化したいから Whyを書く What
  20. © 2024 ESM, Inc. 完璧を目指さない ハードルを下げる • 網羅性は求めない • 正確性は求めない

    • 整合性は求めない 重要なのは対話と共通理解の促進であり、ドキュメントはそのきっかけ そのために作るのをためらう位ならない方が良い 34 (心の声)正直言えば欲しいけど 定義書なのに…
  21. © 2024 ESM, Inc. 作成の単位はPBI 要件はスプリント毎に詳細化される 35 プロダクトバックログ スプリントバックログ 要件定義書

    要件定義書 • 最初に全部作らず、スプリント毎に小さく作る • 「分割統治」と「関心事の分離」
  22. © 2024 ESM, Inc. ステークホルダと会話するようになった Before • POは偉い人 • エンドユーザは遠い存在

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

    • 何に使うのか?は気にしない • 使いやすいか?は気にしない 39 After • どんな機能? • 誰がどんな場面で使う? • どんな価値がある? ビジネス 開発 PO DEV   越境 ビジネス 開発 PO DEV
  24. © 2024 ESM, Inc. 品質が早く安定するようになった Before 1. 欲しいものを指示される 2. 期待(要件)を考えながら作る

    3. 期待を満たす試験を作る 4. 期待通り動くか試験する 5. 欲しいものと違っている 40 After 1. 欲しいものを指示される 2. 期待(要件)を整理する 3. 期待を満たす試験を作る 4. 期待を満たすように作る 5. 期待通り動くか試験する 実装 試験 仕様 試験 要求 製品 試験仕様 製品 要件 実装 試験 要求
  25. © 2024 ESM, Inc. 「理解した」のレベルと範囲 深く理解できるようになった 41 チームの誰かが 理解を書き出せる 他人に説明できる

    わかった気がする 自分で実装できる チームの全員が 理解を書き出せる 他人に説明できる わかった気がする 自分で実装できる レベル 範囲 要件定義書を書くことで ここに到達できる 今まではここで 開発していた
  26. © 2024 ESM, Inc. 行動を誘発する 45 Req-ID 要件 理由 1

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

    • 本当に開発スピードが速くなっているか疑問 特にWF開発を経験していないアジャイル ネイティブ世代と呼ばれる人たちにとって 要件定義という行為そのものが難しい。 ロストテクノロジーになる前に次の世代に 継承していくのがWF世代エンジニアの責務。 47 布教と改善を
  28. © 2024 ESM, Inc. まとめ 今日お話ししたこと • スクラムはフレームワーク、中身は自分たちで考える • 開発で一番大事なことはWhyの共通理解

    • Whyを全員で理解するために要件定義書を書いてみた • スクラムの要件定義書はシンプルで良い • 要件定義書は作成する過程自体に価値がある • 要件定義書を書くことでチームに良い変化が起きた • 本当の価値は会話の誘発 • この取り組みはまだ未完成、旅は続きます 49
  29. © 2024 ESM, Inc. 永和システムマネジメント 52 福井本社 WeWork 沖縄 •

    金融、医療、組込み(自動車) • Web/Cloud、アジャイル開発 • 社員 210名エンジニア集団 We’re hiring!