インフラストラクチャプラットフォームの構築

測定可能な目標を伴う戦略を持つ

「目標を達成できなかった」というのは、何かを数週間または数か月間取り組んだ後に、関係者から聞く可能性のある最悪のことでしょう。インフラストラクチャプラットフォームの世界では、これは問題であり、幹部がそのアイデアを破棄し、予算を他の分野（多くの場合、問題を悪化させる可能性のあるより多くの製品チーム）に費やすことを決定する可能性があります。これを防ぐのは難しいことではありません。すべての関係者が同意する、目標とそれを達成するための戦略を作成することです。

戦略を作成する最初のステップは、問題を定義するために適切な人々を集めることです。これは、組織で何が起こっているかについてコンテキストを提供するのに役立つSMEによって支援された、製品および技術エグゼクティブ/予算保有者の混合である必要があります。以下に、優れた問題ステートメントの例をいくつか示します。

上位15の製品チームにインフラストラクチャの能力を持つ人が十分にいないため、必要な人数を雇うためのリソースがなく、製品の市場投入までの時間が平均6か月遅れています

過去18か月間で、製品の停止時間は合計160時間に達し、200万ドルを超える収益損失が発生しています

これらの問題ステートメントは、課題について正直であり、理解しやすいものです。問題ステートメントを作成できない場合は、インフラストラクチャプラットフォームが必要ない可能性があります。また、インフラストラクチャプラットフォームを作成することで対処したい問題が多数ある場合は、これらをリストアップしますが、ドライバーとして1つを選択し、それに焦点を当てます。複数の問題ステートメントがあると、インフラストラクチャチームが達成することを約束しすぎて、達成できなくなる可能性があります。異なる結果で多くのことを優先順位付けしても、実際には何も達成できません。

次に、問題ステートメントを目標に変換します。例えば

上位15の製品チームに、市場投入までの時間を平均6か月短縮するために簡単に利用できるインフラストラクチャを提供する

今後18か月以内の停止時間を3時間未満にする

これで、問題に対処するための戦略を作成できます。ここに、その方法についての楽しいアイデアをいくつか示します。

これらのセッションの両方を行うことを強くお勧めします。過去と未来の両方のレンズを使用すると、目標を達成し、問題を解決するために必要なことについての新しい洞察が得られます。過去について考える方が脳は簡単に感じるため、最初にポストモーテムを行ってください！1つだけ時間がある場合は、未来を振り返るセッションを行ってください。なぜなら、未来はまだ発生しておらず、より幅広いアイデアと既成概念にとらわれない思考を促進できるため、このセッションの範囲はわずかに広いためです。

これらのセッションの一方または両方を行うことで、目標を達成するために必要なことの実用的なリストが素晴らしいものになることを願っています。これがあなたの戦略です（ビジョンと目標は戦略ではないことに注意してください!!! Richard P. Rumeltの「良い戦略悪い戦略」を参照してください）。

興味深いことに、インフラストラクチャプラットフォームを構築するためのチームを立ち上げることが戦略の一部ではないと判断する可能性があります。それで構いません！インフラプラットフォームは、すべての組織に必要なものではありません。この記事の残りの部分をスキップして、Martinのブログでもっと面白いものを読むことができます！幸運にも、戦略の一部としてインフラストラクチャプラットフォームを作成している場合は、さらに素晴らしいアドバイスのためにシートベルトを締めてください。

顧客のニーズを把握する

私たちアジャイリストは、製品が作られたものの、ほとんどユーザーがいなかったという話を聞くと、適切なユーザー調査を行わなかったのだろうと呆れてしまいます。そのため、多くの組織がプラットフォームインフラを構築したものの、どのチームも利用しないという状況を知ると驚くかもしれません。これは、そもそも誰もその製品を必要としていなかったからかもしれません。あるいは、インフラ製品を構築するのが遅すぎて、すでに各チームが独自のものを構築していたのかもしれません。もしかしたら、構築するのが早すぎて、他のバックログの優先度が高くて誰も気にしていなかったのかもしれません。あるいは、構築したものがユーザーのニーズに合致していなかったのかもしれません。

したがって、何を構築するかを決める前に、顧客向け製品の場合と同様にディスカバリーを実施してください。ディスカバリーを実施したことがない方のために説明すると、ディスカバリーとは（通常は）時間制限付きのアクティビティで、チーム（理想的にはソリューションを構築するチーム）が、何かを構築する問題領域や理由を理解しようとします。このディスカバリー期間の終わりに、チームはインフラ製品のユーザー（複数のタイプのユーザーがいる場合があります）が誰であるか、ユーザーが抱えている問題、ユーザーがうまくやっていること、そしてチームが構築するインフラ製品の大まかなアイデアを理解している必要があります。また、人々が使用しているテクノロジー、以前に試したもののうまくいかなかったこと、知っておく必要のあるガバナンスなど、役に立ちそうなその他のことについても調査できます。

