体験談: グローバルEC会社のDX

私は2017年、某グローバルEC会社(A社とします)でプロダクトマネージャーとして新規ビジネスの立上げを行いました。一般消費者が顧客であるところ、ビジネス顧客を対象としたサービスの立ち上げで、既存資産を生かして成長事業を立ち上げる取り組みでした。当事は業務に終われる日々でしたが、振り返るとデジタルトランスフォーメーション(DX)の推進に参考になる点がありそうです。DXのケーススタディとして、実施したことや学びをまとめてみようと思います。

PLAN ~ トップの投資判断と計画チームの編成

言うは易し行うは難しの経営判断

2014年、A社は米国で新サービスをサービスを立ち上げました。工場消耗品を中心とした品揃えでビジネス購買を対象としたサービスです。消費者向けのECをメインとしているA社がなぜ、ビジネス購買向けのサービスを立ち上げたのか?それはECサイトや物流網といった既存資産を生かし新たな顧客層を対象とした事業による収益を狙っての投資です。

当初新サービスは消費者向けのサービスとは別サイトでサービスを開始しました。品揃えやサイトの見た目においてビジネス用にカスタマイズしたサービスとして立ち上げたのです。ところが、ここで最初の大きな判断を経営トップがしました。立ち上げた新サイトを破棄して、本体のサイトに統合する判断をしたいのです。事業を拡大するにあたり、別サイトを構築するよりも、本体サイトのトラフィックや、品揃えをテコにした方が長期的にはメリットがあるとの判断でした。事実既存サイトで消費者むけの商品を購入しているビジネス顧客が多数存在していました。

当時は思い切った判断をするものだと思いました。A社には短期的な成果ではなく、長期的な成果を重視する行動指針があります。言うは易し行うは難しの判断ですが、トップ自らが行動指針を実践した例と言えるでしょう。

さらに面白いのは、この判断をするためにそれほど厳密な得失評価をしていない点です。細かく評価すれば、機能開発や運営体制の得失、本業への影響、など様々な論点が出ますが、既存資産の活用という一点で時間をかけずに判断しています。

計画策定チームの編成

その後2014年後半に新サービスが米国で立ち上がりました。これを機に米国以外でも同事業を立ち上げることを決め、チームを編成します。新サービスのグローバルチームを編成することを決め、EUと日本でプロダクトマネージャーの採用を開始します。日本のプロダクトマネージャーが私です。

当時入社したばかりの私はよく事情がつかめていませんでしたが、とにかく走りながら組織を整えていく格好でスタートしました。本国に2名のプログラムマネージャー、EUに2名のプロダクトマネージャー、日本は私、全体を統括するシニアスポンサーが1名、まずはこの6名の少人数でロードマップを作成しました。ゆくゆく各国で100名を超える組織体制になるのですが、最初は少人数です。

しかし最初にやることを考えると必要十分かつスピードを担保できる体制であったと思います。各国のローカル要件を反映したサービスの骨格を決め、立ち上げの計画(ロードマップ)を策定するには各国のプロダクト責任者 、プロジェクトを推進するメンバー、事業の責任者がいれば役割は足ります。仕事量に対して人数が足りてるのか、という点は微妙でしたが(かなり忙しかったです笑)。足りなければ考えるくらいで初めてしまうことが大事なのでしょう。

また既存の人員で何とかやりくりするのではなく、きちんと投資するという点も重要でしょう。必要最低限の陣容を吟味して投資していました。

最初の舵取り~立ち上げ順の優先付け

ロードマップを策定するにあたってはトレードオフに関しての難しい意思決定が待ち受けていました。米国以外で規模が大きいマーケットは、ドイツ、イギリス、日本(順不同です)の3つでしたが、それぞれの立場では早く事業を立ち上げたい思いがあります。しかしそれを実現するには開発への投資(開発リソースの増員)が大きくなります。これをどう解決したか?

