私がこれまで関わってきた会議室や開発現場では、いつも2つの考え方の対立を目にしてきました。
それを私は次のように呼んでいます。
- 「完成してから見せる」考え方
- 「一緒に作りながら改善する」考え方
- 完璧主義の落とし穴（完成してから公開）
この考え方は、
「完璧になるまで外に出さない」というものです。
エンジニアリングの現場では、まだユーザーに使われてもいない機能やUIを、何週間もかけて細かく作り込むことがあります。これは一見、安全で正しいように感じます。
しかし、変化の早い環境では大きなリスクになります。
リスク例
6か月かけて「完璧な橋」を作ったのに、
ユーザーが本当に必要としていたのは「船」だった、ということが起こります。
完成した頃には、
- 要件が変わっている
- ユーザーの使い方が想定と違う
ということは珍しくありません。
- 段階的に進める開発（反復・改善型）
もう一つの考え方が、OpenLMが大切にしている方法です。
早く出す・何度も改善する
まずは「動くけれど、まだ完璧ではない」状態でリリースします。
そして実際の現場でどう使われるかを見ます。
これは「未完成」なのではなく、「状況にすぐ対応できる」開発です。
戦略の考え方：「2-way ドア」
Amazonのジェフ・ベゾスは、意思決定を2種類に分けています。
① One-Way ドア（後戻りできない決定）
- 基本アーキテクチャ
- 基幹システムの技術選定
これは慎重に、時間をかけるべき
② Two-Way ドア（やり直せる決定）
- 機能追加
- UI変更
- API設計 など
間違えたら戻せばいい
日本の現場では、この 「Two-Way ドア」まで完璧を求めてしまい、スピードが落ちることがよくあります。
リーナス・トーバルズに学ぶ
Linuxの開発者、リーナス・トーバルズはこう考えました。
「早く出す。何度も出す。そしてユーザーの声を聞く」
Linuxは、完成形になる前に公開されました。
それによって、世界中のエンジニアからフィードバックが集まり、品質が急速に向上しました。
一人で完璧を目指すより、多くの目で早く改善する方が強い、という考え方です。
研究でも証明されている
マシュマロ・チャレンジ
子どもたちは「とりあえず作って、壊して、直す」。大人は「完璧な計画を立ててから作る」。結果は、子どもの方が成功率が高い。
Pixarの方法
Pixarでは「最初の映画は必ずダメ」と考え、早い段階で厳しいフィードバックをもらいます。
モノリス開発 vs 小さなリリース
完璧主義型
- 数か月こもって開発
- 一気にリリース
- ユーザーが使いにくいと気づくのが遅い
反復型
- 最小限でリリース
- 少人数で検証
- データを見て改善
結果として、
無駄が少なく、実際に使われる機能が残ります。
「早いフィードバック」の文化
OpenLMでは
**「まだ粘土が柔らかいうちに意見をもらう」**ことを大切にしています。
未完成なものを見せるのは、勇気がいります。でもその方が、現実に強いプロダクトになります。
目指すのは「最初から正しい」ことではない「一番早く正しくなる」こと
