私がエンジニアリングでスピードを大切にしている理由

はじめに

ここ10年ほど、スタートアップでプロダクト作りをしてきました。シードラウンドのような小さなチームで開発することが多く、その中で自分が何を一番重視しているかと聞かれたら、「スピード」と答えることが多いです。
もちろん、品質やスケーラビリティ、メンテナンス性など、エンジニアリングにおいて大切な要素はたくさんあります。どれも無視できないものですし、「スピードだけあればいい」とは思っていません。
ただ、自分のこれまでの経験を振り返ると、スピードを意識してきたことが結果的に多くの価値につながったと感じています。今回は、なぜ自分がスピードを重視するようになったのかを書いてみたいと思います。

スピードを意識するようになったきっかけ

スタートアップで開発をしていると、競合との戦いは日常です。自分たちが「次はこの機能を出そう」と計画していたものを、競合が先にリリースしてしまうということが実際にありました。
機能の内容がほぼ同じでも、先に出した方がユーザーの印象に残ります。「あのプロダクトは対応が早い」と思われるか、「後追いで真似した」と思われるかは、出すタイミングひとつで変わってしまいます。こういう経験を何度かすると、スピードの持つ意味を痛感するようになりました。
一方で、自分がユーザーとしてプロダクトを使っていても、スピードの価値を感じる場面があります。どんどん機能が追加されて、使うたびに便利になっていくプロダクトには驚きがありますし、「このチームはちゃんと開発してるんだな」という信頼感が生まれます。アップデートの頻度が高いこと自体が、ユーザーにとっての価値になり得るのだと思います。

「品質を上げてから出す」だけが正解ではない

スピードの話をすると、「品質はどうなるの？」という疑問が出てくるかもしれません。これはもっともな指摘だと思います。
たとえばAppleのように、最初から高い完成度と驚きのあるクオリティでプロダクトを世に出すアプローチもあります。あれはあれで素晴らしいですし、そういう戦略が取れるなら理想的だと思います。
ただ、スタートアップや小さなチームの場合、同じアプローチが常にうまくいくとは限りません。私の経験では、完璧を目指して時間をかけるよりも、まず出してしまってからブラッシュアップしていく方が、結果的に良いものができることが多かったです。
なぜかというと、リリースして初めて見えてくるものがあるからです。ユーザーの使い方は開発者の想定通りにはいきませんし、実際のデータやフィードバックを得て初めて「ここを改善すべきだ」とわかることがたくさんあります。机の上で品質を磨き続けるよりも、実際に出してから磨いた方が的確な改善ができるのではないでしょうか。
もちろん、これは立場や戦略によって異なります。私は後者のやり方で物を作り続けてきたので、どうしてもスピード寄りの考え方になっているのだと思います。

スピードは他の価値に変換できる

スピードを重視するもうひとつの理由は、スピードが他のさまざまな価値に変換できるということです。
開発スピードが速ければ、同じ期間でより多くの仮説検証ができます。ひとつの機能を作って反応を見て、ダメならすぐ次のアプローチを試す。このサイクルが速いほど、良いアイデアにたどり着く確率が上がります。
また、リリースの頻度が高ければ、問題の発見も早くなります。小さな変更を頻繁にリリースする方が、大きな変更を一度にリリースするよりも問題の切り分けが簡単です。これが結果的に安定したリリースにつながり、チーム全体の技術力向上にも寄与すると感じています。
ユーザーへの価値提供という面でも、速さは武器になります。「あったらいいな」と思われている機能を素早く届けられれば、それだけで製品やサービスへの信頼感が高まります。

スピードにもいろいろある

「スピード」とひと口に言っても、いくつかの種類があると考えています。
コードを書くスピードは、一番わかりやすい速さです。素早くコードが書ければ、短期間で多くの仮説検証ができますし、アイデアを形にするまでの時間が短くなります。最近はAIの進化によってコードを書くスピードが劇的に上がり、個人や少人数のチームでも驚くほど速くプロダクトを作れるようになりました。その結果、これまでにないペースで新しいプロダクトが生まれ続けています。コードを書くスピードが上がることで、プロダクト開発の形そのものが変わりつつあるのだと思います。
意思決定のスピードも同じくらい大切です。技術選定、仕様変更、問題発生時の対応など、判断を求められる場面は開発中に頻繁にあります。私の経験では、正しい判断をゆっくり下すよりも、多少間違えても早く決断して修正した方がトータルではうまくいくことが多いです。完璧な判断を待っている間にチーム全体の手が止まってしまうのが、一番もったいないと思います。
学習のスピードも見逃せません。新しい技術や概念を素早く習得できれば、環境の変化に柔軟に対応できます。学習が速い人やチームは、技術的な選択肢が広がるので、結果的にスピードのある開発ができるようになります。

まとめ

エンジニアリングで大切なことはたくさんありますし、状況によって優先すべきものは変わると思います。「スピードが絶対的に正しい」と言いたいわけではありません。
ただ、スタートアップで開発をしてきた自分の経験を振り返ると、スピードを意識してきたことが多くの場面でプラスに働いたと感じています。速く出すことで得られるフィードバック、速く判断することで生まれるチームの推進力、速く学ぶことで広がる選択肢。スピードはそれ自体が目的ではなく、さまざまな価値を生み出すための起点になるものだと考えています。
もし同じように「スピードと品質、どちらを優先すべきか」と悩んでいる方がいれば、まず速く出してみて、そこから磨いていくというアプローチも選択肢として考えてみてはいかがでしょうか。