ラボ契約とは？ラボ型開発のメリット・デメリットと請負との違い

台所の蛇口から、水が一滴ずつ垂れるようになりました。

中のゴムの部品を1個だけ買ってきて替えたら、その日のうちに止まりました。

20日ほどして、今度は洗面所の蛇口が同じ音を立て始めます。また1個買ってきて、また替えました。

次は風呂。3回目にホームセンターのレジへ並んでいるとき、ようやく気づきました。家じゅうの蛇口は、同じ年に、同じ型で、まとめて取り付けられていました。

この蛇口の話は、開発の依頼にも重なります。開発を社外のチームに任せる会社が、この数年で増えてきました。なかでもラボ型開発は、月ぎめで開発チームの席を確保して、要件（作ってほしい機能や条件）はそのつど渡す契約の形です。1件ずつ見積もって発注するのではなく、期間で人を押さえます。押さえた時間が、そのままひと月の枠になります。

僕も、1つのプロダクト（製品・サービス）の開発をラボ型開発で1年ほど進めて、失敗しました。同じ型の不具合が、場所を変えて4回出ています。 月ぎめで確保した枠のうち3割が、こうした計画外の直しに消えていました。

先に一行だけ置きます。ラボ型開発では、依頼に書いた範囲より外を、チームは見ません。 不具合の出た1画面ぶんを渡せば、直るのもその1画面だけです。

この話に出てくる事業

大企業と僕の会社が共同事業として立ち上げたプロダクトのひとつに、店舗向けのシフト管理SaaSがあります。この事業で、僕の会社はシフト管理SaaSを開発する役割です。SaaSは、ソフトを売り切るのではなく、使っているあいだ月額を払ってもらう売り方のことです。飲食チェーンや小売の店舗で、店長がアルバイトの勤務希望を集め、勤務表を組み、月末に勤怠を締めるところまでを1つの画面でやります。

契約は店舗ごとの月額なので、解約率（契約店舗のうち解約した店舗の割合）がそのまま売上に効きます。

解約が決まった店舗には、解約時の引き継ぎという業務が残ります。引き継ぎを担当する店長が、過去の勤務表と従業員の名簿を1つのファイルに書き出して（エクスポートして）、乗り換え先の別のサービスへ渡す作業です。この書き出したファイルを引き継ぎ書と呼んでいて、表紙には、引き継ぎを担当した店長の名前が入ります。

このプロダクトの開発を、ラボ型開発で回していました。月ぎめで4名ぶんの席を押さえ、依頼内容や条件を依頼票に書いて渡す。返ってきたものを確認して、また次を渡す。

今日は、その渡し方をどう変えたか、という話をしていこうと思います。

前置きはさておき、本題に入ります。

① 教科書どおりに、月ぎめで開発チームの席を確保した

ラボ型開発（ラボ契約）とは

ラボ型開発とは、一定期間、開発チームの席を確保して、その期間に対して支払う契約形態です。作るものごとに発注するのではなく、人と時間を先に押さえます。

契約の性質としては準委任（履行割合型）に当たります。詳しくは準委任契約とは？請負との違い・2つの類型と契約時の注意点に整理しています。

ラボ型開発は、海外とは限らない

「ラボ型＝オフショア」と説明されることが多いのですが、契約の形と、場所の話は別です。海外にチームを置くオフショアと組み合わせる例が多いだけで、国内でも成立します。混同すると、比較の軸がずれます。

ラボ型開発が注目される背景

国内でエンジニアを採用しても集まらず、案件ごとに外注するとそのたびに見積もりと発注の手間がかかる。この2つが同時に効いてきたのが背景です。

作りたいものが最初に決まらない開発が増えたことも大きいです。決まらないものを「完成」で発注できないため、期間で確保する形が選ばれます。

チーム体制はどうなるか

一般的には、開発者数名に加えて、進行を管理する役割と、日本側とやりとりする役割（海外なら通訳またはブリッジSE）が付きます。

体制図で確認すべきなのは人数ではなく、「日本側の誰が、現地の誰に、何を渡すのか」の線です。ここが曖昧なまま始めると、渡す仕事を作る負荷が全部発注側に戻ってきます。

メリット1｜一定期間、人を確保できる

案件ごとに人を探す手間が消えます。採用と違って、期間が終われば体制を縮められます。開発量が読める時期には、この確保のしやすさが効きます。

メリット2｜人件費を抑えやすい

