アジャイルだって見積もりするって話 #アジャイル日記 6日目

みなさま
今日もお疲れ様ですっ

今回はアジャイルの「見積もり」について
フォーカスしてしていきたいと思います！

今回はアジャイルの中でも
"スクラム"にピックアップしたものになります。
本当に全く見積もりをしないフレームワークが
あったらごめんなさい。。。（無いと思いますけど...）

この記事を見た後に
みなさんの「見積もり」の考え方が
変わることをゴールに記事を書いていきます！

"アジャイルは見積もりをしない"という幻想

よくアジャイルに関して
こういうことをドヤ顔で言う人がいます。

「アジャイルって見積もりしないんだよっ」

え、アジャイルでも
めちゃめちゃ見積もりするよ？？（真顔）

正直、
自分もアジャイルについてよく知らなかった時は
『アジャイル神話』をよく耳にしていました。

◆ アジャイルは見積もりをしない
◆ アジャイルは進捗遅れ大歓迎
◆ アジャイルは無駄をしない、生産性爆上がり
のような飛躍した説明を『アジャイル神話』もしくは
『アジャイル伝説』と筆者は呼称しております（今考えた）

アジャイルって概念がなかなか取っ付きにくいので
人から人へ伝承される時に脚色されて
過程を飛ばした結果だけが
一人歩きしてる感じなんだと思います。

大事なのでもうもう一度いいます。
アジャイルは見積もりをします！！！

アジャイルの見積もりは２種類あるよ

もう少し正確にいうと
１スプリントで開発チームは"２回"見積もります。

★ １回目 ★
プランニングポーカによる開発規模見積もり

開発が始まる際に
まずPO（オーナー）から提示された
ストーリー（受け入れ条件）に対して
開発規模を"プランニングポーカー"
という手法で数値化しますっ

例えば検索ボタンを押下した際に外部APIから現在地の天気情報を表示すること』という"受け入れ条件"があったとします

この条件に対して開発チームは
「１」「２」「３」「５」「８」...
の中から規模を数値化します。

これが「フィボナッチ数列」であるのは、
２は１より"ひとまわり"大きい
３は２より"ひとまわり"大きい
５は３より"ひとまわり"大きい
８は５より"ひとまわり"大きい
と開発規模の比較がしやすくなるためです！

決定までのステップは以下のような感じでっす

STEP1 : POに質問や意見や提案をする
「このデザインも対象ですか？」
「天気情報を取得するAPIに指定ありますか？」
「ユーザーが現在地情報の公開を拒否していた場合は？」
STEP2 : 技術要素を全員で洗い出す
「ここはコンポーネント化しよう」
「DBは今回使わないようにしよう」
「外部API呼び出しはサーバー側でしよう」
STEP3 : 各開発者は規模を頭で見積もる
（外部API呼び出しは初だから時間かかるなぁ）
（DB使わないなら簡単かなっ）
（現在地取得も外部API使うし大変だなぁ）
STEP4 : 各々の見積もりを一斉に公開する
「私は３！」「僕は５！」
「我は３なりぃ！」「某は３でござる！」
STEP5 : 見積もりに差異がある場合は議論
「え！なんで５？」
「前回の○○の実装で見積もりを５にしてたよ」
「確かにぃ！」
（↑もっと深く議論します）
STEP6 : 議論で認識を合わせた上で規模決定
「５にしまーーすっ」

という感じです！
ここでのポイントは
★ POと細かすぎるくらいまでの議論
★ 実際の規模見積もりは相対評価で！

POとはここで認識を一致させておかないと
レビュー時に蓋を開けて
「え...?思ってたのと違う...」となりかねないので。

本当は毎日、POと会話できるのであれば
認識の齟齬の懸念は減りますが
なかなかPOさんも忙しいので、、、

あとは、時間からの開発規模を数値化するのでなく
実績からの規模を相対評価することが重要です。**
開発者の技術力が上がると実装時間は減ります。すると、同じ実装量、技術難易度（開発規模）でも以前は「５」、今回は「３」となり得てしまうからです。

これだと時間当たりの開発量が評価できません。これが評価できないと、開発者の技術向上が目に見えにくくなってしまいます。

加えて、時間で見積もりと正確性がかなり求められます。これは開発者へのプレッシャーになります。それに時間見積もりは確実にぶれます！であればポイントとして開発規模を見積もり、「１スプリントで何ポイント消化できるか」の考え方がシンプルであり、やるべきことにフォーカスするのが狙いです。

この開発規模の見積もりを経て、今回のスプリントで引き受けるストーリーをコミットします！

★ ２回目 ★
コミットした受け入れ条件に対しての時間見積もり

え....???
結局、時間見積もりするんかいっ！

まぁまぁ落ちついてください。

このステップでの見積もりはあくまで開発チーム内部での時間見積もりになります！なのでPOへ公開などはしません。

開発者は開発規模の見積もりを通してオーナーと「約束（コミット）」をしました！

約束は何とかしても最大限守りたいです。そのための時間見積もりです。

時間見積もりのステップはこんな感じっ

STEP1 : タスクの細分化する
「コンポーネントの作成」
「親子のデータ受け渡し」
「外部API呼び出し」
「エラーハンドリング」
「css適用」....etc
STEP2 : それぞれのタスクに時間を見積もる
「コンポーネントの作成」→ 0.25h
「親子のデータ受け渡し」→ 0.75h
「外部API呼び出し」→ 1.5h
「エラーハンドリング」→ 1.0h
「css適用」→ 0.75h     ....etc
STEP3 : タスクカレンダー作成
「月曜にはこれとこれを実装しよう....」
「水曜はAさん休みだからこれだけ実装しよう」

以上のステップ通してカレンダーを作成すると作業進捗の見える化と遅延してしまった場合の早期アラートを可能にします！

まとめ

以上をもってPOとタスクをコミットするための『開発規模見積もり』と開発チームの作業進捗見える化と早期アラートのための『時間見積もり』を説明しましたっ

これら見積もりを毎スプリント行うことで開発チームのベロシティの測定や見積もりの精度向上を測っていきますっ

兎にも角にも重要なのは見積もりを推測に過ぎないという前提を持っていること

だからこそプランニングポーカーという手法で見積もりをしています。この理解をオーナー側も含めチーム全員が認識できていることがアジャイルチームを立ち上げる必要条件になりますっ

今回は以上になります。
まだまだ説明不足があるとおもいます
質問等ございましたら是非コメントくださいませ！

DXから考えるアジャイルについても記事にしていますぅ↓