アジャイル開発を採用しているチームにおいても、ビジネスの要求によっては「一定規模のフィーチャーセット」を「特定の時期にリリースする」ことを、達成しなければなりません。 そういった要求に対し、挑戦する20代の転職サイト「 キャリトレ 」 の開発チームがどのように立ち向かっているのか、リファインメントの実践例を通してご紹介します。

「キャリトレ」は2022年12月21日をもってサービス終了しました。

予測可能性を求めるビジネスの要求とは

分かりやすい例でいうと「業界の繁忙期に合わせて新機能をリリースしたい」などです。 また、BtoBビジネスの場合、開発チームがフィーチャーセットとリリース時期をある程度担保することができれば、 企業のお客様に対し事前のご案内がしやすくなります。 そのことは、リリース直後からその機能を最大限ご活用していただける、という大きなメリットがあります。 事業部一体となって、プロダクトの価値を最大限デリバリーするために、案件によっては予測可能性が重視されることがあります。

リファインメント

何をどれくらいやるのか？

「キャリトレ」ではスクラムイベントの リファインメント で、必要に応じて予測可能性を高めるための作業を行っています。 各開発チームから数名を募ってリファインメントを一定期間集中して実施します。 ゴールはリリースまでに完了させるPBIを全て洗い出し、それぞれのPBIに対しストーリーポイント（相対的な見積もり）を付与することです。 当該期間は技術的検証含めこのリファインメントにエンジニアの作業工数の20-30%程度をかけることもありますが、PBIに着手し始めてからは、リファインメントに割く工数はほとんど不要になります。

それってウォーターフォールでは…？

確かに、2,3スプリントより先のPBIに、予めストーリーポイントを付与するリファインメントのやり方は、一般的なアジャイル開発とは少し異なります。 しかし、ウォーターフォールのように精緻な見積もりはしませんし1、 下図のように一通りPBI群を整理した後は、価値のある塊をインクリメンタルに開発していくというアジャイルのアプローチ2は変わりません。

alt text

ビジネスの要求に答えるためのアプローチとして、時にはこういったアレンジも必要であると考えています。

リファインメントの流れ

見積もりに必要なものは大きく「仕様」と「実装方針」です（「実装方針」については設計次第で大きく見積もりがブレることが予想される場合にのみ明らかにします）。 その2つを以下の流れで明らかにしていきます。

  1. ユースケースでざっくり分解
  2. ユースケースごとに仕様を詳細化する
  3. PBIにまとめる
  4. 実装方針を決める
  5. 見積もる
  6. リリース時期を予想する

1. ユースケースでざっくり分解

例えば新機能として「企業の採用担当者から求職者にスカウトを送る機能」が追加されることになったとしましょう（「キャリトレ」の公開当初からある機能ですが例として使います）。 イメージとしてはこんな感じです。

alt text

MECEに分ける

まず大きな壁にざっくりと色を塗りましょう。 ここで大事なのはMECEであること（塗り忘れがないこと、色同士がかぶらないこと）です。 いわゆるユースケースを使って、こんな感じにざっくり分けます。

alt text

ざっくり分ける際の3つのポイント

ⅰ. 主語を明確にする

主語を明確にするだけである程度MECEになります。 システムに直接的に関わっている人、連携先の外部システムに関わっている人を漏れなく洗い出しましょう。 例えば非機能面で計測要件などは漏れがちですが「マーケ担当」が関わっていることを思い出せれば漏れることはないでしょう。

ⅱ. 詳細化しすぎない

例えば「採用担当者がスカウト送信前に内容を確認する」といったものは、ここでは細かすぎると思います。 その粒度であれば「採用担当者が求職者にスカウトを送信する」というユースケースの中の、詳細な仕様として洗い出した方が良いでしょう。 どれくらいの粒度にすればよいか、明確な基準を設けるのは難しいですが、例えばオンラインの機能であれば、APIのエンドポイントの単位より細かくなることは少ないと思います。 また、これまでの経験からすると、関係者で1時間程度話し合えばほぼ洗い出せていたので、あまり時間をかける工程ではないというのを意識すると良いかなと思います。

ⅲ. 開発・運用保守に関わるユースケースも洗い出す

最終的なゴールは見積もりを出すことです。必要な作業は極力、漏れのないよう洗い出さなければいけません。 そのために「エンジニアが開発する」「QAがテストする」といったものもユースケースとして定義してしまいましょう。 それにより「ブランチ戦略を立てる」「QAがテストする環境を準備する」といった作業を洗い出すことができます。

2. ユースケースごとに仕様を詳細化する

ざっくり塗り分けた色ごとに仕様を詳細化していきましょう。

alt text

仕様を詳細化する際の3つのポイント

ⅰ. 今、分解しようとしているユースケースに集中しましょう

例えば「メッセージにURLが含まれている場合にクリックできる」は「求職者が送信されたスカウトを閲覧する」のユースケースですね。 仕様を洗い出すので、発散する場でもありますが、発散させる範囲を限定しないと収集がつかなくなるので注意したいです。 せっかくユースケースをMECEにしたので、発散する範囲を限定し、抜け漏れのないよう深堀りしていきましょう。