海外に置く場合、国内より低い単価で同等の工程を任せられます。ただし、下がるのは単価であって総額ではありません。進行管理と、渡す仕事を作る工数は別途かかります。

メリット3｜仕様変更の見積調整が要らない

ここが本体です。請負では仕様変更のたびに見積もりが動きますが、ラボ型では動きません。変更は「追加見積もり」ではなく、確保した時間をどう使うかの問題になります。

費用が変わらないのではなく、費用の決まり方が変わります。作りながら決めたい開発ほど、この差が効いてきます。

メリット4｜ノウハウが蓄積する

同じチームが継続するため、業務知識やシステムの前提が引き継がれます。案件ごとに人が変わる形だと、毎回同じ説明からやり直しになります。長く続く開発ほど、この差が積み上がります。

デメリット1｜一定量の発注が必要になる

席を確保している以上、渡す仕事が無くても費用は発生します。発注量が月によって大きく上下する場合、空いた時間ぶんが損になります。

デメリット2｜チームの立ち上げに時間がかかる

業務の前提、既存システムの構造、品質の基準を共有するまでに時間が要ります。最初の数か月は、期待した生産性が出ません。この立ち上げ期間を織り込まずに費用対効果を測ると、早すぎる段階で失敗と判断してしまいます。

デメリット3｜費用対効果が低くなりやすい

立ち上げの固定費があるため、短期・小規模では回収できません。半年以上の継続が見込めるかどうかが、ひとつの目安になります。

デメリット4｜発注側がマネジメントを担う

実務でいちばん効くのは、これです。請負では「作るもの」を渡せば済みますが、ラボ型では渡す仕事を作り続ける必要があります。

何を作るか、どの順で作るか、どこまでできたら完了かを決めるのは発注側です。それを決められる人が社内にいるかどうかで、成否が決まります。

デメリット5｜やりとりの負荷がかかる

請負なら成果物を受け取るだけですが、ラボ型では優先度の判断、仕様の確認、完了の確認が毎週発生します。海外に置く場合は、これに時差と言語が乗ります。

やりとりの頻度ではなく、形式を決めておくのが要点です。動くものを見る間隔と、質問への返答期限を先に決めます。

デメリット6｜始める前の準備が要る

席を確保した初日から渡せる仕事が無いと、その期間は空きます。着手時点で最低でも数か月ぶんの依頼が見えている必要があります。既存システムの構造、テスト環境、判断できる担当者の3つも、開始前に揃えておきます。

ラボ型開発と請負型開発の違い

	何に対して払うか	仕様が変わったら	完成の責任
請負	完成した成果物	追加見積もり	受注者が負う
ラボ型	確保した期間	時間の使い方が変わる	どちらも負わない

どちらが安いかではなく、変更のリスクをどちらが引き受けるかの違いです。

ラボ型・請負・準委任の関係

この3つは並列ではありません。請負と準委任が法律上の契約類型で、ラボ型はその準委任（履行割合型）を「チームを期間で確保する」形に運用した呼び名です。

	法律上の類型	何を買っているか
請負	請負契約（民法632条）	完成した成果物
準委任	準委任契約（民法656条）	事務の遂行
ラボ型	準委任（履行割合型）の運用形態	チームの時間

契約書の表題が「ラボ契約」でも、中身が請負か準委任かは条文で決まります。完成義務が書かれていないかを確認してください。

ラボ型開発とSESの違い

どちらも準委任で、人と時間に対して支払う点は同じです。違いは指揮命令と、チームの単位にあります。

	働く場所と指示	チーム
ラボ型	受注者側の拠点。指示は受注者の管理者を通す	チーム単位で確保する
SES	発注者の現場に入ることが多い。指示系統は契約による	個人単位で調達する

発注者が受注者の作業者へ直接指示を出すと、実態が労働者派遣に近づきます。どちらの形でも、ここは契約書の表題ではなく実態で判断されます。

国内ラボと海外ラボの違い

	単価	やりとり
国内ラボ	下げ幅は小さい	同じ時間帯・同じ言語。確認が速い
海外ラボ	大きく下がる	時差と言語のぶん、往復に日数がかかる

海外に置く場合の詳細はオフショア開発とは？メリット・デメリットと委託先国の動向に整理しています。

ラボ型開発に向いている案件

• 既存サービスの継続的な運用・改修
• アジャイル型で、優先度を入れ替えながら進める開発
• 仕様が動く前提のプロダクト開発
• 長期にわたって手を入れ続けることが決まっているシステム

