不確実性に向き合うためにチームのアジリティを高める開発タスクの切り方

by tanden

Slide 1

Slide 1 text

2022/10/01 XP祭り 2022 炭田高輝（@tac_tanden）不確実性に向き合うためにチームのアジリティを高める開発タスクの切り方

Slide 2

Slide 2 text

自己紹介① BASE株式会社ネットショップ作成サービス「BASE」のエンジニアリングマネージャー Scrum Master (LSM) 北海道旭川市出身 2016.09 - 新卒でWebゲーム開発 2020.01 - BASE株式会社で「BASE」の開発本日はよろしくお願いします！　　　炭田高輝（tanden） Back-End Web Developer 2

Slide 3

Slide 3 text

自己紹介② ● 新卒1年目に「アジャイルサムライ」に出会う ● 「おお、これだ！」と思い、本を読み漁ったりスクラムマスターの研修に行ってみる ● スクラムをチームに提案して実際にトライしてみるも、なんとなく良くなったがうまく定着させることができなかった ● 途中1社を経て、BASE株式会社で「よりよい開発チーム」「品質の高いものをより早くユーザーに届ける」にはどうすればよいか、模索中です　　　炭田高輝（tanden） Back-End Web Developer 3

Slide 4

Slide 4 text

本日のアジェンダ１２３不確実性とは何か受け渡し型開発の構造的な課題ユーザーストーリーで開発タスクを分割する 4

Slide 5

Slide 5 text

不確実性とは何か

Slide 6

Slide 6 text

不確実性とは何か不確実性の定義 ● 白黒はっきりつけられない曖昧さ（確率）が残っている状態や状況のこと ● 不確実性を減らすとは、確率をどちらかに寄せる作業（白黒つける） Q. この設計で負荷の問題は起きるのか、起きないのか？ A. 調査の結果、起きるとわかる結論を出すことで、曖昧さがなくなり、不確実性が減ったとみなせる 6 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング広木大地　著

Slide 7

Slide 7 text

サービス開発における不確実性目的不確実性（Whatに関する不確実性）作ってみるまでは、何がユーザーに受け入れられるのか分からない方法不確実性（Howに関する不確実性）やってみるまでは、どう作ればいいのかわからない通信不確実性（意思疎通に関する不確実性）正しく伝わるか分からない、正しく伝わったとしても他者はその通りに行動するとは限らない

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

不確実性に振り回される5つのパターン不確実性に振り回される5つのパターンを見ていきます ● 突発パターン ● 手戻りパターン ● 大群パターン ● 氷山の一角パターン ● 忘却パターン 10

Slide 11

Slide 11 text

①突発パターン急遽対応したい開発タスクや不具合が入ってくるケース ● 「緊急の開発タスクがあるんだけど、差込でできないかな？」 ● 「調査してみないと原因がわからない不具合が見つかり、対応するのに時間がかかりそうです」突然、新しい不確実性が吹き出してくるパターン。新たに発生したタスクによって、開発計画に大きな影響が出たり、チームの過負荷つながる場合もある。 11

Slide 12

Slide 12 text

②手戻りパターン開発したものが、必要なものと異なっていたケース ● 「あれ、これはお願いしていたものと違いますね」 ● 「すみません、これは〇〇はできないんですか？」成果物がずれていて、不確実性が高い状態に逆戻りするパターン。せっかく開発した機能が使われず、修正作業が必要になる。また、最悪の場合、いちから作り直しになってしまう。 12

Slide 13

Slide 13 text

③大群パターン大量のやることが目の前に広がっているケース ● 「やることが多すぎて、どこから手を付けていいかわかりません」 ● 「修正が必要な箇所が多すぎませんか？」不確実性がある事象の多さに圧倒されるパターン。大量のやることリストがプレッシャーとなり、チームの混乱やモチベーションの低下につながってしまう。 13

Slide 14

Slide 14 text