ⅱ. システム設計を深堀りするのはやめましょう

例えば「スカウト送信をオンラインでやるのか、バッチ処理でやるのか」といったシステム設計についての議論は一旦おいておきましょう。 設計によって見積もりに大きく影響しそうなところは、この後の章でその「実装方針」を明らかにしていきます。

ⅲ. 細かいUIについて話すのもやめましょう

案件のイメージを全員で共有するために、ざっくりとしたUIを用意することは良い方法だと思います。 ただし、UIの詳細について議論しだすとなかなか仕様分解が進まないので注意しましょう。 デザインの詳細が見積もりに大きく影響することは少ないので、この工程で詳細化する必要はないと思います。

それ、初回リリースに必要ですか

いくらコードを書いても、リリースされていなければ何の価値も生まれませんし、市場からのフィードバックを受けることもできません。 規模が大きくなると忘れがちですが、初回リリースのフィーチャーセットの中には、ビジネス要求を満たす最低限の仕様を入れましょう。 上記の例でいうと「テンプレート機能から本文を作成できる」は少し怪しいかもしれません。 このあたりはステークホルダーとしっかりと擦り合わせをしていきましょう。

全体を俯瞰しながら優先順位を付けることができるのも、リファインメントを集中して最初に行うことのメリットだと思います。

3. PBIにまとめる

これまで「ユースケース -> ユースケースごとの仕様を詳細化」という順番で「スカウト送る機能 」を分解をしてきました。 次はこの仕様を、開発および見積もりの単位であるPBIにまとめていきます。

alt text

PBIにまとめるときのポイント

大きくなりすぎないようにする

たくさん仕様が詰まっていたり、開発時に複数のレイヤーを横断するPBIは見積もりにくいです。ちょうどいい塩梅にまとめましょう。 例えば「採用担当者が固定の本文でスカウトを送信できる」といった具合のPBIにします。 そうすると、スカウト本文を入力するフロントエンドの実装やそれに伴うバックエンドの処理などは省略しつつ、各レイヤーの大枠を実装できます。 ちょっと大きいなと思ったら、開発のフローも若干頭にいれつつ、どこかに制約（例でいうと固定の本文）を加えて小さくしましょう。

小さくなりすぎないようにする

ユースケースごとの仕様を詳細化していくと細かなものも出てきます。 例えば入力制御の「本文の入力は必須」と「本文は1000文字まで」は「採用担当者が正しくメッセージ本文を入力できる」といった1つのPBIにまとめた方が良さそうです。 なぜならストーリーポイント（後述）の最小値は1で、実態として1より小さなPBIが増えてしまうと、それらを積み上げた際に見積もりが上振れする可能性があるからです。

4. 実装方針を決める

前述のとおり見積もりには「仕様」と「実装方針」の両輪が必要です。 「実装方針」によって見積もりが大きく変わることが予想される場合、ある程度それらを明らかにしていきましょう。 逆に、どう実装してもあまり見積もりが変わらない、と判断できるものは、実装に着手してから決めればよいと思います。

実装方針を検討するタイミング

見積もりに求められるスピードにもよりますが、最速でやるなら「仕様」の詳細化と並行してやりましょう。 技術が得意なエンジニアには「仕様」よりも「実装方針」の検討に時間を割いてもらうなど、役割分担するのも1つの手です。

進め方

特筆するものはあまりないですが、だいたいこんな感じで進めています。

  1. 担当者を決める
  2. 担当者が考えられる案を複数出し、各案のメリット/デメリットを整理する
  3. エンジニア間で議論し、採用する案を決定

過去の検討例

参考までに、過去にこの工程で検討・調査したことのあるものを一部ご紹介します。

5. 見積もる

ここまでの工程で詳細化された「仕様」が、それぞれのPBIにまとめられました。 そしてそれらを開発するための実装方針も決まりました。何をどう実装するかがだいたいわかれば、見積もることができます。

ものさしとしてのストーリーポイント

PBIの見積もりにはフィボナッチ数を用いたストーリーポイントで相対評価していきます。 特定のPBIを2としたら、それと比べて1なのか3なのか、あるいは5なのか、というざっくりとした見積もりの仕方をします。

複数人で各PBIのストーリーポイントを見積もる

PBIの一覧を列挙し、複数のエンジニアがそのPBIのストーリーポイントを評価していきます。 この工程はスプレッドシートなどを活用し非同期に実施すると効率的に実施できます。

差分の大きいものは議論しその理由を明らかにする

一通り各エンジニアが各PBIを評価し終わった後、ストーリーポイントの最大値と最小値に開きがあるものを対象に議論し、その差分の理由を明らかにします。 議論の後、必要に応じて、各エンジニアがそのPBIに対し再評価します。

PBIのストーリーポイントを決める

ここまで来たらあとは機械的にPBIのストーリーポイントを決めていきます。 例えば、以下のようなロジックがあります。

お勧めしないのは、平均して「切り上げ」など、実質バッファを詰むような集計の仕方です。 バッファを詰む事自体を否定はしませんが、バッファはバッファとして、一定のロジックを持って積んだほうが後で振り返りやすいです。

