プラットフォームをプロダクトとしてどう構想し、成長させていけばよいか? 「Platform as a Product」5つのフェーズ
第6回 プラットフォームの構想から成長まで
仮説期:最初の顧客と解くべき課題を決める
仮説期ではまず顧客セグメントを明らかにします。ここでいう顧客とは一般のエンドユーザではなく、社内の開発者(ストリームアラインドチーム)を顧客と見立てることがポイントです。顧客セグメントは通常のプロダクト開発と同様に、十分な市場規模が必要です。そのため、市場規模が大きい社内の事業領域を含める必要があります。事業領域の選択時には、経営層などのステークホルダーへの説明を推奨します。事業領域の選択理由と他の事業領域への展開予定を説明しておくと、今後の活動の理解を得やすいでしょう。
最初に選択した事業領域の中でも、実現したい世界観に共感しプラットフォームチームと積極的に活動する「アーリーアダプター」を優先して探します。このようなストリームアラインドチームの成果は、社内でもフラッグシップ事例として扱われることが多いです。フラッグシップ事例の成功は、他のストリームアラインドチームでのプラットフォーム採用を後押しします。
顧客セグメントが定まったら課題を深堀りしていきます。プラットフォームが解決すべき主な課題には以下のようなものがあります。
- 環境準備の複雑さ
- ツール間の連携不足
- 社内のセキュリティルールの順守
- ナレッジの分散
課題は会社ごとに重要度が異なります。これまでの開発の改善活動では、課題を主に品質、作業時間、リードタイムの3点に着目していました。プラットフォームにおいては、これらのほか認知負荷の観点も加え、課題の洗い出しと優先度付けをして整理していきます。社内向けプロダクトである特性を活かし、顧客が本当に困っている課題にフォーカスできているかはストリームアラインドチームへヒアリングすることで検証するとよいでしょう。
検証期:独自の解決方法を探索する
仮説期で発見した課題に対する解決方法を検討します。注意点として、今回検討した解決方法は、すでにストリームアラインドチームが利用している、もしくは利用経験のある既存のツールや開発プロセスから乗り換えられるほど、独自の価値があるかということです。独自の価値があるかを探索するためには、通常のプロダクト開発と同様、モックやイメージ図を利用して机上検証を繰り返すことが可能です。独自価値の具体例としては以下のようなものがあります。
- 社内の標準ツールや既存ツール間の連携
- セキュリティルールへの準拠
- ストリームアラインドチーム間でナレッジをシェアする仕組み
独自の解決方法が机上で見えたら、機能を開発して検証します。新しい機能の開発にはストリームアラインドチームとプラットフォームチームが責任を共有する「コラボレーション」という連携方法が適しています。詳細は以下の記事で解説しています。
注意点として、コラボレーションした特定チームにしか利用されないプラットフォームにならないようにする必要があります。具体的な対策としては「解決方法の仕分け」と「機能のオプション化」があります。
解決方法の仕分けについては、検討した解決方法が、特定のチーム、特定の事業領域、プラットフォームのどこで開発すべきかを選別します。機能のオプション化は、必要な機能をオプションとして選択して利用できる構成にすることです。オプション化により、より多くのストリームアラインドチームが既存ツールと組み合せてプラットフォームを利用できます。
この記事は参考になりましたか?
- プラットフォームづくりを成功に導く!開発者のための「Platform Engineering」入門連載記事一覧
-
- チーム全員の生産性を上げる! メルカリ deeeetさんに聞く、Platform Engi...
- Platform Engineeringの先人 メルカリに学ぶ! プラットフォームチームの...
- プラットフォームをプロダクトとしてどう構想し、成長させていけばよいか? 「Platform...
- この記事の著者
-
井沢 祐介(イザワ ユウスケ)
株式会社野村総合研究所に所属し、生産性向上プラットフォーム事業「aslead」に従事。CI/CD、ソースコード検索、AIコーディングなど社内の開発生産性を向上するプロダクトを社内に提供し、マンパワーに頼らない開発体制の実現に向けて活動中。また、社外では現職の経験を活かしPlatform Engin...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
