どのようにしてボトルネックに陥ったのですか？
私たちが遭遇する最も一般的なスケーリングのボトルネックは、技術的負債です。スタートアップは、技術的負債が成長の主な妨げであると定期的に述べています。「技術的負債」という用語は、一般的に、技術プラットフォームとスタックの改善が必要であることを示す、包括的な用語として使用される傾向があります。彼らは、機能開発の遅延、品質の問題、またはエンジニアリングの不満を経験しています。スタートアップチームは、成長段階での技術投資の不足が原因で発生した技術的負債に起因すると考えています。技術的負債の種類と規模を把握するには、分析が必要です。コードの品質が悪い、古い言語やフレームワークが使用されている、または製品のデプロイと運用が完全に自動化されていない可能性があります。解決策としては、チームのプロセスに若干の変更を加えるか、アプリケーションの一部を再構築するイニシアチブを開始することが考えられます。
慎重な技術的負債は、特にスタートアップの初期段階では、健全で望ましいものであるということを言っておくことが重要です。スタートアップは、製品の配信速度のために、品質や堅牢性などの技術的な側面をトレードオフする必要があります。これにより、スタートアップは最初の目標である、実行可能なビジネスモデル、実績のある製品、および製品を愛する顧客を達成することができます。しかし、会社がスケールアップを目指すとき、私たちはとった近道に対処する必要があります。さもなければ、ビジネスに非常に迅速に影響を与えるでしょう。
私たちが遭遇したいくつかの例を見てみましょう。
会社A – スタートアップは、投資家にとって十分な証拠（ユーザートラフィック、ユーザー感情、収益）を示し、次の資金調達ラウンドを確保したMVPを構築しました。ほとんどのMVPと同様に、高品質の技術アーキテクチャではなく、ユーザーフィードバックを生成するために構築されました。資金調達後、そのパイロットを再構築するのではなく、機能に焦点を当てることで牽引力を維持し、その上に構築します。スタートアップには、鋭いエッジを理解し、会社を存続させるために絆創膏ソリューションを適用できる小規模な上級チームがいるため、これはすぐには問題にならない可能性があります。
チームが機能開発に焦点を当て続け、負債が返済されない場合に、問題が発生し始めます。時間の経過とともに、低品質のMVPはコアコンポーネントになり、改善または交換するための明確な道筋がありません。コードを学習、作業、サポートすることに摩擦があります。チームまたは機能セットを効果的に拡張することがますます困難になります。エンジニアリングリーダーは、元のエンジニアの離職と彼らが持っている知識の損失について非常に神経質になっています。
最終的に、技術投資の欠如が表面化します。チームは麻痺し、速度の低下とチームの不満で測定されます。スタートアップは大幅に再構築する必要があり、それは機能開発を遅らせ、競合他社が追いつくことを意味します。
会社B – この会社は元エンジニアによって設立され、すべてを「正しく」行いたいと考えていました。最初からスケールアウトできるように構築されました。最新のライブラリとプログラミング言語を使用しました。きめ細かいアーキテクチャを備えており、アプリケーションの各部分を異なるテクノロジーで実装でき、それぞれが完全にスケールするように最適化されています。その結果、会社が到達すると、ハイパーグロースに簡単に対応できるようになります。
この例の問題は、作成に時間がかかり、機能開発が遅く、多くのエンジニアが製品ではなくプラットフォームの開発に時間を費やしていたことです。また、実験も困難でした。きめ細かいアーキテクチャは、既存のサービスアーキテクチャに適合しないアイデアを実行することが困難であることを意味していました。同社は、顧客ベースの規模に到達するためのプロダクトマーケットフィットを見つけることができなかったため、高度にスケーラブルなアーキテクチャの価値を認識していませんでした。
これらは、Thoughtworksのスタートアップチームが協力してきたさまざまなクライアントの複合体に基づいた2つの極端な例です。会社Aは、会社を麻痺させた技術的負債のボトルネックに陥りました。会社Bは、開発を遅らせ、学習につれて迅速にピボットする能力を損なうソリューションを過度に設計しました。
どちらのテーマも、技術投資と製品デリバリーの適切なバランスを見つけることができないことです。理想的には、慎重な技術的負債を利用して、迅速な機能開発と実験を推進したいと考えています。アイデアが価値があると判明したら、その技術的負債を返済する必要があります。これは非常に簡単に述べられていますが、実際に行うのは難しい場合があります。
適切なバランスを作成する方法を探るために、さまざまな種類の技術的負債を調べていきます。
典型的な負債の種類
技術的負債はあいまいな用語であり、純粋にコード関連として見なされることがよくあります。この議論では、技術的負債を、短期間の機能開発のために技術プラットフォームへの長期的な投資をトレードオフしている技術的なショートカットを意味するために使用します。
- コード品質
- 脆弱で、テストが難しく、理解が難しく、ドキュメントが不十分なコードは、すべての開発および保守タスクを遅くし、エンジニアのやる気を低下させながら、コードを書く「楽しみ」を低下させます。別の例は、現在のビジネスモデルに適合しないドメインモデルと関連するデータモデルであり、回避策が必要になります。
- テスト
- ユニットテスト、統合テスト、E2Eテストの不足、または誤った配布（テストピラミッドを参照）。開発者は、コードが既存の機能と依存関係を破壊しないという確信をすぐに得ることができません。これにより、開発者が変更をバッチ処理し、デプロイ頻度が低下します。大きなインクリメントはテストが難しく、バグが増えることがよくあります。
- 結合
- モジュール間（モノリスでよく発生します）、チームは互いにブロックする可能性があり、デプロイ頻度が低下し、変更のリードタイムが増加します。1つの解決策は、サービスをマイクロサービスに引き出すことですが、独自の複雑さが伴います。モノリス内で明確な境界を設定するより簡単な方法があるかもしれません。
- 未使用または価値の低い機能
- 通常、技術的負債とは考えられていませんが、技術的負債の症状の1つは、扱いにくいコードです。機能が増えると、開発者が設計する必要がある条件、エッジケースが増えます。これにより、配信速度が低下します。スタートアップは実験しています。実験（機能）が機能しているかどうかを常に確認し、機能していない場合は削除する必要があります。感情的には、チームが判断を下すことは非常に難しい場合がありますが、機能の価値を定量化する客観的なデータがあれば、はるかに簡単になります。
- 古いライブラリまたはフレームワーク
- チームは、新しい改善を利用できなくなり、セキュリティ上の問題に対して脆弱なままになります。スキルの問題が発生し、新入社員のオンボーディングが遅くなり、古いバージョンでの作業を強制される現在の開発者が不満を感じるようになります。さらに、これらのレガシーフレームワークは、さらなるアップグレードとイノベーションを制限する傾向があります。
- ツール
- 多くのメンテナンスを必要とする、最適ではないサードパーティ製品またはツール。状況は常に変化しており、より効率的なツールが市場に参入している可能性があります。開発者は、自然に最も効率的なツールで作業したいと考えています。購入と構築のバランスは複雑であり、残りの負債を考慮して再評価する必要があります。
- 信頼性とパフォーマンスエンジニアリングの問題
- これは、顧客体験と拡張能力に影響を与える可能性があります。私たちは、将来の仮説的な状況に合わせてスケールアップするとき、時期尚早な最適化に無駄な労力があったため、注意する必要があります。スケールできる未証明の製品よりも、ユーザーにとって価値があることが証明された製品を持つ方が良いでしょう。これについては、「スケーリングのボトルネック：信頼性と監視を念頭に置いて構築されていない」の記事で詳しく説明します。
- 手動プロセス
- 製品配信ワークフローの一部が自動化されていません。これは、開発者ワークフローのステップや、本番システムの管理に関連するものである可能性があります。注意：投資に見合うほど使用されていないものを自動化するために多くの時間を費やすと、この逆になる可能性があります。
- 自動デプロイ
- 初期段階のスタートアップはシンプルな構成で済ませられますが、これは早急に対処すべきです。小さなインクリメンタルなデプロイが実験的なソフトウェアデリバリーを促進します。4つの主要な指標をガイドポストとして活用してください。少なくとも1日に1回、通常は必要に応じてデプロイできる能力を持つべきです。
- 知識の共有
- 有用な情報が不足していることは、技術的負債の一種です。新しい従業員や依存チームがすぐに業務を開始することを困難にします。標準的な慣行として、開発チームは簡潔に記述された技術ドキュメント、API仕様、およびアーキテクチャに関する意思決定記録を作成する必要があります。また、開発者ポータルや検索エンジンから発見可能である必要があります。アンチパターンとしては、品質を確保するためのモデレーションや非推奨化プロセスがないことが挙げられます。
それは本当に技術的負債ですか、それとも機能ですか？
スタートアップは技術的負債に圧倒されているとよく言いますが、詳しく調べてみると、実際には技術プラットフォームの機能の制限を指しており、これには計画、要件収集、および専任のリソースによる適切な対応が必要です。
例えば、Thoughtworksのスタートアップチームは、顧客のオンボーディングを自動化するプロジェクトでクライアントと協力することがよくあります。彼らは、自動化がほとんどないシングルテナントのソリューションを持っているかもしれません。これは最初はうまく機能します。開発者は手動でアカウントを設定し、インストール間の違いを追跡できます。しかし、クライアントが増えるにつれて、開発者にとって時間がかかりすぎるようになります。そこで、スタートアップは顧客アカウントを設定するために専任の運用スタッフを雇うかもしれません。ユーザーベースと機能が成長するにつれて、異なるインストールを管理することがますます難しくなります。顧客のオンボーディング時間が長くなり、品質問題が増加します。この時点で、デプロイと構成を自動化するか、マルチテナントのセットアップに移行すると、KPIに直接影響します。これは機能です。
他の形式の技術的負債は、特定が難しく、直接的な影響を示すのが難しい場合があります。例えば、扱いにくいコードや、繰り返しの手動プロセスなどです。それらを特定する最善の方法は、日々の業務でそれを経験しているチームからのフィードバックを得ることです。チームの継続的改善プロセスで対応でき、修正するために専用の取り組みは必要ありません。