④氷山の一角パターン予想していたよりもやることが多かったケース ● 「思っていたより全然やること多いじゃん」 ● 「想定していた工数の2倍になりそうです」不確実性の大きさを正しく観測できないパターン。着手してみないとわからないことも多く、開発計画が大きく狂う原因になりやすい。 14

Slide 15

Slide 15 text

⑤忘却パターン出した結論がチームの知識から失われてしまうケース ● 「前に話した気がするんですけど、結論なんでしたっけ？」 ● 「あ、仕様書を更新するの忘れていました」すでに不確実性を減らしたのに、その知識が失われてしまうパターン。せっかく出した結論が忘れられてしまい、探して思い出す作業が発生する。最悪の場合、同じ検討作業が必要になることもある。 15

Slide 16

Slide 16 text

不確実性に振り回される5つのパターン不確実性に振り回されれる5つのパターン ● 突発パターン ● 手戻りパターン ● 大群パターン ● 氷山の一角パターン ● 忘却パターン 5つのパターンが起きることを前提としてうまくコントロールできるようにすれば、開発がぐんと前に進むはず 16

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

受け渡し型の開発とは成果物を受け渡していく開発のこと ● 要件定義 ● 仕様作成 ● デザイン ● 設計 ● スケジュール見積もり ● バックエンド実装 ● フロントエンド実装 ● 結合テスト（QA） ● 受け入れテスト（QA） ● リリース 19 ウォーターフォールやリレー形式の開発と呼ぶこともあります

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

バッチサイズとは何か ”batch”とは束、1回分、ひとまとまりの数量を意味します。システム開発界隈では、同じような種類のデータに対してまとめて処理することを「バッチ処理」と呼ぶことが多いです。この発表では着手からリリースに至るまでの一連の作業を一つのバッチとして考え、その作業量のことをバッチサイズと呼びます。 21 要件定義からリリースまでの一連の作業＝バッチ

Slide 22

Slide 22 text

バッチサイズが大きいことの問題点受け渡し型開発は構造上バッチサイズが大きくなってしまう ● 突発パターン ● 手戻りパターン ● 大群パターン ● 氷山の一角パターン ● 忘却パターンバッチサイズが大きいと上の5つのパターンが起こりやすく、また対応もしにくいことを見ていきます 22

Slide 23

Slide 23 text

①突発パターン突然新たな不確実性が噴き出してくるパターン ● バッチサイズが大きいと、きりの良いタイミングが少ない ● 無理に入れると、更にバッチサイズが大きくなる 23 極論、リリースタイミングしかきりの良いタイミングがない要件定義仕様作成デザイン見積もりバックエンドフロントエンド結合テスト受け入れテストリリース設計

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

③大群パターン不確実性がある事象の多さに圧倒されるパターン ● バッチサイズが大きい分、一度に多くの不確実性が見つかる ● 多くの不確実性に一気に襲われてしまう場合が出てきてしまう 25 要件定義仕様作成デザイン見積もりバックエンドフロントエンド結合テスト受け入れテストリリース設計多くの不具合と仕様変更が見つかる場合がある

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

各パターンの合わせ技で不確実性が襲ってくる② ● 受け入れテストで突然（突発） ● やっぱりこの機能も必要です（手戻り） ● 全部作り直しですが、どこから手をつけましょう（大群） 29 要件定義仕様作成デザイン見積もりバックエンドフロントエンド結合テスト受け入れテストリリース設計受け入れテストで突発的に手戻りが発生して、一気にやることが増える

Slide 30

Slide 30 text

受け渡し型の開発は不確実性に振り回されやすい受け渡し型の開発では、どうしてもバッチサイズが大きくなってしまうその結果、不確実性に振り回されてしまう場面が多くなる 30 要件定義からリリースまでの中で多くの作業を一度に行う要件定義仕様作成デザイン見積もりバックエンドフロントエンド結合テスト受け入れテストリリース設計

Slide 31

Slide 31 text

