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









