and factory.incAdvent Calendar 2023

なんのためにあるの？逆引きスクラムプラクティス

Last updated at 2023-12-18Posted at 2023-12-17

この記事はand factory.inc Advent Calendar 2023 18日目の記事です。
昨日は @be-nao さんの「【Jetpack Compose】HorizontalPagerのスワイプ判定を調整する」でした。

はじめに

バックログ、デイリースクラム、スプリント、ポイントなどなど、アジャイルには先人たちが編み出してきた数々のプラクティスがあります。
日々アプリがアップデートされていくことが前提のモバイルアプリ開発においては、アジャイルを採用しているプロダクトは多いと思いますが、メンバー全員がそれぞれのプラクティスの意味を理解して実践できているチームはどのくらいあるでしょうか？

プロダクトバックログ？開発項目が並んでるんじゃないの？
ポイントって要は見積もればいいってことでしょ？

バックグラウンドが様々なチームではアジャイルに対する理解度もまちまちだと思いますが、
チームの認識がブレれば、手段が目的化して段々と形骸化していきます。

正直僕自身もノリでアジャイルに向き合っていた状況でした。
アジャイルの基礎を学んでいった中で理解したアジャイルやスクラムで行われるプラクティスが、
どんな目的で確立されているのか逆引き形式で書いてみました。

前半部分はアジャイルが解決したい課題、後半部分はプラクティスの逆引き形式になっています。

おことわり

ちょっと釣りっぽいタイトルになっていますが、僕自身本テーマについては初級者のため、そのつもりで読んでいただければ幸いです。
プラクティスを逆引きするという文脈で「スクラム」をタイトルに入れていますが、本記事ではアジャイルの内容のほうが厚く触れることになると思います

参考

本記事はほとんどの内容を「いちばんやさしいアジャイル開発の教本人気講師が教えるDXを支える開発手法」を参考に書いています。

選定は以下の記事を参考にしました。

僕自身、本テーマは学び始めたばかりということで入門編として読みました。
アジャイルが解決したい課題、大切にしている価値観、各プラクティスが何を目的としたものなのか、
平易な言葉で書かれていて非常にわかりやすかったです。

アジャイル開発が何を解決するのか

各プラクティスがなんのために存在するのか、を理解するためには
そもそもアジャイル開発がなにを解決したいのかを理解しなければはじまりません。

プラクティスを見る前に基本的なアジャイルの精神の部分に触れていきます。（なるべく簡潔に）
既に理解されてる人は飛ばしてください。

なぜアジャイルか

既存の開発手法で解決できない課題

既存のシステム開発手法として古くからウォーターフォールモデルがあります。
ウォーターフォールは一方向に開発が進んでいくので、作るべきものが事前に定義できるのであれば優れた開発手法ですが、それは「作るべきものが事前に定義できる」という前提が成立する場合です。

要件定義はあくまで仮説に過ぎず、ユーザー自身も本当に必要な機能を理解していないことが往々にしてある
工程ごとにコミュニケーションは分断されるので、前工程などの疑問点や改善案を出しにくい
フィードバックループが生まれず失敗を次に活かしづらい

など、システムが複雑化・多様化し、ゴールが決まったところに向かって一度作ってしまえばいい、という前提が崩れていくケースが増えていく中で、
総じて、ソフトウェア開発についてまわる不確実性への対応が苦手、というウォーターフォールの弱点が露見されるようになりました。
（逆に作るものが定まっている場合、ウォーターフォールは今も有効な開発手法）

アジャイルでどう不確実性と向き合うか

アジャイル開発の構造は以下のようになっていて、
なにか具体的な手法ではなく、まずは不確実性に向き合うためのマインドセットを第一にしており、
各プラクティスはあくまでそのマインドセットを実現するための手段にすぎません。

マインドセットとしてはアジャイルソフトウェア開発宣言にまとめられているのですが詳細はたたみます。

アジャイル開発宣言を読み解く

プロセスやツールよりも個人と対話
- プロセスやツールは既に定義されている範囲ではよい働きをしてくるが、それよりも言語化できていない事実に気づき、見える化するにはチーム内で対話することが重要
包括的なドキュメントよりも動くソフトウェア
- ドキュメントはソフトウェアの未来予想図だが、ドキュメントレベルでは問題ないように見えても「実際にできたソフトウェアが必要なものと異なる」という自体は起きる。ドキュメント通りに作られているかどうか、ではなくソフトウェアが価値を提供しているかどうかが重要
契約交渉よりも顧客との協調
- 契約により期待を明文化し意識を揃えることも重要だが、契約内容を境界とするよりも顧客と協調して必要なソフトウェアを探索するほうがよりよりよいものづくりにつながる
計画に従うことよりも変化への対応
- 計画にこだわり変化を拒むのでなく、変化はより良い成果を生み出すための機会

