The Modernization Imperative: プラットフォーム エンジニアリング プロジェクトは必ず失敗する？
Google Cloud Japan Team
※この投稿は米国時間 2023 年 6 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。
最近の The Modernization Imperative（TMI）で、私の同僚である Richard Seroter が、開発者とオペレーター双方の負担を軽減するために、事前構築済みのプラットフォーム機能を活用する、つまりシフトレフトをやめてシフトダウンに移行することの重要性について投稿しました。クラウドのモダナイゼーションに関してエンジニアリング リーダーに助言を行う立場である私は、これに強く同意します。しかし、組織が（プラットフォーム エンジニアリング チームによって）独自のプラットフォームを構築しようとしているのであれば、始める前にいくつかの質問を自問してみてください。さもないと、プラットフォームは大失敗に終わることになるはずです。
最近、企業内で社内テクノロジー プラットフォームを構築することが大流行していますが、それには相応の理由があります。IT スペシャリストの各々の生産性が上がり、一元化されたガバナンスとセキュリティを維持できるからです。クラウド自体がプラットフォームであるのはもちろんですが、たとえば、BigQuery を使用したデータ プラットフォーム、Vertex AI を使用した ML / AI プラットフォーム、Apigee を使用した API 管理プラットフォーム、Google Kubernetes Engine を使用したマルチテナント コンテナ ランタイム プラットフォームなどは、クラウド上に追加の社内プラットフォームを開発する絶好の機会となります。プラットフォーム上でプラットフォームが動作するというわけです。
CIO やエンタープライズ アーキテクトにとって、プラットフォームへの投資に対する戦略的重要性は疑いの余地がないことかもしれません。ただ、1 つだけ問題があります。それは、社内でプラットフォームのことを気にかける人が、ほかに誰もいないということです。あなたがプラットフォームを構築したからといって、ユーザーに活用してもらえるとは限らないのです。
もちろん、ユーザーにプラットフォームを使用するよう強制はできますが、それでは使命の半分しか達成できたことになりません。一元化されたガバナンスとセキュリティ対策は得られるものの、社内ユーザーにとっては求めていない、必要だとも思わないなんらかの再学習や再調整、プラットフォームの再構築を強いられることになり、使用する前からいらだちを抱かせてしまうからです。ユーザー エクスペリエンスが完璧でなければ、プラットフォームもあなたも非難されることになります。
普及を促したり、幅広い受け入れを促進したりすることはできるのでしょうか。新しい社内プラットフォームは常に失敗する運命にあるのでしょうか。いえ、そんなことはありません。
成功への道筋をつけるためには、まず 3 つの重要な質問に答える必要があります。「誰のためにプラットフォームを開発するのか？」、「誰が開発するのか？」、そして最後に、「成功をどのように測定するのか？」という質問です。
質問 1: 誰のためにプラットフォームを開発するのか？
「ユーザーを重視するところから始め、そこから逆方向に作業する」というアドバイスは誰もが聞いたことがあるでしょう。ただし、大企業では、これが想像以上に難しい場合があります。社内プラットフォームの実際のエンドユーザーは別の部門の別の従業員ですが、そのニーズは部門責任者やプロダクト オーナーが代弁します。彼らは「プラットフォーム X の責任者」とやりとりし、その責任者が機能のバックログに優先順位を付けて、アーキテクチャ設計をエンタープライズ アーキテクトに委任します。そして、エンタープライズ アーキテクトがプラットフォーム エンジニアにその構築方法を説明します。これで果たして、ユーザーの正確なニーズは伝わるのでしょうか。
社内プラットフォームを構築するプラットフォーム エンジニアは、チームの一員であるプロダクト マネージャーのサポートを受け、実際のユーザーと顔を合わせながら定期的にミーティングを行う必要があります。プラットフォームの構築や使用に関わるすべての人が 1 つの部屋に集まるか、少なくとも Meet / Zoom / Teams の 1 つの画面で顔を見せる必要があります。これは、ユーザーが最初に自分たちのために構築したものが、往々にして最適なプラットフォームとなるのと同じ理由です。あなたがユーザーであるなら、あなたほどの適任者はいないのです。
関係者全員を同じ部屋に集めることができない場合、「ユーザーの同時視聴セッション」という優れたツールをデプロイしてそのギャップを埋めることができます。ユーザーの同時視聴セッションは、フォーカス グループに相当するもので、エンジニアを集めて、隣の部屋にいるユーザーがプラットフォームを操作する様子をマジックミラー超しに見ることができます。実際は、ユーザーのコンピュータ画面と音声を記録するだけです（もちろんユーザーの許可を得ます）。必要なのは、5 人のテストユーザーを確保し、置き換えようとしているレガシー プラットフォーム、またはすでに構築している新しいプラットフォームの MVP バージョンのいずれかを使用して、同じ目標を 2 つか 3 つ達成してもらうだけです。その際、テストユーザーには、声に出して考え、思い込みや混乱している点などを発言するよう依頼します。
知識があり技術に精通したテストユーザーでさえ、思っていた以上に時間がかかり、意外なところでつまずくのを目の当たりにして驚くかもしれません。このような観察事例を例外的なものとして無視したり、より明確なドキュメントや追加のトレーニングですべての問題を修正できると考えたりしたくなるかもしれません。しかし、実際には新しいプラットフォームが直面する真の課題、つまりユーザーを喜ばせ仕事を簡単にするうえでのニーズを、フィルタを通さない形で目撃しているのです。
ユーザーの同時視聴セッションには、誰もがまったく同じことを見聞きしているため、エンジニアリング チーム内で優先順位を調整できるという利点もあります。以前は、チームメンバーそれぞれに、次に構築したいお気に入りの機能があったかもしれませんが、今ではどの既存機能がチームの注意を必要としているのか、痛いほど明らかになります。
質問 2: 誰が開発するのか？
アイデアを出すのは簡単ですが、実行するのは難しいものです。この質問に自己批判的に取り組まなければ、プラットフォームを構築するはずのチームが、アイデアを提案しただけのチームになってしまいます。受け入れ難いかもしれませんが、これはあなたやプラットフォーム エンジニア、プラットフォーム責任者、CIO に関するものではなく、ユーザーに関するものだということを忘れないでください。ユーザーのニーズを最優先に、個人的な希望はその次に据えて、最適なプラットフォーム チームを編成する必要があります。
次に、プラットフォーム チームはどうあるべきでしょうか。簡単に言えば、少人数で部門横断的な専任のプラットフォーム チームが理想的です。10 人が他の多くの優先的な日常業務を行いながら新しいプラットフォームに取り組むよりも、3 人のエンジニアがフルタイムで新しいプラットフォームに取り組む方が良いでしょう。そのためには、専任のスタッフと、開発の初期段階でこのチームを支援する強力な上層部の支持者が必要です。あらゆるデジタル ネイティブ企業が、この方法で社内プラットフォームの構築に着手しているため、これをおすすめします。
プラットフォームの構築で課題となるのは、実行ではなく学習であるため、チームの成功には迅速なフィードバック ループと学習の共有が非常に重要です。これは、チームメンバーが互いに（物理的または仮想的に）近くに座り、他のチームへの依存が最小限に抑えられている場合にのみ成功します。また、各個人が自分の専門知識やジョブ プロファイルに合った仕事しか引き受けず、「自分の仕事ではない」と断ってしまうような事態を避けるためにも、このような近接は不可欠です。「方法を見る」という心構えを共有することで、チームメンバーは最初からそれぞれのサブジェクト マター エキスパート（SME）の作業を確認できますが、チーム全員が技術的課題を解決できることが期待されます。
最後に、特定のサービスを使用するために、他の人（CISO やエンタープライズ アーキテクトなど）の承認が必要になる場合は、少なくともチームの貢献が Policy as Code やアーキテクチャ ブループリントの形でプラットフォームに組み込まれるまでは、それら承認者（またはその代理人の 1 人）をチームの中核メンバーに据えます。
質問 3: 成功をどのように測定するのか？
プラットフォームがスコープ内、期限内、予算内に提供されても、広く普及しなければ誰も利益を得ることができません。誰もが利益を得られるようにするには、プラットフォーム チームの成功をこの種のプロジェクト KPI（スコープや期限、予算）で測定しないことです。代わりに、プラットフォームの有用性、導入状況、ユーザー満足度を測定するプロダクト KPI に注目します。
ソフトウェア プロダクトの成功を測定するうえで、すべてに当てはまる唯一の正しい方法はありませんが、次の 3 つの質問に対する適切な答えは、成功に向かって進んでいることの証明になります。
ユーザーが目標を達成するまでにどれくらいの時間がかかるか？（少ないほど良い）
何人のユーザーが、どれくらいの頻度でそのプラットフォームを使用しているか？（多いほど良い）
ユーザーはどの程度満足しており、このプラットフォームを他の従業員にすすめる可能性はどれくらいあるか？
Google は、消費者向けプロダクトの多くに H.E.A.R.T. フレームワークを使用しています。また、社内 IT プラットフォームの一部には、S.U.P.E.R. と呼ばれる変更されたプラットフォームも使用しています。
ユーザーに歩み寄る
ここまで、プラットフォームを構築する際に、社内ユーザーとの距離を縮めることが非常に重要である理由を説明し、ユーザーの同時視聴セッションを促進することで距離を感じさせないようにする方法を紹介しました。また、少人数で部門横断的な専門のチームを作ることの重要性と、ただ単に IT プロジェクトを 1 つ完了してから次のプロジェクトをこなすのではなく、従業員の仕事をより快適にする魅力的なプラットフォームを構築するという動機を高める方法について取り上げました。
今回は、プロダクトとしてユーザーを引き付けるプラットフォームを計画、構築、実行することが何を意味するのか、そのほんの一部を説明したにすぎません。ユーザーのペルソナ、ユーザー ジャーニーのマッピング、プロダクト マネージャーの真の役割の重要性などをはじめとして、まだまだ多くのことを語ることができます。
この記事で伝えられる重要なポイントが 1 つあるとしたら、「ユーザーが何を必要とし、何を望んでいるかはわからない」ということです。仮説を立てても、それを証明したり反証したりする必要があります。プラットフォームを構築したからといって、ユーザーに活用してもらえるとは限りません。ユーザーに歩み寄ってみてください。
