2022/07/05 「不確実性」にどう立ち向かう？アジャイル開発現場のリアル 炭田高輝（@tac_tanden） アジャイルで不確実性に向き合う ための開発タスクの切り方 

自己紹介 BASE株式会社 Product Dev Division エンジニアリングマネージャー Scrum Master (LSM) 2016.09 - 新卒でWebゲーム開発 2020.01 - BASE株式会社で『BASE』の開発 本日はよろしくお願いします！ 　　　 炭田高輝（tanden） Back-End Web Developer 2 

本日のアジェンダ １ ２ ３ 不確実性とは何か 受け渡し型開発の構造的な課題 ユーザーストーリーで バッチサイズを小さくする 3 

不確実性とは何か 

不確実性とは何か 不確実性の定義 - 白黒はっきりつけられない、曖昧さ（確率）が残っている状態や状況のこと - 不確実性を減らす＝確率をどちらかに寄せる作業（白黒つける） 問い：この実装で負荷の問題は起きるのか、起きないのか？（A. 起きる） 結論を出すことで、曖昧さがなくなり、不確実性が減ったとみなせる サービス開発における不確実性 - 目的不確実性 - 何を作ればよいのか（What） - 方法不確実性 - どう作ればよいのか（How） 5 

不確実性＝チャンスでもある 良い問いを立て（不確実性を切り出し） それを解くことできれば（不確実性を減らす）組織や個人に利益をもたらす - サービスが売れるのか売れないのか（目的不確実性） - 白黒つけることができれば大きなビジネスチャンス - アーキテクチャをAにするのか、Bにするのか（方法不確実性） - アーキテクチャを決定できれば、プロダクトにとって大きな前進 6 

不確実性に振り回されないことが大事 不確実性の全てが悪いわけではない 不確実性はむしろチャンスになり得る 不確実性に振り回されずに、不確実性をコントロールしながら白黒つけていくことが できればチャンスを活かせる可能性が高まる 7 

不確実性に振り回される5つのパターン① 突発パターン 突然、新たな不確実性が噴き出してくる 例：差込でこの対応お願いしたいんだけど、きりの良いタイミング無いかな？ 手戻りパターン 出した結論が間違っていて、不確実性が高い状態に逆戻りする 例：あれ、これってお願いしていたものと違いますね 大群パターン 不確実性がある事象の多さに圧倒される 例：やることが多すぎて、どこから手を付けていいかわかりません 

不確実性に振り回される5つのパターン② 氷山の一角パターン 不確実性の大きさを正しく観測できない 例：思ってたより全然やること多いじゃん 忘却パターン 前に不確実性を減らしたのに、その知識が失われた 例：これって前に話した気がするんですけど、結論なんでしたっけ？ 

不確実性に振り回されないために この発表では 不確実性をコントロールするための 開発タスクの切り方を紹介します 10 

受け渡し型開発の構造的な課題 

受け渡し型の開発とは 工程間で成果物を受け渡していく開発のこと - 要件定義 - 仕様作成 - デザイン - スケジュール見積もり - バックエンド実装 - フロントエンド実装 - 結合テスト（QA） - 受け入れテスト（QA） - リリース ウォーターフォールやシーケンシャルな開発、リレー形式の開発と呼んだりする 12 

受け渡し型開発の構造的な課題 受け渡し型の開発で、構造上どうしても避けられない課題があります 着手からリリースに至るまでの作業量が多い＝バッチサイズが大きい バッチサイズが大きいと、どう不確実性に振り回されるのか具体的に見ていきます 13 要件定義からリリースまでの中で多くの作業を一度に行う 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 

突発パターン 突然新たな不確実性が噴き出してくるパターン 「差し込みでこの対応お願いしたいんだけど、きりの良いタイミング無いかな？」 - バッチサイズが大きいと、きりの良いタイミングが少ないか、そもそもない - 無理に入れると、更にバッチサイズが大きくなる 14 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 極論、リリースタイミングしか きりの良いタイミングがない 

手戻りパターン 出した結論が間違っていて、不確実性が高い状態に逆戻りする 「あれ、これってお願いした機能と違うのですが...」 - 判明した時点から前の工程の作業が無駄になってしまう - バッチサイズが大きい分、無駄になる作業も多くなる 15 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース テストで気付くことが多い 