ここもトップダウンで、米国以外の小売事業の責任者が追加リソースの上限を決め、その中で最大成果をとなるプランを立てよ。以上でした。この結果、ドイツ、イギリスを先行させた方が投資効果が早く創出できることから、日本は三番目の立ち上げと決定されました。

日本の立場にいた私としてはこの決定には不満でしたが、一方で客観的に考えれば合理的な判断であると納得できました。あの時トップが判断を示さず、プロジェクトに判断を委ねていたら決まらない議論で時間を費やしたことでしょう。トップが判断を示したことで迷走することなく、合理的な判断を迅速にできたと言えます。

結果、日本の立ち上げはだいぶ待つ事になりました。その間、日本では何をするのか?そんなことはお構い無しです(笑) 大きな意思決定する際には枝葉まで見てられません。それで良いと思います。

ACTIVATE~アジャイルな組織づくり

チーム編成~米国と日本の役割分担

実際立ち上げに向けて、プロダクト、マーケティング、営業など様々なチームを立ち上げていきました。その際に問題になるのが、何をローカル側に置き、何をグローバル(米国チーム)で持つか、という役割分担とガバナンスです。特にプロダクトはUSで開発したプロダクトを最大限活用することが前提のため、米国のプロダクトチームとの役割分担が重要になります。

この役割分担は当初、試行錯誤というか曖昧な状況の中で全部ローカルで対応する勢いで進めていましたが、最終的には、米国のプロダクトチームが全世界にプロダクトを立ち上げる責任があるという分担に落ち着きました。ローカルのプロダクトマネージャーからのサポートを得て、ローカル要件の取り込みや、翻訳を行うという役割分担です。

ローカルのプロダクトマネージャーの役割は何か?大きく2つです。グローバルのプロダクトを日本で立ち上げる際の検証と、ローカルニーズのプロダクトへの反映です。後者は機能レベルでの対応もあれば、オペレーションでの対応もあります。

もし連携して立ち上げる、といった玉虫色の線引きであったなら機能しなかったと思います。USと各国それぞれリソースを抱えてサイロ化して非効率が生じるのがよくあるパターンです。チームに対して当初の責任範囲を超えた役割を持たせることができると、その後の非効率を防止できる例だと思います。

事業部との連携

もう一つ組織体制づくりとして事業部の協力を得る必要がありました。事業部とはECサイトで販売している商品カテゴリを担当している部門と思ってください。商品や仕入れ、価格管理、在庫管理などを担っています。新サービスの組織としては、ビジネス顧客向けの商品の仕入れや、価格設定(数量割引)などで事業部の協力が必要でした。

新サービスは事業部にとって自分の部門に新しい顧客層による売上増が期待できるサービスでした。このため協力は得やすい立場であったのですが、如何せん立ち上げ当初のビジネス規模が小さく、優先順位が上がらないというジレンマがありました。わざわざ人をさくほどの事業規模ではなく、そうするといつまでたっても事業が拡大しないという問題があったのです。

これに対して米国がとっていたアプローチは人の投資を新サービス側で行い、事業部に人を送り込むという方法でした。一見合理的に見える方法でしたが、結論から言うとうまくいきませんでした。事業部がコミットしなかったため、頭数だけ揃えてもビジネス向けの品揃えが拡充しなかったのです。

これを受けて、EUや日本では事業部側を後押しする運用を行い、事業部がオーナーシップを発揮するよう進めていきました。チャンピオン(Point of Contact)を置いてもらい、現場レベルでの連携を密に行ったのと、事業部長と月次での定例会議を行い計画や進捗の共有を行ったのです。事業部により温度差はありましたが、結局のところ事業部のオーナーシップが発揮されない限りうまくいかないため、そこにフォーカスした運営は正しかったと言えるでしょう。

