「あとで直す」仕様が増えるほど、リリースは不安の塊になる

ソフトウェアの現場には、例外が付き物です。法令対応、急な営業要求、運用上の抜け道。例外をゼロにするより、例外を回収する約束を置けるかどうかの方が現実的です。ところが「あとで直す」が口頭のまま増えると、リリース前の空気は一瞬で変わります。変わるのは、バグの数だけではありません。テストが何をもって完了かが分からなくなるからです。分からないとき、人は不安を数では測れません。測れない不安は、今晩の睡眠と明日の居場所に影響します。

tugiloでは、この状態を責めずに整理するとき、まず「未完リスト」を外に出すことを勧めます。未完リストとは、TODOアプリの話ではなく、製品として公開してよい暫定の宣言です。宣言には最低限、何が暫定で、誰がいつまでにどう直すかが要ります。要らないと、暫定は布石になりません。布石にならないものは、心理としては「負債」です。負債は悪ではありませんが、見えない負債は強いです。強いほど、現場は口をつぐみます。

「後回し」は悪い言葉ではない。可視化されないのが悪い

後回しは戦略の一部になり得ます。今週は価値の芯だけ出す。角は角まで引かない。引けない角は次のイテレーションで引く。これは健全な優先順位です。健全でも、角がどこかが記録に残らないと、次の週はまた別の角が増えます。増えるほど、リリースは「全部なんとかした」感になります。感は気持ちよいですが、テスト設計には使えません。

テスト設計に必要なのは、範囲の境界です。境界が曖昧だと、テストは「念のため」に膨らみます。念のためは、心遣いの言葉としては美しいですが、工数の言葉としては危険です。膨らんだ工数は、また次の「あとで」に押し出されます。押し出されるほど、未完は増えます。

境界を書くとき、否定形が有効なことがあります。「今回は◯◯はやらない」「◯◯ブラウザは対象外」など、否定は冷たく聞こえますが、現場の集中を作ります。集中ができると、品質は上がります。上がる品質は、網羅の広さではなく、重要箇所の深さです。

「ついでに足す」が増えるほど、リリースは遠のくとセットで見ると分かりやすいです。ついでは積み上がり、後回しは隠れ積み上がりになりやすい。見え方が違うだけで、チームにかかる負荷の形は似ています。

暫定を許すなら、「許す条件」を一行で書く

暫定を許すチームは強いです。強いのは、妥協ではなく、合意形成が短いからです。合意が短いとは、全員が好きなように諦めることではありません。捨てるものの名前が早いことです。名前があると、捨てたものは戻りにくい。戻りにくいから、再議論のコストが下がります。

一行の条件の例は次のようなものです。「v1では◯◯のケースのみ手入力で捌く。v1.1で自動化する。期限は◯月◯週」。一行で足りるかは場合によります。足りなくても、最初の一行があると、議論は具体に落ちます。具体に落ちない議論は、だいたい不安の共有で終わります。共有は必要ですが、共有だけでは製品は動きません。

要件が増えるほど、「誰の仕事か」が見えなくなるとも接続します。後回しのオーナーが無いと、誰の仕事でもなくなります。誰の仕事でもないものは、Releaseノートに載りません。載らないものは、現場が背負います。

不安は「品質」ではなく「物語」の問題になる

リリース直前の不安は、しばしばバグの数では語られません。語られるのは物語です。「あの人が言っていた」「あの会議で決まったはず」。物語は正しさの検証が難しい。難しいほど、テストは過剰になります。過剰なテストは、遅延を増やし、遅延はまた物語を増やします。

物語を減らすには、決めをログに残すのと同じぐらい、捨てた決めを残すことが効きます。捨てた、は敗北ではありません。今回は捨てて、次に拾う。拾う担当と期限があるなら、それは計画です。計画は不安を下げます。下がらない不安は、計画が口頭か、期限が無いかのどちらかです。

テスト観点を書くときも同じです。「今回は見ない」は逃げではなく、契約になり得ます。見ない理由が業務上正当なら、Releaseノートに書けます。書けると、サポートも営業も同じ地図を持てます。地図が揃うと、問い合わせは減りませんが、迷いは減ります。迷いが減ると、夜のデプロイが怖くなくなります。

「緊急例外」が恒久化すると、後回しは仕様になる

例外対応は最初は本当に緊急です。緊急は許容されます。許容されるほど、例外は手癖になります。手癖は、後回しリストに載らないことが多いです。載らない後回しは、画面には出ず、現場の頭だけに残ります。頭だけに残ると、引き継ぎで消えます。消えると、同じ緊急が再来します。再来は、組織学習ではなく、組織ループです。

ループを切るには、緊急でも一行だけ残す。暫定の正当性を書くのです。「法令対応のため」「顧客◯社の固定要件のため」など、短くていい。短い正当性があると、後で優先順位を付けられます。付けられない正当性は、勢いです。勢いは悪くないですが、積もると仕様になります。仕様として見えた瞬間、後回しはもう後回しではなく、既定の挙動です。

リリースの怖さを下げるのはテスト件数ではなく境界の明文化

件数を増やすほど安心に見えます。見えるほど、コストは増えます。増えたコストは、次の「あとで」に押し出されやすいです。だから境界の明文化は、精神論ではなく、経済の話でもあります。境界が明文化されると、自動テストも手動テストも設計できます。設計できると、むだが減ります。

まとめ：後回しを止めないなら、可視化だけは先にやる

すべてを最初から完璧にすることは現場では不可能に近いです。だからこそ、後回しは出ます。出ることを前提に、見える化された後回しに変えるかどうかが、チームの持続性を分けます。見える化は、白状ではなく、契約です。契約があると、テストは境界を引けます。境界を引けると、リリースは怖くなくなる。怖さが下がると、また速く戻れます。

次のスプリントの最初の10分で、未完の「あとで」を三つまで列挙してみてください。三つで止めるのは、現実的だからです。三つのそれぞれに、オーナーと期限を付けられないなら、それはまだ言葉として早すぎます。言葉が早い未完は、チームをすり減らします。すり減りは、機能では測れません。測れないからこそ、一行で早くに止める価値があります。

リリース後の問い合わせで火事になるのは、しばしば「想定外」ではなく、想定内の暫定が顧客側から見えていないときです。見えていない暫定は、実装都合の言い訳に聞こえます。聞こえると、信頼は落ちます。落ちないようにするには、暫定を恥として隠すのではなく、利用上の注意として短く出すことです。注意は売り文句の敵に見えますが、長期では味方です。味方になるのは、期待の一致です。

またあとで、を口癖にしないために、口癖の代わりに使う短文を決めてもよいです。「今回のスコープ外。起票は◯番」。短文は冷たく聞こえるかもしれません。冷たさは、境界の明確さとして受け取られることもあります。明確さがあると、反対は減らないかもしれませんが、迷いは減ります。

不安は夜に増えます。夜に増える不安は、日中的には杞憂だったことも多いです。それでも夜の不安は消えにくいです。消えにくい不安に効くのは、白日の下での境界の一行です。一行があると、人は眠れます。眠れるチームは、速さではなく持続性で勝つことがあります。

リリースノートに「未対応」を書くのは怖いです。怖いから隠したくなる。隠すほど、サポートは火消しになります。火消しは勇敢に見えますが、設計ではありません。設計としては、未対応を明記し、次の版で拾う日程を置く方が筋が良いです。筋が良いと言っても、社外交渉や契約次第では難しい局面もあります。難しい局面ほど、社内の未完リストは共有が要ります。共有は弱みではなく、同期です。