大群パターン 不確実性がある事象の多さに圧倒されるパターン 「QAで不具合と仕様変更のコメントが多すぎて、どこから手を付けていいか わかりません」 - バッチサイズが大きい分、一度に多くの不確実性が見つかる - 局所的に、多くの不確実性に一気に襲われてしまう場合が出てきてしまう 16 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 多くの不具合と仕様変更 が見つかる場合がある 

氷山の一角パターン 不確実性の大きさを正しく観測できないパターン 「見積もりの内容より、全然やることが多いじゃん」 - バッチサイズが大きい分、含まれる不確実性の大きさを見極めることが難しい - その結果、実体より小さく見積もってしまう 17 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 見積もる作業範囲が広くなってしまう 

忘却パターン 前に不確実性を減らしたのにその知識が失われたパターン 「これって前に話した気がするんですけど、結論なんでしたっけ？」 - バッチサイズが大きいと、決定した情報を活用するまでの期間が長くなってしまう - その結果、過去の決定を忘れてしまい、最悪の場合再び決定作業をする必要がある 18 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 仕様作成を行ったのは3ヶ月前 昔のことは忘れてしまう ? 

実際は各パターンの合わせ技で不確実性が襲ってくる 受け入れテストで、突然（突発） 「この機能ではなく、別の機能が必要です」と言われ（手戻り） 実はそれが仕様書の更新漏れが原因（忘却）ということが判明する バッチサイズの大きさ故に、5つのパターンが発生しやすく、対応もしにくい 19 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 受け入れテストで突発的に 手戻りが発生する ? 

ユーザーストーリーで バッチサイズを小さくする 

受け渡し型開発の構造的な課題 受け渡し型開発の構造上の課題＝バッチサイズの大きさ 開発タスクの切り方を工夫することでバッチサイズを小さくすることにトライします 21 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース 

開発タスクを工程に分けない 工程に分けるするのではなく、全ての工程を含むように開発タスクを小さくしていきます 全ての工程を含むように、横に切らずに縦に切るイメージ 22 要件定義 仕様作成 デザイン 見積もり バックエンド フロントエンド 結合テスト 受け入れテスト リリース データストアの設計 APIのインターフェースの設計 APIの実装 … バッチサイズが大きくなる ので避ける 

オススメの開発タスクの分け方 ユーザーストーリーを使って、最低でも受け入れテストを必ず含むように小さく 分割していくのがオススメです ※受け入れテスト＝開発した機能が実際にビジネスメリットをもたらすか検査する 理想は細かく分割した開発タスクを都度リリースすることですが、以下の理由から 難しい場合も多いと思います - リリース作業のコストが高い - そもそもユーザーにリリースするまでの十分な機能が足りていない ですが、受け入れテストまでであれば頻繁に行うことを許容できるチームも多いのでは ないでしょうか 23 

ユーザーストーリー ユーザーストーリーを以下のようなフォーマットで表すことが多いです - ユーザーとして - 「アクション」をしたい - それは「ビジネスメリット」のためだ ユーザーの部分をより詳細に「ペルソナ」とすることもあります 24 

ユーザーストーリーで分けることで生まれる作用 受け入れテストでユーザーストーリーのビジネスメリットが達成できるかを確認すること が、開発タスクの完了条件として自然になります 例 - ユーザーとして - 自分の登録しているクレジットカードの有効期限を確認したい - 今も利用できるクレジットカードか確かめたいからだ 受け入れテストでは、今も利用できるかユーザーが判別できるかどうかを見れば良さそう ユーザーストーリーに分割することで、受け入れテストまでの全工程を含む形に 開発タスクを分割できるようになります 25 

実際にユーザーストーリーで小さく分けてみる 具体的に開発タスクを細かくユーザストーリーに分ける例を見ていきます ここでは例として、ToDo管理アプリケーションを開発するケースを考えてみます 26 

