実装はリファクタリング。プロトタイプ開発における「製造」フェーズの役割

別の記事で、プロトタイプの実装がそのまま本開発に流用できるという話をしました。この流用を突き詰めると、プロトタイプ開発における「製造」フェーズの実態が見えてきます。一般的な開発プロセスにおける製造フェーズが「仕様書を読んでコードをゼロから書き起こす工程」であるのに対し、プロトタイプ開発の製造フェーズは、既に動いているコードを本番品質に仕上げていく工程です。この性質の違いは、実務上の見積もりやアサインの考え方にも影響します。

「製造」という言葉が持つイメージとのギャップ

「製造」という言葉からは、白紙の状態から部品を組み立てていく工程がイメージされます。仕様書ベースの開発プロセスであれば、このイメージは実態と一致します。設計書・仕様書という「文書」を、動くコードという「実装」に変換する作業だからです。

プロトタイプ開発では、この変換は上流工程の時点で既に一度行われています。プロトタイピングの過程で、確認したい範囲について本番相当のロジックを持つコードが既にでき上がっているため、製造フェーズの開始時点で手元にあるのは仕様書ではなく、動くコードです。ここから行う作業は、ゼロからの組み立てではなく、既存の実装に対する加筆・修正・整理であり、性質としてはリファクタリングに近いものになります。

製造フェーズで実際に行うこと

プロトタイプ段階のコードは、確認したい論点を検証することを目的にしているため、本番運用に必要ないくつかの要素が意図的に省略されています。製造フェーズでは、主にこれらを引き上げる作業を行います。

エラーハンドリングの具体化: プロトタイプでは正常系の動作確認が優先されるため、異常系の処理が簡略化されていることがあります。製造フェーズでは、通信エラー・入力不備・排他制御の衝突といった異常系を具体的に洗い出し、処理を組み込みます
バリデーション・認可の厳格化: プロトタイプの段階では、確認したい論点と直接関係のない入力チェックや権限チェックが最小限になっていることがあります。ここを本番の運用要件に合わせて厳格化します
パフォーマンスの最適化: プロトタイプでは動作確認に必要な件数のデータで検証していれば十分なため、クエリの効率やキャッシュ戦略までは踏み込んでいないことが多くあります。想定される本番のデータ量・アクセス量を踏まえて見直します
テストの追加: プロトタイプの段階でも簡単な動作確認はしていますが、自動テストとして整備されているとは限りません。製造フェーズでは、リグレッションを防ぐための自動テストを追加します
命名・構造の整理: 検証を優先して急いで書いたコードには、命名の粗さや重複が残っていることがあります。ここで一般的なリファクタリングと同様の整理を行います

いずれも、確認済みのドメインロジックそのものを作り直す作業ではなく、その周辺を本番品質まで引き上げる作業です。ドメインロジックの骨格は上流工程で既に固まっているという前提があるからこそ、この進め方が成立します。

テストとの関係:リファクタリングにはテストの安全網が要る

一般的なリファクタリングの定義では、外部から見た振る舞いを変えずに内部構造を改善する作業を安全に行うために、自動テストの裏付けが前提とされています。テストがない状態でのリファクタリングは、振る舞いが壊れていないことを確認する手段がなく、実質的には手探りでコードを書き換えることに近くなります。製造フェーズがリファクタリング中心の作業である以上、この前提は製造フェーズにもそのまま当てはまり、TDD（テスト駆動開発）の考え方が品質維持の助けになります。

ただし、厳密には区別しておきたい点が2つあります。1つは、プロトタイプ実装には最初からテストが付いていないケースが多いことです。この場合、いきなりTDDの「テストを先に書いてから実装する」というサイクルを回すのではなく、まず現在の振る舞いをそのまま記録するテストを書いて安全網を先に張ってから、中身のリファクタリングに進むという順序になります。これは厳密には狭義のTDDというより、既存コードにテストを追加してから手を入れるという定石に近い作業です。もう1つは、製造フェーズではプロトタイプ段階になかった新しい振る舞い（バリデーション・認可・異常系など）を追加する作業も発生することです。この「新しく書き足す」部分については、テストを先に書いてから実装するサイクルをそのまま適用できるため、狭義のTDDが直接効いてきます。

いずれの場合も着地点は同じで、テストという安全網があることで、リファクタリングによって意図せず振る舞いを壊すリスクを早期に検知でき、結果として品質を維持しやすくなります。製造フェーズを「リファクタリング中心の作業」と捉えるなら、テストへの投資は後回しにできる付帯作業ではなく、本質的な部分だと言えます。

リファクタリングと捉えることの実務的な意味

製造フェーズをリファクタリングと捉えると、いくつかの実務判断が変わってきます。

1つは見積もりの立て方です。ゼロから書く前提で見積もると、既にある実装の質を考慮しない過大な工数になりがちです。逆に「動くものがあるから早い」という楽観だけで見積もると、異常系やテストの作り込みが漏れます。実際には「動くロジックを組み立てる時間」ではなく「そのロジックの周辺を固める時間」が製造フェーズの主なコストになる、という前提で見積もる必要があります。

もう1つはアサインするメンバーのスキルセットです。ゼロから設計して書き上げる力よりも、既存のコードを読み解き、意図を壊さずに手を入れられるリファクタリングの力が問われます。これは新規開発とはやや異なるスキルであり、コードレビューでも「元の実装の意図を壊していないか」という観点が重要になります。

プロトタイプ実装の質が、製造フェーズの生産性を左右する

製造フェーズがリファクタリングである以上、その生産性は土台となるプロトタイプ実装の質に強く依存します。プロトタイピングの段階から「どうせ後で作り直す」という前提で雑に書いてしまうと、製造フェーズで読み解くコストが余計にかかり、リファクタリングというより実質的な書き直しになってしまいます。

これは、使い捨てのモックではなく本番相当のロジックを持つ「完全型プロトタイプ」を作るという考え方とも一貫しています。プロトタイプの実装を製造フェーズにそのまま引き継ぐ前提に立つなら、プロトタイピングの段階から、最低限の可読性と構造の一貫性は意識して書く必要があります。「検証が終われば捨てる」コードと、「検証が終わったらそのまま育てる」コードとでは、書くときに払うべき注意の水準が異なります。

まとめ

プロトタイプ開発における製造フェーズは、仕様書からゼロでコードを書き起こす一般的な製造フェーズとは異なり、既に動くプロトタイプの実装を本番品質に仕上げていく、リファクタリングに近い性質の作業です。エラーハンドリング・バリデーション・パフォーマンス・テストといった、検証時には後回しにされていた要素を引き上げることが中心になります。この前提に立つと、見積もりやアサインの考え方はもちろん、プロトタイピングの段階でどの程度の可読性・構造を意識して書くべきかという判断にも影響が及びます。