タスクは分割するのではなく、ステップを積み重ねていく

スクフェス金沢2024での登壇資料です。

https://confengine.com/conferences/scrum-fest-kanazawa-2024/proposal/20007

このセッションでは、タスクを「分割」するのではなく、タスク達成のために必要となるステップを列挙することを提案します。

Agile において計画の重要性はよく知られていると思います。だからこそ、 Scrum においては Sprint Planning が Scrum のイベントの一つとして定義されているのでしょう。

その計画を行うにあたって、「大きい」タスクがまず持ち込まれると思います。たとえば、「フリマアプリにおいて、在庫を持つ商品を出品できるようにする」などです。当然、それをそのまま「よし、やるぞ」というわけにはいきません。具体的なアクションにまで落とし込まないと実行に移すことはできないわけです。

そこで、その「大きい」タスクは分割されます。これにより、分割されたそれぞれの「小さな」タスクごとに何をしたら完了で、どのようなアクションが期待されているかが明確になり、チームが自信を持ってそれぞれの「小さな」タスクに取り組むことができるようになります。

このとき、もとの「大きな」タスクをどのように分割しますか？そのタスクを達成するために「やらないといけないこと」を列挙していくのではないかと思います。実は分割する、と言ったときに文字通り分割することはないはずです。つまり、分割という響きから、すでにそのタスクの内容に「答え」が含まれていて文字通り「分割」するだけに感じますが、よくよく考えてみると「分割」ではなくゴール達成までの「ステップ」を組み立てているのではないでしょうか。

しかし、チームによっては「分割」を文字通り解釈してしまいます。そうした解釈によってなされる「分割」をすると、「大きい」タスクは 「実装」「レビュー」「テスト」みたいになります。ソフトウェア開発の工程はたしかに大まかに「実装」「レビュー」「テスト」などに分けられるでしょう。だからこそ、その工程をもとの「大きな」タスクに当てはめて「分割」したわけです。しかし、そのような「分割」だとそれぞれの分けられた「小さな」タスクの完了が曖昧です（テストがないのに完了なわけはないですよね）。いわば、「大きな」タスクにウォーターフォールの世界観が持ち込まれたような感じがするのです。

このように「分割」という言葉にはタスクを文字通り切り刻んでしまう落とし穴があると思うのです。

そこで、私はタスクを分割するのではなく、タスクがあったら、それを達成するためにステップを重ねて積み上げていくイメージで計画を立てることを提案します。タスク達成のために必要なことを列挙してそれらを並び替える、それらを完成させると「大きな」タスクが完了します。「カレーをつくる」方法を考えてみると、「具材を切る」「具材を炒める」「煮る」「ルウを入れて煮込む」というステップに分けられますね（ハウス食品さんのレシピを参考にしました）。このときそれぞれのステップには完了の定義があるはずです。炒めるステップでは「玉ねぎがしんなり」することを目指していますね。それらのステップがすべて終わるとカレーができあがります。これと同じでタスクについてはそれを達成するためのステップを考えていくことで、計画がしやすくのるのではないかと思います。

Transcript

