Platform as a Product 〜開発チームのためのプラットフォーム
まずPais氏は、プラットフォームを定義するところから本セッションを始めた。ここでは、プラットフォームを「魅力的な社内製品としてまとめられたセルフサービスAPI・ツール・サービス・ナレッジ・サポートの集合体」だと位置づける。
プラットフォームの存在意義は、開発チームの仕事をやりやすくすることだ。具体的には、開発チームの認知負荷を下げること。そして開発チームが、リードタイム・デプロイ頻度・平均修復時間・変更失敗率といったメトリクスを改善しながら、顧客への価値提供や課題解決への集中を支援することだ。
しかし、プラットフォームを適切に実装しないと、開発チームの認知負荷が増加し、逆に生産性が低下する可能性がある。具体的には、利用時に常にプラットフォームチームへの依頼が必要となるものや、サービスの統合が不十分で複数のインターフェースを使い分けねばならないもの。そして頻繁にダウンしたり、速度が遅すぎたりするなど、パフォーマンスが低いものが挙げられる。そのような開発チームに苦痛をもたらすプラットフォームは、そのうち使われなくなる。
逆に、優れたプラットフォームが備えるべき性質は何だろうか。Pais氏は、先程のプラットフォームの定義を引用しながら、以下の特徴を列挙する。まずプラットフォームは、セルフサービスで利用できなければならず、プラットフォームチームの作業を待つ必要はない。またプラットフォームチームは、そのために必要なナレッジとサポートも提供しなければならない。
加えて、プラットフォームは、インフラ、監視、データなどの物事をシンプルにし、デリバリーを加速させるためのものだ。そのためにはプラットフォームは、できるだけシンプルに厳選された、相互補完的なサービスやパターンで構成されるべきだと、Pais氏は言う。
例えば、手順やノウハウを記した、シンプルなWikiページであっても、立派なプラットフォームになりうる。Wikiページがあることで、新しいメンバーがすぐに仕事に取りかかり、より早く会社に価値を提供できるようになるからだ。
次に、「プラットフォームが製品である」とは何を意味するのだろうか。
Pais氏は、ここでの「製品」を以下のように定義する。製品とは、機能・デザイン・マネタイズ・コンテンツが一体になったものだ。製品を使うかどうかはユーザーの自由であり、強制されるべきではない。また製品は、ユーザーのペルソナやジャーニーに沿って慎重に設計される。製品は、ユーザーの仕事をシンプルにし、テクノロジーの変化に応じて進化すべきものだ。
これらの要素をプラットフォームに当てはめると、製品としてのプラットフォームは以下の性質を備えることになる。
- プラットフォームは、開発チームが自ら進んで使うべきものだ。使用を強制されるものや、誰も理解できないものは役に立たずに廃れる。また、利用を促進するためのマーケティング活動も必要になる。
- プラットフォームはユーザーとなる開発チームを念頭に置いて設計する必要がある。ユーザーとの対話を通じて、そのニーズに基づき、機能追加や、タスクやワークフローの簡素化をしなければならない。
- 毎週・毎月のように起きる変化に対応できないと、プラットフォームは開発チームから信頼してもらえない。そこでプラットフォームは、明確かつ柔軟なロードマップに基づいて、提供する機能を進化させる必要がある。
このような製品としてのプラットフォームを発展させるには、熟練したプロダクトマネージャーが必要だと、Pais氏は言う。つまりユーザーである開発チームのニーズを理解し、優先度をつける能力を持つ技術者でなければならない。
プラットフォームは時間とともに成長していくが、提供するサービスは厳選するべきだ。そしてプラットフォームチームと開発チームのインタラクションの中で、適切な規模感を探る必要があると、Pais氏は続ける。