すっごくざっくりまとめると以下が重要なんだと思います。

アジャイルでなにを実現したいか
- 不確実性に向き合いながら、不要なものを作らずに、本当にやるべきことに集中する
アジャイルでどうやって実現したいか
- 不確実性を前提として、スプリントから学びを得ながら随時やり方を改善する

アジャイルのコアコンセプト

参考書籍ではアジャイルのコアコンセプトとして以下の３つがあると説明しています

インクリメンタル
イテレーティブ
チーム

インクリメンタル・イテレーティブ

不確実性の高い開発では、想定だけで一度に多くのことを実現しようとしても、的を得た物になりません。
そのため少しづつ（インクリメンタル）、繰り返し的に（イテレーティブ）に作り進める事が重要です。
少しづつ反復的に進めることで、不確実性を徐々に取り除き、本当に作るべきものに近づけていくことができます。

チーム

不確実性を乗り越えて、アジャイルが大切にする価値観を実現するには

🙅‍♂️ 決められたことのみをやるチーム
🙆‍♂️ 経験を学びに変えて、必要なアクションを取れるチーム

である事が重要です。

アジャイル開発において機能するチームは「自己組織化」されており、「職能横断型」なチームです。
各メンバーがそれぞれ複数の専門性を持ち、自発的に動くことが必要です。
ハードルが高くも感じますが、だからこそチーム自体も学びを得ながら少しずつ作り上げていく必要があります。

見える化する・一緒に取り組む

ここまでアジャイルの大枠やコンセプトの部分を確認してきました。
ここからもう少し踏み込み、コンセプトを満たすために大事な行動である「見える化する」と「一緒に取り組む」について触れていきます。

見える化する

少しづつ、反復的にプロダクトを作るには、現在の問題や状況を正しく把握する必要があります。

現在の状況が見える化されていなければ

差し込みのタスクが発生しても、現在のタスクと正しく優先順位を評価することができない（=本当にやるべきことがわからない）
後で見返したときに、なぜイレギュラーが発生したのか、意思決定のプロセスは妥当だったか、見直すことはできない（=学びを得ることができない）

また、この見える化は取り組みとしてはいくつかに分けることができて

タスクの見える化
日常の見える化
やったことの見える化

などがあります。

一緒に取り組む

不確実性に向き合いながら、良いチームを作り上げていくには、
日々の作業やふりかえりなどをメンバーが一緒に取り組むことが有効です。

一人ではわからないことが、チーム全体で見ることで明らかにできます。また、一緒に取り組むことでともに働くメンバーを理解して、チームとしての出力を高めていくことに繋がります。

逆引きプラクティス

前置きが長くなりましたが、ここからプラクティスごとの目的を整理していきたいと思います。
ここまで触れてきた項目をふまえると、各プラクティスは明確にアジャイルを実践するために設計されたものだと解釈することができます。

僕が学習した中で代表的なものを書いてるにすぎないので、不足していることも多々あるかとは思いますが、その点はご容赦ください。

プロダクトバックログ・スプリントバックログ

これはなに？

「作るべきもの」を一覧で管理したもの

目的

インクリメンタルに作るために、入れ替え可能な粒度でタスクを項目化する
入れ替え可能な粒度であることで都度発生する不確実性に対応する柔軟性を得られる

詳細

アジャイル開発では少しづつ作るために「作るべきもの」を一覧で管理し、これをプロダクトバックログと呼ぶ

メリット
- 何から作ればよいかが自明（一覧の先頭から作り始めればよい）
- 次に何を作ればよいか迷わない
- 作る順番を入れ替えやすく変化への対応がしやすい
メリットを享受するために
- 一覧の項目一つ一つが明確で、ほかの項目に依存しないことが望ましい
  - 依存が大きいと入れ替えが難しくなる
- 各項目の内容を十分に小さく（1日以内で開発が終わる程度）することで独立性が高められる
気をつけなければならないこと
- プロダクトバックログだけではプロダクトの全体像が見えにくくなる
  - プロダクトをユーザー視点で捉える以下のアプローチが有効
    - ユーザーストーリーマッピング
    - ユーザー行動フロー
- 全体と詳細の両面を捉えるスタイルがインクリメンタルな開発に必要
直近のスプリントで行うべきスプリントバックログがある
- 当初見えていなかった差し込みタスクが発生した場合、優先順位を正しく見極め、適切なタイミングで取り組む
  - 差し込みが発生しても、バックログ化されていることで、あとから振り返り次の計画づくりに活かしやすい

