仕様が正しくても、なぜその実装を選んだかは残らない

週末の3日間で、列指向のOLAPデータベースを一つ作った人がいる。疎なデータに対するクエリでは、DuckDB比で93倍から185倍速い。ログラスCTOの伊藤博志氏が公開した資料「動くだけのその先へ」に出てくる実績の一つだ(出典)¹。

同じ資料には、8日間で既存のクエリエンジンを置き換え、表示速度を約30倍にした業務SaaSの事例も載っている。品質保証には開発時間の半分近くを費やし、組み合わせると3,000万通りに膨らむテストケースを、ペアワイズ法で82構成まで圧縮して検証したという数字まで添えられている。

速い。ただ、この資料が語りたいのは速度の話ではないらしい。

「正しく作る仕組みは、間違いを高速に量産する」

資料にはもう一つ、気になる一節がある。「正しく作る仕組みは、間違いを高速に量産する」。

資料はこれをハーネスと呼ぶ。形式手法、独立したAIレビュー、オラクルテストといった外付けの規律を組み合わせれば、仕様どおりに動くコードは決定論的に作れる。だが、その仕様そのものが間違っていたら、正しく動く間違ったコードを、これまでよりずっと速く大量に作ることになる。

だから資料は、開発を三つの層に分けて論じる。「How」層は実装と検証で、ハーネスによってAIが自走できる領域。「What」層は仕様策定で、双方向トレーサビリティによって矛盾を事前に潰す領域。「Why」層は価値そのものの検証で、ダブルダイヤモンドの発散と収束を通じて、打席数と打率の掛け算で仮説を試す領域だ。

AIの時代に開発を最先端まで押し進めると、結局は顧客理解と対話という開発の原点に戻る、という構図である。仕様が正しければ、正しく動くコードは速く生まれる。仕様策定にどれだけ人間の判断を投じるかが勝負を分ける、そう読める。

ただ、この三層構造には、通っていない場所が一つある。

三層構造の外側にあるもの

仕様(What)が正しく、実装(How)がハーネスを通ってグリーンになったとしても、一つの仕様を複数の実装が同時に満たす場面は珍しくない。そのとき、なぜこちらを選び、なぜもう一方を捨てたかという理由は、仕様書にもテストコードにも残らない。三層構造は「正しく動くか」を担保するが、「なぜその動き方を選んだか」までは担保しない。

上流の仕様さえ固めておけば、下流の判断は要らなくなるのではないか。そう思いたくなる。だが、仕様が複数の実装で満たされる限り、その中からどれを選ぶかという判断は、仕様策定の時点ではまだ生まれていない。実装に着手して初めて具体的な選択肢が並び、どれかを選び、残りを捨てる。仕様がどれだけ正しくても、この選択の瞬間はコードが書かれるときにしか訪れない。

Parryが解こうとしている場所

これは、PRレビューツールParryが立てている問いそのものである。Parryは「confirm, don't write」、AIが書き、人間が確認するという設計思想を取り、PR作成時にWhy(なぜこの変更か)、Risk(影響範囲)、Confidence(自信度)、Context(背景)という4項目の入力を必須にしている。埋めなければレビューという次の工程に進めない。

伊藤氏の資料がハーネスで固めているのは、コードが仕様どおりに動くかという上流の確からしさである。Parryが固めようとしているのは、そのコードが書かれたあと、なぜその形になったかという下流の記録である。上流でどれだけ仕様の正しさを詰めても、下流で「なぜこの実装か」が記録されなければ、半年後に同じコードを触る誰かは、diffだけから判断を再構成する羽目になる。

伊藤氏の資料が解いているのは「仕様が間違っている」問題で、Parryが解こうとしているのは「仕様は正しいが、選んだ理由が消える」問題だ。二つは同じ開発工程の、別の場所にある穴である。

週末3日でOLAP DBを作り、DuckDB比185倍の速度を叩き出した判断の中にも、選ばなかった実装が必ずあったはずだ。その理由は、伊藤氏の頭の中には残っているだろう。三層構造の外にあるその理由を、三日後にコードを触る別の誰かが読み取れるかどうかは、また別の話である。

Footnotes

1. 伊藤博志「動くだけのその先へ」(SpeakerDeck、ログラスCTO登壇資料)。スライド画像主体の資料のため、本文中の要約は取得できた範囲の情報に基づく。 ↩