共通するのは、「作るものが最初に決まらない」という点です。決まらないことが前提なら、決めてから発注する請負とは噛み合いません。

ラボ型開発に向いていないケース

• 仕様が固まった、一度きりの開発
• 発注量が月によって大きく上下する
• 半年以内に終わる見込みの案件
• 発注側に、何を作るかを決められる人がいない

最後の1つが、いちばん見落とされます。席を確保しても、渡す仕事が用意できなければ、確保した時間は別のことに使われます。

ラボ型開発を依頼するときに確認すること

確認すること	確認しないと
目的と、発注計画の見込み	空き時間が出て、費用対効果が読めなくなる
やりとりの体制と頻度	確認の往復が滞り、手戻りが増える
開発実績と、技術者の定着率	人が入れ替わるたびに前提の説明をやり直すことになる
成果物の権利の帰属	納品物を自社で改変・再利用できない
契約終了時の引き継ぎ範囲	終わったあとに動かせるものが残らない

権利の帰属と引き継ぎ範囲は、開始時に決めておかないと後から変えられません。

ラボ型開発の導入手順

段階	やること
1. 目的と発注量の見込みを出す	何のために、どれくらいの量を、どれだけの期間出すのか
2. 委託先を選ぶ	実績・定着率・やりとりの体制で見る。単価表の順に選ばない
3. 契約を結ぶ	期間、人数、権利の帰属、検収、再委託、引き継ぎ範囲を決める
4. チームを立ち上げる	業務の前提と既存システムの構造を渡す。ここに数か月かかる
5. 依頼票を回し始める	渡す単位と、完了の基準を決める
6. 定期的に見直す	発注量と成果を突き合わせ、体制を増減する

4を短く見積もると、最初の数か月を「遅い」と誤解します。立ち上げ期間は費用対効果の計算に最初から入れておきます。

契約期間・人数と、費用の考え方

契約期間は半年から1年で結ぶことが多く、短いほど立ち上げの固定費を回収しにくくなります。

費用は「人数 × 月額単価 × 期間」で決まります。請負と違い、作った量ではなく確保した量で決まるのが要点です。だから、渡す仕事が用意できているかが費用対効果を左右します。

人数は、最初から多く確保しないほうが安全です。渡せる仕事の量が見えてから増やすほうが、空きが出にくくなります。

ラボ型開発を成功させるポイント

ポイント	具体的にやること
スモールスタートにする	少人数・短期間で始め、渡せる量が見えてから増やす
目的と発注計画を先に決める	何を、どれくらい出し続けるのかを数字で置く
やりとりの形式を決める	頻度ではなく形式。動くものを見る間隔と返答期限
渡す単位を統一する	画面単位か、機能単位か、原因単位か。混ぜない
進捗を数字で追う	「順調です」を受け取らない。完了した票の数で見る

4つ目が、この記事の後半の主題です。

ラボ型開発の始め方は、素直に教科書どおりにやりました。

教科書に載っている手順は3つあります。期間で席を確保すること、要件を固めきらずにそのつど渡すこと、優先度の高いものから順に流すことです。仕様（機能の内容や動き方）が変わる前提の事業なので、1件ずつ見積もる形よりも合っていました。

そして、ちゃんと速くなりました。最初の3か月で、依頼票を書いてから画面に反映されるまでが平均2日です。1件ずつ発注していたころは、見積もりのやり取りだけで5日かかっていました。

依頼票の書き方も、教科書どおりにしました。1枚に1つの画面。誰がどの画面で何をして、何が起きてほしいか。テスト用のアカウントと、不具合を同じ状態で起こすための再現手順まで書いて渡します。

チームの動きも良かったです。渡した票は、たいてい翌日には着手されていました。この段階では、ラボ型開発の進め方を間違えたという感覚はまったくありませんでした。

ここまでが、ラボ型開発の教科書どおりの整理です。仕様が動く前提の開発では、この形が噛み合います。

この記事の後半で扱うのは、噛み合った後の話です。確保した時間が、何に使われていたのか。

ラボ型の体制を実際の案件で組む話は、Global AI Lab（オフショア・ラボ型開発）のページに整理しています。依頼票の切り方から設計したい場合は、こちらからご相談ください。

② 月ぎめで確保した時間が、同じ不具合の直しで埋まっていった

ところが、解約時の引き継ぎ書を作り込んでいるうちに、様子がおかしくなってきました。

最初に出たのは、小さな不具合です。書き出したファイルの表紙に、店長の名前ではなく「未設定」という文字が入っていました。

