詳細ガイド
QAとスプリントのボトルネック・シミュレーター:開発がテスト能力を追い越すとき
業界のエグゼクティブ分析
ソフトウェアチームはパイプラインであり、パイプラインは最も遅い段階より速くリリースすることはできません。開発者がテスターの検証できる数より多くの機能を完成させると、余った仕事は消えず、待ち行列に加わります。管理者は、忙しそうな開発者と、スプリントボードがいっぱいなのを見て、チームは生産的だと判断します。しかし、構築されてもテストされていない機能は何も稼いでおらず、待つ週ごとに価値を失います。その状況で開発者を増やすと、人件費と待ち行列の長さが同時に増え、リリースされる成果は全く変わりません。
この問題の構造は、二つの速度の差にあります。開発者の出力は、開発者の人数に、各自が完成させる機能数を掛けたものです。QAの対応能力は、テスターの人数に、各自が検証できる機能数を掛けたものです。リリースされる機能は二つのうち小さいほうで、その差が待ち行列の増える速度です。待ち行列は月ごとに積み上がるため、そのコストは一定ではなく、積み重なっていきます。わずかに能力を超えているチームは、最初のスプリントでは問題なく見えても、6回目には明らかに破綻しており、だから問題は大きくなるまで見過ごされやすいのです。
ドミノ効果は、その順序を示します。開発者の出力が高いと、要求されるQAの対応能力の割合が100%を超えます。その負荷が待ち行列を伸ばし、後ろに並ぶすべての機能を遅らせます。待つことは直接価値を損ない、さらに、バグ修正や質問を通じて開発者を古い作業に引き戻すため、開発者の時間がコンテキストスイッチで失われます。過負荷のテスターは急ぐので、不具合がすり抜けます。各段階が次の段階に影響するので、二番目の枠での小さな過負荷が、数回のスプリントで最後の枠を赤くすることもあります。
氷山は、人件費とボトルネックのコストを切り分けます。水面の上にあるのは、誰もが目にする開発者とQAの給与です。水面下には、項目としてほとんど現れない四つのコストがあります。機能が待つ間に失われる価値、テストが急がれたために顧客に届いたバグのコスト、コンテキストスイッチで失われる開発者の時間、そして過負荷のもとでテスターが行う残業です。これらを合わせると、それらを解消できたはずの追加のテスターのコストを上回ることもあります。シミュレーターを使って、パイプラインが採算に合わなくなる開発者とQAの比率を見つけ、テスターを追加する場合と比べましょう。
計算式と方法論の設計図
このモデルは、定常状態で月単位に計算します。開発者の出力は、開発者の人数に各自の機能数を掛けたものです。QAの対応能力は、テスターの人数に各自の機能数を掛けたものです。リリースされる機能は、二つのうち小さいほうです。待ち行列は毎月その差の分だけ増え、6か月の期間における平均の待ち行列は、その増加分の6倍の半分です。遅延コストは、平均の待ち行列に遅延のコストを掛けたものです。開発者は、待ち行列の機能一つにつき時間の1%をコンテキストスイッチで失い、上限は20%です。すり抜ける不具合は、過負荷に応じて増加します。
- 開発者の出力
- P = 開発者数 × 開発者一人あたりの機能数
- 毎月完成してQAへ渡される機能数です。
- リリースされる機能
- S = min(P, テスター数 × テスター一人あたりの機能数)
- パイプラインがリリースできるのは、テストが検証したものだけです。
- 待ち行列
- Q = max(0, P − 対応能力) × 3
- 待ち行列は直線的に増えるため、6か月の期間にわたって待つ機能の平均数です。
- すり抜けのコスト
- E = S × (3% + 15% × 過負荷) × 4,000
- QAが過負荷になるほど顧客に届く不具合は増え、一件あたり4,000のコストがかかります。
- パイプラインの結果
- Net = S × 価値 − 人件費 − Q × 遅延コスト − E − コンテキストスイッチの負担 − QAの残業
- 月間の結果です。損益分岐の負荷は、これがゼロになる点です。
連鎖する弾力性
開発者の出力とQAの対応能力の差は、待ち行列、遅延、コンテキストスイッチ、すり抜けを同時に引き起こすため、最も感度の高い要因です。機能一つあたりの価値は、リリースされる成果に直接比例します。人件費は線形に効き、しきい値として働きます。だからこそ、テスターを一人増やすと、そのコストの何倍も元が取れることがよくあります。
実例に基づく3つのケーススタディ
自己資金で始めるスタートアップ
3人のプロダクトチーム
開発者3人とテスター1人が小さな製品に取り組んでいます。開発者は月に6機能を完成させ、テスターは7機能を検証できるので、待ち行列は生じません。構築とリリースが等しく、解消すべきボトルネックのない、バランスのとれた小さなチームを、読み込んで確かめましょう。
成長中の中堅企業
バランスのとれた開発者24人の組織
大きな組織が、開発者24人に対してテスターを7人置き、自動化にも投資しているため、QAは開発者の出力をわずかに上回っています。待ち行列は最小限で、リリースされる価値は高くなります。健全な比率が、なぜ大きなチームの収益を保つのかを、読み込んで確かめましょう。
ブラックスワン級の危機
開発者10人と、過負荷の2人のテスター
速い開発者10人が月に30機能を完成させますが、テスター2人が検証できるのは10機能だけです。待ち行列は月に20機能ずつ増え、バグはすり抜け、開発者は古いコードに戻り続けます。比率の問題が、大きな人件費を損失に変えてしまう様子を、読み込んで確かめましょう。
業界ベンチマーク一覧
| 指標 | 危険ゾーン | 業界平均 | 上位10%のエリート水準 |
|---|---|---|---|
| テスター一人あたりの開発者数 | 8:1超 | 3~5:1 | 自動化を伴う2~3:1前後 |
| QAの負荷(対応能力に対する開発者の出力) | 130%超 | 90~105% | 90%未満 |
| テストを待つ平均の待ち行列 | 10機能超 | 2~4機能 | 2機能未満 |
| リリースごとに本番環境へすり抜ける不具合 | 10%超 | 3~6% | 2%未満 |
| 完成からリリースまでのサイクルタイム | 4週間超 | 1~2週間 | 3日未満 |
変数とレバー
開発者
機能を構築するエンジニアです。開発者が増えると出力は増えますが、テストの速度は上がりません。
レバー: テストの対応能力が増えるまでは開発者を増やさないようにしましょう。仕掛り中の作業に上限を設ければ、完成は減っても、リリースは増えます。
開発者一人あたりの月間完成機能数
一か月に開発者が完成させ、QAへ渡す機能の数です。
レバー: スプリントで着手する機能は、QAが検証できる数に絞りましょう。完成していてもテストされていない仕事は、何も稼ぎません。
QAテスター
リリース前に機能を検証する人員です。
レバー: テスターを増やすか、テストエンジニアをチームに組み込みましょう。テスターが一人増えるごとに、いま待っている機能のまとまりが解放されます。
テスター一人あたりの月間検証機能数
一人のテスターが一か月で、完全にテストし、再テストし、承認できる機能の数です。
レバー: 回帰テストを自動化し、受け入れ基準を事前に書いておきましょう。そうすれば、テスターは古い確認の繰り返しではなく、新しい仕事の検証に専念できます。
リリースされた機能の価値
機能がユーザーに届いたときにもたらす、売上、定着、または削減額です。
レバー: 機能は価値によって優先順位をつけ、価値の低いものはやめましょう。テストの対応能力は、待ち行列に入ったものすべてに費やされます。
機能一つあたりの月間遅延コスト
待ち行列で待つ月ごとに、各機能が失う売上や顧客からの信頼です。
レバー: より小さな増分をより頻繁にリリースしましょう。すべての機能の待ち時間が短くなり、遅延のコストも下がります。
このシミュレーターの使い方
- 1開発者の人数と、各自が一か月に完成させる機能数を入力します。
- 2テスターの人数と、各自が検証できる機能数を設定します。
- 3リリースされる機能の価値と、機能一つあたりの月間遅延コストを見積もります。
- 4五つのドミノを見て、QAの負荷が100%を超える時点を確認します。
- 5「パラレルワールド」タブでテスター追加の計画と比較し、リンクを共有します。
避けたい間違い
- 完成した機能の数で開発者を評価することです。テストを待っている仕事は成果ではなく、在庫です。
- 長期間で平均することです。毎月増える待ち行列は、初めは小さく見えても、後には大きくなります。
- テスターを削るべきコストとして扱うことです。ボトルネックにおいては、テスターの対応能力こそがパイプラインで最も価値のある対応能力です。
- 遅延のコストだけを数えることです。すり抜けたバグとコンテキストスイッチは、それを上回ることがよくあります。
よくある質問
なぜ開発者を増やしてもリリースされる成果は増えないのですか。
リリースは最も遅い段階によって上限が決まるからです。追加の開発者はQAの前の待ち行列を増やすだけで、リリース速度は上げずにコストだけを上げます。
開発者とテスターの比率だけで計画を立てて十分ですか。
出発点にはなりますが、役に立つ比較は、出力と対応能力の比較です。自動化、要件の質、製品の種類によって、比率は大きく変わりえます。
遅延のコストはどう見積もりますか。
待っている機能一つあたりの月間の損失として、失われる売上、定着、信頼で見積もります。前提なので、低い値と高い値の両方を試して、どちらが支配的かを確かめてください。
なぜ過負荷になると不具合が増えるのですか。
急かされたテスターは、ケースを飛ばし、再確認が減ります。モデルは、需要が対応能力をどれだけ超えているかに比例して、すり抜けを加えます。
テスター追加のシナリオは何を示しますか。
テスターをもう一人増やして回帰テストを自動化する効果を示します。QAの対応能力が上がり、たいていは待ち行列が解消されます。24か月のタブで、いつ元が取れるかがわかります。
どれくらい正確ですか。
示した前提に基づく学習用の計画モデルであり、エンジニアリングや財務の助言ではありません。入力はご自身のスループットとコストのデータに置き換えてください。
これは前提条件を明示した、教育目的の計画モデルです。財務、税務、法律に関する助言ではありません。入力値はご自身の数字に置き換え、重要な判断は必ず資格を持つ専門家に確認してください。