1. タスクは分割するのではなく、 ステップを積み重ねていく Yutaka Kamei Scrum Fest Kanazawa 2024 @金沢未来のまち創造館 July 20, 2024
2. Self-introduction • Yutaka Kamei • @yykamei on GitHub • @_yykamei on X • Timee, Inc. ◦ このあと会社紹介のお時間いただきます
5. タイミーの実績 スキマ バイト No.1 ※1 ※2 [調査方法]インターネット調査 [調査期間]2024 年 2 月 9 日~11 日 [調査概要]スキマバイトアプリサービスの実態調査 [調査 委託先]株式会社マクロミル 5 累計求人案件数 ・ダウンロード数 ※1 ※2 導入事業者数 98,000企業 ワーカー数 700万人
6. 募集人数の推移 コロナ禍においても、 過去に例を見ない程の 加速的高成長を実現。 ※1：2023年4Qと2022年4Qの比較 6
8. 大きいタスクを小さくしていく取り組みに ついて話してみます
9. 期待値調整 • 経験則を交えて話します • 参考にした文献はありますが体系的に網羅されているわけではありません • 「タスク」や「ストーリー」という言葉を入れ替え可能な形で使います
10. 計画は大事
11. タスクは大きくなりがち 最初にビジネスの視点から「実現したい」ことの 塊が取り上げられます。 これは開発者がすぐに着手できないことが多いで す。 もちろん、それがだめというわけではなくて最初 の「入力」としてはそういう塊が計画段階で取り 上げられることになります。
12. よし、タスクを分割しよう
13. 適正なサイズは場合による • ビジネスにとっての適正なサイズ ◦ ロードマップ単位 • ユーザー、顧客にとっての適正サイズ ◦ リリース単位 • 開発にとっての適正サイズ ◦ 実行可能単位 ビジネス ユーザー、顧客 開 発 Jeff Patton; 川口 恭伸 (監修), 長尾 高弘 (翻訳). ユーザーストーリーマッピング (p. 176). オライリージャパン . を参考に作成したもの
14. 分割のイメージ 「分割」されて個々の パーツになるわけでは なく、それ単体で一つ の独立したもの “ストーリーは岩のようなものとして考えるようにしましょう” Jeff Patton; 川口 恭伸 (監修), 長尾 高弘 (翻訳). ユーザーストーリーマッピング (p. 171). オライリージャパン.
15. 分割のイメージ（好ましくない）
16. どっちの分割？ ↑こちらのほうが Agile っぽくてよさそう
17. ケント ベック, マーチン ファウラー; 飯塚 麻理香 (翻訳). XPエクストリーム・プログラミング実行計画 (The XP Series) (p. 53). 桐原書店. ユーザがコンセプトを2つもしく はそれ以上に分割し、新しいカー ドを書き、古いカードを捨てる
18. よし、岩のように分割だ！ 🤔
19. yykamei (2024) やりたいことがあるならそこに至る 道筋を考える方が自然な気がする
20. ステップを積み重ねる というイメージはどうでしょう？
21. ステップを積み重ねていくイメージ ……y ….. …..yx y…. ……. c….. .cv… …. ……. c…… .h… ……. e…. …x… …… … t..t.ol …… 列挙して... …… y….. …..y xy…. ……. c….. .cv… …. ……. c… ….h … ……. e…. …x …… …… t..t.ol …… 並び替える 大きいタスク …CC…………… …AA…………… ……XX………… ………y………… ………m………… ……o….…89….. 1………..0.9…… ………………..3 ……………….2… …………X……… …4…………
22. ステップを積み重ねる — 架空の例
23. ステップを積み重ねる — 架空の例
24. ステップを積み重ねる — 架空の例
25. ステップを積み重ねる — 架空の例 「どうなる」ゲーム
26. 以上です 分割ではなくステップを 積み重ねていこう、でした とはいえ、分割って言葉を使っても いいと思います。ステップを積み重 ねる考え方も分割も、結局は「タス クを小さくしたい」というのは同じ です。考え方が違うだけです。 余談ですが、KPT と YWT ってほ とんど同じなのにたまには YWT や ろうって言ったらいつもと違うのが 出てくることありますよね。それと 同じです。
27. ここからは、タスクを小さくするために私がよいと思った プラクティスを列挙してみようと思います。
28. 全員同席 • プロダクトの成功のために必要なスキルを持っ た人たちをチームに集める ◦ 「顧客」が含まれていることが大事 ◦ エンドツーエンドの視点が含まれやすいため • 雑に言うと「コミュニケーション大事」 • “何度かやり直すことになるかもしれないが、全 員が同じ部屋で作業していれば素早く良いス トーリーを作る方法が分かってくるだろう” ◦ ケント ベック, マーチン ファウラー; 飯塚 麻理香 (翻訳). XPエクストリーム・プログラミング 実行計画 (The XP Series) (p. 54). 桐原書店. • “会話は、大きなストーリーを分解するための最 良のツールの一つだ” ◦ Jeff Patton; 川口 恭伸 (監修), 長尾 高弘 (翻訳). ユーザーストーリーマッピング (p. 172). オ ライリージャパン.
29. 曳光弾 • 最小の実装をエンドツーエンドで リリースすることで早い段階でデ リバリーに関する課題を発見する • 複数のアーキテクチャーレイヤー が必要だとした場合に、それらす べてを通るようにタスクを組み立 てる
30. SPIDR（スパイダー） • Mike Cohnがまとめたストーリーを分割す るための5つの方法 • Spikes ◦ 技術的なものの実現可能性を検証するプロトタ イプの実装 • Paths ◦ ストーリーに複数の経路がある場合に考慮する • Interfaces ◦ デバイス。iOSとかAndroidとか • Data ◦ データもストーリーの境界になりうる • Rules ◦ ストーリーで満たさないといけないルールを特 定して、それを緩めたバージョンのストーリー とそのルールを適用するストーリーに分ける
31. まとめ • タスクは分割するという考え方ではなくステップを積み重ねる ◦ 「どうなる」ゲームが有効 • 分割にしろ、ステップを積み重ねるにしろ、使えそうなプラクティスがある ◦ 全員同席 ◦ 曳光弾 ◦ SPIDR