戦略策定の一環として問題定義を行うことで、組織のニーズを理解します。次に、このニーズがユーザーニーズ（ユーザーとは主に開発者であるプロダクトチーム）とどのように重なるかを理解する必要があります。戦略を念頭に置いて活動に焦点を当ててください。たとえば、戦略がセキュリティに焦点を当てている場合、次のことを行う可能性があります。

• セキュリティ侵害の例（原因を含む）（事後分析を行った場合はその情報を使用）を強調する
• セキュリティに関与するさまざまな人（セキュリティ責任者、技術責任者、技術リーダー、開発者、QA、デリバリーマネージャー、BA、情報セキュリティ担当者など）にインタビューする
• イベントストーミングなどのワークショップを使用して、製品の既存のセキュリティライフサイクルをマッピングする。インフラプラットフォームがサービスを提供したい期間内で、できるだけ多くのチームでこれを繰り返す

ディスカバリーの一環として一つだけ行うのであれば、イベントストーミングを実施してください。顧客となるチームまたは複数のチームを、物理的な壁のある物理的な部屋または仮想ホワイトボードのある通話に集めます。この図に開始点と終了点を含むタイムラインを描きます。インフラプラットフォームのディスカバリーでは、プロジェクトの開始からユーザーが利用できる本番環境になるまでをマッピングすると役立ちます。

次に、プロジェクトの開始から本番環境になるまでのすべての出来事を、1色の付箋にマッピングするように全員に依頼します。

次に、チームに、不満な点、うまくいかないこと、または常にうまくいかないことを別の色の付箋で重ねて表示してもらいます。

時間があれば、使用されているテクノロジーやシステム、さまざまな部分にかかる時間、さまざまな部分に関与する可能性のあるさまざまなチームなど、潜在的なユーザーが直面している問題領域のアイデアを得るのに役立つ可能性のあるその他の情報を重ねることができます（これは、セッション後に特定の領域を深く掘り下げて調査する場合に役立ちます）。セッション中およびセッション後、ファシリテーター（ディスカバリーを実行しているチーム）は、各付箋の背景を理解し、必要に応じて興味のある領域を深く掘り下げてさらに調査する必要があります。

ディスカバリー活動をいくつか行い、ユーザーが顧客向け製品を提供するために必要なもののアイデアを得たら、最も早く最大の価値を提供できるものを優先順位付けします。ディスカバリーを形作るのに役立つオンラインリソースはたくさんあります。良い例はgov.ukです。

早期にユーザーをオンボーディングする

「それは私たちには使えない」というのは、特に、すべての正しいことを行い、ユーザー（開発者）のニーズとエンドユーザーのニーズを真に理解した後に、インフラプラットフォームに関して聞きたくない最悪の言葉かもしれません。実際、なぜこのような状況に陥ったのかを考えてみましょう。作成しているインフラ製品をエピックやストーリーに分解し、細部にまで深く入り込むにつれて、あなたとあなたのチームは製品について意思決定を行うことになります。あなたが下す意思決定の中には、小さくて重要でないように思えるものもあるため、ユーザーとすべての小さな詳細を検証するわけではありません。当然のことながら、小さな実装の詳細を定義するたびに、ビルドの進行を遅らせたり、停止させたりしたくないでしょう。これは問題ありません！しかし、数か月が経過しても、インフラ製品を構成するこれらの小さな意思決定についてフィードバックが得られていない場合、構築しているものがユーザーにとって完全には機能しない可能性はますます高まります。

従来の製品開発では、最小限の実行可能な製品（MVP）を定義し、早期のフィードバックを得るでしょう。私たちが一般的に苦労していることの1つは、インフラプラットフォームにおいてはさらに、実行可能な製品とは何かを知ることです。インフラプラットフォームを構築する理由を振り返ってみると、実行可能とは、セキュリティリスクが軽減されたとき、またはチームの市場投入までの時間が短縮されたときかもしれません。ただし、この定義から「実行可能」になるまでユーザー（プロダクトチームの開発者）に製品をリリースしない場合、「それは私たちには使えない」という回答の可能性が高くなります。したがって、インフラプラットフォームについて考える場合、最初のユーザーがオンボードする時期として、最短価値パス（SPV）について考えることを好みます。最短価値パスとは、その名前が示すように、チーム、ユーザー、組織、またはそれらの組み合わせのいずれであっても、最も早く価値を得られるのはいつかということです。SPVアプローチを好むのは、これにより、学習の最も早い機会がいつであるかを継続的に考え、より薄いスライスを推進するのに役立つためです。したがって、お気づきでないかもしれませんが、ここでのポイントは、可能な限り早くユーザーをオンボードして、何が機能するか、何が機能しないかを見つけ出し、組織全体でのより広い消費のためにこのインフラ製品を改善するための次の開発努力をどこに注力すべきかを決定できるようにすることです。

