こんにちは。LayerX バクラク事業部 バクラクビジネスカード開発チームEMの @shnjtk です。新しいMacBook Proがとても気になっています。スペースブラックいいですね。欲しい。
この記事は LayerXテックアドカレ 13日目の記事です。前回は @itkq による 情報の流通性を上げコミュニケーションを活性化させるNotionデータベース でした。次回は @yossylx が担当します。
今回は、開発チームの開発速度をどのようにして測るかということについてお話します。
ストーリーポイントによるベロシティの計測
ストーリーポイント（SP）とは、アジャイル開発において、開発しようとするユーザーストーリーや機能、その他のタスクの大きさを表す見積もりの単位であり、タスク同士の相対値で表現されます。例えば「この機能はSP 3」、「この機能はSP 5」のように使われます。タスクの完了にかかる実時間（○時間、○日など）ではなく相対値であるというのがポイントで、1、2、3、5、8といったフィボナッチ数が使われることが多いと思います。
1スプリント期間中に完了できたタスクのSPを合計することでベロシティを算出できます。ベロシティとは、開発チームが1スプリント期間中に対応できるタスク量、言い換えると開発速度を指します。スプリントごとにベロシティを算出することで、新たにスプリントを始めるときに、その期間中でどの程度のタスクを完了させることができそうかという見積もりの精度を上げることができます。
LayerXが開発で大事にしていること
私がいるバクラクビジネスカード開発チームでも、以前はSPを使ってタスクの見積もりを行っていましたが、なんとなくモヤモヤを感じていました。それは何なのかを考えてみたところ、LayerXが開発で大事にしていることとあまりマッチしていないのでは、という結論に至りました。
事業部CTO/CPOの @mosa が書いた 開発速度が速い #とは というスライドで説明されていますが、LayerXでは、機能の開発（アウトプット）が速いことではなく、顧客への価値提供（アウトカム）が速いことを重視しています。
これを前提として開発チームの開発速度について改めて考えてみると、測るべきは1スプリントにおいてどの程度のタスクを完了できたかではなく、どの程度のアウトカムを創出できたか、ではないかと思いました。
スプリント運用の改善
この考え方にもとづいて、スプリント運用の改善を検討しました。私のチームではNotionを使ってお客様からのご要望やバックログ、スプリント期間中のタスクの管理を行なっています。 最初に、使用するNotion DBの全体像を示します。
- ご要望DB
- 顧客企業様からのご要望のリスト
- 既に存在するものと同じ内容のご要望であっても、異なる企業様からのものであれば新規に登録する
- Backlog
- いただいたご要望のうち、開発対象となったもののリスト
- 1つのバックログに対して複数のご要望を紐付けることができる
- Sprint Board
- スプリント期間中に開発するタスクのリスト
- 1つのバックログを複数のタスクに分割することがある
ポイントは1つのバックログに複数のご要望を紐付けている点です。例えば、「リストを日付でソートできるようにしてほしい」というご要望を3社の企業様からいただいた場合、バックログとしては「リストを日付でソートできるようにする」という1件だけが作成されますが、そのバックログには3つのご要望が紐付いているため、このバックログ（機能）は何社の企業様から求められているかというのがすぐに分かるようになっています。
バックログのアウトカムを定義する
バックログの各項目について、アウトカムを数値で表現できるように定義します。式は以下のようになります。
バックログのアウトカム = (要望企業数 / 開発工数) * インパクト
開発工数は以下の5種類を定義しています。
| 開発工数 | 内容 |
|---|---|
| 1 | 半日程度 |
| 2 | 1~3日程度 |
| 3 | 5日程度 |
| 4 | 10日程度 |
| 5 | 1スプリント以上かかる。見積もり困難 |
「インパクト」とは、その機能が提供されることでお客様に与える影響度を示します。現在は以下のような項目を定義しています。
| 項目 | 値 |
|---|---|
| その機能を利用できるユーザー権限の数 | 1ユーザー権限あたり +15 |
| 運用で代替もしくは回避可能かどうか | 代替や回避不可なら +20、可能だが大変なら +10 |
| 発生頻度（機能が必要とされる頻度） | 該当する操作が週に数回以上発生するなら +10 |
| 事故誘発の可能性 | その機能がないことでオペレーションミスなどの事故を誘発しそうなら+30 |
この式の意味するところは、多くの企業様から求められていて、開発工数がそれほどかからず、お客様に与えるインパクトが大きいものほど大きなアウトカムになる、ということになります。お客様に与えるインパクトと、開発の投資対効果が考慮されている点が特徴です。
先ほどの例に沿って、「リストを日付でソートできるようにする」という機能のアウトカムについて考えてみます。
まず、開発工数については半日程度で完了できる見込みであるとして 1 とします。
次に、インパクトについて各項目の値を検討します。
その機能を利用できる権限が管理者・経理担当・一般ユーザーの3つであるとして +45 となります。
運用で回避可能かどうかという点については、仮にリストのCSV出力機能があり、CSVに出力した後で手元でソート可能であれば代替は可能であると言えます。なお、もしCSV出力機能がなければ、画面に表示されているものをスプレッドシートなどに手作業でコピペしてソートするなどが考えられますが、この場合は作業が大変なので +10 となります。
発生頻度について、この作業を毎日行う場合は週に数回以上発生するため +10 となります。
事故誘発の可能性については、例えば上述したようにCSVに出力してからソートする場合、CSVファイルが古く最新の情報が反映されていないまま作業を行なってしまうことで誤った処理や意思決定をしてしまうことが考えられるため、事故を誘発しそうであるということで +30 とします。
以上より、この機能のインパクトは 45 + 10 + 30 = 85 となります（CSV出力機能ありとして算出）。 これらの値をもとにこの機能のアウトカムを計算すると、 要望企業数 : 3、開発工数 : 1、インパクト : 85 であるため、 3 / 1 * 85 = 255 となります。
NotionのBacklogでは、要望企業数、開発工数、インパクトのそれぞれをプロパティとして用意しているため、値を入力すれば自動的にアウトカムが計算されるようになっています。
各スプリントで創出したアウトカムを算出する
ここまでくれば後はシンプルです。
各スプリントで完了したバックログのアウトカムを合計すれば、そのスプリント期間中に創出できたアウトカムが分かりますので、これを開発チームの開発速度の指標として用いることができるようになります。
ご参考までに、NotionでBacklogを作成したところをお見せします。なお、記載されている内容は実際のBacklogとは異なり、本記事用のサンプルデータとなります。
ここでは「要望企業数」「開発工数」「インパクト」はそれぞれ単純な数値入力としていますが、実際には「要望企業数」は Rollup を使ってBacklogに紐付いているご要望の数を自動的にカウントするなどの工夫を行なっています。
「アウトカム」には Formula を使っています。式は下図のようになります。
このような構成にすることで、完了のチェックが入っているものをフィルタしてアウトカムの合計値（SUM）を算出すれば、そのスプリントで創出できたアウトカムがどの程度なのかが分かるようになります。
余談ですが、1つのバックログに複数のご要望企業様を紐付けることで、その機能がリリースされたときに、ご要望をいただいていた企業様を特定し個別にご案内することができるようになります。
おわりに
今回は、アウトプットではなくアウトカムにもとづいてチームの開発速度を測る方法についてご紹介しました。 アウトカムを算出するための元となる項目や値についてはまだまだ調整する余地はありますが、開発工数ベースではなくお客様への提供価値ベースで開発チームのパフォーマンスが測れることはLayerXの開発組織のカルチャーともマッチしていて、個人的にはモヤモヤが解消されてしっくりきています。
アジャイル開発の基本的なところは踏まえつつ、こういった形で自社のカルチャーに合わせたカスタマイズを施していくのはこれまであまりやったことがなかったため、良い経験になりました。この記事を読んでくださったみなさんもそれぞれ工夫しながら開発に向き合っていらっしゃると思いますので、「もっと詳しく聞きたい」とか「自分たちはこうしている」といったご質問やご意見がありましたらぜひカジュアルにお話しましょう！
おまけ
LayerXオフィスでドリンクを楽しみながら、技術や開発などの話をゆる〜く行うイベントを企画しています。 今月は 11/22 (水) に開催します。私も参加予定ですので、よければお気軽にご参加ください。
2023-11-21 追記
思いがけず反響をいただき、まずは読んでくださった方々に感謝です。どうもありがとうございます。 「技術的負債の解消どうしてるの？」とか「顧客には影響ない改善系のタスクやれなくない？」という感じのコメントをいただいたので、そのあたりについて補足させていただきます。
私のいるチームでは、上記のような技術的負債の解消や改善系のタスクは、Backlogに「改善」というタグをつけて積んでいます。 そして、毎月「改善デー」という名の、その日1日は通常の開発タスクを止めて、Backlogに積んでおいた改善系タスクを集中的にやりましょうという日を設けており、ここで負債の解消や改善に取り組んでいます。
もちろんその日にしかやらないわけではなく、日々の開発の中でも、「これは今やっておいた方がいい」というものがあれば、改善デーを待たずに対応することもあります。 そうすると、そういうタスクのアウトカムはどうなるの？というのが気になるところだと思いますが、現状ではこういったタスクにはアウトカムの値はついていません。
チームとしては、ただアウトカムという指標だけを追いかけているわけではなく、常にアウトカムと品質のバランスを考えています。 スプリントの中で改善系のタスクの消化が増え、アウトカムが減ってきたとすると、それは品質面において黄信号であると言えると思います。そういう場合は、アウトカムよりも品質の向上に向けて、スプリントの中で取り組むタスクとして改善系のタスクを増やしたりするなど、臨機応変に対応しています。
一方で、コメントでもご指摘いただいたとおり、プロダクトやコードの品質を表す指標として、改善系のタスクにも何らかの指標はあった方がいいとも思っていますので、ここは次に向けた課題であると感じています。 こういった考え方や取り組みについて、共感していただける方、話したい！、アイデアあるよ！と言ってくださる方はぜひお話ししましょう！
