プロダクトのアイデアを、本番稼働するシステムへ

プロダクトのカテゴリーによって、エンジニアリングの難所がどこにあるかは異なります。SaaSプラットフォームの中心は、テナンシー、サブスクリプション課金、テナントごとの設定です。FinTechアプリケーションの中心は、台帳の正確性、冪等なトランザクション処理、照合（リコンサイル）、監査可能性です。マーケットプレイスの中心は、二者間のフロー、検索、当事者間で預かる決済、信頼を担保する仕組みです。

APIプロダクトではコントラクトそのものがプロダクトであるため、バージョニング、レート制限、利用量の計測、開発者向けドキュメントが最優先になります。社内向けエンタープライズシステムやワークフロープラットフォームでは、既存システムとの連携、組織を反映したロールモデル、設定可能なプロセス定義が大きな比重を占めます。B2Cプラットフォームは予測できないトラフィックを吸収し、オンボーディングを短く保たなければなりません。一方、B2Bプラットフォームにはシングルサインオン、きめ細かな権限、監査証跡が必要です。

カテゴリーを早期に特定することで、工数が均等に分散してしまうことを防げます。難所にはシニアエンジニアの注力と個別のエンジニアリングを充て、それ以外は標準的なコンポーネントを使います。

スケーリングの問題の多くは、エンジニアリングの関与なしに下されたプロダクト上の決定から始まります。顧客ごとのカスタマイズを約束すれば、設定の仕組みがモデルに組み込まれていない限り、顧客ごとのフォークが生まれます。無料プランは負荷の特性と不正利用の対象領域を変えます。リアルタイムのコラボレーションは、データアーキテクチャを根本から変えます。

私たちは、ディスカバリーの段階から一貫して、プロダクトとエンジニアリングを同じ議論の場に置きます。ロードマップの各項目には技術的な影響とコストを添え、アーキテクチャ上の各決定は、それを正当化するプロダクト上の必要性に紐づけます。見積もりに信頼性を与えるのもこの進め方です。コミットする前に、スコープ、デザイン、アーキテクチャを合わせて理解しているためです。