技術的なビジョンを伝える

おそらく当然のことながら、ここで重要なのは、技術ビジョンを早期に明確にすることです。複数のチームがあなたと同じものを構築するのを防ぎたいでしょう（これは実際に起こります！）。利害関係者があなたが何をしているのか、そしてなぜそうしているのかを知るようにしてください。これはソリューションに対する信頼を築くだけでなく、製品に関する早期の洞察を得るためのもう1つの機会になります！

あなたのビジョンは、高精細なUMLの傑作である必要はありません（共通のモデリング形式の多くは頼りにするのに非常に役立ちます）。ホワイトボードと油性ペン/ホワイトボード用マーカーをつかんで、自由にやりましょう。アイデアを伝えようとすると、物事は混乱するので、簡単に拭いてやり直せるようにすることが重要です！これらの種類の図に対してCADプログラムにすぐに飛びつく誘惑は避けてください。それらは最終的にあなたを創造的なプロセスから遠ざけます。

とはいえ、この段階で実装するのに十分な軽量ツールがいくつかあります。たとえば、次のようなものがあります。

技術ビジョンを構築できたら、それを使用して進捗状況を伝えてください！スプリントデモに持ち込みます。チームとの設計に関する会話を導くために使用します。次の脅威モデリング演習にちょっとした日帰り旅行に出かけましょう。このドキュメントでは、C4図の表面を少しなぞっただけです。これをより深く探求する素晴らしい記事がたくさんあります。まず、このInfoQの記事から始めてください。

そしてそこで止まらないでください！上記のテクニックは当面の会話を導くのに役立ちますが、ソフトウェアはあなたが引退した後も長く存在する可能性のある生き物であることを忘れないでください。技術ビジョンを、あなたの手を導くことができた一連の意思決定として伝えることができることは、もう1つの便利なツールです。

ユーザーの立場になって考える

組織内で、オンボーディングが非常に簡単で手間がかからない内部ツールやサービスをお持ちの場合は、幸運です。私たちの経験からすると、必要なものにアクセスできるようになることは、まだ非常に驚くべきことです。したがって、インフラストラクチャプラットフォームを構築するために時間と労力を費やし、オンボーディングするチームが「すごい、簡単だった！」と言うような世界を想像してみてください。インフラストラクチャプラットフォームを構築する理由が何であれ、これが目標であるはずです！インフラ製品の使用を義務付けなければならない場合は、物事がうまくいかないことがよくあります。そのため、人々が製品を使いたくなるように実際に努力する必要があります。

通常の製品開発では、ユーザー調査、サービスデザイン、コンテンツ作成、ユーザーエクスペリエンスの専門家などの能力を持つ人がいるかもしれません。プラットフォームを構築する場合、これらの役割を果たすことを忘れがちですが、組織内の人々がプラットフォーム製品の使用を楽しむようにしたい場合は、同じように重要です。したがって、開発者、BA、UX担当者のいずれであっても、インフラストラクチャ製品のエンドツーエンドのサービスデザインを推進する人がチームにいることを確認してください。

開始する簡単な方法は、ユーザーの旅を描くことです。オンボーディングの例を見てみましょう。

この旅がどのようなものかの背景がなくても、ユーザーエクスペリエンスがそれほど友好的ではない可能性を示す兆候となるものがあります。

• 開発者ユーザーとプラットフォームチーム間の引き渡し
• 開発者ユーザーがオンボーディングで後退する可能性のあるループがいくつかあります。
• 自動化の欠如 - プラットフォームチームによって多くのことが行われています。
• 開発者ユーザーがオンボーディングを完了するまでに9つのステップがあり、その間に待ち時間と遅延が発生する可能性があります。

理想的には、オンボーディングプロセスはこのようになるはずです。

