「ここはスピード優先で開発しよう！」は本当に正しいのか？または、本当に間違っているのか？
「この機能、Aの方法で実装するかBの方法か、どうしますか？」
「うーん、じゃあとりあえずスピード優先でAにしよう！」
そんな会話を幾度となく繰り返した皆さま、もしくはこんな会話に幾度となく疲弊した皆さま。こんにちは。成澤です。
冒頭の会話は、スタートアップ界隈のプロダクト開発でしがちな会話だと思うのですが、実際のところ「"スピード"を優先するべきなのか？時間をかけてでも"質"を追求すべきなのか？」という問いに、明確に答えを出すのはそれなりの経験が必要なのではないでしょうか。
もちろん、この問題の答えは「時と場合による」でしかありません。
しかし、「このパターンは自分ならこうする」というパターンをいくつかお話しようと思います。
「とりあえずスピード優先で！」パターン
最初からざっくりしたパターンですが、冒頭のような「とりあえず」が一番NGです。
「質」と「スピード」のトレードオフは確かに存在しますし、そのメリットとデメリットを見極めるのが難しい場合はありますが、思考を放棄してしまうと一生見極めができません。
トレードオフを見極めるのは難しいですが、毎回しっかりと考え尽くして、考えた上で決断をすることにより、見極めの力が上がります。
また、理想をベースに考える文化がチームにない場合、理想のサービスは絶対に生まれませんし、チームメンバーの一人一人の成長も見込めません。
こんなセリフがでる場面は、大抵エンジニア/PMが理想のサービス像を考えるのを放棄しているだけで、「質」をとってもそう大して工数変わらないパターンが多いように思います。
まずは理想のサービス像を考え、それをいかに実現するかを考えるのを基本方針としながら、理想を外れるべき明確な理由が他にあれば一旦妥協を許す、という思考の流れが良いでしょう。
特にエンジニアの成長という観点で、開発は質とスピードを両立することがベストであり、スピードを優先しているとこれは一生達成できません。妥協した微妙な実装のスキルを身につけるより、正しく理想的な実装を最高速で行えるスキルを身につけるべきでしょう。
実際のところ、それなりの開発経験を積んだ自分にとって、質を下げるとスピードが上がるというケースはあまり思い浮かびませんし、大体の場合で質とスピードは両立するものですし、世の中の開発におけるスピードか質かとかいう話の大半はエンジニアのスキルの低さに起因するものだと感じます。
※スキルが低いエンジニアがダメだとか言いたい気持ちは全くなく、自分のスキルを謙虚に客観視し、サービスの理想像だけでなく自身の理想像をもしっかり考えた上で、日々の議論をするべきだというスタンスです。
また、人のスキル不足を責め立てるような互いのリスペクトのない態度はもちろんNGです！
非エンジニアの方がこういった言葉を言ってしまうケースでは、そもそも技術的な知識がなく、判断材料がなさすぎて止むを得ず思考放棄の状態になっていることも多いと思います。
その場合の解決策は、やはり判断材料を積極的に手に入れることでしょう。あるあるパターンだと
「Aの仕様の方が実装楽なので、Aの方法で実装します」
とエンジニアに言われた時に
「なるほど！仕様検討したいので、どれだけ工数違うか、ざっくりで構わないので教えてもらえませんか？」
「できればBでやりたいんですが、なんとかできないですかね…？」
などと聞くか聞かないかで判断の質が全く異なるかなと思います。
「この不具合は深刻じゃないから後回しで」パターン
「う、エラー出てる。。今日直しときますね！」
「いや、これ確かに変な表示になるけど、機能は動いてるしユーザー影響ほぼないから別に良くない？これ直すことで売上あがるの？それより新機能の開発優先じゃない？スピード優先してこ！」
これもWebサービスの運用フェーズになるとあるあるですね。
これも一概に悪いとは言えず、特に短期的な視点で見たときにはありうる選択だと思います。
しかし、中長期的な視点だと微妙なケースかと思います。一番に考えるべきは、負債を背負ってまでスピードを優先すべきか？という観点です。
A. 使いづらく不具合がよくでる機能が20個実装されている
B. 完璧な機能が10個実装されている
の2パターンで、前者が好まれる状況は機能の価値検証期間（特にPMF前）のみであり、価値検証が終わった機能を微妙な状態を放置し続けるのは非効率です。なぜなら、放置している間に悪影響がで続けますが、結局いつかは必ずその不具合を修正するはずなので、今直しても後回しにしてもかかる工数は変わらないためです。
つまり「開発リソースを前借りする代わりに、（様々なデメリットという）利子を払っている」という状態で、まさしく「負債」「借金」です。そして、借金はいつか必ず返済する必要があります。借金をしてまで短期的なリソースを確保するべきフェーズなのか、考えるべきでしょう。
「返済計画がある状態で目的をもって借金をする」例えば、ローンで高いカメラを買ってそのカメラを使って仕事をするのは正しい借金の仕方ですが、「とにかく目の前のお金がないから、毎月借金して無駄な利子を払う」は残念ながら非効率で負のスパイラルに陥る危ない方法です。
「慢性的に開発リソースが足りない」場合にやるべきは、借金し続けて無駄に利子を払うことではなく、開発量を減らすことです。無計画に「余裕が出たら直す」と考えてるなら、余裕なんて一生でないので、余裕を作りましょう。
逆に、利子が大したことないのであれば、借金し続けるのは悪くない方法です。また、借金して新しい機能を作ることで、短期的にも長期的にも確実に売上が上がると見込めるのであれば、その選択もありだと思います。しかし、繰り返しになりますがくれぐれも計画的に行うべきアクションですね。
ここでは「不具合を後回しにするかどうか」という話をしましたが、「自動テストを書かない」「リファクタリングをしない」「微妙なコードをそのままにする」なども、結局潜在的に不具合やサービスクオリティ低下に繋がるため、同じ話になります。
最低限の機能になってないパターン
「先を見込んでマイクロサービス化しておきます！インフラはk8sで！どれだけアクセス来ても耐えられます！」
「SP/PC対応、アニメーションゴリゴリで実装します！」
「多言語対応しよう！」「決済機能いれよう！」
「スピードよりも質！」という方向の話が続いたので、逆に質に拘りすぎてしまうパターンについて。スキルフルで拘りのあるエンジニアが実装をしてくれるときにこういうパターンが多いだろうなと思いますが、仕様・実装がオーバースペックではないかを常に考えましょう。
実際に経験した怖い話をすると、某案件で営業より「サービスのAPIを公開して、APIとして売り出したい！」という話があったため、個人的には既にあるAPIを工数3日くらいで雑に手直しして一旦公開するだけでいいかと思ったのですが、結局他のエンジニアが3週間かけてしっかりとした外部公開用APIとドキュメントを整備し、しかし結局そのAPIは一度も使われないまま削除された…という怪談話があります（辛い）。
このパターンは、いわゆるリーンスタートアップの文脈のMVP(Minimum Valuable Product)になってないという問題ですね。不確実性の高いこの現代でサービス開発を行う場合、我々が頭の中で考えたものを顧客が求めるとは限らず、顧客のニーズが明らかになっていない状態の過度な開発は無駄になる可能性が高いため、価値検証前に過度な開発リソースをかけるべきではありません。
価値検証が終わるまでは、最低限の開発を行うべき、できるなら開発をしないべきです。
（逆に、価値検証が終わっているのであれば、前章までの質を重視すべきというのが基本方針でしょう）
そのため、例えば最初の例については、多言語対応は国内で十分に価値検証した後にやれば良いと思いますし、決済はトラブルが怖いのでできるなら後回しにしたいし、最初期のWebサービスはSP or PCだけのシンプルなデザインで良いし、モノリシックなアプリケーションでとりあえず動くインフラに乗ってれば十分と個人的には考えてます。
Webサービスなら、ほとんどの場合においてサービス初期はRuby on Rails + Nuxt.js + Google App Engine という技術スタックで十分なんじゃないでしょうか。RailsとかNuxtは似たフレームワークであれば個人の好みで良いと思いますが、個人的にはこれほど初期の開発パフォーマンスが出やすいフレームワークは現状他に無く、リーンスタートアップの文脈に尤も適していると思ってます。
※勿論ですが、この議論はサービスの性質や事業戦略に依存します。また質とスピードが両立するのであれば何でも構わないと思います。
※こういう話を聞いて「最初だから雑に開発してオッケー！」と勘違いする人が多いのですが、最低限の機能のみを丁寧に高速に開発すべきという意図なのでお間違いないよう。
MVPについて補足しておくと、日本では「Minimum Viable Product = 実用最小限の製品」と訳されることが多く、「とにかく機能を少なくしよう！」となりがちなのですが、「価値検証するのに最小限の製品」の意味なので気をつけましょう。
機能が少なすぎて価値検証ができなければ意味はないですし、そもそも作る前に「何の価値を検証したいのか」を明らかにする必要があります。その意味では、たまに言われるMinimum Lovable Productという言葉が分かりやすいですね。
まとめ
・思考放棄はNG。理想の実現を前提に考え、常にトレードオフを最大限の解像度で見極める
・開発における質とスピードを両立できるように成長する
・負債を背負ってリソースの前借りすべきフェイズなのかを考える
・PMF前は価値検証できる最低限の開発をする
まとめるとどれも当たり前のことなのですが、思考の整理に役立っていれば幸いです！