プラットフォームエンジニアリングのカギ「オンボーディングプロセス」の落とし穴

プラットフォームリリース時に欠落しがちな「オンボーディング」

企業はプラットフォームのリリース時からユーザーエクスペリエンスを重視することで、導入率とユーザーエンゲージメントにおいて非常に大きなメリットを得られます。

筆者がこれまでいくつかのプラットフォームチームと仕事をする中で、どの企業にも同じ弱点があることに気付きました。それは、プラットフォームのユーザーであるデベロッパーのオンボーディングプロセスです。

予算が限られている新興のスタートアップ企業であれ、リソースに余裕のある大企業であれ、デベロッパーがプラットフォームに触れる体験を軽視する例が多く、これが導入の大きな妨げとなりがちでした。

これについて、マーケティング戦略のイノベーター理論を例に見てみましょう。実際にはイノベーター理論とは、新たな製品（商品・サービス）などの市場における普及率を示すものですが、ここでは企業のプラットフォームエンジニアリングチームが、チーム内のデベロッパーにプラットフォームを普及させるプロセスとして解説します。

イノベーター理論では「ユーザー導入率16%」という数字が、イノベーションが初期市場からメインストリーム市場へと移行できるかどうかの重要なしきい値となります（普及率16%の論理）。

市場投入当初は未完成のソリューションであっても、寛容で、かつ好奇心旺盛なイノベーターやアーリーアダプター（早期導入者）によって初期の導入が推進されます。ところが、普及率が16%に到達し、さらにそれを超えるためには、ソリューションをより使いやすく改善してアーリーマジョリティ（初期段階で加わる慎重な一般ユーザー層）の注目を集める必要があります。

市場全体のうち34%を占めるアーリーマジョリティは、メインストリーム市場で成功を収める上で非常に重要な存在です。彼らが求めるのは、実証された価値、安定性の証明、直感的な使いやすさなのです。

これを、プラットフォームのオンボーディングプロセスに当てはめると、デベロッパーの期待がユーザーの層によって異なるため、プラットフォームの取り組みでは対処しきれない課題が生じるのです。

オンボーディングプロセスに欠陥や摩擦点があっても、初期導入期のデベロッパーなら気にしないか気付かないかもしれませんが、メインストリームユーザーは見逃さないでしょう。ここから、プラットフォームのオンボーディングプロセスを構築する際に考慮すべき重要な点をいくつかご紹介しましょう。

永続的に使用できる独自のブランドアイデンティティを選ぶ

プラットフォームのネーミングなどブランドアイデンティティは、デベロッパーとソリューションとの最初のタッチポイントとなります。特定のツールやフレームワークを参照せずともデベロッパーにもわかりやすく伝わる、自社ならではのものを選択しましょう。

プラットフォームの効果的なネーミングの特徴
・基盤となるインフラストラクチャに関してではなく、得られるメリットについて伝える
「K8sパイプライン」のような専門用語を使用せずに、「Runway（滑走路）」のように意図する価値提案を強調する名前を付けることを検討しましょう。
・プラットフォームの目的が伝わる、明確で記憶に残る言葉を用いる
一度耳にしただけで理解でき、記憶に残るかどうかが大切です。多くの場合、「Beacon」のようにシンプルで発音しやすい名前の方が、「Syzygy」のように複雑なものより効果的です。

よくありがちな命名ミス
・名前にバージョン番号を含める
過去のイテレーションが失敗を想起させ、持続性への懸念を生じさせます。
・他の略語と区別がつかないような、覚えにくい3文字の組み合わせを選ぶ
・テクノロジーに焦点を当てた名前を付ける
これでは、デベロッパーのニーズよりもシステムを重視していると捉えられます。

プラットフォームの第一印象は、その大部分が視覚的な情報に左右されます。たとえ基本機能がしっかりしていたとしても、インタフェースが時代遅れだったり、一貫性がなかったりすると、デベロッパーが離れてしまう可能性があります。ブランディングの統一性、配色パターン、メッセージのトーンに気を配りましょう。これらの要素はあまり重要でないように見えるかもしれませんが、ユーザーインタラクションの基盤となります。