原因はすぐ分かりました。引き継ぎ書を書き出す時点で画面に出ている店長名を、文字としてファイルに写し取り、そのまま固定していたからです。招待リンクから入った店長は、名前をあとから登録します。書き出しの時点でまだ登録されていなければ、写るのは「未設定」の3文字です。

つまり「あとから登録された名前は、二度と伝わらない」という状態でした。表紙に写された「未設定」は、そのまま固まります。

依頼票を1枚書いて渡しました。引き継ぎ書の表紙について、名前をその場で引き直すように直してもらう。1日で直りました。

17日後、名前まわりをまとめて直す依頼を出しています。登録した名前を過去の記録へ流し込む処理と、すでに固まった記録をまとめて直す一括修復です。返ってきた変更の量は177行あり、1枚の票で頼む直しとしては大きなものでした。これで終わったつもりでいました。

このとき票に書いた条件は1つだけです。「直すのは空と『未設定』だけで、人が手で入れた名前には触らない」。気にしていたのは、どこまで直すかではなく、直しすぎないことでした。

その11日後、引き継ぎ書の表紙に「未設定」が固まる不具合がまた起きます。

③ 気づいたのは、直していない穴が「分かったうえで残っている」と書かれていたときでした

再発した日のことは、よく覚えています。

朝いちばんに届いた報告は、引き継ぎ書の表紙がまた「未設定」で固まっている、というものでした。前の月に直したはずの画面です。

再発時の修正で引っかかったのは、返ってきた変更に添えられた説明です。依頼票を書いて渡すと、不具合はその日のうちに直りました。返ってきた変更の量は207行で、11日前にまとめて直したときより大きくなっています。説明には、チームが把握している未改修の箇所が残っている、という意味の言葉がありました。チームはその箇所を「既知の未改修穴」と書いていました。

つまり、まとめて直したはずの修正は、1か所を塞いだだけでした。残りの場所は、塞がないまま置かれていたことになります。

そこで、名前が固まる可能性のある場所を、全部数えました。書き出しの表紙だけではありません。シフト確定の通知、月次の勤怠レポート、勤務希望の提出フォーム。「未設定」という文字を書き込んでいる場所は、12件ありました。

再発した日は、3時間42分のあいだに、同じ型の直しを3件渡しています。引き継ぎ書の修正は13時14分でした。その日の午後、続けてあと2件を直しています。16時20分にシフト確定の通知、16時56分に月次の勤怠レポートです。

一括で修復した過去の記録は、引き継ぎ書が6件、通知が10件、勤怠レポートが64件でした。合わせて80件が、間違った名前のまま固まっていたことになります。

そして、「名前」に触った依頼票を数え直したら、28枚ありました。1年かけて渡した票のうち、これだけの依頼票が、すべて1つの項目である店長名の扱いに関する不具合を修正するためのものでした。

④ 原因を1件に絞る

ラボ型開発の進め方を間違えた理由として思い当たることは、いくつもあります。設計をチームに任せきったこと、出来上がった内容を確認するレビューが浅かったこと、テストが画面単位だったこと。

ただ、原因を絞ると1件でした。

依頼票を、画面ごとに書いていたこと。

ラボ型開発で渡すのは、要件そのものではなく票です。そして、票に書いた範囲より外を、チームは見ません。「引き継ぎ書の表紙だけ直してください」と書けば、引き継ぎ書の表紙だけが直ります。

チームの力量の話ではありません。月ぎめで席を確保しているかぎり、開発チームは依頼票を続けて処理します。依頼票を処理しているあいだ、開発チームはその票に書かれていない範囲を調べません。

⑤ 直したのは依頼票の1行だけ

やったことは、依頼票に欄を1つ足すことだけです。

足したのは、「この値の正本はどこにあるか」という1行です。ここでいう正本とは、その値の元として扱う1か所です。不具合を渡すときに、直す場所ではなく、その値がどこから来るべきかを書きます。

引き継ぎ書の表紙なら、正本は店長の登録名です。通知も、勤怠レポートも、提出フォームも、正本は同じ1か所でした。それを票の先頭に書くと、票の題名が「引き継ぎ書の表紙」から「店長名の解決」に変わります。ここでいう解決とは、どの登録名を使うか決めることです。

このとき票の下に、原則を1行だけ添えました。「表示に出ている値を写して保存するのをやめ、正本から引き直す」。

あわせて、月ぎめの枠のうち計画外の直しに何割を使ったかが、月末に1つの数字で出るようにしました。新しく作る作業の票と、直しの票を、分けて数えるだけです。

