ラボ型開発｜画面ごとに頼まず、不具合の原因ごとに頼む

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

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

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

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

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

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

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

この話に出てくる事業

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

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

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

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

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

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

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

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

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

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

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

チームの動きも良かったです。渡した票は、たいてい翌日には着手されていました。この段階では、外した感覚はまったくありませんでした。

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

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

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

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

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

「同じ型がある場所」を先に書くという見方は、扱っているものには依存しません。名前でも、住所でも、税率でも同じです。