受け渡し型の開発は不確実性に振り回されやすい受け渡し型の開発だと不確実性に振り回されやすいではどうすればよいか 31

Slide 32

Slide 32 text

ユーザーストーリーで開発タスクを分割する

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

ユーザーストーリーで分割するユーザーストーリーを使って、最低でも受け入れテストを必ず含むように小さく分割していくのがオススメですこの発表における「受け入れテスト」は、開発した機能が実際にビジネスメリットをもたらすかをユーザー視点でテストすることを指します。仕様通りに動作することはもちろんですが、ユーザーが機能を使った結果として望む通りの行動や成果がもたらされるかを主眼に検証を行うことを「受け入れテスト」と表現しています。 35

Slide 36

Slide 36 text

受け入れテストであれば頻度を上げられる理想は細かく分割した開発タスクを都度リリースすることですが以下の理由から難しい場合も多いと思います ● リリース作業のコストが高い ● そもそもユーザーにリリースするまでの十分な機能が足りていないしかし、受け入れテストまでであれば頻繁に行うことを許容できるチームも多いのではないでしょうか 36

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

比較：受け渡し型開発の場合例えばバックエンドの開発工程の中で、以下のように分けることが一般的だと思います ● ToDoタスク登録用APIの開発 ● ToDoタスクのステータス更新用APIの開発 ● ToDoタスクの削除用APIの開発 40 要件定義仕様作成バックエンド受け入れテストリリース …. …..

Slide 41

Slide 41 text

比較：受け渡し型開発の場合工程に分けてしまう場合、ユーザー相当の検査（＝受け入れテスト）が行われるまでのバッチサイズを小さくすることはできません 41 要件定義仕様作成バックエンド受け入れテストリリース …. ….. ● 登録用APIの開発 ● ステータス更新用APIの開発 ● 削除用APIの開発

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

ユーザーストーリーによる分割③ ● ユーザーとして ● タスクのタイトルを設定したい ● タスクを見つけやすくして、実施漏れを防ぐためだ ● ユーザーとして ● タスクの詳細を記入したい ● タスクの背景や実施する理由を忘れないようにするためだ ● ユーザーとして ● タスクの優先度を設定したい ● 重要度によってタスクを分類したいからだ 45

Slide 46

Slide 46 text

Slide 47

Slide 47 text

ユーザーストーリーによる分割④ ● ユーザーとして ● タスクのタイトルを保存したい ● タスクを見つけやすくして、実施漏れを防ぐためだ ● ユーザーとして ● タスクのタイトルを更新したい ● タスクの内容が変わったことを反映するためだ ● ユーザーとして ● タスクのタイトルの設定に失敗したことを知りたい ● タイトルの保存をやり直す必要があるかどうかを知れるからだ 47

Slide 48

Slide 48 text

ユーザーストーリーで小さく分割する 48 ToDo管理をしたい登録をしたい完了にしたい削除したいタイトルを設定をしたい詳細を記入したい優先度を設定したいタイトルを保存をしたいタイトルを更新をしたい設定に失敗したことを知りたいユーザーストーリーを使って開発タスクを小さくしていくことでユーザー相当の検査が行われるまでのバッチサイズを小さくできます

Slide 49

Slide 49 text

バッチサイズを小さくするメリット① きりの良いタイミングを多く作れるので、突発パターンに対応しやすい ● 「ストーリー2が今日中に完了するので、明日から着手します」 ● 「ストーリー5までをまずは優先したいので、それが完了してから着手するでもよいでしょうか？」 49 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7 ストーリー4と5の間で着手する

Slide 50

Slide 50 text

バッチサイズを小さくするメリット② 手戻りが起きた場合でも捨てられる作業量は少しで済む ● 「期待とずれていることが早めにわかってよかった」 ● 「その範囲ならコストも少ないですし、試しに作って検証してみましょう」 50 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7

Slide 51

Slide 51 text

