アンドパッド輪読会のふりかえり〜「アジャイルな見積もりと計画づくり」編〜

こんにちは!

ソフトウェアエンジニアの福間(fkm_y)です!

アンドパッドでは業務時間中にいくつか勉強会をしているのですが、そのなかの「アジャイルな見積もりと計画づくり」の輪読会が終わったのでどんなふうに輪読会をやっていたのか紹介したいと思います!

輪読会について

f:id:fkmy:20210525150516p:plain

はじめに

はじめに「アジャイルな見積もりと計画づくり」の輪読会に参加したい人をSlackで募り、見積もりや計画作りに興味、課題感を持っている有志のメンバーを集めました。その後、どんな形式で進めるかディスカッションしてルールを決めてからやっていきました。

  • いつ
    • 毎週月曜の12:30~13:00
  • ルール
    • 毎週1章づつ予め読んでおき、気になったことをメモに残しておく
    • 会当日
      • 気になった点を一人ずつ順番にボードに出していく
      • 同じような内容であれば他のメンバーも一緒に出す
      • 出されたテーマについて話し合う

2020年11月から読み進めていたのですが章が23章あったため2021年5月まで掛かりました。

やってみて

どんな意見が出た?

マルチタスク化が遅れを助長する

  • なるほどという感じ。人によって3つ同時並行の方がパフォーマンス出る場合もあるかと思っていたが、基本的には2つまでが効率が良いということを知れただけで良かった。


イテレーションの終了時点でプロダクトがリリース可能な状態になっていること

  • この縛りでユーザーストーリーを解決するための機能が洗練されそう(優先度が低い機能は削らないといけない)。

ストーリーポイントによって「作業量の見積り」と「期間の見積もり」とを完全に分けて考えていることである

  • 「作業量の見積り」と「期間の見積もり」を分離して考えるのが大事とのこと。納得。
  • ストーリーポイントはスケジュールではなく規模!


人は10倍以内のものならうまく見積もれる

  • 14章で最大値をどこにするか?という話題があったが、役に立つ見積りのためなら10倍が妥当といういうことですね。 ←大きすぎたら分割するという基準になるが細かすぎても抜け漏れが出る可能性がある…ふむ。


最もうまく回していけるストーリーの大きさは、2日~5日ぐらいなのだ

  • 1week sprint の場合は1~2枚のチケット(ストーリー)を対応している時が効率良い気がする。


ミーティングはタスクに含める(それも多めに)

  • これは同意。結構忘れられがちだけど結構な時間になってるので!


個人単位でベロシティをトラッキングしてはならない

  • ベロシティ上げようと行動するのも止したほう良いとのこと、ボトルネックを除外する行動は良いとのこと。
  • チームメンバー間の助け合いを阻害する要因になるため。


ガントチャートにはフィーチャを載せるべきだ。

  • 良い!ガントチャートに拒否反応を起こす人がいるが中長期のスケジューリングには向いてると思うので短期/詳細なタスクはカンバンに任せて、フィーチャはこちらで見るの賛成。
  • 期間はイテレーション単位とし、各フィーチャには担当を設定しないのか。


ある回のディスカッションで使用したボード

f:id:fkmy:20210601194621p:plain

滞りなく運営できた?

昨今の事情から物理的に集まらず最初から最後までオンラインで輪読会を行っていました。オンラインは喋るタイミングが被ることや意見が出ないなどの問題が起こりがちだと思いますが、喋ることを予めカードに記載して順番に喋るようにしていたのでその問題があまり起こらなかった気がします。

また始めの1,2回は意見が多すぎて時間が足りないこともありましたが、参加者数によってメモを1人2枚に限定したりメンバーの誰かがタイムキーパーを行うなど都度工夫して回せたことや、発起人のファシリテーターが不在のときには参加者が率先して代わりにファシリテーターをしていたので滞りなく運営を回せていました。

f:id:fkmy:20210608180715p:plain

感想

読んだ感想を持ち寄って、これはSaaSツールの開発でも当てはまるのか、今の自分のチームで出来ているか組み込むことはできそうかなどわいわいディスカッションできたのは楽しかったですし、理解しにくい箇所をメンバーで補完しながら読み進めることが出来たので学びも多く感じました。

学べたことが多いので抜粋しますが以下のようなことが学べました。

  • 見積もりの不確実性
  • 数回のイテレーションを回しながらスケジュールの決め精度を高めていく
  • 不確実性に対して適切なバッファを設ける
  • 必須要件の工数は全体の70%を超えないようにしてフィーチャバッファを設ける

「アジャイルな見積もりと計画づくり」をさいごまで読み、アジャイル開発は常に現実を見て反映させながら現実的な計画を立てているので使い物になるので楽しいと感じるような気がしました。

さいごに

今回紹介した「アジャイルな見積もりと計画づくり」輪読会だけでなく他の輪読会や勉強会も多々あり、それぞれ異なった進め方をしています。 勉強会でインプットしたことを実業務でアウトプットするサイクルを一緒に回したいと感じた方は以下のリンクから職場環境などを見てみたりカジュアル面談に来てみてください。お待ちしてます!

engineer.andpad.co.jp