プラットフォームをプロダクトとして扱う

第2章 製品としてのプラットフォーム 製品としてのプラットフォーム

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

プラットフォームと 内部開発者プラットフォーム（IDP）という用語は、単一の既製品のPaaS（Platform as a Service）製品、または組織が内部使用のためにキュレートしたツールの特注コレクションを表すことができる。これらの定義は、プラットフォームは、インフラプロジェクトであり、始まり、納品マイルストーン、そして、開発者が構築されたものや購入したものを使用するという漠然とした希望を持つものであるという考えを強める可能性がある。しかし、このアプローチが持続的な価値をもたらすことはほとんどない。

単なるツールのスタックではない

プラットフォームとは、単なるツールやテンプレート、ワークフローの集まりではない。ユーザのニーズに継続的に対応しなければならない、進化するシステムなのだ。そのためには、プロジェクトとしてではなく、製品として扱われなければならない。

製品としての考え方を採用するには、ビジネスコンテキストを継続的に評価し、「構築か購入か」の決定を管理することから始める。規模、コンプライアンス要件、従業員のスキルベースや技術スタックの多様性といった文脈上の要因によって、組織はしばしば、既製の解決策を選択せず、特定のニーズに合わせて設計された統合機能セットに投資する必要がある。その結果、プラットフォームにはユーザが存在し、設計、反復、フィードバック、明確な価値提案が必要となる。これらすべてを考慮する考え方がなければ、プラットフォームチームは、成果に焦点を当てた戦略的イネイブリングチームではなく、機能リクエストに追われる社内サービスプロバイダになってしまう危険性がある。

この章では、プロダクト思考への基本的なシフトを探り、プラットフォームチームが初日以降も続く価値をもたらす方法を概説する。

プロダクトマインドの実践

共著者のコリン・ハンフリーズ氏は、プラットフォーム製品を「既存のシステムと統合された、再利用可能なサービスの進化したセットであり、ビジネスに価値ある成果を作成するもの」と定義している。それは一度限りの提供ではない。意図的で、ユーザを重視した設計（ユーザとは、主にエンジニアを含むが、エンジニアに限定されない、プラットフォームと対話するすべての人のことである）を通して、ソフトウェアのデリバリーをサポートし、加速するための持続的な取り組みである。

図2-1に示すように、この製品マインドセットでは、実現可能性（技術的に可能なこと）、実行可能性 （ビジネスとして理にかなったこと）、ユーザビリティ （開発者が実際に使いたいこと）、価値（プラットフォームが組織にもたらす測定可能な成果）の間でバランスを取る必要がある。また、プロダクトマネジメント、UXデザイン、ユーザリサーチなど、従来インフラとは無縁のスキルも必要となる。

図2-1. 製品の考え方

このアプローチで成功するプラットフォームチームは、次のような傾向がある：

• ユーザと直接コラボレーションし、ユーザがプラットフォームとどのように対話するかを観察し、真の痛点を特定する。