バッチサイズを小さくするメリット③ 少しずつ処理するので、不確実性の大群に一度に襲われない ● 「やるべき範囲が明確で、進めやすいです」 ● 「一度に出てくる不具合のチケットが少ないですね」 51 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7

Slide 52

Slide 52 text

バッチサイズを小さくするメリット④ 作業単位が小さいことで、不確実性の大きさを捉えやすい ● 「範囲が狭いと、見積もりがしやすいですね」 ● 「見積もりのぶれが少なくなった気がします」 52 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7

Slide 53

Slide 53 text

バッチサイズを小さくするメリット⑤ 期間が短いことで忘却の発生を抑えることができる ● 「昨日決まったところの実装が終わりました」 ● 「今話して決まったところは、今から実装してしまいますね」 53 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7 検討から実行までの時間が短い

Slide 54

Slide 54 text

バッチサイズ小さいと5つのパターンに対応しやすいバッチサイズを小さくすることで ● 切れ目が沢山でき、方向転換が簡単になる（突発パターン） ● 無駄が少なくなる（手戻りパターン） ● やることの多さに圧倒されない（大群パターン） ● 不確実性を捉えやすい（氷山の一角パターン） ● 忘れないうちにやりきれる（忘却パターン）バッチサイズを小さくするためには ● 着手ギリギリまで工程に分けない ● 受け入れテストを含むように開発タスクを分割する ● ユーザストーリーでの分割が便利 54

Slide 55

Slide 55 text

ユーザーストーリーで開発タスクを分割するさらなるメリット

Slide 56

Slide 56 text

ユーザーストーリーで全員が協力できる① 最初から技術レイヤー（例：APIの実装）でタスクを切り出してしまうと、例えばAPIの実装工程の話の場合、バックエンドエンジニア以外は一歩引いてしまう場合も多いと思います。 ● 「 APIの実装はお任せするので、自分はフロントエンドの作業進めますね」 ● 「要件と仕様は伝えたので、APIの実装をよろしくお願いします」早い段階で工程に分けすぎるとサイロ化してしまう。 56

Slide 57

Slide 57 text

ユーザーストーリーで全員が協力できる② ユーザーストーリーのよいところは、ユーザー視点という共通認識を通して対話できるところです。ユーザーストーリーの場合、開発チームだけでなく、ステークホルダーを含めた全員が議論に参加しやすく、色々な人の知識や経験を動員することができます。共通認識を獲得でき、抜け漏れや求めていることが違ったといった、氷山の一角パターンや手戻りパターンを回避することにも繋がります。 57

Slide 58

Slide 58 text

スコープを柔軟に変えられる① ● 細かくユーザストーリーに分けて開発していくことで、開発を進めながら「どの機能まで作るのか」のスコープを柔軟に変更できます 58 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7 最初はストーリー7まで作る予定 →途中でストーリー4までで十分だと分かった

Slide 59

Slide 59 text

スコープを柔軟に変えられる② 59 ToDo管理をしたい登録をしたい完了にしたい削除したいタイトルを設定をしたい詳細を記入したい優先度を設定したいタイトルを保存をしたいタイトルを更新をしたい設定に失敗したことを知りたい「タイトルの設定」と「詳細の記入」を作って使ってみて「優先度を設定できる機能は後回しにしても十分機能として使える」のような判断がしやすくなる。

Slide 60

Slide 60 text

開発チームのモチベーションを保ちやすい① 受け渡し型開発の場合、実際に画面上で触れるようになるまでが長く「今何を作っているのだろう」という感覚に襲われることがある。 60 画面上で操作できるようになるのは、結合テストの工程要件定義仕様作成デザイン見積もりバックエンドフロントエンド結合テスト受け入れテストリリース設計「実際に使えるようになるまであと3ヶ月くらいか、長いな...」

Slide 61

Slide 61 text

開発チームのモチベーションを保ちやすい② ユーザーストーリー毎に動くものができるので、その都度実際に触ることができ、進捗を実感しやすい。「おおー、ToDoタスクのタイトル設定できる！」「ToDoタスクの詳細まで保存できるようになりましたね」 61 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7