最初の月に出た数字は、3割でした。

⑥ あとで知った ── 計画外の直しの割合には名前がありました

しばらくして、開発チームの成果を測る方法を長く調べている研究プログラムの資料を読み、手が止まりました。DORA という名前で、dora.dev で公開されているものです。

そこには、開発チームの状態を測る指標が並んでいました。長く使われてきたのは4件です。変更を1つ出すまでにかかる時間、本番（利用者が実際に使う環境）へ出す頻度、壊れてから戻すまでの時間、そして出した変更のうち失敗した割合。その4件に、5件目として deployment rework rate が足されていました。

定義はこう書かれています。「Percentage of deployments that are unplanned work to fix bugs」。計画外の、不具合を直すための作業が、全体の何割かという意味です。

この5件目が足されたのは2024年です。それまで、直しにどれだけ時間を取られているかは、4件目の change failure rate（変更失敗率）から間接的に読むしかありませんでした。この数字は「acted as a proxy for the amount of rework a team must perform」——手戻りの量の代理でしかなかった、と書かれています。だから、手戻りそのものを直接数えることにした、というわけです。

月ぎめの枠の何割が計画外の直しに消えたか。票を分けて数え始めたのは、それを知りたかったからです。新しい理屈は、ひとつも要りませんでした。

⑦ 変えてみて、何が良くなって、何を失ったか

依頼票の1行を変えてから、開発チームから返ってくる修正内容が変わりました。

正本の欄を埋めようとすると、依頼票を書く僕の会社の担当者が先に調べることになります。「この値はどこから来るべきか」を書けない票は、そもそも渡せません。書けない票が出た時点で、それが1画面の不具合ではないと分かります。

計画外の直しの割合は、3割から1割台に下がりました。6か月ぶん見て、いちばん高かった月で13%です。

ただ、代償があります。3件書いておきます。

1件目。票を書くのが遅くなりました。 正本を調べてから書くので、思いついた不具合をその場で流せません。1枚あたり、平均で30分ほど余計にかかっています。

2件目。月ぎめの枠が、見た目には空きました。 直しの票が減ったぶん、チームの手が浮きます。何を渡すかを先に決めていないと、ラボ型開発の枠はそのまま待ち時間になります。実際、切り替えた最初の月は10日ぶんの席を遊ばせました。

3件目。過去の記録は、票を変えても直りません。 固まってしまった80件は、一括修復の依頼を1件ずつ書いて直すしかありませんでした。先に正本から書いていれば、払わずに済んだ代償でした。

⑧ ラボ型開発で票を渡すなら、この3つの欄

依頼票に置いている欄は、3つだけです。

欄	書くこと	書けないときに起きること
正本	その値が、どこから来るべきか	直しても、別の画面で同じ不具合が起きる
同じ型がある場所	同じ値を写して保存している他の画面	1件ずつ、日を分けて直すことになる
過去分	すでに固まっている記録をどうするか	画面は直るが、古い記録は間違ったまま残る

3つのうち、いちばん効くのは真ん中です。同じ型がある場所を先に書き出すと、12件の票が1枚に統合されます。統合された票なら、1回で渡せます。

逆に、真ん中の欄が埋まらない票は、ラボ型開発では流さないほうがよいと思っています。月ぎめの枠は途切れないので、埋まらないまま流すと、翌月に同じ票が別の題名で戻ってきます。

「同じ型がある場所」を先に書くという見方は、扱っているものには依存しません。名前でも、住所でも、税率でも同じです。ただし、この3つの欄が要るのは不具合の直しの票だけです。新しく作る機能の票には、正本がまだ存在しません。そちらは、範囲と目的を書く別の形で渡しています。

⑨ この渡し方が効き続ける理由

チームが入れ替わっても、正本から先に書くという順番は変わらないと考えています。

ラボ型開発で買っているのは時間であって、成果物ではありません。時間を買うと、その時間に何を見るかは、票を書く依頼元が決めることになります。見る範囲は買えません。

そして、同じ型の穴は、たいてい複数の場所に開きます。値を写して保存する作り方は、1つの画面で思いつくものではありません。その事業の初期に1回決まって、あとから12件の画面へ順にコピーされていくからです。

一方で、正本を書く欄は、使う道具が変わっても、頼むチームが変わっても、票の先頭に残ります。残るのは、依頼票の形です。