プラットフォームエンジニアリングチームは専門用語を避けて、デベロッパーから見て明確で親しみやすいコミュニケーションを目指しましょう。伝わりやすい言葉づかいにより、部署やスキルレベルを問わず、さまざまなチームのメンバーに「使いやすいプラットフォーム」という印象を与えられます。

初期の利用プロセスの効率化

多くの組織は、スムーズで簡単なエクスペリエンスの提供という基本的な要件を軽視したまま、プラットフォーム機能の改善に数カ月も費やしています。 この傾向は規模や業種を問わず見られ、次のような障害を生じています。

・セルフサービスとうたっているにもかかわらず、プラットフォームへのオンボーディングプロセスが手動である
完全に自動化できない場合は、手作業をできる限り非同期で処理するようにしましょう。
・長い承認ワークフローや制限により、すぐにテストを行えない
この問題に対するおすすめの解決策は、プラットフォームへの一時的な即時アクセスを30日間トライアルで提供することです。30日あれば、プラットフォームが役に立つかどうかを判断し、フルアクセスの取得に必要なリクエストを提出するのに十分です。
・プラットフォームの利用前にトレーニングが必要
トレーニングは有用ですが、前提要件とするのではなく、プラットフォームの利用開始後に受講してもらうべきです。

包括的なサポート体制の確立

どれほど優れたプラットフォームであっても、ユーザーであるデベロッパーへのサポートは不可欠です。迅速で応答性の高いサポートの提供は、デベロッパーからの信頼を得る上で最も効果的な方法です。サポート対応時にはデベロッパーの不満を最小限に抑え、導入の勢いを維持することを目標とします。

プラットフォームエンジニアリングチームは、次のような手段を使用して、強力なサポート体制を構築しましょう。

・チケットシステムを使用すると、課題を追跡できます。また、既存のワークフローへの統合も可能です。
・十分な説明が求められる複雑なトピックに対応する際は、メールでのやり取りが適しています。
・リアルタイムチャットを使用すると、デベロッパーの作業中に即座に問題を解決できます。
・ドキュメントハブでは、よくある質問に対する回答をセルフサービス形式で提供できます。

プラットフォームエンジニアリングチームは、複数のプラットフォームをモニタリングしなければならないとしても、デベロッパーが希望するコミュニケーション手段で常にサポートを提供できる状態を維持しましょう。デベロッパーからのチャットリクエストには1時間以内に対応し、解決策を必ず公開して、組織全体がその恩恵を得られるようにしましょう。

プラットフォームを成功に導くための設計図

優れたプラットフォームエンジニアリングを構築するために必要なのは、最適なテクノロジーを選ぶことではありません。その土台となるのは、デベロッパーに対する共感と理解です。卓越したプラットフォームチームは、デベロッパー、セキュリティ担当者、運用担当者の日常業務を深く理解しています。そして、これらのチームが直面する制約や、成功の指標、最大の障害となっている要因を把握しています。

企業はプラットフォームのリリース時からユーザーエクスペリエンスを重視することで、導入率とユーザーエンゲージメントの面で非常に大きなメリットを得られます。スムーズなオンボーディングワークフロー、包括的なドキュメント、信頼性の高いサポートチャネルを構築することで、デベロッパーに手間をかけさせずに、満足感の高いユーザーエクスペリエンスを提供できます。

忘れてはいけないのは、プラットフォームのユーザーであるデベロッパーは「ソリューションに注目し、信頼を寄せる価値があるかどうか」という重要な判断を迫られているということです。

入念にオンボーディングプロセスを設計することで、プラットフォームエンジニアリングチームの敬意がデベロッパーに伝わり、組織全体に受け入れられる可能性が大幅に向上するでしょう。