スプリント・イテレーション

これはなに？

少しづつ形作る上で定められた、一定の開発期間。
この単位で開発作業を進めていく。

目的

期間上の仕切りを作ることで、行動の結果から学びを得て、次の開発機関で適応するサイクルを確保する。

詳細

この一定の期間をスクラムではスプリント、スクラム以外ではイテレーションと呼ぶ

スプリントプランニング

これはなに？

スプリントの計画づくり

目的

スプリントで開発する内容を決める
また、スプリント単位で計画することでこれまでの反省を活かし、不確実性を減らした計画を立てる

詳細

質を問うべきは計画そのものではなく、計画づくりのプロセスそのもの
イテレーティブというコンセプトを守るためには、計画をやり切る習慣化が大事
- プロダクトづくりに伴う不確実性はプロジェクト全体で受け止める
  - 例) 誰かが負担を引き受けるのではなく適切にバッファを設ける
- プロダクトづくりの確実性はスプリント単位で高める
  - 例) 受け入れ条件を定義する

スプリントレビュー

目的

見積もりを出しつつ、メンバーのタスクに対する理解度を高める

詳細

やりかた

見積もりは相対的に行う
- 見積もりたいのは絶対的な時間ではなく規模感なので、仮想の単位の「ポイント」を用いる
- 1,2,3,5,8,13と増加していく、フィボナッチ数列が有効
  - 大きなタスクサイズほど誤差を含むことを表現しているため
経験値や組織における立場に関係なく、全員でタイミングをあわせる見積もり手法
- 見積もり値が揃わなかった場合は、メンバーそれぞれに見積もりとなった理由を聞く
- メンバーの見積もり値が一致することは殆どない
  - 不一致こそがタスクへの理解度を揃えるきっかけになる
    - 「過去の同様の開発で時間がかかった」「検証に時間がかかる」など知見が得られる
    - 動くところまで作るのか、リリース可能なレベルまで作るのか、といいったゴールのズレに気づくことができる

ペアプログラミング・ペアワーク

これはなに？

プログラミングなど日々の業務を一緒に取り組むこと

目的

互いの知識を保管し合いながら、タスクの達成を目指す
またその過程で暗黙知の共有を行う

詳細

ペアプログラミングのメリット
- ケアレスミス・分かりづらいコードを書く、などを防止
- コードレビューよりも待ち時間や手戻りが少ない
- 書いたコードを知っている人が増える
- 暗黙知の共有
- お互いの得意分野を活かせる
ペアワークも様々なケースで有効
- 緊急トラブルの対応
  - 複数の視点で見ることで原因特定のスピードが早くなる
- ツールのインストールや設定
  - ミスの防止
  - 長いドキュメントを目の前にしても心が折れない
- レベル差がある業務の伝達
  - 業務の暗黙知が共有される
  - その場で質問・疑問を回収できる

最後に

こうやってアジャイルの精神まで理解した上で見ると、これまで深く考えずに取り組んできたものが、それぞれなにを解決したかったのかが見えるようになってきました。

正直、プロダクトバックログとか、開発項目をそれっぽい言い方してるだけって思ってました。
こうしてみると不確実性に対応することを前提に設計された仕組みで、小さく設定すること、独立性を高めることが重要なのだなという、ことに気づくことができました。

大変長い散文になってしまったので、誰が呼んでくれるんだろうか、、みたいな気持ちになってるのですが、最後まで呼んでくれた方はありがとうございました！

明日以降のアドベントカレンダーもお楽しみに！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

なんのためにあるの？逆引きスクラムプラクティス

はじめに

おことわり

参考

アジャイル開発が何を解決するのか

なぜアジャイルか

既存の開発手法で解決できない課題

アジャイルでどう不確実性と向き合うか

アジャイルのコアコンセプト

インクリメンタル・イテレーティブ

チーム

見える化する・一緒に取り組む

見える化する

一緒に取り組む

逆引きプラクティス

プロダクトバックログ・スプリントバックログ

これはなに？

目的

詳細

関連

スプリント・イテレーション

これはなに？

目的

詳細

関連

スプリントプランニング

これはなに？

目的

詳細

関連

スプリントレビュー

これはなに？

目的

関連

ふりかえり・スプリントレトロスペクティブ

これはなに？

目的

詳細

関連

インセプションデッキ

これはなに？

目的

詳細

関連

タスクボード

これはなに？

目的

詳細

関連

朝会・デイリースクラム

これはなに？

目的

詳細

関連

プランニングポーカー

これはなに？

目的

詳細

関連

ペアプログラミング・ペアワーク

これはなに？

目的

詳細

関連

最後に