横展開は初日から設計する

パイロットは順調でした。最初の市場で利用者がプラットフォームを使い始め、数字も良好で、運営委員会は横展開に合意しました。それから1年たった今も、稼働しているのは1つの市場だけです。

これは、地域統括会社から最もよく聞く課題のひとつです。原因が技術にあることはまれです。問題は、誰もがパイロット市場のことだけを考えていた最初の数週間に下された判断にあります。

横展開が止まる理由

繰り返し見られる原因は3つあります。

パイロットが1つの市場の業務を前提に作られている。 ルール、画面、データ構造が、最初のディストリビューターの業務のやり方を暗黙の前提にしています。2番目の市場では業務が異なり、その違いがすべて変更要求になります。
設定がコードの中にある。 価格、承認ステップ、販売店リスト、メールテンプレートがアプリケーションに直接書き込まれています。市場を追加するには、設定の変更ではなくリリースが必要になります。
新市場の立ち上げに責任者がいない。 パイロットを構築したプロジェクトチームは次の仕事に移ります。次の市場の本番稼働は小さな追加作業として扱われ、独自の計画・人員・予算が必要な仕事とは見なされません。

いずれもパイロットの段階では見えません。そして、いずれも2番目の市場で大きなコストになります。

結果を変える4つの設計上の選択

ディストリビューター向けコマースから保証・認定まで、私たちが地域統括会社向けに構築・運用しているプラットフォームでは、次の4つの選択が成否を分けています。

1. 地域共通の標準と市場ごとの設定を分ける

どこでも同じでなければならないものと、市場ごとに変えてよいものを、早い段階で決めます。私たちが運用する地域コマースプラットフォームでは、プラットフォームのインスタンスは1つです。各ディストリビューターは専用のストアを持ち、カタログ、価格、決済、配送の設定もそれぞれ独自です。VINによる部品検索のような共通機能は一度だけ構築し、すべてのストアで使います。

同じ原則は、より小規模なシステムにも当てはまります。販売店認定エンジンでは、販売店と署名者のリストはマスターデータとして地域統括会社が自ら更新します。開発者がコードを書き換えるものではありません。

2. アプリケーションを環境から独立させる

最初の市場向けにMVPとして構築中の保証プラットフォームでは、アプリケーションをインフラから意図的に切り離しています。次の地域が独自のクラウド環境、ネットワーク、データ保管場所の要件を用意しても、アプリケーションの構成要素はそのまま引き継げます。

3. 新市場の立ち上げそのものを設計する

2番目の市場は最初の市場より容易であるべきです。ただし、そうなるのは立ち上げの進め方が設計されている場合に限られます。各市場が用意すべきもののチェックリスト、データのテンプレート、研修資料一式、テスト計画、そして明確な責任者です。市場が本番稼働するたびに、この手順書は改善されていきます。

テンプレートもここで役立ちます。複数の地域ブランドサイトでは、2番目のサイトは最初のサイトと同じCMS、インフラ、セキュリティの構成要素から始めるため、新たに作るのはブランド固有の機能だけです。

4. 本番稼働の前に運用の方法を決める

これから10の市場で使われるプラットフォームには、監視、サポート、アップグレードと、そのための予算が必要です。運用コストを後回しにすると、新しい市場が加わるたびに、その規模を想定していないチームの負荷が増えていきます。私たちは最初の本番稼働の前に、運用モデルと、サポート工数を市場間でどう分担するかを合意します。

稼働だけでなく、定着を測る

横展開は、ある市場でシステムが稼働した時点では終わりません。その市場の人々が使うようになって、初めて終わります。アクティブユーザー数、取引件数、いまだにメールで処理されている依頼の件数など、市場ごとの定着度を追跡します。稼働したのに使われていない市場は、未解決の課題として扱います。

どこから始めるか

すでにパイロットが稼働しているなら、最も有効なのは、上に挙げた3つの原因を率直に見直すことです。どのルールがコードに直接書き込まれているか、新しい市場ごとに何を変える必要があるか、次の本番稼働の責任者は誰か。2番目の市場のコストのうち、まだどれだけを避けられるかは、多くの場合、短い作業セッションで見えてきます。

プラットフォームの展開がパイロットの後で止まっているなら、状況をお聞かせください。