Slide 62

Slide 62 text

「現在地」がわかりやすい① 受け渡し型開発の場合、目標に対しての「現在地」がわかりにくい。「バックエンド工程のフェーズとしては今どのへんですか？」 62 画面上で操作できるようになるのは、結合テストの工程要件定義仕様作成デザイン見積もりバックエンドフロントエンド結合テスト受け入れテストリリース設計「ToDoタスクを保存するAPIの実装」は全体からみてどの段階に位置する？

Slide 63

Slide 63 text

「現在地」がわかりやすい② ユーザーストーリーの場合、目標に対する「現在地」がわかりやすい。「今の所、残り3つのユーザーストーリーを作りきれば、リリースできる機能が揃いますね」 63 ストーリー1 ストーリー2 ストーリー3 ストーリー4 ストーリー5 ストーリー6 ストーリー7

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

ユーザーストーリーでの分割に関するFAQ

Slide 66

Slide 66 text

FAQ① バッチサイズの目安バッチサイズが大きいから小さくしないといけないと判断する基準はありますか？ ● 基本的には1スプリントの中に収まるかどうかを基準に判断するのがよいと考えていますが、チームや開発内容によっても変わってくると思います。 ● 例えば、自分のチームに関しては2-3日で終わるかどうかを目安に分解していくのがちょうどよいという感覚を振り返りを重ねる中で得られたので、今はそれを基準に分解していくことが多いです。 66

Slide 67

Slide 67 text

FAQ② 技術的な改善タスクとユーザーストーリーユーザーが直接使うような機能の開発ではない、技術的な改善のプロジェクトでもユーザーストーリーは使えますか？ ● ユーザーストーリーの目的は「誰が」「何をすることで」「どんな得があるのか」を明らかにすることだと考えています。 ● 例：エンジニアが、アプリケーションのPHPのバージョンを8.0に上げたい、8.0にすると使いたいライブラリが使えるようになるからだ ● 技術的な改善をすることで、誰が、どんな得をするのかを加えると「PHPのバージョンを8.0に上げる」とだけ書かれた開発タスクよりも意図や目的がわかりやすくなるのでおすすめです。 67

Slide 68

Slide 68 text

FAQ③ 細かく分解しすぎると全体が見えないユーザーストーリーに細かく分解しすぎると、機能全体を俯瞰しにくいのですがどうすればよいですか？ ● 機能全体を俯瞰するために、ユーザーストーリーマッピングをするのがおすすめです ● 分解したユーザーストーリーをユーザーがとる体験の時系列に沿ってマッピングしていく手法です ● 細かくしていくと全体を俯瞰しにくくなりますが、ユーザーストーリーマップが全体の視点を提供してくれるよき相棒になってくれると思います 68

Slide 69

Slide 69 text

FAQ④ ユーザーストーリーを開発するときの疑問 1つのユーザーストーリーを複数人で実装すると、コードのコンフリクトやコミュニケーションが増加して非効率になる場合もあると思いますが、なにか対策はありますか？ ● XPのプラクティスを参考にしてやってみることが多いです。 ● ペアプロ・モブプロやCI、自動テストなど。 ● XPのプラクティス以外にも、同期レビュー、トランクベース開発の考え方などが参考になると思います。 69

Slide 70

Slide 70 text

FAQ⑤ 分解するときにツールは何を使っているのか最近はリモートで仕事をする場合も多いと思いますが、ユーザーストーリーに分解するのに、何かツールを使っていますか？ ● ツールはなんでもよいと思います ● BASEの社内では、スプレッドシートやToDo管理ツールを使っているチームもいます ● 自分がスクラムマスターとして関わっているチームはFigjamを使っています 70

Slide 71

Slide 71 text

まとめ

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

https://herp.careers/v1/base We are hiring! ご清聴ありがとうございました！