正本や同じ型がある場所を依頼票に書く設計を、実際のプロダクトに落とす話は、AIプロダクト開発のページに整理しています。ラボ型開発の枠が直しで埋まっている感触があれば、こちらからご相談ください。

蛇口のほうは、まだ2個残っています。トイレの手洗いが、先週から一滴ずつ垂れ始めました。

家じゅう同じ型だと分かっているので、まとめて買えばよいことは分かっています。それでも今日も、1個だけ持ってレジに並びました。

以上です。

▶ この記事のテーマを実務で相談する: AIプロダクト開発

ラボ型開発のよくある質問

ラボ型開発（ラボ契約）とは何ですか？

一定期間、開発チームの席を確保して、その期間に対して支払う契約形態です。作るものごとに発注するのではなく、人と時間を先に押さえます。契約の性質としては準委任（履行割合型）に当たります。

ラボ型開発は海外に頼むことなのですか？

契約の形と、場所の話は別です。海外にチームを置くオフショアと組み合わせる例が多いだけで、国内でも成立します。「ラボ型＝オフショア」と混同すると、比較の軸がずれます。

ラボ型開発のメリットとデメリットは何ですか？

メリットは、一定期間人を確保できること、人件費を抑えやすいこと、仕様変更の見積調整が要らないこと、ノウハウが蓄積することの4つです。デメリットは、一定量の発注が必要なこと、立ち上げに時間がかかること、費用対効果が低くなりやすいこと、そして発注側がマネジメントを担うことの4つです。最後の1つが実務でいちばん効きます。

ラボ型開発と請負型開発の主な違いは何ですか？

請負は完成した成果物に対して払い、仕様が変われば追加見積もりになり、完成の責任は受注者が負います。ラボ型は確保した期間に対して払い、仕様が変われば時間の使い方が変わるだけで、完成の責任はどちらも負いません。

ラボ型開発は、どのような案件に向いていますか？

既存サービスの継続的な運用・改修、アジャイル型の開発、仕様が動く前提のプロダクト開発に向いています。逆に、仕様が固まった一度きりの開発、発注量が読めない場合、そして発注側に何を作るかを決められる人がいない場合には向きません。

ラボ型開発とは何ですか？

ラボ型開発は、月ぎめで開発チームの席を確保し、要件をそのつど渡す契約の形です。1件ずつ見積もって発注するのではなく、期間で人を押さえます。確保した時間が、そのままひと月の開発枠になります。仕様が動く前提の事業では、優先度の高い依頼から順に流せます。

ラボ型開発では何を買っているのですか？

ラボ型開発で買っているのは時間であり、成果物ではありません。その時間にチームが何を見るかは、依頼票を書いた側が決めます。依頼票に書いた範囲より外を、チームが見るとは限りません。そのため、時間を確保しても、問題を見る範囲まで買えるわけではありません。

ラボ型開発で同じ不具合が繰り返されるのはなぜですか？

不具合を画面ごとの依頼票で渡すと、直るのもその画面だけになるためです。記事の事例では、店長名を文字として写して固定する同じ作りが12件ありましたが、最初は引き継ぎ書の表紙だけを直しました。その結果、同じ型の不具合が場所を変えて4回発生し、名前に触る依頼票は28枚に増えました。チームの力量ではなく、依頼票の範囲の切り方が原因でした。

ラボ型開発の依頼票には何を書くべきですか？

依頼票には、正本、同じ型がある場所、過去ぶんの3つを書きます。正本には、その値がどこから来るべきかを記します。同じ値を写して保存している他の画面を洗い出すと、複数の直しを1枚の票に統合できます。すでに固まった記録をどう直すかも書かなければ、画面だけが直り、古い記録は間違ったまま残ります。

ラボ型開発の手戻りは、どのように測りますか？

新しく作る票と直しの票を分け、月ぎめの枠のうち計画外の直しに使った割合を数えます。記事の事例では、最初に測った割合は3割でした。依頼票を変えたあと、6か月ぶんでは最も高い月でも13%となり、1割台まで下がりました。DORAでは、不具合を直すための計画外の作業がデプロイ全体に占める割合をdeployment rework rateと呼んでいます。

依頼票を原因単位に変えるデメリットは何ですか？

正本を調べてから書くため、依頼票1枚あたり平均で30分ほど余計にかかります。直しの票が減ったぶん、次に渡す仕事を決めていないと、確保したチームの時間が待ち時間になります。記事の事例では、切り替えた最初の月に10日ぶんの席が空きました。また、すでに誤った値で固まった80件の記録は、別途一括修復する必要がありました。