「不確実性」にどう立ち向かう？アジャイル開発現場のリアル【BASE・DMM】の登壇資料です https://dmm.connpass.com/event/251552/
2022/07/05「不確実性」にどう立ち向かう？アジャイル開発現場のリアル炭田高輝（@tac_tanden）アジャイルで不確実性に向き合うための開発タスクの切り方
View Slide
自己紹介BASE株式会社Product Dev DivisionエンジニアリングマネージャーScrum Master (LSM)2016.09 - 新卒でWebゲーム開発2020.01 - BASE株式会社で『BASE』の開発本日はよろしくお願いします！ 炭田高輝（tanden） Back-End Web Developer2
本日のアジェンダ１２３不確実性とは何か受け渡し型開発の構造的な課題ユーザーストーリーでバッチサイズを小さくする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
ご清聴ありがとうございました
tanden
tanakahisateru
okuzawats
yahiru
niftycorp
tomokusaba
pospome
findyinc
ivanova1991
suzukimar
takefumiyoshii
palkan
phodgson
colly
jcasabona
jmmastey
reverentgeek
pauljervisheath
danielanewman
sstephenson
csswizardry
samlambert
speakerdeck
shlominoach