アジャイル開発における計画

アイスブレイク

Google Nest Hub（第2世代）を購入しました。
画面の付いたスマートスピーカーなのですが、ベッドサイドに置いておくと睡眠状態を記録してくれるので結構便利です。
睡眠トラッキングで呼吸数を測れたりするのは珍しいですね。

アジャイル開発：日々の過ごし方

アジャイル開発の基本的な日々の過ごし方はざっくりこんな感じです。（1スプリント=2週間の場合）

細かい部分はチームによって様々です。

• 朝会じゃなくて夕会がよいとか
• スプリント計画は振り返りのあと同じ日にやってしまいたいとか
• 月曜スタートじゃないほうがよいとか（日本だと月曜祝日が多いため）
• バックログリファインメントを明示的に設けるとか

※この辺はプロダクトやチーム状況によります。スプリントを回しながらチームに合った形に改善していきましょう。
チームによって細かなところは違いますが、一般的にはこのようなイベントをこなしつつ日々のタスクを消化していきます。

アジャイル開発だからといって特殊なことは何もしていません、普通の仕事のやりかたと同じです。

• 見通しのよい単位に仕事を分割し　→タスク
• いつまでに何をやるかを考える　　→スプリント計画

アジャイル開発：困りごと

ソフトウェア開発ではユーザーの要望を満たす、ということが目的です。
それを「チーム単位で期間を固定してやりましょう」というのがアジャイル開発です。
しかし、ただ要望を洗い出したとしても以下の問題があります

• やりたいことの大きさがバラバラ（簡単なもの、すごく難しいものまで色々）
• 優先度がバラバラ（あったら良いな、なのか、ないと困るなのか）
• 前後関係がわからない（AのためにはBという機能必要だよねとか）
• いつまでにどうなってるかが分からない
• 最終的にどこを目指しているのか分かりづらい

アジャイル開発：計画

ではどうするのでしょうか、というお話です。
ユーザーストーリーマッピングという手法が有名ですね。
（似たような手法にカスタマージャーニーマップとかもあります）

アジャイルは行き当たりばったりではなく、ちゃんと計画しますよ、ということです。

用語整理

• タスク
  • 開発者が日々向き合う課題。ユーザーストーリーと表裏一体
    • 同じ内容を別の言葉で表現しているに過ぎません
  • 一般的にサイズ感は「ストーリー＞タスク」になりがち
    • しかし場合によってはプログラムの共通化によって逆転することもあります
    • この「ストーリー⇔タスク」の相互作用をうまく制御することがアジャイル開発の醍醐味です
    • エンジニアリングサイドからビジネス課題にインパクトを与える。なんかワクワクしますね。

• ユーザーストーリー
  • ユーザーの言葉で書かれた要件。ユーザー視点で価値を生み出す単位。
  • 例：
    • 「販売者は商品を登録できる」
    • 「販売者は商品を削除できる」
    • 「販売者は新商品情報をメールで購入者に送信できる」
    • 「購入者は商品をカゴに入れることができる」etc…

• ナラティブフロー
  • ストーリーの流れや前後関係
    • 例：商品登録よりまえにカゴに入れることはできないし、購入もできません
  • 別の表現で「エピック」という概念があったりしますが、そちらは前後関係がないですかね
    • どちらも雑多なストーリーを何らかの意味合いでグルーピングするものです

• バックボーン
  • ストーリーの骨格
    • 例：「販売者は商品を管理できる」「購入者は商品を購入できる」
  • 経営層からのオーダーはこのレベルのことが多いですね

ストーリー、ナラティブフロー、バックボーンを考えていくのに順番なんてありません。
バックボーンからブレイクダウンして考えていく場合もありますし、
小さなストーリーを沢山書き出したら流れやバックボーンが見えてきたという場合もあります。
そのため、ホワイトボードや付箋を使ってブレインストーミング的に実施するのがよいとされています。

この手法で大切なことは

• ユーザを巻き込む
  • ユーザとはソフトウェアを実際に使う人です（そのソフトウェアを使って価値を生み出す人）
  • よくある失敗にITや管理部門の論理でシステム開発した結果、誰にも使われないというものがあります
  • ソフトウェア開発の目的はソフトウェアを作ることではなく「ソフトウェアを使ってビジネス価値を最大化すること」です

• MVP（Minimum Viable Product）を理解する
  • 日本語で言うと「実用最小限の製品」
  • そのソフトウェアがもたらす価値を端的に実現したものがMVPです
  • 本質的な価値以外を削ぎ落としたあとに残るものです
  • 「◯◯できたら便利」という発言はたいていMVPとは無関係です

• 計画に従うことよりも変化への対応
  • ユーザーストーリーマッピングは最初に1度実施すれば終わりではありません
  • 要望は変化しているかもしれません
  • ソフトウェアの価値を最大化するため常に見直し、優先順位の高いものから実現しましょう
  • これを行うのが「バックログリファインメント」というイベントです

スプリントとリリース

MVPを1スプリントで獲得できる。素晴らしいですね！最高の結果です。
しかし現実はそんな簡単にいきません。最初の2週間ではそんなにたいしたものが作れないためです。

MVPを達成するまでリリースする意味はないのか？というとそんなことはありません。
まずここで言う「リリースとは何なのか」をはっきりさせましょう。
ここでは「実際に触って動かせるソフトウェアを提供する」ぐらいの意味です。
（実際そのソフトウェアで業務をするとか、社外のエンドユーザに使ってもらうとかではない）

「要望を出した人に使ってもらってフィードバックを得る」これが一番やりたいことです。
そうやって得られるフィードバックを早期に獲得しながら開発し、MVP達成を目指します。
（社内業務システムなら実運用開始。BtoCなら正式リリース）

もちろんMVPを達成したから即フルオープンではなく、
影響度等を考慮して一部のユーザだけ部分リリース（Beta版等）というのも良い考えです。
プロダクトの性質に応じて判断しましょう。

最後に

常に変化するビジネス状況にいかに対応していくかという手法がアジャイル開発です。
「変わるのだから先のことは考えなくて良い」ではありません。
「常に現時点でのベストを考え続け、それに固執せず変化に対応する」ということです。

変化に対応していきましょう！