試行錯誤ファースト——AI時代の開発は「触りながら発見する」
「使えないシステム」はなぜ生まれるのか
完璧な要件定義書があった。承認プロセスも踏んだ。テストも通った。
なのに、納品されたシステムを使ってみると「なんか違う」。
この現象は、システム開発の世界で何十年も繰り返されてきた。なぜか。
ユーザーは最初から正解を知らないからだ。
触ってみて初めてわかる
要件定義の段階で「何が欲しいか」を正確に言語化できるユーザーは、ほぼいない。
これは能力の問題ではない。構造的な限界だ。
- 使ったことがないものを、正確に想像することはできない
- 言葉で説明されても、動くものを触らないとピンとこない
- 触ってみて初めて「あ、これじゃない」とわかる
つまり、正解は最初から存在しない。触りながら発見するものだ。
従来の開発思想の問題
従来のシステム開発は、この現実を無視していた。
| 従来の思想 | 何が問題か | |-----------|----------| | 要件を正確に定義する | そもそも正解がわからない段階で定義を求める | | 1回で正しく作る | 正解がわからないのに「正しく」作れるわけがない | | 承認してから次へ | 触らずに承認しても意味がない | | 完成を目指す | 「完成」という概念自体が幻想 | | 変更は「手戻り」 | 変更をネガティブに捉えるから硬直する | | 機能を積み上げる | 機能が多くても体験が悪ければ使われない |
この思想の根底にあるのは、「変更はコストである」という前提だ。
人間が作る時代には、これは正しかった。変更には時間と費用がかかる。だから、最初に正確に定義して、変更を最小化しようとした。
しかし、この前提が崩れたらどうなるか。
AI時代：変更コストがゼロに近づく
AIが開発を担うようになると、変更のコストが劇的に下がる。
- 初回生成：5分以内
- フィードバック反映：1〜2分
- 1日で10イテレーション可能
変更コストがゼロに近づくなら、「変更を最小化する」という戦略は意味を失う。
むしろ、変更を前提とした設計が正解になる。
Development Factory OS というコンセプト
この新しいパラダイムを「Development Factory OS」と呼ぶ。
目的
ユーザーが「本当に欲しいもの」を発見できる環境を提供する
「作る」ことが目的ではない。「発見する」ことが目的だ。
前提
- ユーザーは最初から正解を知らない
- 触ってみて初めてわかる
- 何度でも試行錯誤していい
サイクル
雑に言う → すぐ触れる → 気づく → また言う → すぐ触れる → ...
このサイクルを高速で回すことが、本質的な価値を生む。
思想の転換
Development Factory OS は、開発思想の根本的な転換を求める。
| 従来の思想 | 新しい思想 | |-----------|-----------| | 要件を正確に定義する | 触りながら発見する | | 1回で正しく作る | 何度でも作り直す | | 承認してから次へ | まず動かしてから判断 | | 完成を目指す | 進化し続ける | | 変更は「手戻り」 | 変更は「学び」 | | 機能を積み上げる | 体験を磨き上げる |
特に重要なのは、**「変更は手戻りではなく学び」**という捉え方だ。
従来、変更は失敗の証拠だった。要件定義が甘かった、設計が悪かった、という反省につながった。
しかし、新しい思想では、変更は成功の証拠だ。触ってみて、気づきが生まれた。学びがあった。だから変更する。
変更の数は、学びの数。
AIの役割
この思想を実現するには、AIが重要な役割を果たす。
嫌がらずに何度でも作り直す
人間の開発者に「また作り直して」と言うのは、心理的なハードルがある。相手の時間を奪う罪悪感。「さっき言ったことと違う」と思われる不安。
AIにはそれがない。何度でも、嫌な顔せずに作り直す。
ユーザーの曖昧な言葉から意図を汲む
「なんかもうちょっとこう...」という曖昧なフィードバックでも、AIは意図を汲んで提案できる。
従来の開発では、曖昧な要件は悪だった。「もっと具体的に」と求められた。
AI時代には、曖昧なままでいい。AIが解釈して、具体化して、提案する。違ったらまた言えばいい。
過去のイテレーションから学ぶ
AIは過去のやり取りを覚えている。
- 「前回はこういう方向だったけど、今回は違うんですね」
- 「以前却下されたパターンは避けますね」
この文脈の蓄積が、イテレーションの質を高める。
「使えないシステム」からの解放
Development Factory OS がもたらす成果は明確だ。
1. ユーザー主導の開発
開発者ではなく、ユーザーが主導権を持つ。「作って」ではなく「これを試したい」。受動的な発注者から、能動的な探索者へ。
2. 本当に価値のあるシステム
何度も触って、何度も直して、磨き上げたシステムは、最初から「正解」を定義しようとしたシステムより、はるかに価値が高い。
3. 「使えないシステム」からの解放
触りながら作るのだから、「触ってみたら違った」という事態が起きない。納品後に「なんか違う」と言われることがなくなる。
実現に必要なもの
この思想を実現するには、いくつかの条件が必要だ。
技術面
- 高速な生成能力（5分以内）
- 高速なフィードバック反映（1〜2分）
- 文脈を保持する対話能力
組織面
- 「変更は悪」という文化の転換
- 承認プロセスの簡素化
- 試行錯誤を許容する時間的余裕
マインド面
- 「最初から正解を出す」というプレッシャーからの解放
- 「わからない」と言える心理的安全性
- 触りながら考える習慣
まとめ
- ユーザーは最初から正解を知らない
- 触ってみて初めてわかる
- だから、何度でも作り直せる環境が必要
- AIは変更コストをゼロに近づける
- 変更は「手戻り」ではなく「学び」
従来の開発は、「変更はコスト」という前提に縛られていた。
AI時代の開発は、「変更は学び」という前提で設計される。
Development Factory OS は、この新しいパラダイムを体現するコンセプトだ。
試行錯誤ファースト。触りながら発見する。
これが、AI時代の開発の本質だ。