比較：受け渡し型開発の場合 要件定義 仕様作成 ... バックエンドの開発 … リリース 例えばバックエンド開発の中でさらに以下のように分けることが一般的だと思います - 登録用APIの開発 - ステータス更新用APIの開発 - 削除用APIの開発 しかし、構造上ユーザー相当の検査が行われるまでのバッチサイズを小さくすることは できません 27 

ユーザーストーリーでの分割① まず、ToDo管理アプリケーションを大きなユーザーストーリーに仕立ててみます - ユーザとして - ToDo管理をしたい - それは、やる必要があるタスクを忘れずに実行し、完了させたいからだ 最初のユーザーストーリーができました 28 

ユーザーストーリーでの分割② さらに分割を進めていきます - ユーザとして - ToDoタスクを登録したい - タスクを忘れたくないからだ - ユーザとして - ToDoタスクを完了状態にしたい - 終わっていないタスクを判別したいからだ - ユーザとして - ToDoタスクを削除したい - する必要がないタスクを実行してしまう無駄をなくしたいからだ 29 

ユーザーストーリーでの分割② さらに分割を進めていきます - ユーザとして - ToDoタスクを登録したい - タスクを忘れたくないからだ - ユーザとして - ToDoタスクを完了状態にしたい - 終わっていないタスクを判別したいからだ - ユーザとして - ToDoタスクを削除したい - する必要がないタスクを実行してしまう無駄をなくしたいからだ 30 

ユーザーストーリーでの分割③ - ユーザとして - ToDoタスクのタイトルを登録したい - ToDoタスクを見つけやすくして、実施漏れを防ぐためだ - ユーザとして - ToDoタスクの詳細を登録したい - ToDoタスクの背景や実施する理由を忘れないようにするためだ 他にも、サブタスク、実施日、優先度や画像の登録など、ToDoタスクの登録と一言で 言っても、色々なケースが思い浮かびます ユーザストーリーを保ったまま、着手可能な大きさになるまで開発タスクを小さくしてい くことで、ユーザー相当の検査が行われるまでのバッチサイズを小さくできます 31 

バッチサイズを小さくするメリット① - きりの良いタイミングを沢山作ることがでる（突発に対応しやすい） - 手戻りが起きた場合でも捨てられる作業量は少しで済む - 少しずつ処理するので、不確実性の大群が一度に襲ってくることはまれ 32 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7 

バッチサイズを小さくするメリット② - 作業単位が小さいことで、不確実性のサイズを捉えやすい（氷山を小さくする） - 期間が短いことで忘却の発生も抑えることができる 33 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7 

無駄を小さく＆方向転換を簡単にする バッチサイズを小さくすることで - 切れ目が沢山でき、方向転換が簡単になる - 無駄が少なくなる リーンでアジャイルなチームに近づくことができると考えています バッチサイズを小さくするためには - 着手ギリギリまで工程に分けない - 受け入れテストを含むように開発タスクを分割する - ユーザストーリーでの分割が便利 34 

分割にも慣れが必要 困った場合はお近くのスクラムマスターにぜひご相談を！ もしくは、以下の書籍やブログが参考になります - ryuzeeさんのブログ「プロダクトバックログアイテムの分割方法」 - 『アジャイルな見積りと計画づくり』 12章「ユーザーストーリーの分割」 - 『アジャイルエンタープライズ』 　　18章「ユーザーストーリーで協力する」 - 『エッセンシャルスクラム』 　　　　5章「要件とユーザーストーリー」 6章「プロダクトバックログ」 - 『More Effective Agile』　　　　　9.4「基本原則：バーティカルスライスでのデリバリー」 - 『スクラム実践入門』　　　　　　　 3.3「スプリントプランニング」 　　　5.4「ユーザーストーリー」 - 『スクラム現場ガイド』　　　　　　 12章「ストーリーやタスクを分割する」 - 『大規模スクラム（LeSS）』　　　　11章「プロダクトバックログリファインメント」 35 

まとめ 

まとめ - 工程に分けて成果物を受け渡していく開発はバッチサイズが大きくな り、不確実性をコントロールするのが構造的に得意ではありません - 開発タスクを全工程を含むように小さく分割することで、無駄が減り、 荒ぶる不確実性をコントロールしやすくなるのでオススメです 37 

ご清聴 ありがとうございました