写真：左から、柳（㈱ギックス Enabling Div. Lead）、清水様(アサヒプロマネジメント㈱)、花谷（㈱ギックス 取締役 事業推進担当）
アサヒグループの営業効率化/高度化プロジェクト
弊社クライアントである、アサヒプロマネジメント株式会社の清水博様に、ギックスとの取り組みについてお伺いする機会を頂戴しました。
清水様は現在、アサヒグループの営業領域における横断的なIT戦略を主にご担当されています。
2007年に中途でアサヒビールに入社された当初は、グローバル戦略の一環として、中国市場の攻略をご担当されていらっしゃいましたが、2014年頃から「アサヒの競争力強化のためには自社のITインフラを大きく改革する必要性がある」という課題意識の下、自らIT部門への異動をご希望されました。ご異動後は、前職でのIT領域でのご経験も活かしながら、“業務”と“IT”をつなぐ役割を担っていらっしゃいます。
最近は、とりわけ営業領域に対する新しいテクノロジーの導入に注力されており、お客様へのより良いご提案・面白いご提案の実現を通じた、アサヒグループの競争力強化・競合との差別化を推進していらっしゃいます。尚、ギックスは2018年5月より、“量販店様向けのご提案機能”の効率化/高度化プロジェクトの企画・実現フェーズをご支援させていただいております。
清水 博 様へのインタビュー：
どのような課題に取り組んできたのか
かなり昔から、量販店様向けの営業グループ（以下、量販チーム）の中には「量販店様に対して、より価値のある提案をしたい」というニーズがありました。当然ながら、そのためには、より多くのデータ、より多様なデータを分析することが求められます。そういうことをITでどうやって実現するか、という課題に2015年から取り組んできました。
取り組んできた改善活動はいくつかありますが、ひとつはPOSデータの分析基盤を構築したことが挙げられます。これにより、従来よりも詳細なカテゴリの単位で、消費動向を理解することができるようになりました。そのほかにも、ラウンダー*の店頭活動の可視化にも取り組みました。それらの活動の後に、満を持して、カテゴリマネジメント（カテマネ）のツールを、営業メンバーがもっと活用するようにできないか、という話に軸足を移しました。
*)ラウンダー：店頭の状況を、実際に店舗に赴いて調査する職種
カテマネの改善に取り組めるようになったのは、2016年になってからですね。特に解決すべき課題として、分析の”過程“に時間がかかりすぎている、ということがありました。営業が欲しいのは分析の”結果“であるにも関わらず、膨大な時間をデータの取得・分析作業に費やしてしまう。これは、極めて勿体ないな、と。
この問題をよく観察すると、どういう業務の流れで分析業務を行うべきなのか、が十分に整理されていない、ということに気づきました。ますはそこから着手しようということで、量販チームに「どういう業務にしたいのか、を整理して欲しい」と伝えました。
仕組化したいという要望をもらっても、IT側で勝手に作るわけにはいきませんし、そんなことをしても役に立つ仕組み、ちゃんと使ってもらえる仕組みにはなりません。本当に必要なものは何か、を、業務が分かっている人たちが定義することが大切です。
そうして、量販チームの求める “あるべき分析業務”の整理に着手し、大手コンサルティングファームの支援を得ながらアウトプットとしてまとまったのが2017年のことです。
マイクロサービスで実現するという新しい試み
これで、やりたいことは分かりました。では、どうやって仕組みを構築したらよいのか、となるのですが、皆目見当がつかない。SIベンダーにお願いしても、マーチャンダイジング（MD）業務をしっかり理解していないとつくれそうにない。一方、社内のMDに詳しい人たちを集めても、最新テクノロジーの知見が無いので、仕組化にはつながらない。
そんな時に、岡大勝（おか・ひろまさ：ZOZOテクノロジーズ所属・ギックス技術顧問）さんにお会いして「それは、コンテナ**でやると良い」というお話になったんですね。まぁ、コンテナって言われても当時の私には、どういうものかわからなかったんですが、強く自信をもって断言されたので、そういうものかなと思いました。笑
そうやって「マイクロサービスで作る」という方針は決まったけれど、今度は、誰と作るのかで、また悩むことになりました。コンテナの開発というものが一体どういうものなのか分からないし、システム子会社にも経験がないという状況。まったくの新しい取り組みなので、外部に支援を求めるべきだと判断し、ギックスを含む4社に声をかけました。2018年の1月頃のことです。
**)コンテナ：アプリケーション実行環境の仮想化技術。軽量で起動が速い、作成した環境の複製(再現)が容易であるといった特徴を持つ。
動的でフレキシブルで軽い運用が理想
営業領域で、web系の仕組みがたくさん動いていることから、フロント部分はMicrosoft Azureにすることは決まっていました。一方、バックエンドの処理はGCP（Google Cloud Platform）が良いだろうと思っていたので、この時点で、複数のクラウドを融合させたアーキテクチャになることが見えていました。
そんな取組みは、アサヒにとって初めてでしたから、期せずして、アサヒグループのパブリッククラウドの活用戦略を考えることにまで踏み込んでしまったわけですね。
とはいえ、実際、アサヒグループのシステムの状況を俯瞰してみると、運用コストが極めて高く、ITコストのほとんどは運用で占められています。それでは、新しいことに投資できず、色々なことに挑戦できない。この状況を大きく変えるべく、運用を軽くした分を投資に回すために、動的で、フレキシブルで、運用が軽い、そんな提案が欲しかったんです。
新しすぎて、決めるのが怖い
委託先の選定において重視したのは、コストよりも「運用イメージ」「アーキテクチャのレベル感」が、私たちの思うものに合致しているかどうかでした。どの機能をPaaSレイヤーでやるのか、NoOps的な発想を組み込んでいるか、など、そういう部分に注目して提案を見ていく中で「ギックスが良さそうかな」という話になりました。
が、先ほども言った通り、コンテナもマイクロサービスも、この時点では良く分からない。ギックスに限らず、誰に頼んだとしても、本当に実現できるものなのか自信が持てない。なんとなくできそうな気はするが、できるという確信がない。悩みましたね。
アサヒグループとして初めてということもそうですが、そもそも、Kubernetes***もそんなに事例がない頃ですよ。どうにも決めきれない。大きいベンダーに頼んだ方が、開発がコケたときにもなんらかフォローしてくれるじゃないか・・・みたいなことも頭をよぎるんですよね。苦笑
で、悩んで悩んで悩んでいると、岡さんに一喝されました。「何を迷ってるんですか？技術的には大丈夫です。やるんですよ。」と。笑
背中を押されて、覚悟を決めて、ギックスに発注しました。2018年の3月頃です。
*** )Kubernetes：複数のコンテナを管理する仕組み。コンテナの特徴を生かして、負荷分散をはじめとした分散処理環境の構築を可能にする。
プロトタイプを作り、どんどん改善していく開発サイクル
プロジェクトが始まってみると、6週間くらいで、最初のプロトタイプがでてくる。3月から始めたのでゴールデンウィークの頃です。もちろん、完璧なものじゃないし、完成形のイメージもまだ見えない。ただ、それを見ながら、議論をすると、次の打合せには、もう一歩進んだものがでてくる。それを繰り返していくうちに、自分達が本当に欲しいものがどんどん分かってくる。
このプロジェクトにおいて、私の希望は「一日も早く、新しい機能を世に出したい」ということだったのですが、「いま、どこまで実現できているか」を実感できるので、この進め方は、とてもニーズに合いました。
この改善サイクルを6ヶ月続けて、2018年11月中旬に、無事に、仕組みをリリースすることができました。
議論を重ねて、一緒に答えを探しに行く
仕組みを使う立場である現場のメンバーから、「ギックス“が”いい」「ギックス“と”やりたい」というような声が上がっています。彼らは“議論”がしたいんですね。
こっちが言ったことを全て「その通りです」と言われても、我々も不安になる。え、それ、一晩考えただけの思いつきだぞ、とか思っちゃったりね。笑
その点、ギックスは議論ができる。会話の中から答えを探すことができる。
共に議論して、本当に必要なもの、本当にやるべきことを探していけるので、信頼できる。
当たり前なのですけど、議論していくためには、業務知識が必要です。ギックスのメンバーが、もともとこの業界・この業務に詳しいかというと、必ずしもそうではない。知らないことは多い。でも、全員が、業界・業務に対して興味を持って、より深く知ろう、理解しようとしているなと感じます。知らないことがあると、メチャクチャ訊いてくる。笑
だから、こちらも “確実に答えられる人”を打合せに参加させます。現場のエースを連れてきて、何を聞かれてもその場で答えられるようにする。「他の人に訊いておきます」「持ち帰って確認します」ということを無くすんです。
そうすることで、改善サイクルが早く回りますから、結果としてギックスを使い倒せるんですよ。一回の打合せの密度を上げるのが、私の責務だと思っています。
信頼関係に基づくアジャイル開発
このプロジェクトは、いわゆる「アジャイル型」で進んできました。チーム全体にストーリーポイント****の概念が浸透して、共通言語になっています。お互いに、次にどういう機能を作って行くのかについて、同じ指標で開発ボリュームを見極めながら進めています。ただ、これも信頼感の問題。信頼感が無いと、ストーリーポイントで運用なんてできません。プロジェクトの中で、様々な意見を交わし、一緒に機能を作り上げていく中で、信頼できる相手になってきたのだと思います。
****)ストーリーポイント：アジャイル開発手法の一つ「スクラム」において、追加開発の要素となる「要望・課題」の大きさの“単位”。1週間などのサイクル内で、対応できるストーリーポイントの総量が定義され、その範囲内で、どの「要望・課題」に取り組むかを合意しながら進めていくために用いる。
正直な話、アジャイルかどうかはどうでもよかったのですけど、「どんどんものができて、変わっていく」というスタイルはとても気に入っています。リリース時にAzureで構築していた部分を、一部GCPに置き換えたりもしていますが、こういう変更が利用者には見えない状態で進んでいます。開発してリリースしたら終わり、ではなく、常に最適なものを選んで改善していく柔軟性は、とても新鮮だし、価値が高いと思います。
※上段のコントローラーなどがGCPに置き換わっている
機能改善を続けて、競争優位性を築きたい
今回の仕組みで、営業メンバーがデータを集める時間が激減しました。これまでは、データを集めるために個々人が膨大な工数を費やしてしまっていましたが、そういう各人の作業を本社に一本化したことによって効率化が大きく進みました。
データの可視化が進んだことで、しっかり考察することに時間をかけて、競合と差別化した提案ができるようになってきています。集めたデータを読み解いて理解し、そこから考察していくことの方に時間を使って欲しいと常々思っていましたが、まさにその形に近づいてきていると感じています。実際、現場での成果も出始めています。とはいえ、まだまだ全てのデータが統合されているわけではありません。基本的なデータがつながった状態に過ぎませんから、今後は、いろいろなインプットデータを現場要望に応じて優先順位を付けながら取り込んでいき、提案内容の更なる高度化につなげていきたいと思っています。
2019年7月31日-8月1日に開催された「Google Cloud Next ’19」の基調講演およびセッションにアサヒグループ様がご登壇され、本プロジェクトに関してお話されておりますので、そちらもご参照ください。
