エンジニアリングチームが採用を増やしても遅くなる理由
数年前、私が関わったプロダクトチームは15人のエンジニアで構成されていました。彼らは2週間ごとに機能をリリースしていました。経営陣は、さらに高速にリリースするためにチームを倍増することを決定しました。6か月後、30人のエンジニアを擁するチームは、3週間ごとにリリースするようになりました。誰もが困惑しました。エンジニアが怠けているわけでも、スキルが低いわけでもありません。目に見えない何かが彼らを遅くしていたのです。
その目に見えないものこそ、現在「認知負荷」と呼ばれるものです。そして、これこそがプラットフォームエンジニアリングが存在する主な理由です。
コードを書く前の隠れた作業
あなたが新しい機能を開発するよう割り当てられた開発者だと想像してください。ビジネスロジックを1行も書く前に、以下のことを行う必要があります。
- 適切なブランチ保護ルールを備えた新しいリポジトリをセットアップする
- ビルドパイプラインとテストパイプラインを作成する
- 開発用データベースに接続する開発環境を構成する
- ステージング環境へのデプロイ方法を理解する
- 会社の本番環境デプロイプロセスを学ぶ
- 問題が発生した場合のロールバック方法を理解する
- サービスの監視とロギングをセットアップする
これらのタスクの1つ1つにコンテキストスイッチが必要です。チームがどのCIツールを使っているか、ステージング環境をホストしているクラウドプロバイダーはどこか、互換性のあるデータベースのバージョンは何か、本番環境へのアクセスを誰に依頼すればよいか、これらをすべて覚えておかなければなりません。
ユーザーが実際に目にする機能の構築に集中したい開発者にとって、これは非常に負担です。そして、これはスキルの問題ではありません。シニアエンジニアでさえ、インフラストラクチャの知識と機能ロジックを同時に扱わなければならないと、速度が落ちます。
本当のコスト：認知負荷
認知負荷とは、タスクを完了するために必要な精神的労力の量です。機能を書いているとき、あなたの脳はビジネスロジック、データフロー、エッジケースを処理しています。それだけでも十分です。そこにデプロイコマンド、環境変数、パイプライン設定、ロールバック手順が加わります。あなたの脳は、その容量を2つのまったく異なる領域に分割することになります。
結果は予測可能です。機能の開発に時間がかかり、ミスが増え、エンジニアは一日の終わりに疲れ果ててしまいます。仕事ができないからではなく、一度にあまりにも多くのことを頭の中に保持しなければならないからです。
この問題は、会社が成長するにつれて複合的に悪化します。3〜5人のチームであれば、知識を非公式に共有できます。誰もが他のメンバーのデプロイ方法を知っています。しかし、10のプロダクトチームがあり、それぞれが異なる好みを持っている場合、混乱は倍増します。あるチームはJenkinsを使い、別のチームはGitLab CI、さらに別のチームはGitHub Actionsを使います。あるチームは本番環境に直接デプロイし、別のチームは3段階の手動承認を必要とします。あるチームはKubernetesを実行し、別のチームはプレーンな仮想マシンを使用します。
すると、プラットフォームチームやDevOpsチームは、すべてのチームが異なるセットアップで支援を必要とするため、圧倒されます。そして、プロダクトチームは依然として遅いままです。なぜなら、彼らは時間の半分をインフラストラクチャに費やしているからです。
プラットフォームエンジニアリングは単なるツールではない
ここでプラットフォームエンジニアリングが登場します。しかし、それが何であり、何でないかを理解することが重要です。
プラットフォームエンジニアリングは、派手なダッシュボードを構築したり、新しいツールを購入したりすることではありません。それは考え方の転換です。インフラストラクチャとパイプラインは、チームが時間があるときに処理するサイドプロジェクトではなくなります。それらは、顧客が使用する製品と同じ厳格さで設計、構築、保守されるべき内部製品になります。
核となるアイデアはシンプルです。すべてのチームがゼロから独自のパイプラインを構築する代わりに、プラットフォームチームがすぐに使えるパスを提供します。すべてのチームが本番環境へのデプロイ方法を学ぶ代わりに、プラットフォームがテスト済みで安全なデプロイメカニズムを提供します。プロダクトチームはコードと機能に集中します。プラットフォームがインフラストラクチャとパイプラインのオーバーヘッドを処理します。
これにより、認知負荷が劇的に削減されます。開発者は、環境のセットアップ方法、監視の設定方法、ロールバックの処理方法を覚えておく必要がなくなります。プラットフォームがそれを行います。開発者はコードを書いて、すでに存在するパイプラインを実行するだけです。
万能なアプローチの罠
しかし、ここで多くのプラットフォームの取り組みが失敗します。彼らはすべてのチームをまったく同じワークフローに強制しようとします。チームには異なるニーズがあるため、それは機能しません。高速なデプロイサイクルを必要とするチームもあれば、厳格な承認ゲートを必要とするチームもあります。特定のデータベースやプログラミング言語を使用しており、特別な処理が必要なチームもあります。
プラットフォームが硬直的すぎると、チームはそれを回避します。独自の回避策を構築し、断片化されたインフラストラクチャと高い認知負荷という元の問題に逆戻りします。
優れたプラットフォームは、チームをすべて自分で管理するように戻すことなく、違いに対応します。一般的なケースをカバーする標準パスを提供しますが、チームが重要な部分で選択を行えるようにします。ここで「ゴールデンパス」の概念が登場します。これについては後で詳しく説明します。
あなたのチームにとっての意味
エンジニアリングチームが成長しているのに、デリバリ速度が向上していない場合は、目に見えない作業に注目してください。開発者に尋ねてみてください。「機能を書き始める前に、何を知っている必要がありますか、または何をする必要がありますか？」その答えが、認知負荷が最も高い場所を示してくれます。
プラットフォームエンジニアリングの目標は、チームを管理することではありません。チームを遅くする摩擦を取り除くことです。うまく機能すれば、開発者はフロー状態を維持し、重要な機能を構築することに集中でき、プラットフォームが残りを処理します。
実践的なチェックリスト
プラットフォームの構築を始める前に、次の質問を自問してください。
- 開発者は、すべての機能やサービスでどのようなタスクを繰り返しているか？
- 学習やトラブルシューティングに最も時間がかかるインフラストラクチャタスクはどれか？
- 既存のプロセスが合わないために、チームが独自の回避策を作成しているのはどこか？
- 開発者が今日、ゼロから新しいサービスをデプロイするために知っておく必要があることは何か？
- リリース中に最も不安や遅延を引き起こすパイプラインの部分はどこか？
まとめ
あなたのチームが遅くなっているのは、仕事ができないからではありません。目に見えない重荷を抱えているからです。プラットフォームエンジニアリングは、その重荷を取り除くことであり、ツールを追加することではありません。まず、開発者が実際に何に苦労しているかを理解し、その苦労をなくすパスを構築することから始めてください。