日本でサービスを立ち上げるまでの間、私の仕事は、もっぱら事業部に対する新たに始まる新サービスの啓蒙と、事業部に商品の拡充を進めてもらうための計画づくりと実行支援でした。しかし自分の期待通りには進みませんでした。ただそれは経営資源をどこに割り当てるか、という判断の結果です。その判断にために必要なインプットを適切に行った結果だとすれば、他にやりようもなかったと思います。

CONTROL〜MVPからのビジネス拡大

MVPでの立ち上げ

小さな成功を示すことが変革の最初のステップとして大切です。新サービスの立ち上げも必要最小限のプロダクト(MVP:Minimum Viable Product)にて立ち上げました。私は、この時初めてMVPという概念を知りました。それまでも要件定義にて必須要件か、Nice to haveか、といった識別はしていましたが、サービスとして成立する最小プロダクト、という基準でスコープを定義したのはこの時が初めてでした。

プロダクトとしてスコープを議論するには、対象とするカスタマーと提供価値の点でスコープを議論するという視点が必要になってきます。一方で、必須要件か否かを検討する際は、この点が明確に意識されないように思います。ビジネスの立ち上げにおいては、カスタマーと提供価値の点でMVPを決めるとこが重要です。アジャイル開発はプロセスの問題ではなく、プロダクトの問題です。プロセスだけアジャイルにしようとしても上手く行きません。

何を持ってMVPとするかは2つのデータに基づき判断を行いました。1つはカスタマー調査、もう一つは購買データです。カスタマー調査では対象とするカスタマーセグメントにおいて、当たり前品質とみなされている機能(あっても満足度が上がるわけではないが、それがないと使えない機能)を特定しました。この時点で日本ではUSにない機能がMVPに必要だという仮説がありましたが、自分たちは特別だという思いがあるためでしょうか、説得できませんでした。

そこで購買データからはビジネスカスタマーと思われるカスタマーの購買比率を調べました。USと比べて著しく低いビジネスカスタマーの購買比率から、米国のMVPになかった機能を日本向けには実装する決定を行いました。外部データはどうしても一般論になりがちなため、いかにして自社のカスタマーからフィードバックを得るかが重要と言えます。

顧客の声を得る仕組みづくり

MVPを立ち上げた後は継続してプロダクトを拡張していきます。このためにカスタマーから顧客の声(VOC)を得る仕組み化を行いました。営業部隊、コールセンター、サービスページからのコメント投稿の3つのチャネルからフィードバックを集め、不具合は即時対応、改善要望は月次で緩急をつけて対応していきました。改善要望の優先順位を判断するために、要望元のカスタマーセグメント(規模や業種)を付与しました。

どう取捨選択したかは後述しますが、カスタマーのフィードバックをもとにプロダクトを拡張していくことは判断を容易にします。フィードバックを得て共有する仕組みを構築することもまたサービス立ち上げと同時に行うべきと言えるでしょう。

プロダクト責任者としてはカスタマーフィードバックを集めることほど重要な仕事はないように思います。しかしながら私がコンサルタントとして接してきた企業でカスタマーフィードバックを得る仕組みを持っている企業や、自分たちでチェックする活動を行なっている企業は決して多くありません。内部管理の強化に意識が囚われすぎているように感じます。片手落ちにならぬようカスタマーとのタッチポイントを検証すべきと考えます。

サービス拡張要件の優先付け~GTMと連動させるべし

こうして集めたVOCを開発部隊にフィードバックして開発をしてもらうこと、またロードマップやサービスリリースを内部関係者に周知することもプロダクトマネージャーの仕事です。開発がテンポよく行われればいかにコミュニケーションを円滑にするかが課題になりますが、当時は開発にリクエストしても実行されるまで時間がかかる、なかなか実行されないという状況だったため、優先付けはビジネス判断そのものでした。

また個々のプロダクトの拡張だけでなく、サービス全体としての整合を取る必要もあります。そうしないと例えば、ある機能開発にリソースを投入しても、その機能を使うために必要となる別な機能がリリースされておらず意味がない、という状態が起こります。

