- プロトタイプ（試作版）で、使いたい人がいることは確かめられました。ただ、大勢の利用者、入力ミスのあるデータ、何度も重なる修正には、まだ一度も出会っていません。
- プロトタイプを丸ごと捨てる必要はありません。そのまま残す部分、補強する部分、作り直す部分の3つに分けられます。
- プロトタイプの後で時間がかかるのは、検証と、システムが出す結果への責任です。AIで速めることはできても、人が担う必要があります。
プロトタイプで証明できたこと、まだ証明できていないこと
たとえば、AIツールを使って自分でデモを作り、1週間で完成させたとします。何人かの顧客に試してもらうと好評でした。そこで本番システムの見積もりを取ったところ、期間は数か月単位でした。最初に浮かぶのは、1週間と数か月の差は何に対して払うのかという疑問です。
プロトタイプは、ソフトウェア開発でかつて最もお金のかかった問いに、すでに答えを出しています。使いたい人はいるのか、ユーザーにわかりやすい画面はどれか、省ける手順はどれか、という問いです。AIが登場する前は、こうした答えを得るのに数か月の時間とまとまった資金が必要でした。バイブコーディングで作ったプロトタイプには実際に価値があり、本番システムの出発点として使うべきものです。
プロトタイプがまだ証明していないのは、デモでは一度も起きなかった状況でどう動くかです。本番のシステムなら1年目のうちに必ず出会う状況を6つ挙げます。
| デモでは起きなかった状況 | 本番で初めて起きたときの結果 | 本番システムが備えていること |
|---|---|---|
| 2人が同じ品物を同じ瞬間に予約する | 品物は1つしかないのに、2人とも予約確認を受け取る | データベースで対象をロックするルールと、処理がぶつかるケースのテスト |
| ユーザーが過去の日付やマイナスの数量を入力する | 合計が合わず、月末のレポートが狂う | 入力データのチェックと、何を直せばよいかをユーザーに伝えるメッセージ |
| ある機能を直したら、別の機能が壊れる | 顧客からの電話で初めてチームが気づく | リリース前に毎回実行される自動テスト |
| ユーザーが10人から数千人に増える | 利用が集中する時間帯にページが遅くなり、使えなくなる | 事前の負荷テストと、拡張できる構成 |
| 作った人が辞める、またはAIにどう指示したかを覚えていない | 誰もコードに手を出せない | ほかの人が読めるコード構成、ドキュメント、変更履歴 |
| 新しい機能をリリースしたら不具合が出る | 顧客の目の前で、チームが本番システムをその場で直す | 事前に試すためのステージング環境と、数分で前のバージョンに戻せるロールバック |
コードはずっと安くなったが、本番システムにはまだ時間がかかる
AIのおかげで、コードを書く速さは何倍にもなりました。残っているのは確認の仕事です。AIが書いたものを読むこと、起きてはいけないのに起こりうるケースを試すこと、顧客のお金やデータに関わる判断を下すことです。こうした仕事には、結果に責任を持てる人が今も必要です。
バイブコーディングで書かれたコードは、たいてい最短の道筋で結果にたどり着きます。同じロジックが何か所にも重複して書かれ、変数名からは意味が読み取れず、テストもついていません。このようなコードは、修正が要らないうちはうまく動きます。ところが、料金体系を変える、拠点を増やす、会計システムとつなぐといった変更が必要になると、1か所直すたびに別の箇所を壊すおそれが出てきます。エンジニアはこの負担を技術的負債（Technical Debt）と呼びます。システムを直すたびに、利息のように膨らんでいくからです。
今年は優れた開発チームもAIでコードを書いています。違いはコードの周りの工程にあります。システムに取り込む前に別のエンジニアがコードを読む工程があり、これをコードレビュー（Code Review）と呼びます。修正のたびに自動で走るテストがあり、本番に出す前に試すための独立した環境があり、新しく入った人が仕事を引き継げるドキュメントがあります。見積もりに書かれた数か月は、こうした工程に対して払うものです。
架空のケース
イベント機材レンタル会社と、二重に予約された音響機材
イベント機材のレンタル会社の経営者が、AIを使って6日で予約システムを作りました。営業担当の4人はExcelファイルをやめて、このシステムに移りました。最初の1か月は何の問題もありませんでした。ところが予約が詰まる年末になって、営業担当2人が同じ日の同じ音響機材セットを、それぞれ別の顧客に予約し、システムはどちらも確定させてしまいました。会社が気づいたのはイベント当日の朝、機材をトラックに積んでいる最中でした。結局、ほかのレンタル業者から音響機材を借りることになり、その費用は顧客から受け取るレンタル料を上回りました。
エンジニアがコードを調べたところ、原因は、機材が空いているかの確認と予約の記録が別々の2つの処理になっていることでした。そのため2人が同時に最初の処理を通過できたのです。試していた頃は一度に1人しか使っていなかったので、プロトタイプでこの問題が起きることはありませんでした。会社はシステムを使い続けることに決め、次の3つの仕分けで、どこに手間をかけるかを判断しました。
3つに仕分ける：残す、補強する、作り直す
- プロトタイプの画面と機能をすべて書き出します。
- 項目ごとに2つの質問をします。この部分が間違えたら誰が何を失うのか、そして来年この部分をどのくらいの頻度で直すことになるのか、です。
- 「残す」に入るのは、間違えても誰もお金を失わない画面やレポートです。そのまま使い続けられます。
- 「補強する」に入るのは、ロジックは正しいものの、テストや入力データのチェックがまだない部分です。テストを追加し、エンジニアにレビューしてもらいます。
- 「作り直す」に入るのは、お金、在庫、権限、顧客データに関わり、しかも今の構成のままでは直し続けるのが難しい部分です。
このケースでは、機材の検索画面とカレンダーが「残す」、レンタル売上のレポートが「補強する」、予約と料金計算が「作り直す」に入りました。記録として残しておくべきなのは、全項目の一覧と、それぞれをその分類にした理由です。ただし、プロトタイプがまったく部分に分かれておらず、1か所を直すとシステム全体に響くような場合、この方法は使えません。そのときは、プロトタイプを仕様の見本にして全体を作り直すほうが早く済みます。
どんなシステムならバイブコーディングのままでよいか
本番運用に耐えるシステムにする必要がないものも、たくさんあります。数人のチームで使うツール、3か月でやめる予定の試み、短期キャンペーンのWebページなどは、開発チームに頼まずバイブコーディングのままで構いません。本番運用向けに作り直す投資が見合うのは、システムの間違いにコストがかかり始めたときです。
本番運用向けに作り直す時期が来たサイン
- 社外の顧客がログインして使う
- お金や在庫の動きをシステムで扱う
- 複数のチームが同時に使う
- システムが止まると会社の業務も止まる
- 会計システムなど、ほかのシステムにデータを渡す必要がある
リスクの少ない進め方は、段階を踏むことです。まず、3つの仕分けでプロトタイプを評価します。次に、リスクの高い部分から作り、少人数のユーザーに従来のやり方と並行して使ってもらいます。全ユーザーを移すのは、繁忙期を1回、重大な問題なく乗り切ってからです。その間は3つの数字を見てください。チームより先に顧客が見つけた問題の件数、リリース後に前のバージョンへ戻した回数、新しく入ったエンジニアが自分でコードを直せるようになるまでの期間です。
開発チーム向け · 技術指標
変更失敗率（Change Failure Rate）、ユーザーから報告されたバグとチームが自ら見つけたバグの比率、お金と在庫に関わる部分のテストカバレッジ（Test Coverage）、コミットから本番反映までのリードタイム（Lead Time）、新しいエンジニアのオンボーディング期間を追跡します。予約と決済の部分には、同時実行テスト（Concurrency Test）と、空き状況の確認と記録をひとまとめにするトランザクションを用意します。
止めどきのルールも決めておきます。顧客が見つける問題が2回続けてリリースのたびに増えたら、機能の追加をやめ、壊れた部分のテストを先に補強します。
BUSINESS & PRODUCT READINESS
開発チームと話す前に、4つのことを用意する
経営者が次の4つの質問への答えを用意しておくと、評価はずっと速く、正確になります。答えは完璧でなくてよく、おおよその数字でも構いません。開発チームはそれをもとに、どの部分をどこまで頑丈に作るかを決めます。
機能の一覧と、それぞれが間違えたときに誰が何を失うか
ユーザー数と、利用が最も集中する時間帯
データをやり取りする必要があるほかのシステム
誰がコードを所有し、引き渡し後に保守するか
プロトタイプを引き取り、事業が頼れるシステムに仕上げる
どの品物なら重複して予約してよいか、価格がいつ変わるか、誰が値引きを承認するかといった事業のルールを知っているのは、経営者と社内のチームです。DNA Makerは、プロトタイプと、現場のチームと一緒に実際の業務を見た内容からこうしたルールを取り出し、ワークフロー、案件ごとのステータス、ビジネスルール、テストケースとして書き起こします。難しいケースにまだ出会っていなかったから正しく動いていた部分が、テストで正しさを確かめた部分に変わります。
私たちはプロトタイプを3つの仕分けで評価し、使える部分は残したうえで、お金とデータに関わる部分を拡張性のあるアーキテクチャの上に作り直します。チームはエンジニアのレビューのもとでAIを使ってコードを書き、CI/CDと3段階の環境を通してリリースします。ソースコード、ドキュメント、デプロイ手順書は、自社で所有できる形でお渡しします。DNA Makerは2012年から500を超えるプロジェクトを納品してきたので、公開後の問題がどこから起きやすいかを知っています。プロトタイプがすでにあるなら、デモのリンクと、今後12か月で事業に必要になることの一覧を持って、ご相談ください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
こうした用語は、開発チームの見積書や計画書に出てきます。意味を知っておけば、時間とお金がそれぞれ何に使われているのかを読み取れます。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Technical Debt | とりあえず速く書いたコードがたまっていき、次の修正を遅く、危険にしていく負担 | レンタル料の計算式が5か所に重複して書かれていて、値上げのたびに5か所すべてを直す必要がある | システムのどの部分に負債が最も多くたまっていて、そのせいで修正がどのくらい遅くなっていますか？ |
| Code Review | システムに取り込む前に別のエンジニアがコードを読み、間違いを見つけ、基準をそろえること | AIが書いた料金計算のコードを別のエンジニアが読み、本番反映の前に値引きが重なるケースについて質問する | お金と顧客データに関わるコードは誰がレビューしていますか？毎回行っていますか？ |
| CI/CD | コードのテストと本番反映を、手作業に代えて毎回同じ手順で自動的に行う仕組み | コードを直すたびにシステムが自動でテストを実行し、合格したらテスト用のサーバーに反映する | コードの修正が終わってから本番に反映されるまで、どのくらいかかりますか？まだ手作業で行っている工程はありますか？ |
| Staging | 本番システムと同じように作った検証用のシステム。新しい機能を顧客に公開する前にここで試す | 営業チームが事前予約の機能をステージング環境で1週間試してから、本番で公開する | ステージング環境と本番環境はどこが違いますか？本番への反映は誰が承認しますか？ |
| Automated Test | 重要な機能が今も正しく動いているかを確かめる一連のテスト。コードを直すたびに自動で実行できる | 2人が同じ品物を同時に予約する状況をテストで再現し、予約できるのが1人だけかを確かめる | 本番で起きた不具合のケースは、もうテストに追加されていますか？ |
| Rollback | 新しいバージョンに問題が出たときに、システムを前のバージョンに戻すこと | 新しいバージョンで見積書が出せなくなり、チームが5分以内に元のバージョンへ戻す | ロールバックを最後に練習したのはいつですか？その間に発生したデータはどうなりましたか？ |
| Refactoring | システムの動きは変えずに、後から直しやすいようにコードの構造を整理し直すこと | 5か所にあったレンタル料の計算式を1か所にまとめる。ユーザーから見た変化はない | 今回の構造の整理で、次の機能はどのくらい速く、あるいは安く作れるようになりますか？ |