各PBIの見積もりを積み上げる

ここまででPBIごとのストーリーポイントが出たので、単純に積み上げましょう。 これでこの案件全体の見積もりを、ざっくりですが一定の精度を持って出すことができました。

6. リリース時期を予想する

開発チームのベロシティ

ベロシティとは開発チームが1スプリント（「キャリトレ」では1週間）でどれくらいのストーリーポイントを消化できるか、という値です。 この記事の前提となりますが、チームのベロシティがある程度安定していないと、リリース時期を予測することはできません。

単純な割り算ではない

PBIの見積もりの総量が150ストーリーポイントで開発チームのベロシティが15だった場合、単純に割ると10週後にはリリースできる計算となります。 しかし、そう単純にはいかないことも多いので、以下に考慮すべきポイントを挙げてみます。

ⅰ. 開発チームがその案件にかけられる工数の割合

一定期間、その案件に集中して開発を進めると決めたとしても、たいていの場合、別の小規模案件が差し込まれたりします。 スプリントごとにどの程度差し込まれそうか、というのは、これまでの開発チームの歴史を振り返るとだいたい分かるのではないでしょうか。 MAXのベロシティから、その分は差し引いて考えたほうが良さそうです。

ⅱ. タスクの依存関係

全エンジニアの開発工数を、一斉にその案件に当てられるかというと、そうでもない場合があります。 タスクAが完了していないとタスクB,C,Dができない、といったこともあるはずです。 各PBIを俯瞰して、どのあたりに依存関係がありそうか確認してみましょう。 特に開発着手して間もない時に、そういった依存関係が多いような気がします。

ⅲ. リリースに必要なタスク

「キャリトレ」の場合、リリースの前にはシナリオテストを実施しています。また中規模案件の場合は、該当案件の通しのテスト、というのも実施しています。 その他にも、外部システムとの接続がある場合は、先方がテストする期間も確保する必要があります。開発が全て完了していても、リリースに必要なタスクが完了していないとリリースできません。 それらの期間も加味してリリース予想時期を算出しましょう。

まとめ

ここまでの内容を整理しつつ、もう少し抽象化した内容に触れたいと思います。

alt text

リファインメントに限らず物事を推進するときにはinput -> process -> outputを意識することが重要だと考えています。 上記の図はここまで話してきたことをその観点でまとめたものです。

何かをoutputするのに必要なinput

当たり前ですが、何かをoutputしたい時には、何かのinputがないとできません。 outputしたいものを後ろから考えて、どういったinputが必要なのか事前に整理しておきましょう。 例えば一定の精度で見積もりをoutputするためには「仕様」と「実装方針」のinputが必要だということを述べました。

では「ユースケース」をinputに「ユースケースごとの詳細仕様」をoutputするのに、他にはどういったinputが考えられるでしょうか？ 仮にその組織でQAが一番全体の仕様に詳しいとすると「QAの知見」なども有益なinputになるかもしれません（他機能との整合性の観点が手に入りそうです）。 何か上手くリファインメントを進められないな…となったときはシンプルに「どんなinputがあれば進められるのか？」を考えると良いと思います。

processを効率化する

processについて本記事ではあまり詳しく語っていませんが、ここを効率よくやらないと、いつまで経っても見積もりが終わりません。 5W1Hでいうと、whyは要求、whatがinputとoutput、それ以外のwho, when, where, how 全てprocessですね。 「ユースケース」から「ユースケースごとの詳細仕様」をoutputするために、例えばこんなprocessが考えられます。

  1. 1人のエンジニアが「詳細仕様」のたたき台をスプレッドシートで作る
  2. 複数のエンジニアでそのたたき台を非同期にupdateする
  3. ステークホルダーと打ち合わせで合意する

組織の都合や案件に合わせて、どのように進めるのが効率的かを検討しましょう。

終わりに

「キャリトレ」の開発チームは「いつリリースできるのか？」という問いに、少しずつ上手に答えられるようになってきました。 リファインメントの推進方法について、一定の「型」ができてきたかな、という印象をもっています。 本記事では書ききれなかった細かい話や、実装着手後の進捗のモニタリング手法など、「キャリトレ」で実践していることは他にもありますので、 もう少し詳しく話を聞きたいという方は、是非お気軽にご連絡ください。

未来の仲間に

私は10年以上、SIerに勤め、今の会社に入社しました。 様々な技術に触れながら、モノづくりを純粋に進められる今の環境がとても気に入っています。 弊社に限らず、同じようなキャリアを検討されている方は是非、ご連絡ください。 転職後のイメージなど、いろいろとお伝えすることができるかと思います。

  1. ちなみに私の前職はSIerで、もっぱらウォーターフォール開発でやってました。FP法などを使って年単位の見積もりを精緻に？実施していた記憶があります。 ↩︎

  2. 参考文献 More Effective Agile 第20章「より効果的なアジャイル：予測可能性」 ↩︎

中瀬 貴晴
中瀬 貴晴

もっと技術をやりたいという想いからSIerからビズリーチへ転職。子供とバスケの1on1をすることが一番の楽しみ。