チーム数の多いエンジニアリング部門では、一貫性と開発スピードの両方を確保するために、共通の課題に対する解決策を標準化する必要が出てきます。こうした共有ソリューションのオーナーシップを担う「プラットフォームチーム」を設けるアプローチは、これらのプロジェクトの保守や方向性に関する課題の解決に役立ちますが、同時に新たな課題ももたらします。

なぜプラットフォームチームを作るのか

インフラからアプリケーション開発まで、開発チームはさまざまな共通の課題に直面します。生産性を高め一貫性を保つには、これらの課題に対する解決策を標準化することが不可欠です。標準化によって開発は加速し、保守コストは下がり、チーム間の異動も容易になります。さらに、UIのブランディングやGDPR対応といったビジネス上の要請にも対応しやすくなります。

当初、こうした解決策はアドホックに共有されることがよくあります。コードをコピーしたり、共有ライブラリを導入したり、他チームのAPIに接続したりといった形です。しかし、全体の方向性も、長期的な保守の責任も、知識移転の明確な仕組みもないまま、こうした仕組みを有機的に成長させてしまうと、たちまち扱いに手間がかかるものになり、時には使い物にならなくなることさえあります。こうした解決策に責任を持つチーム、一般に「プラットフォームチーム」と呼ばれるチームを設けることは、この問題の解決に役立ちますが、新たな課題も伴います。

優先順位付け

新設されたプラットフォームチームが早い段階で直面する課題の一つが、優先順位付けです。プラットフォームに依存するエンジニアリングチームが数多く存在するため、チームは容易にあちこちから引っ張られてしまいます。重要な問いは、「何から手をつけるべきかをどう決めるか」です。

エンジニアリングチームにとってプロダクトオーナーの存在は重要であり、特にScrumを採用しているチームではなおさらです。しかし、プラットフォームチーム内でこの役割に適した人材を見つけるのは容易ではありません。エンジニアからの要望を技術的に正しく理解しつつ、ビジネス上の優先順位にも精通し、事業全体のイニシアチブを横断して効果的に優先順位を付けられる必要があります。実際には、この役割を担え、かつ十分な時間を確保できる人材を見つけるのは難しいのが現実です。

一つのアプローチは、ハイレベルな優先順位の意思決定を行う委員会を設けることです。シニアエンジニア、アーキテクト、プロダクトマネージャー、上級マネジメントなどで構成することが考えられます。ただ、このようなグループは頻繁に集まることはできません。そのため、日々の優先順位や作業スコープについて意思決定する権限を持つ人物が別途必要になります。チームと密に連携するシニアエンジニアやマネージャーがその役割を担うことになるでしょう。

スケジューリング

優先順位を決めていても、プラットフォームチームは依然としてプロジェクトデリバリーにおける単一障害点やボトルネックになり得ます。「プラットフォームチームのせいでプロジェクトが止まっている」という声を繰り返し聞くのは、士気を下げ、悪影響を及ぼします。プラットフォーム本来の目的はデリバリーのスピードを上げることですが、チーム間の依存関係を適切に管理できなければ、かえって遅延を招いてしまいます。

有効なアプローチの一つが、BasecampのShape Upのような「固定期間のプロジェクト」を採用することです。期間を固定しスコープを限定したプロジェクトにコミットすることで、短いスプリントよりも長いスパンで、チームが何を提供し何を提供しないのかを明確にできます。「ベッティングテーブル（Betting Table）」という考え方も、先ほどの優先順位付け委員会のアプローチと相性が良いでしょう。

もしプラットフォームチームが常に複数のイニシアチブに追われて手一杯になっているなら、やり方を見直すときです。優れたプラットフォームはエンジニアの足を引っ張るのではなく、スピードを上げるものであるべきです。柔軟性が鍵となります。よくある要望は、明確なドキュメントを整備してセルフサービス化しましょう。プラットフォームチームはすべてを抱え込むのではなく、システム設計やコードレビューを通じて他チームを支援する、頼れる「コンサルタント」のような存在になることもできます。

新機能の要望に常に受動的に対応することに終始してはいけません。他のエンジニアリングチームが容易に変更を加えられるようにすることに注力しましょう。自分たちが提供するツールやフレームワークを使って、彼ら自身が課題を解決できるようにするのです。そうすれば、プラットフォームチームの仕事の大半は、本当に大きな新規追加や変更といったものに集中できるはずです。

実際に使われるものを作る

プラットフォームチームの最優先の使命は、他のチームが問題を解決するのを支援することであるべきです。しかし、独立したチームを設けることで、他のエンジニアリングチームが実際に悩んでいる課題から乖離してしまいがちです。

プロダクトオーナーがいることで大きな違いが生まれます。支援対象のチームが実際には使いたいと思わない解決策で問題を解決しようと夢中にならないようにしましょう。ユースケースに合わない、あるいは彼らにとって優先度の低い問題だからといった理由で、使われないものを作ってしまいがちです。

プラットフォームは一つのプロダクトであり、他のエンジニアリングチームは顧客であることを忘れないでください。強制されて使うのではなく、自ら使いたいと思い選んで使いたくなるようなプラットフォームを目指しましょう。顧客視点を保つ方法を見つけ、標準を「強制する」方法を考える前に、利用が進まないのであれば自らの解決策を再評価してください。

早すぎる共有

