スタートアップでの自社プロダクトの技術的な意思決定について頻繁に考えるような立ち位置で仕事しています。

どのような会社においても様々な状況、市場がどうだ、製品はどうだ、体制はどうだなど、枝葉のパラメータも見ていくと無限にも思えるようなパラメータを考慮しつつ、技術的な意思決定が行われているかとおもいます。

結論を先に書くと、スタートアップにおいて自社プロダクトの技術的な意思決定を行う際には以下の優先順位で技術的な選択がなされるべきという結論に至っています。

  1. 顧客に対して最速でデリバリできるか
  2. 顧客にとって価値があるか、または、価値があるかどうかを検討できるか
  3. 自社の利益率向上に寄与するか

Web のエンジニアリング界隈では、現在のシステムアーキテクチャ面のトピックで一番多いのは microservice か monolithic かといったところだと思いますが、上記の優先順位にしたがう場合 microservice が選択されることはありません。 なぜならば、1年以内程度の短期視点で見た場合に microservice アーキテクチャでのシステム構築に仮に組織として慣れていたとしても、 monolithic なシステム構築と比較した場合に境界面でのインターフェイス定義が増加することにより意思決定ポイントが増えるという副作用によって最速でデリバリできる手段とは言えなくなるためです。 一方、すでにプロダクトとしての年齢を重ね、一定規模、例えば MRR ベースで単月黒字を達成できている SaaS 製品の場合は monolithic なアーキテクチャから microservice アーキテクチャへの移行を検討してもよいでしょう。 サーバー台数も増え、システムのデプロイそのものの時間も数時間に渡るようになり、システム内部の依存関係も複雑で機能追加が難しくなってくる頃合いである、そういうイメージが持てるため、それらの対策としての microservice という話を具体の効果として、言い換えるとコスト削減・利益率向上への寄与が可能と言えるからです。

プロダクトマネジメント観点からは、最速でのデリバリとプロダクトが提供する価値あるいはソリューションの仮説検証を高速に回転させつづけることが可能な体制、これらが達成できていない状況でプロダクトを開発しつづけても暗中模索してしまうだけで神頼みしかやれることがない、という状況に陥ってしまいます。PMF 達成への道のりを計画し、適切に要件を小さくしつつフェーズを分け、粛々とデリバリからの検証を回す。これがプロダクトの成長においてゴールデンパターンかと思いますが、それに対して技術側としては強い意志できれいなコードを書くことを諦めたり、きれいなアーキテクチャを諦めたりすることが必要になります。ときにはちゃんとテストしない、カスタマーサポートによる運用でカバーを前提とする、そういった意思決定が重要と考えています。技術は手段ですので。