小さく作ることと、雑に作ることは違う

新しい機能を小さく作るとき、「品質を下げて早く出すこと」と混同される場合がある。しかし、この二つはまったく別の判断である。

小さく作るとは、解く問題の範囲を狭めることだ。雑に作るとは、選んだ範囲の中で必要な確認を省くことだ。

前者は学習を速める。後者は不確実性を隠したまま、将来の作業を増やす。

削るのは品質ではなく、約束する範囲

最初のリリースで、すべての利用者、すべての入力形式、すべての運用環境を支える必要はない。対象を社内の1チームに限定してもよい。対応するデータ形式を一つに絞ってもよい。手作業が一部残っていても、検証したい仮説に影響しないなら問題ではない。

一方で、データを壊さないこと、失敗を検知できること、元に戻せることは、範囲を狭めても必要な場合が多い。ここを省くと、試した結果が悪かったのか、単に実装が壊れていたのか分からなくなる。

小さなリリースには、明確な境界がある。

• 今回、誰のどの問題を扱うのか
• 意図的に扱わない条件は何か
• 成功と失敗をどう判断するか
• 問題が起きたときにどう止めるか

この境界が説明できれば、小さいことは弱さではなく設計になる。

最短経路にも、検証可能性は必要

動く画面を早く見せることには価値がある。ただし、見た目が動くことと、仕組みが正しいことは同じではない。

たとえば、外部APIから情報を取得して一覧表示する機能を作るとする。最短の実装でも、通信が失敗した場合、同じデータが重複した場合、古い情報が残った場合の挙動は考える必要がある。すべてを自動化しなくてもよいが、何が起きたかを確認できなければ、試験結果を信用できない。

最低限のログ、主要な処理のテスト、手動確認の手順は、完成品のためだけにあるのではない。試作から正しく学ぶためにある。

検証できない試作は、速いのではなく、結果の判定を後回しにしているだけだ。

一時的な実装には期限と出口を置く

現実の開発では、時間の都合で理想的でない実装を選ぶことがある。それ自体は失敗ではない。問題は、一時的な判断が無期限に残ることだ。

一時的な実装を選ぶなら、理由、影響範囲、置き換える条件を残す。「利用者が100人を超えたら変更する」「次の四半期に認証基盤へ統合する」「このデータ形式を追加する前に設計を見直す」といった具体的な条件が必要になる。

単に「あとで直す」と書いても、優先順位は生まれない。何が起きたら直すのかが分かれば、負債は管理可能な判断になる。

速さは、戻れることから生まれる

大きな変更が遅い理由の一つは、失敗したときの影響が読めないことだ。変更を小さく分け、利用者を限定し、元に戻す方法を用意すると、試すための心理的・技術的な負担が下がる。

これは慎重さと速さの交換ではない。慎重に境界を設計することで、速く進められる。

良い小規模リリースは、完成品を薄くしたものではない。最も重要な仮説だけを検証できる形にしたものである。扱う範囲は狭くても、その範囲については信頼できる。

小さく作るときほど、「何を作らないか」と同時に、「何だけは守るか」を決めておきたい。