プラットフォームチームができたことで、さまざまな人が「汎用的な解決策」として推したい優れたアイデアの受け皿ができました。しかし、早すぎる共有への衝動は抑えましょう。

たった一つの確かなユースケースから、共有システムにとって適切な抽象度を導き出すことは不可能です。早すぎる段階で共有の実装にコミットすると、新しい要件が出てくるたびに追加のオプションが継ぎ足された、分かりにくいAPIになりかねません。複数のコンシューマーを抱えた状態で破壊的変更を行うコストは高くつきます。

新たなプラットフォーム機能の可能性を早い段階で認識しておくことは有益ですが、将来的にプラットフォームレベルの解決策になり得るとしても、エンジニアリングチームが自律的に問題を解決する余地を残しておきましょう。

プラットフォームに解決策を追加すべきかを判断する際のガイドラインとして、私は3の法則（Rule of Three）が有用だと感じています。「再利用可能なコンポーネントは、再利用ライブラリに受け入れるのに十分な汎用性を備えるまでに、3つの異なるアプリケーションで試されるべきである」という考え方です。

• 1回目の要望：自分で解決する
• 2回目の要望：既存の解決策を確認し、システム設計で協力するが、実装はやはり自分で行う
• 3回目の要望：3つのユースケースすべてをサポートするプラットフォームレベルの解決策を実装する

レガシーの置き換え

プラットフォームチームを結成したのであれば、それはおそらく、有機的に成長し、オーナーシップやシステム設計、保守の欠如の犠牲となってきたいくつかの共有ソリューションが存在するからでしょう。これらのシステムは扱いが非常に厄介で、ドキュメントも乏しく、サポートが終了したソフトウェアバージョンで動き続けているかもしれません。すべてを取り壊してゼロから書き直したいという誘惑は非常に強いものですが、同時にリスクも伴います。

おそらく、完全な置き換えが必ずしもより良い結果をもたらすとは限りません。特にユーザーの視点から見ればなおさらです。どれだけ乱雑に見えても、実戦で鍛えられた本番のソリューションには、時間をかけて積み重なった複雑なビジネス要件が詰まっていることが多いのです。

さらに悪いことに、特に複数の箇所で使われている場合、旧システムを完全に置き換えられない可能性も高いでしょう。新しいシステムへの移行は、他のチームにとって作業とリスクを生み出します。部分的な移行に留まれば、1つではなく2つのシステムを支え、両者の機能の乖離を管理しなければならず、保守の負担は倍増します。

理想的な解決策を明確にすることはもちろん重要ですが、既存のシステムへの漸進的な改善に焦点を当てましょう。書き直しのプロジェクトが提案されたら、警鐘を鳴らすべきです。現在のシステムをより深く理解し、徹底的にドキュメント化し、自動テストを作成して、変更を加える際のチームの自信を高めましょう。

もちろん、大規模な置き換えが避けられず正当化される場合もありますが、作業範囲を定める際は慎重になりましょう。実装フェーズだけでなく、移行のサポート、適切な検証、ドキュメント作成、そして他のチームに切り替えを優先してもらうための説得など、あらゆることを考慮してください。しっかりとした計画なしに書き直しに飛びついてはいけません。漸進的な改善の方が、後々の無用な頭痛の種を避けさせてくれるかもしれません。

知識のサイロ化

プラットフォームを利用する際に他のチームが日々直面している課題から切り離されたサイロになるのも、非常に起こりがちです。チームを定義することは、共通の焦点を持つ集団をまとめる一方で、「私たち」と「彼ら」の間に一線を引き、対立を生むことにもなりかねません。

人と話し続け、自ら働きかけて彼らの課題に耳を傾けることが重要です。エンジニアはブロックされたくありません。あなたとの関係が築けていなければ、あなたのソリューションに問題があっても相談するより、回避策で済ませてしまうことがよくあります。

つながりを築くことは不可欠です。オープンなコミュニケーションを促し、他の人が気軽に声をかけられるようにしましょう。効果的な手法の一つが、エンジニアのローテーションを通じてプラットフォームの知識を共有することです。メンバーが入れ替わることで、新鮮な視点やこれまでの経験から得た貴重な洞察がもたらされます。

部門を越えたコードコントリビューションを歓迎し、コラボレーションの文化を育みましょう。ユーザーは独自の視点や改善のための貴重な意見を提供してくれます。プラットフォームチームがソリューションに責任を持つとはいえ、組織全体のエンジニアがその成長に貢献する能力を十分に備えていることを忘れないでください。

結局のところ、コラボレーションとオープンな対話が、より強力で効果的なプラットフォームチームにつながります。継続的な改善のために、知識と視点を共有する力を活かしましょう。

おわりに

プラットフォームチームを導入することは、共有ソリューションに対する明確なオーナーシップを確立する優れた方法ですが、同時に特有の課題も伴います。

成功のためには、プラットフォームを社内プロダクトとして扱うことが極めて重要です。プロダクトオーナーの役割を担う適任者を見つけることは、円滑な運営に不可欠です。他のチームと協力し、エンジニアが心から使いたいと思えるプラットフォームを作り上げましょう。

実装そのものと同じくらい、あるいはそれ以上にドキュメントが重要であることを忘れないでください。まずはAPI設計を正しく行うことを優先し、迅速に実装した後は、詳細で包括的なドキュメントの作成に焦点を移しましょう。