サービス全体として整合をとりつつ、ビジネス判断に直結する優先付を行うことがプロダクト責任者の仕事でした。個別に要望について優先度を議論しても埒が明かないと考え私がとったアプローチはGoToMarket Planとプロダクトロードマップを整合させることでした。こう書くとごく当たり前に聞こえますが、実際には組織としてGoToMarket Planを確立するのに苦労をしました。カスタマーの行動への理解、具体的には、カスタマーがどういうステップを経てより沢山の購買を行うようになるかの理解、が足りてなかったためです。

立ち上げ当初はGo To Marketプランとして中小企業を対象に立ち上げ、その後大企業に浸透させる、くらいのざっくりした方針しかありませんでした。しかし、立ち上げ後、カスタマーの理解が進むにつれ、一度サービスを使い始めたからといって一足飛びに利用度が最大になる訳ではなく、徐々に浸透していくその過程が見えてきました。詳しいことは伏せますが、5段階の利用ステージを定義して、規模と業種で定義したカスタマーセグメント毎に到達させたいステージを設定することでビジネスのフォーカスを決めました。そして、当該ステージに達するためにブロッカーとなる要件を充足させるようプロダクトの拡充を図りました。

アジャイルでMVPからスタートすべしとよく言われていますが、その後の拡張についての議論はあまり聞きません。実体験に基づく考えは、カスタマーサクセスをステップ分けして、プロダクトを拡張していくアプローチが重要になると思います。ゲームでの課金、金融商品のクロスセルなどお客様の利用ステージを上げるためのステップをどう想定するか、ステージを上げるために訴求すべきことは何かを設計し実行することが重要となるでしょう。

END~変革の定着化

データ・ドリブンでのビジネスレビュー

立ち上げ後、即時に通常のビジネス運営に移行します。こなれるまでに多少の時間は要しますが、慣れの問題であってあくまで通常のビジネス運営が始まります。具体的には以下のレビューの仕組みによってビジネスが回り始めます。

  • ビジネスレビュー:週、月、期毎の進捗確認。インプット指標の進捗状況、とアウトプット指標
  • VOCレビュー:重要なVOCに対応判断と状況確認。ビジネスレビューに組み込み月次で実施。
  • 事業部との合同ビジネスレビュー:月次で品揃えや価格政策の計画と進捗確認

プロダクト(サービス)の拡充、ターゲットカスタマーの拡充という活動がBAU(Business As Usual、定常業務)に組み込まれている点がポイントです。当時は当たり前に過ごしていましたが、変化し続けることがBAUに仕組みとして組み込まれている、しかも、わざわざそういう必要性を認識するでもなく、当たり前に実行していた点を振り返るに、まさしく変革がDNAに組み込まれているということなのかもしれません。

DNAとしての行動指針

どんなDNAか?もちろんメトリクスによる管理はその一つです。徹底的に数字で管理していきます。しかしそれだけでは片手落ちです。

カスタマーエクスペリエンスに対する徹底したこだわり、計算されたリスクをとってスピードを重視する、誰もがリーダーであるという高い目線、など行動指針で示される共通の思考様式、価値基準があればこそのメトリクス管理だと考えます。これによってカスタマーに対して価値があることをする共通の価値基準が生まれ、それがチームがサイロにならずに目標達成に動く原動力になります。

KPIという用語が認知され、データ・ドリブン経営が注目されていることは良いことだと思います。しかしメトリクス管理だけを強調すると、チームがサイロ化し、数字達成が目的化します。私が見てきた企業の多くがこの状態になっていました。また昨今の経営不祥事もこの影響ではないでしょうか? データを重視した判断が重要になればなるほど、事業のミッション、行動指針を浸透させる努力が大事になると考えます。

コメント

タイトルとURLをコピーしました