ご覧のとおり、オンボーディングにプラットフォームチームの関与はないため、完全にセルフサービスであり、開発者ユーザーが従うステップは3つだけです。ユーザーにとってそのような素晴らしいエクスペリエンスを実現するには、何を自動化できるか、何を簡略化できるかを検討する必要があります。シンプルなユーザーの旅とシンプルなコードベースの間にはトレードオフがあります（「複雑にしすぎない」で説明したように）。どちらも重要なので、このトレードオフが、そもそもプラットフォームを提供している理由に適していることを保証できる強力なプロダクトオーナーが必要です。たとえば、製品をより迅速に市場に投入できるようにプラットフォームを構築しているのであれば、シームレスで迅速なオンボーディングプロセスは非常に重要です。

実際には、オンボーディングプロセスはこれに似ているかもしれません。

特に、mvpをリリースするとき（前のセクションを参照）。この考え方を、製品の使用時にチームが経験する必要がある可能性のある他のインタラクションやプロセスに適用してください。優れたユーザーエクスペリエンスを作成することで（そしてもちろん、人々が求めるインフラ製品を持つことで）、幸せなユーザーだけでなく、組織内で他のチームがオンボーディングしたいと思うような素晴らしい広報活動も行う必要があります。このアドバイスを無視して、組織が消費するのが悪夢のようなインフラストラクチャプラットフォームの使用を義務付けており、すべての開発チームが悲しんでいる状況にならないでください:(

物事を複雑にしすぎない

すべてのソフトウェアは壊れています。事をあまり落胆させたくないのですが、書いたコードのすべての行は、すぐに時代遅れになる可能性が非常に高いです。すべてのifステートメント、デザインパターン、すべての構成行には、破損したり、奇妙な副作用を引き起こしたりする可能性があります。これらは、再現が困難なバグまたは本格的な障害として現れる可能性があります。プラットフォームも例外ではありません！製品に派手なレスポンシブUIや高可用性APIがないからといって、バグが発生しないという意味ではありません。そして、構築しているものが他のチームが独自のサービスを構築するプラットフォームである場合はどうなりますか？

他のチームが依存するインフラストラクチャプラットフォームを開発している場合、顧客の開発環境は本番環境です。プラットフォームが倒れると、他の全員を巻き込む可能性があります。他のチームの開発プロセスにダウンタイムを導入するリスクを冒したくはないでしょう。信頼を損ない、助けようとしていた人々との関係を損なうことさえあります！

ソフトウェアのバグの主な（そしてひどく陰湿な）理由の1つは、複雑さに関係しています。サポートされる機能の数が多ければ多いほど、プラットフォームが実行しようとするほど、誤動作する可能性が高くなります。しかし、プラットフォームチームで複雑さが生じる主な理由の1つは何でしょうか？

コンウェイの法則は、すでによく知っている人もいるかもしれませんが、組織は自身の内部コミュニケーション構造を反映したシステムを設計する傾向があることを述べています。ソフトウェアの観点からすると、多くの場合、システムは組織の歴史の中で特定の時点に対応する特定の「注意点」または「回避策」を使用して設計されている可能性があります。これは必ずしも悪いことではありませんが、現場での設計決定に簡単に影響を与える可能性があります。APIを構築している場合、この種の設計決定はチーム内で十分に処理できます。ただし、多くの異なるチーム（およびそれらのさまざまなニュアンスの多様性）に対して多数の異なる統合を備えたシステムを構築している場合、これはより大きな問題になります。

それでは、ビジネスプロセスに密接に結合された多数のきめ細かいコンポーネントを記述することと、組織の成長をサポートできるプラットフォームを構築することの間で、どこに最適な場所があるのでしょうか？

一般的に言えば、チームとして記述するすべてのコンポーネントは、測定、保守、サポートが必要になる別のものです。既存のアーキテクチャ上の負債、コンプライアンスの制約、またはセキュリティ対策によって制限されている場合もあります。ここで私たちの教訓は、ソリューションに別のコンポーネントを導入する前に、もう一度考えてみることです。開発するすべての可動部は、ライブ後のサポートへの投資であり、潜在的な故障モードです。

重要なものを測定する

より優れたインフラストラクチャプラットフォームの構築に関する記事は、物事を測定することについての注意書きなしには完了しません。以前に、測定可能な目標を設定して戦略を定義することについて説明しました。それでは、成功とはどのようなものでしょうか？これはコードで抽出できるものですか？おそらく、運用上の摩擦を減らすことでユーザーのデプロイ頻度を増やしたいと考えているのではないでしょうか？おそらく、あなたの真北は、チームが依存できる安定した安全なアーティファクトリポジトリを提供することにあるのではないでしょうか？時間をかけて、この成功指標を軽量ダッシュボードに変えることができるかどうかを確認してください。勝利を祝うことができることは、チームの士気と、組織全体でのプラットフォームへの信頼を構築するのに役立つ大きなメリットです！