講演１　労働集約型サービス産業におけるサービス工学の導入－Data Drivenな企業改革－

 

 

新村　猛氏
（がんこフードサービス株式会社　代表取締役／神戸大学バリュースクール　客員教授）

 

サービスの生産性問題を解決するためにデータを活用する

　私は35年前にこの業界に調理師として入りました。現場上がりでもともと研究者ではありません。研究しながらビジネスをしている理由ですが、非製造業の生産性向上が個人のスキルに依存しているという問題を解くためです。個人のスキルに依存すると、人が抜けたり交代すると、生産性が上がったり下がったりするので、持続的に生産性が上げられない。トレーニングや教育も大事ですが、非製造業における生産性を上げる技術を構築し、一般化しないと産業全体が良くならない、ということで現場をやりつつ研究もしています。

　私からは、サービス工学というキーワードでお話しします。サービス工学という概念そのものが議論されたのは四半世紀ほど前で、20世紀の後半から21世紀になる頃でした。サービス工学の議論のスタートキーを押したのは東京大学の吉川弘之先生です。製造業の成長と生産性に限界が生じ、モノづくりだけで国を成長させるのは限界がある。そこで非製造業を工学的にどうやって研究すべきか、という議論が始まったのが1990年代の終わりです。

　モノづくりがある限界点に達する一方、サービス業のg比率（経済成長率）が上がってきたのですが、この動きは国や社会、個人にとっても良いことです。なぜならば、経済が成長、成熟して、皆が豊かになり、旅行へ行く、ホテルに泊まる、外食に行くなど、サービスを楽しむ機会が生まれ、皆にとってハッピーだったわけです。ところがサービス業は、シンプルかつ大きな問題を抱えていました。それは、図1の左のグラフのように生産性が低いということです。このように、製造業からサービス業に社会構造が変化していくと、高生産性の製造業のシェアが下がって、低生産性のサービス業のシェアが広がり、国として生産性が落ちます。生産性が落ち、国際競争力が落ちるという問題が起きてしまいました。これが20世紀の終わりくらいから先進諸国でいわれるようになった課題で、この課題にどう立ち向かうのかが大きなテーマになりました。

　なぜサービス業は生産性が低いのかという議論はほぼ終わっていて、これに対して異論を唱えている人はいません。製造業の場合は何かモノをつくっています。工場でつくって在庫を持つので、比較的、生産現場で計画生産ができます。ところが、サービス業は在庫ができないので、計画生産ができません。例えば、マッサージ屋や理髪店ではお客さまが来ないと待っているしかありません。生産と消費が同時のビジネスなので、お客さまがいない間がすべて待ち時間になってしまいます。待ち時間といえども人件費は発生するので、この単純かつ非常に重要な問題が非製造業の生産性を低めているといわれていますし、これはコンセンサスが取られています。

　なぜデータとサービス業の生産性の問題がつながるかといいますと、サービスは無形ですから目に見えないので、問題の分析もできないし、対策の打ちようもない。サービス業の生産性の研究をする際、可視化して分析する必要がありました。何かデータを取る、ないしは画像で取る、ということで、計ってデータ化することからスタートしないと、このサービス工学分野が成立しませんでした。データがこの領域において重要であった1つの背景になります。

問題解決のためのデータ活用は4ステップで進める

　サービス工学分野を作り上げて、非製造業の生産性向上を実現しようということで、自然科学分野で研究が始まりました。経営学分野では、PDCA（Plan、Do、Check、Action）でマネジメントサイクルを回し、経営改善をしていきましょうといわれています。われわれ自然科学分野の研究者は、サービス工学の議論をするときに、これに倣って少しアレンジしました。非製造業における生産性はPDCAではなく、CAPD（Check、Action、Plan、Do）だと説明しています。なぜかというと、非製造業はサービスが無形なので見えません。人の満足や不満足も見えないし、例えばホテルで働いているとすると、1階の従業員は3階のお客さまの状況は見えません。いろいろな意味で見えない部分が多いので、まず何が起こっているかを理解するため、データを取ったり定量化することをステップ1で実行します。

　次に分析です。ここに分析を入れるポイントは、顧客満足や心理のような不確実な情報を理解するため、より高度な分析が必要だったからです。サービス工学研究が始まった30年前は、人工知能学者や数学系の人たちが、お客さまのファジーな意思決定の遷移やものの考え方の遷移、飲食業の売り上げは何で上がり、何で下がるのかという「ふわっとしたテーマ」を、どのようにデータ分析するか考えていました。それに基づいてサービスをデザイン（Plan）し、現場に投入（Do）しましょうということで、PDCAサイクルに対してCAPDという概念を持ってきました（図2）。

　次に、どのようにわれわれがサービス業の生産性を変えていこうとしているかについて、図3を参照してください。サービス工学の約30年の研究蓄積は何かというと、サービス業の生産性を向上させるための個別のモジュールになる技術を、ひたすらみんなでつくってきたことです。図3に書いてあることは、今でこそ当たり前になっていますが、20年、30年前には、このような技術は絵に描いた餅で、実際に使えると思われていませんでした。30年を経て、やりたい技術が個別に出てきて、これらのモジュールたる技術を組み合わせて、今後30年でサービスシステムの構築をやらなければならないと思います。

知りたいことを知るためのデータを創る

　どんなことをやっているのか事例をいくつか紹介します。1つ目は、シミュレーションの技術です。非製造業のシミュレーションはどのようにするべきか、神戸大学の藤井先生と一緒に15～20年研究してきました。2年前に、こういったシミュレーションをいろいろなサービス事業者に提供しようということで、藤井先生とDsDという会社を神戸大学認定ベンチャーとして設立し、われわれはユーザーであると共にベンダーになっています。その源流になった技術です。

　図４にシステム構成を書いています。シミュレーションそのものは以前からある技術ですので、シミュレータをつくること自体はそれほど苦ではありませんでした。シミュレーションがあらゆる現場で気軽に使えるように、軽いシステムにして、誰でもアプローチできるようなシミュレータにするところが、ベンダー側としての苦労でした。ユーザー側としては、データが存在しないことでした。注文のPOS（Point of Sale：販売時点情報管理）データや勤怠管理システムで従業員の勤務状況のデータが取れます。ところが、8時間労働の中で従業員が何をしているか、というデータは全くありません。つまり、勤怠管理システム上、Aさん、Bさん、Cさんが出勤していることと、POSデータの取られた注文で、どのようにAさんたちの作業を推定するかを考える場合、どうやってひも付けていくかデータがなかったので大変でした。

　マシンで料理をつくる（生産する）ので、キッチン内のマシンの配置と従業員の配置のデータセットをつくろうとしましたが、それでもシミュレーションするのに壁がありました。それは、料理をする時間のデータベースを持っていないことでした。汎用性の高いシミュレータをつくりたかったので、何種類の調理作業があるのかについて調理事典で調べました。私の見た辞書では約7,200の調理作業が掲載されていました。7,200種類のデータベースをつくるのは難しいので、同じような作業工程は1つの作業として扱い、人間の作業として意味のあるくくりにすると約300作業に集約されました。集約された300の調理作業をVTR（Video Tape Recorder）で計ってデータセットをつくり、シミュレータを回しました。しかし、ここで何が起こったかというと、あり得ないほどシミュレーション上の作業が速いことに気づきました。理由は、全作業について調理長で計ったからです。調理長以外の従業員の方が多いのに、作業の早い調理長の時間計測が基になったため、全員の作業スピードが早い設定になってしまいました。そのため、現場の従業員で計測し直して、実際にはどのくらいのスピードなのかについて、スキルとスピードのひも付けをしてシミュレーションを回しました。しかし、まだ駄目でした。なぜかというと、シミュレータの中では誰もミスをしないからです。このように現場で使えるシミュレータにしよう、それを新しい分野に投入していこうというときに、データをいかに集めて、計測して、使えるデータにしていくかというプロセスで四苦八苦しました。

問題が起きている場所の文脈（Context）を知る

　このようなデータを用いて現場の従業員と一緒に「では、どうするのか」と話し合った改善事例について紹介しましょう。図5は、JR京都駅ビル店のキッチンのレイアウトです。実際に現場の従業員が見ても、自分たちの長年の労働慣行は変えられません。われわれの現場はラインに近いです。例えば、一番左にCellと書いていますが、このCellの上の赤いのは揚げ物担当者です。Cellの下の人は麺類担当者です。その右横に縦に二人並んでいますが、煮物担当者と焼物担当者です。その対面はおすし担当で、料理の種類別に分業して生産効率を上げようということです。

　このシステムは、ランチタイムの12～13時は上手く機能します。たくさん注文が入るので、分業したほうが生産性は上がります。ところが、14～17時のお客さまがほとんどいない時間帯は、キッチンの人員を減らして1～2人で仕事をします。1時間に4つか5つしか注文が通らなくても、キッチン内を移動して１人で調理することは不可能です。暇なときはライン生産ではなくて、どこか1か所に料理器具を集めて、1人でやってもらわなければならないわけです。忙しい時は場所別に分業し、暇なときは頭を切り替えて、1人で全種類の料理がCellでできるように生産性システムを組み替えなければなりません。

　実際にやってみましたが、破綻しました。私も職人なので、煮物、揚物、焼物、なんでも作ることができますが、飲食店は4種類も5種類も同時に料理するという生産システムではありません。煮物なら煮物、焼物なら焼物で作業分担するので、多能工だったとしてもジャンルの異なる料理を調理するというトレーニングを受けていません。データ分析して生産システムを替えるとともに、オペレーションする人間のトレーニングや意識改革をしなければならなかった。しかも、われわれ職人はポリシーがあって、「手伝われたら負け」という意地があります。協力するとか、みんなで助け合うとか、複数の人間でいろんなポジションを回すという考えはあまりありません。特に職人は、昔気質の人が多いので、考え方を変えてもらうのが難しく、トレーニングや教育という面で苦労しました。

　図6は、コロナ禍で閉店しましたが、銀座にあった2フロア300坪ぐらいの大きな店です。この店は予約比率が5割だったので、計画生産できる料理と受注生産の料理が1対1の比率で通っていました。従来通り注文も決まってる計画生産と受注生産を混在して生産していたのですが、それを分けたらどうなるのかを考えました。予約料理は作り終わったら担当者は帰る、予約のない料理は都度生産する、というふうに1か所のキッチンで予約ありと予約なしのモジュールを作った場合の生産システムとそうでない場合とどちらがいいんだろうということです。私は図6右側のBtO、 BtP（Built-to-Order / Built-to-Plan）のレイアウトがいいと思いました。

　ところが、取締役会で「1つの店にキッチンを2つ作ってどないすんねん」と言われ、シミュレーションして議論することになりました。結果、シミュレータはBtO、 BtP を選んだので、約2,000万円かけて設備投資をしました。図7のBtO、 BtPと従来手法を注目していただきたいのですが、1つ目の事例がLine and Cellで、1人1時間当たりの売り上げをKPI（Key Performance Indicator：重要業績評価指標）にしていますが、12,000円から14,000円に生産性が改善しています。計画生産と受注生産は、銀座店の事例ですが、こちらも12,000円から15,500円に生産効率がかなり上がっていることが確認できます。

　2つの事例は、やったことがないのでいいか悪いか分からないし、投資しても回収できるかどうか分かりません。そのような際に、シミュレーションを用いてデータを取って、ファクトベースではないけれどイフシナリオでどちらがいいかということをきちんと可視化するということが、いかに経営の意思決定にとって大事かということであり、意思決定しても現場が簡単に変わるわけではないので、粘り強く教育や意識改革をする必要があるということです。

全ての人が問題を“問題だ”と理解するためにデータを可視化する

　次はサービスのデータ化に関する事例です。先ほど見ていただいたキッチンのデータ化は比較的簡単でした。なぜなら、POSデータや注文データがあったので、データ化もできていたし、シミュレータになじみやすかったのですが、問題は接客です。接客はPOSデータがなく、従業員の勤務開始、終了のデータのみで、作業内容を可視化するには動画を撮ってタイムプリズムのような動作解析ソフトで分析する必要があります。しかし、それでは手間がかかりすぎ、ビッグデータ化できません。そこで、人間にセンサーを付けて測ることになりました。

　屋内での計測のためGPS（Global Positioning System：全地球測位システム）を使わずに、RFID（Radio Frequency Identification）デバイスを部屋の中に貼って、実際に人間にセンサーを付けて、相対値を測りながらデータ計測をして可視化しました（図8）。

　これもデータを可視化して、生産効率が良いか悪いかを分析するとともに、現場の従業員にデータを見せて、自分たちの動きが良いか悪いかを確認してもらいました。それをもとに現場で自分たちのオペレーション上の課題を発見して、サービスの改善活動をしてもらいました。

　図9は、「作業改善で浮いた時間を、お客さまとの接客時間に費やすと料理の注文が増えるのか」の実験結果データです。ランチタイムは変化がなく、ディナータイムに有意差があり注文が増えました。これは単純明解で、ランチタイムはいくら頑張って接客をよくしても、セットメニューを食べてお腹がいっぱいのところに追加注文しません。ビジネスモデルが1オーダーで1カスタマーの会計は完結するので、改善しても無意味でした。

　ところがディナータイムは、従業員がバタバタしていると注文できないので帰ってしまったり、気を使って追加注文しないということがあります。それに対してサービスオペレーションを改善してお客さまと接する時間を増やすと、注文量が増えるという改善活動の結果です。

　図10は、従業員のトレーニング成果に関するデータです。右にデータが寄れば寄るほどお客さまに接している時間が長いと理解してください。これで従業員を計測すると、慣れていない従業員ほどお客さまのそばを離れていることが多いです。慣れていない従業員に自分のデータとベテラン従業員のデータを見せて、動きの違い、差分を見せて、どのように動けばいいかについて教育します。それに基づいて改善を促進する。これにより、従業員がお客さまに接する時間が増えたということです。

　従業員に感想を聞くと、「自分の動きを見たことがないので、見ることそのものが面白い」と言われました。ただ、「ずっと見られていて、嫌」「たばこを吸っているのがばれる」などいろんな意見があるので、測り方や測る場所、時間は配慮が必要だと思います。

　図11は、VR（Virtual Reality）空間の中に、データが取得できている従業員のデータを活用して、サービスシミュレータを作りました。お客さまを被験者にして従業員をトレーニングすることはできないので、VR空間の中に仮想店舗を作り、サービス現場をVR空間上で再現して、慣れていない従業員や店長、スーパーバイザーがトレーニングを受けることができるシステムを作っています。

　例えば図12のように、シミュレータで新店舗を作り、お客さまのデータを実際に流し込み、この店舗レイアウトの効率は良いのか悪いのかを可視化する研究も、現在、産業技術総合研究所（以下、産総研）でやっています。これもデータが取れているからこそできることではないかと思います。

データは経営の神経である

　最後に、サービスロボットの導入とデータ活用の話を紹介します。サービス業にとってロボットが重要だということは報道でもたくさん取り上げられています。私がロボットを導入しようと思ったのが15年前です。その当時、今後、労働人口が減少していくので、従業員は人がやらないといけないことに集中して、人がやらなくてもいい仕事をロボットにさせようということで、料理をロボットが運ぶことを考えました。

　ロボットを導入して見えてきたことは、ロボットと人間を混在させると人間がロボットに振り回されます。なぜなら、工場の場合はロボットで生産完結しますが、サービス業の場合、ロボットと人間が混在してサービスをすることになります。ロボットが人間の動きを把握して動くわけではないので、人が振り回されることになります。人間がロボット導入に伴ってどのような動きをするか、しっかり見なければならないということがわかりました。

　もう1つ、ロボットを導入する際に事故の議論をしました。われわれがロボットを入れたのは10年前です。今でこそDX（Digital Transformation：デジタルトランスフォーメーション）とよく聞くようになりましたが、導入時はDXがまだ一般的ではなかったので、1店目で失敗したら世間からたたかれるし、ほかの事業者に迷惑がかかるかもしれません。何かあれば報道され、ロボットと人間を混在するべきではないと言われるのではないかと思いました。もともと産業用ロボットは、人間とロボットを切り離すということが開発要件だったので、人とロボットが混在する現場づくりを遅延させないように議論しました。例えば、赤ちゃんがはいはいしても衝突回避できるかなど、どのようにロボットを動かすべきか、あらゆる事態を想定して試験走行、計測し、データ分析して安全性を確認しました。

　ロボットに人間が振り回されるかどうかを分析しようと思い、作業者側の動作を5つのセンサーを使って、モーションキャプチャーやRFIDデバイスもなしで、自律的に計測可能なところまで技術開発を進めています。さらなるチャレンジは指の動きです。指の動きが計測できると作業内容の推定精度をより高くできるので、それをやりたいというのがモチベーションですが、まだ道半ばです。

　今は作業のディクショナリーを作っています。われわれはAI（Artificial Intelligence：人工知能）を使って、人間はどういう作業をしているか推定するための教師データを作成し、未知のデータから正解が推定できるようにしなければいけません。作業者の作業データを計測してディクショナリーを作り、正解の分からないデータをぶつけて、作業内容の精度を推定することをやっています。これもまだ道半ばです。

　このようなことを一連でやりながら、実際に生産性が上がったのかということですが、ロボット導入前後の労働時間のデータを見ると、1日当たり22時間の労働時間削減になりました。当時このロボットは2,600万円でしたが、2年半で回収できました。ロボットと人間の共同ということと、データドリブンでしっかり現場を分析したことが、うまくいった要因ではないかと思います。

　本当にやりたかったことは、ロボットを入れることによって接客時間を増やすことでした。ロボットを導入して、人間とロボットがうまく作業分担する、それによってサービス業の本来の使命である「お客さまと接する時間を増やし、サービス品質を向上させる」ことが重要であり、システム導入によって接客時間を2.5倍に増加させることができたのが、効率向上以上に意義がある結果だったのではないかと思います。

　こういう活動が、ロボット大賞や日本サービス大賞を受賞するきっかけになりました。よくロボットの導入でこれらの賞を受賞したと誤解されますが、これはロボットと人間が一緒に働くこと、データドリブンで分析するサービス設計システムを構築したことが受賞理由となっています。ロボット、マシン、様々な技術、IoT（Internet of Things）、WEB、いろんなモジュールがありますが、それをつなぐのはデータなので、データが神経であり、血液のような機能を果たしているのではないかと思います。

講演1のディスカッション

 

 

 

＜進行＞森村　文一（神戸大学大学院経営学研究科　教授）

 

森村　新村先生、どうもありがとうございました。Q&Aに入りたいと思います。

藤井　次に登壇する藤井です。データがあると思われがちなんですが、必要なデータはない場合がほとんどで、産総研さんなどのPDR（Pedestrian Dead Reckoning：歩行者自律航法）でデータ取得するとか、処理データを取得するとか、あらためてデータを取ることの難しさというか、苦労をあらためて伺えたらと思いますが、いかがでしょうか。

新村　ありがとうございます。あらゆることをやってきて、意外にあるのは人間側の抵抗というか、一定量はデータに対して苦手意識がある人がいます。センサーを付けて手足の動きのデータを取ることになると、頭をかいているのもばれますし、精緻（せいち）に取るほど個人情報やプライバシーという問題に踏み込んでいきます。仕事でデータを取る場合は問答無用ですけど、研究では人間工学実験のデータとして取ることに同意を得る必要があります。そこで丁寧に説明しないと、「なぜ、そんなことをするのか」ということになるので、測ることの社会的な意義や自分の会社をよくするという理由がしっかり説明できないと、全員がウエルカムで協力するわけではないというところが1つ目です。

　2つ目が、きれいに測れない。例えば人間の位置計測は20年やっていますが、電磁波によってある時間帯のデータが切れることがあります。今、吹田のサービスエリアで測っていますが、車の走行量が多いと、どうしてもノイズ的なものが出てデータが切れることがあり、環境的な取りづらさがあります。新大阪店は、電車が近くを走っているので、データを無線で取りづらいとか、エレベーターが動くと切れるとか、物理的な障害には想像以上に頭を悩ませています。

　共同研究では、マネジメント側がデータを気にしなくても、経営の本質は分からないのに、隠そうという人が意外に多いです。マネジメントのメンバーが、大きいものを得るために、データをみんなで共有するという思想を持たないといけない。古い世代のマネジメント層の人ほどデータを隠したがるので、そこに対する理解を促進させることも重要ではないかと思います。

森村　ありがとうございます。チャットに「観測される際にはセンサーの品質が課題になると思いますが、センサーの選定に試行錯誤はありましたか」と質問をいただいております。これについては、いかがでしょうか。

新村　1つは、屋内か屋外かによって根本的に違うということがあります。つまり、GPSが使えるかどうかということです。そして、センサーモジュールが、非常に高価だという問題です。今、高さは気圧で取っていたはずです。角速度はジャイロセンサーです。どちらを向いているかは磁気のセンサーなど、5つぐらいのセンサーモジュールを組み合わせて作っています。ひじとひざのセンサーは1個10万～20万円ぐらいします。

　将来的には安くしたいので、スマートフォンにアプリを入れて位置計測しています。今、重心はスマートフォンのアプリ、ひじとひざのところに自作のセンサーモジュールでやっています。センサーモジュールを買わなくても、例えば、アップルウォッチのような身の回りにあるものを利用して測れるようにならないと、世の中に技術は普及しないと思います。最終的には、計測用のセンサーモジュール開発よりも、世の中にある既製品でデータ取得できないと、データが取れない事態が起こりえます。生産モジュール開発をやめて、既製品に乗り替えることが開発チームのモチベーションにつながります。

田中　後で登壇します田中です。データを取るところの苦労だとか、そこから効率化を図って、最終的には接客時間を伸ばすなど、御社の提供価値を高めるところにつなげていらっしゃることに、大変感銘を受けました。

　質問は、データドリブンでいろいろやられた結果として、お客さま側のデータもいろいろ取られているのでしょうか。

新村　そうですね。お客さまの注文用タブレットでは、単純に客単価が上がってます。2つ理由があって、人間だと待たせる場合がありますが、デバイスであれば待たせることがない。もう1つが、2010年前後に、ひたすら顧客満足のデータ分析をしていましたが、タブレットはお客さまの体感的待ち時間が落ちます。なぜかというと、料理が来るまで暇だからタブレットを押すとそこに動画が流れます。そうすると、特に関西のお客さまは気が短いので、待ち時間を測るとクロックタイムの8～12分が4～6分に感じるんです。

　ですから、デバイスがあることによって体感的な待ち時間が下がることもあります。

　直接的なデータの話ではないんですが、実はロボットを入れる時に、私は心配していました。いろんなお客さまがいるので、何か言われたどうしようという心配はありました。しかし試験操行の時に、見ていたみんなが喜んでロボットについて行きました。トラディショナルなビジネスと全く親和性のないロボットやテクノロジーに対して、お客さまが嫌がると思っていましたが、面白い組み合わせとして受け取っていただけて非常によかった。そして当時報道で取り上げていただいたんですが、ES（Employee Satisfaction：従業員満足度）が上がりました。自分たちは、何か新しい、大事なことをやろうとしている職場で働いているという、第三者が評価していることに対する従業員のモチベーションアップというのは、意外な波及効果だったということです。

田中　いろいろありがとうございます。大変よく分かりました。

森村　私からも質問です。こういうデータを使って生産性を上げるプロジェクトは、新村先生が単独で考えて実行された、もしくはチームを作ってされたのかというのが1つ目で、2つ目は、そのチームにいろんな人が参加すると思いますが、その人選で気をつけた点はあるのでしょうか。

新村　1人で始めましたが、人が中心の業界にテクノロジーとか、データとか、人間を排除するつもりなのか、ホスピタリティ産業の意味が分かってないと世間的にも業界でも、社内でもたたかれました。ファーストペンギンはそんなものなのでしょうけど。社内の従業員が何人かアサインしましたけど、理解は全くなかったですし、9割9分いやいやです。

　潮目はどこだったかというと、お遊びのような実験から、徐々に実装に入っていった時に、一番ベテランだった旅館出身の料理長が研究に飛び付いたんです。なぜかというと、現場で人が足りなくて困っていたことと、料理長の発想が柔軟でした。興味を持つ幹部メンバーと一緒に何か所かの職場で実験して、徐々に効果が出てくると、「何か変なことをしていたけれど、面白いらしい」「いい結果が出るらしい」と、現場ネットワークでじわじわ広がっていって、現場から「次、うちでやりませんか」という声が徐々に上がってきました。そういう状態になるまで15年ぐらいかかりました。

　料理人は「鉛筆を持つのが嫌だから包丁持っている」という人が多いので、データとか、テクノロジーと真逆の世界です。そういう会社に理解を深めていくのは、ある意味、我慢比べみたいな状況でした。

森村　なるほど、スモールスタートでやっていって、成功体験を積み上げていくということと、キーマンになる人を特定して巻き込んでいくのが不可欠だという学びですね。

新村　そうですね。やはりトップ自身がどこまで腹を据えられるかが大事だと思います。私の場合は、今、会社のトップですが、データを取り始めた時は、創業者が現役でした。創業者は文系でこういうことに対する理解力はゼロでした。ただ、「ごめん、わしは文系で、君の言っていることは理解できない。ただ、何となくやらなくてはいけないということだけは分かる」と言われました。産総研と共同研究を始めた時も当時の部門長と一緒に創業者に会いました。その時には「何も分からないから、まな板の上のコイだと思ってやってください」と言われました。トップが何も分からなくても、覚悟だけはあるということを示すことは大事だと思います。

　データを見て従業員が面白いことを言いました。ロボットを入れた時に、ロボットの位置情報をディスプレイに表示するようにしました。それを見ていた60歳半ばのアルバイトの方が、「私、店全体のことが考えられるようになりました。目の前の仕事をしている時は、自分のことしか分からないので、自分のことだけを考えていました。ところがロボットA、B、C、Dがどこにいるかが表示されるので、ロボットの位置に対して自分が何をすべきかということを考えるようになりました。このディスプレイが入ることによって、個人プレーヤーからチームプレーヤーに変わったんです」と言いました。テクノロジーファミリアではない普通のアルバイトさんが、全体最適の視点を持つというのは、データが人の組織貢献や全体最適に対してこんなにインパクトがあるという、非常に興味深いコメントだったので紹介しました。

森村　なるほど、それは恐らくデータリテラシーというか、マネジメントリテラシーが上がった結果が得られたということですね。新村先生ありがとうございました。

 

講演２　デジタルトランスフォーメーション（DX）と価値創出　

 

 

藤井　信忠氏
（神戸大学DX・情報統括本部情報基盤センター　教授）

 

システム的視点でデータ活用を考える

　「デジタルトランスフォーメーション（DX）と価値創出」ということで、前半にデータを使ってどのように革新につなげていくかという概念的な話をします。実例は新村先生や田中さんと共同研究をしているので、今、なぜこういうことをやろうとしているのかというモチベーションと価値について、われわれのスタンスを紹介したいと思います。

　私は神戸大学工学部機械工学科出身です。機械工学科ですが、機械の中でも生産システム系のことを学生の頃からやっています。例えば、全ての要素が移動しながらものをつくると、非常に柔軟なものづくりができるのではないかということで研究を始めました。

　学生だった1998年ごろからシミュレーションの画面を作成して実験データを可視化できるようにしています。自由度の高いものをどのように動かすかが非常に難しく、最近は、多数のドローンを協調的に動かすとか、制御技術の固まりのようなやり方で動くようになってきています。自律分散システムといわれる生物の意思決定の仕方で、AIなどを使って、ものづくり現場を革新しようというのが研究を始めたきっかけです。

　新村先生と出会って、サービスの研究をするようになりました。最近では、第2次産業だけではなく、特に飲食業の方々と研究していますので、材料供給の産業ともいえる農業や林業、これから水産業も一緒にやろうとしています。いろんな分野を連携させて、システム全体で最適化することを目指しています。

　もう1つが公共です。まちのデザインはアーバンシステムデザインといわれます。神戸の三宮地下街の「さんちか」のシミュレーションをしました。コロナ前のデータ計測結果では、1日10万人ぐらいが「さんちか」を通行します。「さんちか」を通行する人の移動行動データを取って、画面上に再現してシミュレーションします。これはリーシング（商業用不動産の賃貸を支援する業務）の計画でやっていたものです。いろいろなものを対象に、システムを用いた研究をずっとやってきています。

　2年前、神戸大学にDX・情報統括本部ができました。私はDX・情報統括本部の情報基盤センターに所属していますが、教育面は工学部および大学院システム情報学研究科で担当しています。バリュースクール（V.school）でも活動していますので、その話も紹介します。

　まずDXの話です。ソフトウエア分野のStoltermanとForsの論文に「デジタルトランスフォーメーション」という言葉が最初に出てきたといわれています。DXの本質的なことが彼らの論文に書いてあるので、私はよく引用しています。論文には「デジタル技術によって引き起こされる人の生活の全ての場面における変化のこと」と書いてあります。何か特定のものがデジタル化するということではありません。「特定の領域における変化だけでなく、大きな全体としての変革が期待される」ということと「デジタルデバイスによって全ての要素がつながり、部分の変化が全体のシステミックな変化を引き起こす」ということです。「システミア」と私たちは言っていますが、この論文は「システマティック（systematic）」ではなくて「システミック（systemic）」というキーワードが使われているという点で、Stolterman先生とFors先生はDXをよく分かっていると思いました。

　システミックは「システム的に」という意味です。システムを定義するのは難しいですが、「状態の記述」といわれているような性質です。新村先生が最後に紹介された従業員の方がシミュレーションを使って全体を見られるようになったというエピソードは、まさにシステム的視点を獲得したともいえると思います。そういった意味での「システマティック」ではない「システミック」な変化がしっかりと書かれているという点を、私は強調しています。DXは、「人々が良い人生を送ることが重要であり価値である」ということや、「美的体験（aesthetic experience）を実現することが重要」「良い人生を送ろうとしている人に仕える（being in service）」といったあたりはソフトウエア分野の人たちなので、SaaS（Software as a Service）的なサービスの考え方でこういう表現をされていると理解しています。つまり「システマティック」が全体を構成物に分解し、その関連性を系統的に理解するという意味で用いられることが多いのに対して、「システミック」は全体のことを指しています。DXは系統変化（構成物の一部の変化）ではなく、全体変化を指すという意味です。

目指すべき姿を定め、手段としてのデータを創り活用する

　日本では経済産業省から、DXレポート2.1が出ています。その中でデジタイゼーション、デジタライゼーション、デジタルトランスフォーメーションという段階があります。単なるアナログ・物理データをデジタルデータ化するだけではなくて、それを使って個別の業務・製造プロセスをデジタル化する。それをさらにつなげていって、システムや組織全体の革新につなげていくのがDXの考え方ですが、それを引き起こすための最初の入り口になるのがデータになります。

　DXは、目的ではなくて手段であるとよくいわれますが、私は結果であると思っています。つまり、データがあるとかないとか、あるから何かできないか、革新につなげられないかというのは、議論が逆だと思っています。まずは、目指すべき姿や何を実現するかというのを先に定める方が良い。それを議論するきっかけにして、今あるデータで議論を始めることはすごく有意義だと思います。手段としてシステム情報技術、あるいはデジタル技術を活用して、先に何をしたいかを議論するべきだと思います。

　今あるデータでは、できることは限られてしまうので、必要なデータを取得する必要があります。いろいろな技術的制約あるいは組織的な制約があって、苦労されているところだと思います。では、データがそろったとして、トランスフォーメーション（変革、革新）する際に、方向付けのための、価値の議論は避けられません。誰のためのどんな価値かということです。その価値の源泉が何かを議論するべきだと思います。

データと人の関わりから価値共創を考える

　サービス工学の上田完次先生は私の師匠で、学生の頃からずっとお世話になっていました。上田先生たちの議論に私も参加させてもらい、勉強させてもらっていた中で、とても大切だと思う観点を紹介したいと思います。

　まず、よくいわれたのは、高度経済成長期はものをつくれば売れた時代です。いわゆる大量生産の時代で、そもそも、社会も、消費者も、技術も未熟であったことなど、いろいろな要因があると思いますが、技術者主導でものがつくられていました。良いものができれば、それを欲しいと思って買っていたわけです。この消費者の状態あるいは思考を、技術者が分かっていたということです。あるいは技術者主導でつくっていたものが、消費者が求めているものと一致していたということです。

　私が学生だった頃によくいわれたのが、もはや消費者は一様な価値観を持つ集団ではなく、多様な価値観を持つ集団と捉えなければいけない。まさにマーケティングが発展してきた時代だと思います。「変動への適応可能なものづくり」が私の研究テーマで、人工物の生産システムに生物の柔らかさのようなものを導入できないか、ということを研究し続けています。

　大量生産だった頃の価値提供型ものづくりは、技術者主導で製品自体の価値をつくり込んで、その価値を提供していたと思います。それが、多品種・変種変量生産のいろいろなものを用意して、その市場の変動に対して適応することが、ものづくり側の価値であると考える価値変動適応型ものづくりに変化してきました。

　さらに今、超多様な価値観を持つ、Z世代、α世代の学生に欲しいものを聞いても答えられないです。それが良い、悪いという議論をするということではなくて、そういう変化が起こっているということです。このような変化が起こっている時代にマーケットの主役であり、これからマーケットのメインになっていく彼ら、彼女らに対して、どのようにものやサービスをつくり、提供して対価を得るかを考えると、その価値がいったいどこにあるかを議論せざるを得なくなってきます。性能として表すことができる客観的な価値ではなくて、主観的な価値をどのように捉えていくかを考える必要が出てきます。そういった中で「価値の共創」「コ・クリエーション（Co-Creation）」というキーワードが出てきて価値提供から価値共創へ移行していると理解しています。

　そこに対してデータなどを使って、きっかけをつかんでいくということだと理解していますが、私がもともと研究していた第2次産業、製造業のサービス化や製品・サービスシステム、あるいはサービタイゼーション（Servitization：製品や商品をサービスとして顧客に提供し、売り上げを出すビジネスモデル）といったいろいろな研究があります。サービス産業の製造業化は一時期よくいわれたことですが、高付加価値やそれらにつながる第1次産業、あるいは公共・都市デザインなど、同じものの考え方を使うことで、いろいろな革新ができると思います。現在、私は対象を絞ることなく、いろいろなことにチャレンジしています。

　価値の議論で、面白い議論を紹介します。工学者が従来やっていたのは、価値工学の分野でよく出てくる「機能/コスト」です。投入コストを下げ、得られる機能を最大化することで価値が大きくなる。しかし、客観的な価値だけでは、議論ができなくなっているのが現状で、どのように拡張していくかということです。そうなると社会学や人文科学分野の知見を借りざるを得なくなってきて、1つは経済学の「価値は価格である」ということです。人の主観を考えると、認知系や心理学の「価値は満足である」になると思いますが、そういった観点を取り込まざるを得なくなってきます。私は工学に軸足を置いていますが、従来の工学は変動要素として、人の主観のようなものはできるだけ排除しようとしてきました。典型的なキーワードは「ヒューマンファクター」が表現しているとおり、人的要因は排除するものでした。今はいろいろな学問分野を統合して、人的要因を使ってどう価値を生み出すかという議論をしていると理解しています。

　バリュースクールで『価値創造の考え方』という本を出版しました。1年間、議論した成果をまとめたものです。本には、「価値創造スクエア」という考え方を提案しています。PDCAサイクルとも関係しますが、課題が与えられて、何かやって、結果が出る。これは客観的な世界で、あるものを評価できる。つまり、何らかのシステムが評価できるということを示します。実はその課題の裏には主観的なユーザーなり、従業員の期待などが隠れていて、そこがリンクしなくてはいけないし、結果も単にパフォーマンスがどうということではなくて、使った人がどう満足するかという主観的な立場です。そういうものをどのように捉えていくか、「課題」「期待」「結果」「満足」の4つの関係をしっかり考えないといけません。バリュースクールはスタートして丸4年たちますが、「価値創造スクエア」は一番のよりどころとしている考え方です。

　従来の製造業は、ある仕様が与えられて、その仕様を満たすようにものがつくられます。製造業のサービス化は、そこに従業員満足やユーザー満足を加えて考えるので、結果の評価に主観的なものを入れたのが従来のサービス業だとすると、そこを速いスピードで回すのは、ソフトウエア工学分野で今、よくやられているアジャイル開発です。

　それに対して、デザイン思考は課題をどう導くかに主眼が置かれているので、期待をどのように取り込むかを議論していると考えられます。サービスマーケティングもどちらかというと期待と満足、あるいはアート思考も同様だと位置付けています。価値創造スクエアなのに、「価値」というキーワードが現れていないのが面白いと思います。

　そもそもPDCAのような1サイクルを回すことで価値が出てくるという考え方もあると思いますし、満足から次の期待が生まれてという形で、次の課題から結果、満足という形で数珠つなぎに価値が創出される。あるいは「スパイラルアップ」という言い方もされますが、改善が相乗効果で好循環を生むような形で価値がどのように生まれていくかを議論することも大切だと思います。この枠組みを使って、いろいろな分野に対してアタックしていくことを考えていますし、既存の研究を位置付けても面白いのではないかと考えています。

　サービスなり製品をつくって、提供して、受容するというように、従来のシーケンシャルなものがあり、製造業でコンカレントエンジニアリング[1]がずいぶん前に提案されていました。最近は「共創」という言葉を使うときに、インタラクティブな関係性を考えざるを得なくなるので、生産・提供と受容者にとっての価値共創を実現するシステムをつくることを、私の研究テーマの一番の大枠に位置付けています。従来型の生産・提供理論や、消費者のモデリング、経済学、認知科学などで人がどう感じるかという話も含めて、どう取り込んでいくかにチャレンジしています。

　例えば、第3次産業と第1次産業の連携では、食と材料供給である農業の全体で研究もやっています。また、材料供給たる農業生産で、JAや農業技術センターの皆さんとわれわれの技術で収量予測の共同研究を5、6年やっています。今、レタスの収穫時期を予測するアプリを、JA経由で農家の方に使ってもらい精度良く活用できています。撮った写真で葉っぱの枚数を数え収穫時期を予測するというやり方で、±3.5日ぐらいで予測が当たり実用化の段階に来ている状況です。

　収穫時期が分かると、販売側（例えば、農家）から使う側（例えば、飲食店）にいろいろな情報を提供できますし、今度は使う側が、材料発注のときにも産地の情報を使えるようになるので、連携がうまくできればフードロスも減りコストメリットも出てくると思います。

データを活用して社会全体の価値共創を目指す

　デンソーテンの田中さんにもご協力いただいている、まちづくりについて紹介します。今、神戸という「まち」はどう変わっているかを考えたことがあるでしょうか。あるいはこれまでの神戸と問われたら、開港から150年以上の歴史があるということでしょうか。「神戸ってどんなイメージですか」と聞くと「外国人が多い」「洋菓子がおいしい」「おしゃれ」などがあげられると思います。あるいは、1995年の阪神・淡路大震災。当時、私は大学3年生でした。この震災は私の心に大きな爪痕を残していますし、いろいろな考え方に影響を及ぼしていると思います。まち自体もそうでした。震災の復旧・復興工事（改修）が終わって、ようやく今、三宮の駅前再開発が始まっています。それまでの神戸は、震災からの復旧・復興ということだけで、時代の変化に取り残されてまち自体が変化してきませんでした。神戸は製造業中心の産業構造だったので、下請け会社が非常に多かったというのが事実としてあります。GAFAM（Google, Amazon, Facebook (現 Meta Platforms), Apple, Microsoft）をはじめとするプラットフォーム寡占が起こり、産業構造が変わったのに対して、対応が遅れています。これから神戸のまちをどのように変えていくのかを考えたときに、行政がまちの将来図を描いて、トップダウンで進められることでは面白くないし、白けてしまいます。医療産業都市を打ち出して、ポートアイランドに様々な分野の先生がたくさんいらっしゃいますが、市民の方々がそれをどれだけ認識しているか考えるとなかなか難しい状況です。神戸ならではの価値をボトムアップで市民がつくり上げていかないといけないのではないかと思いました。

　まちづくりでデータを考えるときに、「スマートシティ」というキーワードがあります。スマートシティもいろいろな考え方があって、大きく受け入れられているのは次の3段階だと思います。1つ目はBEMS（Building Energy Management System：ビルエネルギー管理システム）といわれる、ビル間の熱を融通し合って効率よくするところから始まったといわれている技術中心のビジョンです。これがまずスマートシティ1.0とされています。それを政府主導のビジョンとして、生活の質を向上させるEnabler（コア技術やデバイスを持った新たな社会システムを構築する上で不可欠な企業）の技術ソリューションを利用する。今は技術主導がスマートシティ2.0までの段階だと思います。スマートシティ3.0は、生活の質を向上させて、繁栄を生み出すための市民との共創に基づいた市民または人間中心のビジョンであるというのが、スマートシティ分野でよくいわれる話です。

　DXの定義とよく似ていて、その考え方がまちづくりの分野で結び付いて、整理されているのがスマートシティの考え方だと理解しています。私はスマートシティが目的ではなく結果であって、トヨタのウーブン・シティのような技術がたくさん入った先進的なまちがスマートシティではないと思います。「スマートな都市生活ができるまち」と定義すると、そこで暮らす人々がスマートになるスマートシチズンが醸成されて、ハード（まち）もソフト（人）も多面的に発展する。単に特区をつくって、技術を入れて「新しいまちにしましょう」と言っても誰も感動しません。今までの歴史や文化、アートなどもうまく取り込みながら、人が中心のまちにしていかないといけないと考えています。

　私は今、「078KOBE」というイベントを主催者の一人としてやっています。このようなイベントをフックにしたまちづくりは、国内外のいろいろな地域でやっています。まちづくり団体などと連携して、まちづくりの専門家から見たアドバイスなどもいただいています。ICT（Information Communication Technology）技術では田中さんにも協力いただいています。地域ICT推進協議会（COPLI）が兵庫県最大のITのコンソーシアムです。COPLIとも連携を図って、神戸で新しいまち、スマートシティを実現したいと思っています。

　単にまちづくりということだけではなくて、アイデアをどう社会実装するかという枠組みで考えても、実はすごく意味のあることだと思っています。具体的にどのように研究に結び付けているかというと、例えば人流を解析します。データをどう取るかをまちで展開したということです。カメラと人工知能や画像処理の技術を使うと、人がどこからどこまで、どのように歩いているかは、カメラを屋上に設置するだけで人流データは取れます。埼玉県大宮市で共同研究した事例では、歩道空間にベンチを置いて多機能化してユーティリティーを上げました。しかし、本当にベンチがどのように使われているのか、どれぐらい効果があったかという定量的な評価はできていません。年に1回、もしくは数回、人手で2、3日計測しますが、それはあくまでスナップショットでしかないので、カメラで継続的に見ていく必要があります。例えばヒートマップでは、あるエリアは人が滞留しますが、同じような仕掛けがあっても人が滞留しないエリアもあります。そのように今まで見えていなかったまちの様子が見えてくるということです。

　私の研究ではありませんが、三宮地下街の「さんちか」で人流と気流のセンサを用いた空調制御の実証実験を紹介します。一様な温度に冷やす地下街は、人がいないところは冷えすぎていることがあります。人の流れ、疎密を測って、人が密なエリアの温度を下げて、疎のエリアはそれほど温度を下げずにエネルギーコストを40％削減しました。

　そのときに測った人流データを用いて、私は人の流れを計算機の中に再現してシミュレーションをするリーシングをしました。南側の神戸市役所寄りは飲食店が多く、北側で阪神やJRの駅寄りは、ファッションやグロサリーのお店が多いです。

　飲食やファッションなどの機能で区分けするよりも、機能を混ぜた方がいいという研究結果を得ていたので、その結果を用いて、どのようなまちづくりをしたのか、あらためて「さんちか」を検証しに行こうと思います。

　シミュレーションは、As-Is（現状）の分析です。人の流れが再現できると、各店舗への入店者の情報が取れます。そのシミュレーションをすることで、パラメータを変えて、商店の店子の並び方を変える、レイアウトを変えると入店者数がどうなるかということが、結果として出てきます。一番いいレイアウトはどういったものかを知りたくなるので、シミュレーションの上に最適化を示す。これは「シミュレーション＋最適化」というやり方です。最適化のアルゴリズムを組み合わせることで、レイアウト計画を最適化していきます。これは計算量が多いので、どのようにやるかは、腕の見せどころです。「さんちか」も、入店者数を最大にするレイアウトとはどんなものかを、計算の結果、導くことができます。そういったものをレイアウト計画に活用してもらっています。

　他にも、スタジアムの周辺の混雑緩和については、人の行動変容が関わってきます。「さんちか」は空間のデザインですが、こちらは人の行動をどう変容につなげていくかということです。個人の目的（早期帰宅）と主催者の目的（混雑緩和や周辺商業施設の売上向上など）のバランスをどうするとよいか、デンソーテン社と共同研究しています。

講演2のディスカッション

森村　藤井先生、どうもありがとうございました。Q&Aのセッションに移ります。

　チャットに「DXの実現に際して、産業ごとに普及や進化がまだら模様となるのは、十分な予算確保とは別に産業団体あるいは企業がその目指す姿を設定できていないことも要因だと考えていいでしょうか」という質問をいただいてます。

藤井　おっしゃるとおりだと思います。製造業は、目指しやすい分かりやすい業態だと思います。よく技術相談を受けるのは「こんなデータがあるんですけど、何かできませんか」と聞かれます。いろいろ話をしている中で、実際に課題感や目指す姿を議論しながら設定できてきます。その結果として、こういうデータが必要だということになるので、予算も必要ですが、そもそも何ができるかも分かりにくいというのもあると思います。

森村　今の話について伺いたいのですが、企業がデータを持ってきて、それを見て何かできそうという場合とできなさそうだという場合の分かれ目は、どういうところにあるとお考えでしょうか。

藤井　無目的に取っているデータは使えないことが多いです。データは目的があって取るべきものだと思います。データを取る能力と計算能力が上がってきているので、無目的で猛烈にデータを取ってというのは、ある種のビッグデータです。しかし、取りやすいデータしか取れていないことがほとんどなので、本当に必要なデータはコストをかけて設計して取っていかないと使えないことが多いと思います。

　無目的なデータで議論をスタートすることは意味があると思いますが、役に立たないというのは、それだけで閉じないことの方が多いというのが正確な言い方かもしれないです。

森村　なるほど。ありがとうございます。

筧　 まちづくりのお話について興味を持ったのは、DXの説明の中で手段ではなく目的だという話がありました。例えば、まちの人流を分析する上で最適なところを考えていくという話でした。最適なところは、お店の人、まち、あるいは市役所の人によってゴールがそれぞれ違うのではないかと思います。そのあたりはデータを使って、どうやって最終的にまとめられるのか、非常に興味を持ちました。

藤井　先ほどの地下街の事例は、神戸地下街株式会社とやっていたので、「商店をどう活性化していくか＝売り上げ」が本来はいいのですが、そのデータも完全には出てこないので、彼らが部分的に持っていた過去の入店者数を計測したデータに合うようにシミュレーションをチューニングしてつくったものです。この場合、目的は明示的に与えられているのでやりやすかったです。

　われわれは工学者なので、目的を初めに置きますが、まちづくりの目的は、地域活性や回遊性を上げるなどになると思います。どちらかというとアブストラクトというか、ぼやっとした目的で始めざるを得ないところがあって、その中でやっていくには、どういう目的ならできそうかという議論をしていくしかないような気がします。市役所がどう感じるか、あるいは通行者がどう感じるか、そこに入っている業者の方がどう感じるかというのは、われわれの分野でいう多目的構造になるので、その部分の目的と全体の目的をどう整合させていくとか、コンフリクトが起こるときもあるので、そこをどう考えていくかは非常に難しい問題だし、面白い問題だと思います。

　目的を定めなくていい、あるいは定まらないという工学的な視点でいうと悪構造な問題ですが、実はそこに面白さの本質があると思っていて、逆にまちづくりの方に出ていっていると言ってもいいかもしれないです。

筧　ありがとうございます。農業の最適化にデータ活用されているというお話がありました。一方でそれを使って生産者に提供されている飲食業のサービスもあると思いますが、そこをトータルでエンドユーザーに向けて最適なサービスを提供して、フードロスをなくすという話があったと思います。製造から販売までを一気でやっている会社にとってはそのデータを共有し合って、そこで最適化することができると思いますが、そうでない場合は、農家は農家、飲食は飲食と分かれていると思います。その場合、データを共有する際に、何か弊害があったりするのでしょうか。

藤井　地域の物産展に出店されているような6次産業化をされている方は、一気通貫でデータをお持ちですが、農業地域の多くは、タマネギだけではなくて、レタスもキャベツもハクサイも多品種つくっています。1つの品種で1日に何万ケースも出荷される産地でやるのも面白いと思います。そういうところは、JAの力がすごく強いので、JAのガバナンスが効いている地域であるとデータは集めやすく、JAが窓口になっているので、私たちが開発したソフトウエアを無料で使用してもらっています。使ってもらうことで私たちの情報収集にも役立つし、農家にも役立ちます。たくさん集めたデータでJAが出荷予測して、それを大手販売業者や小売業者とデータをやりとりすることを将来的には描いています。

　分断していますが、キープレーヤーが業界にいるので、うまくデータでつなぐことができると一気に変わる可能性があると思います。6次産業をされている方はご自身でできますが、それはなかなかスケールしないと思うので、私たちはむしろ産地に入り込んで、スケールする方向を目指してやっています。

筧　ありがとうございました。

森村　藤井先生がされている研究やお話をJAに持っていくとすんなり受け入れられて「じゃあ、やってみましょう」とはならない気がします。例えば、抵抗があった場合、それをどのように乗り越えられたか、可能な範囲でお話しいただけないでしょうか。

藤井　ある自治体のケースですが、農業地域では、高齢化で困っているとか、労働力が足りなくてというのは、どこでも抱えている問題で、そういった状況を改善しなければいけないと思っている方はたくさんいます。そういう方とJAの熱意のある方が、JAの中を調整して、何とかうまく進め始めているということですが、抵抗勢力があったり、自治体側もかなり好意的にやってくれてはいますが、スマートアグリなどには理解がないということはあります。

　そこはスモールスタートで試作品を作って、使ってもらってということを地道に繰り返して5～6年やっています。そういうことを繰り返して、少しずつ拡張、拡大してようやく本物になりつつあるという状況です。

森村　なるほど。ありがとうございます。最初にそれを定義しましょうということと、そこから、観測、分析、設計、適用を始めましょうというプロセスを経て理解ができるということですね。

藤井　やはりそれがないと、みんな乗ってきません。「面白そうだから、やりませんか」と言っても、忙しくて余裕がありません。問題意識があるところに突き刺して「これ、困っているんですよ。やってみようよ」という人が1人でも出ると、一気に進み出す実感は何となくあります。

森村　なるほど。藤井先生、どうもありがとうございました。

---

[1] コンカレントエンジニアリング：製品開発における複数のプロセスを同時並行で進め、開発時期の短縮、コスト削減を図る

 

講演３．顧客志向のデータ利活用

 

 

田中　真一氏
（株式会社デンソーテン　イノベーション創出センター　プロジェクトリーダー）

 

人と社会の問題を解決するデータ活用を考える

　「顧客志向のデータ利活用」と題しまして、主にモビリティ界隈のデータ利活用について、様々な事例を交えながら、お話しできればと思います。

　私は関西大学の電気電子工学科の出身ですが、入社以来、自動車が好きで、特に盗難防止装置やボデー系と呼ばれる、走る、曲がる、止まる以外の利便系の電気系部品やシステムなどハード設計をしていました。車に残っているユーザーの操作履歴などのデータも駆使して、おもてなし機能や安心、安全系の商品企画に携わりました。その後、米国シリコンバレーの富士通研究所アメリカに出向し、今はイノベーション創出センターで、MaaS （Mobility as a Service）の先行領域やスマートシティにおける企画開発などを行っています。オープンイノベーションで、移動社会の価値向上を狙っています。

　かつての商品企画の取り組みについて紹介します。先進安全支援系のサービスをてんこ盛りにしたような車を大改造で仕立て、皆さんに見て、触れていただいています。特に形にすることにはこだわってきていて、企画というのは、民間企業の人間からすると、通してなんぼの世界です。一番難しいのは社内を動かすところだと思っているので、お客さまに「いいね！」をもらって会社を動かすというのが、一番早いと思いますので、大事にしています。

　シリコンバレーに3年ほど行かせていただきました。イベントに参加すると、CEOやCFOといったCレベルの方が１対１でフランクに話してくれます。大事なのはネットワークだと思います。今でもそのネットワークには本当に助けられていますし、起業家の課題設定や新しいサービスをたくさん見てきました。今回のお話も、インターネットで調べた情報も一部ありますが、ほとんどが対話で私自身がつかんでいる情報をベースにしています。

　カリフォルニア大学サンディエゴ校（UCSD: University of California San Diego）の先生方と、ドライバーモニタリングシステムを研究して、ものにしました。オンデマンドデータコレクションの仕組みを企画して、これもものにして検証しました。後ほど紹介します。

　現在は、藤井教授と森村教授と共同研究している「Be Kobe Fun！」という、神戸のまちなかでの回遊と消費を促す技術サービスをやっています。この取り組みは、私が「Smart Move」というコンセプトを掲げ、目標は移動社会における時間やエネルギーの無駄の最小化です。もともとの思いは市民の皆さんにウェルビーイングな移動生活の価値を提供したいということで取り組んでいます。

　まずモビリティの領域で、多くのデータをもとに価値創出するパターンを主なスコープとしています。図1は、レンタカーの貸し出し無人化や安全運転支援ソリューションのフローです。例えば、その人の顔データで認証して車の鍵を開けますといった１対１のことではなくて、多くの利用者のデータが集まることで、ヒヤリハットについての分析ができたり、相対的にその運転手さんのリスクが分析できたりします。結果、リアルワールドの利用者に、「この辺りでは路上駐車が多いから注意してください」といった注意喚起ができます。面白い例として、韓国から来たインバウンドの方がレンタカーを使うと、一旦停止を無視する人が多いらしいです。アメリカから来られた人は、路上駐車しがちといった傾向があるようです。そういうことを事前に、気を付けてくださいと呼びかけられるような、安心、安全系の価値を提供できるものです。このあたりをメインでお話しします。

「どんなデータで何ができるか」を考える

　まずデンソーテンを紹介します。カーナビなど、カーインフォテインメント機器や、AE（Automotive Electronics）事業であるハイブリッド制御やバッテリーマネジメントの制御などをやっています。データドリブン分野を中心にタクシー配車システムやセキュリティシステムなどいろいろやっている会社です。製造業からデータなどを使い生活の価値向上に軸足を置いていきたいという思いで、「VISION2030」を掲げています。

　自社のフリート関係の事例です。フリートというと、業務用車とかレンタカーなどになりますが、「Offseg」というサービスがあります。トラブルを防ぐ、事故を防ぐ、無駄を防ぐを指して、「を防ぐ」でOffsegです。いろいろな方のドライブデータを元に、ドライバーの状態や事故リスクを検知して警告することが可能です。自動車保険のユースケースで、これは自動車保険Ａ社の話ですが、裏側は、当社はこのエッジの端末、通信内蔵のドライブレコーダーを使いながらデータを取って、自動車保険もDXで変わりつつあります。こういったユースケースでは、保険会社のユーザ向けサービスの、ハードとクラウドをわれわれが提供しています。自動車保険は、図2のようなフローです。不幸にも事故に遭ってしまったら、事故受付があって、クレーム請求してという流れになると思います。経験された方は分かると思いますが、結構時間がかかります。データが集まることによって、保険会社も事故受付の時間短縮、クレーム処理を効率化できるということで、良いサービスとして保険会社あるいはユーザーに認知されつつあると思います。

　使っているデータは、日時、位置情報、車両ID（IDentification）、ドライバーID、車速、加速度などですが、これはほんの一部です。例えば、どこのドアを開け閉めしたかとか、どのスイッチを触ったかといったデータもありますが、それが全部クラウドに上がっているわけではありません。こういうデータが欲しいと説得して取ってくることが大事だと思います。データには、何か操作した、アクセルを踏んだ、といったデータや内部の圧力センサー情報といったものもあります。これに加えて、ドライブレコーダーのデータなどが車の通信回線を通して上がってきます。

　ここで、自動車を取り巻く社会問題を俯瞰して、どんなデータ利活用事例があるのかをお話ししたいと思います。われわれは、都市集中の問題にもともと着目していました。シェアリングと自動運転という組み合わせです。最終的にはWaymo社がやっているロボタクシーが1つの答えだと思います。彼らは2016年ごろからシリコンバレーの公道で実験しています。

　自動運転プラスシェアリングサービスなどの課題に対して、大きな潮流である4つのアプローチがあると考えられます。自動運転の開発は、安全確立のためのデータエコシステム。そして、運転から解放されることにもなってくると思います。こういった人に対しての時間有効活用策、あるいはシェアリング関連からのビジネスの効率化やその利用者の方への安心の提供というアプローチに着目しました。

　安全確立のためのデータエコシステムでは、EDR（Event Data Recorder）によるデータ収集。そして、メーカーをまたいでデータ共有する仕組み。そのデータをシミュレーションして、仮想データも含めて、シミュレーションするのがソリューションとして考えられます。CG（Computer Graphics）でのシミュレーションも行っている米NVIDIAが、昔からしていることです。

　シェアードカーサービスの効率面でいくと、最近、相乗りの話が日本でも出てきていますが、これは欧米では以前からやっていて、同じルートで通勤、通学する人を分析、マッチングして、例えばUberだと、乗車してもらう場所まで少し歩いてもらって効率化していきます。それによって、ユーザーも少し安い値段で乗車できます。一方で、Uberのドライバーは、走行距離がすごく多いので故障も多いです。古い車を使っている方も非常に多い。アメリカでは自主点検しなければならないのですが、なかなかしません。そこで、センサーを1つ後付けすることで、振動データから故障予測しようというのもあります。また、モビリティサービスに対する利用者への安心提供ということで、個人のリスクをいろいろ判定するものも出てきています。

　いろいろなデータ利活用の事例がありましたが、仕組みとしてはほぼ同じで、現実世界にある車などのデータを、仮想世界のクラウドで処理して現実へ返すという構図です。われわれの着目するビジネス領域としては、自動車メーカーの構想を実現していくことが一番大事だと思っています。

　例えばトヨタ自動車様でも、自社だけで活用するわけではなく、様々なことに使ってもらおうという動きをされています。こういったモビリティサービス・プラットフォームでやりながら、このいろいろなサードパーティーのサービスに、トヨタ車のデータを活用していく。トヨタみたいに台数があるところは、自前でこういうことをやろうという絵を描きますが、うまくいっていないところも多いというのが実情です。

　私が注目をしたのは、自動運転を含む車両開発や地図更新のユースケースです。車から多くのデータを取る必要がありますが、容量も限られているし、通信料もかかるので何でもアップするのは非現実的です。

　そこで、私が取り組んだのが、「On Demand Date Collection」（図3）というデータ収集のプラットフォームです。車から全部データを集めると、私の当時の見積もりですが通信料だけで年間9,000億円もかかってしまうので非現実的です。1台当たりの車のデータ量は、1時間で25GBといわれています。これを全部収集するわけにはいかないのでボトルネックになっています。多くの車から得られる、急ブレーキや急ハンドル、あるいはABS（Anti-lock Breake System）や横滑り防止装置の作動情報が集まると、落下物や故障車、事故車などの把握ができて、それを後続車に伝えることは可能だと思いますし、こういうデータが自動運転の開発にも不可欠です。こういうコーナーケースも学習させないと自動運転の開発はできないので、それにも使えるということです。

　そういうものも事例にしながら、様々なユースケースに対応できるデータ収集の仕組みはどうあるべきかを考えました。図3のDashcam ECUはエッジ側になりますが、画像認識AIがポイントです。車の前の映像データはプライバシーの観点でそのまま収集することはできません。人の顔情報やナンバープレートをマスキングしないといけません。ここをAIで処理して、クラウドへ送信する。送信するのは映像を送信するのではなく、この車はこんなデータを持っているというタグ情報、テキスト情報だけをクラウドに送信します。そのため、この段階では非常に通信量が低い状況をつくり出すことができます。

 

　例えば、自動運転の開発者だとすると、落下物をよける制御を開発するときに、そのタグ情報を元にしたメタデータを元に、必要な実体データ、そのシーンだけの映像データをオンデマンドで取ることができる仕組みを考えました。試作して実際に複数人で走行して、データがたまった時点でデータの利用者側に立って、必要なデータにリーチできるか試しました。顧客展示会で発表して、「いいね！」をたくさん得て、実際にこの仕組みは採用されました。これは大変うれしかった事例です。

　他社になりますがイスラエルOtonomo社では、様々な自動車メーカーと連携し、マーケットプレイス、あるいはデータエクスチェンジプラットフォームを作られています。映像データは取り扱われていないと思いますが、数多くのOEM （Original Equipment Manufacturing）が契約しています。このOtonomo社が着目するデータ利活用の領域は、保険とかフリートマネジメント（社用車や事業用車両の適切な管理運行）系で、サービスのインパクトが大きくお金になりやすい、お金になりやすいはずだということで彼らはやっていますが、もうかっているかというとまだまだ厳しいようです。最近ではEV（Electric Vehicle）の流れに乗って、EVの充電管理、あるいは電池の健康状態の管理などに注力しているようです。なぜうまくいかないかは、みんなでやろうという形になかなかならない。あるいは、かかるコストに対して金銭的な価値につながっていないというのが実情だと思います。

　では、スマートシティのユースケースを紹介します。サンディエゴの米Netradyne社に伺いました。フリート向けに非常にリッチな車載機を積んでいます。加えてクラウドのデータ分析も非常に優秀で、地形情報の収集やコーナーケースの落下物など映像情報収集も行っていて、OEMに売っています。本体は高額ですが、これをもし一般ドライバーが取り付けたら、そのドライバーにも見返りがあってもいいかもしれません。

　もう１つは米RoadBotics社です。ここも私は一緒に実験させてもらいました。車の前にスマホを付けて、前の映像を撮ったら、クラウドで分析してくれて、路面状態が分かります。何のためにやっているかというと、アメリカはポットホールといわれる穴が道路にたくさんあります。これは道路管理者が1〜2週間以内に直さなければいけないというルールになっているので、優先順位を決められますから、非常にニーズが高いようです。

　次は保険関係です。先行事例で紹介すると、映像を含むポストクラッシュデータというクラッシュした後のデータを活用して、事故受付やクレーム処理を効率化します。Xtract社が、事故の可視化と定量化ソリューション。イスラエルEndovitech社が、事故時の車両センサーのデータを元に、クラウド側でその乗員の方の傷害部位やレベルを推定して、医療機関に先に乗員の状況報告を送ります。保険会社は、事故受付や支払処理が非効率になっているので、ここの効率化、高機能化は、本当に大きなビジネスチャンスになると思います。

　仕組みとしては、データを売る、クラウド側のデジタル空間で行う処理のアルゴリズムを売る。あるいは、現実世界へ返す価値を売るということで、層別していけると思います。データを売ることだけに着目してしまいそうですが、現実的にはそうはいかないと思いますので、どこで商売できそうか、どう組み合わせたらいいのかを、よく考える必要があると思います。

　まとめとして、レイヤーで層別にすると一番上が、顧客が誰か、そこにどんな価値を提供するか、その下にマイクロサービス。マイクロサービスを組み合わせることで、サービスレイヤーにします。その下は技術レイヤーがあります。藤井教授とご一緒しているのは、シミュレーションによる先読み、あるいは全体最適、個別最適のバランシング、といったところがコア技術になると思います。その下層にデータレイヤー。本当はその下にデータを生む物理レイヤーがあります。

顧客の課題を定義しデータの活用や連携を考える

　大事なところは、保険やフリートのユースケースでもあったように、お客さまである保険会社やユーザーの課題は何か、何をしたらうれしいかを、先に考えるべきだと思っています。一方で、どんなデータがあるのかというデータドリブンの考え方も大事です。私のところではメンバーは少ないのですが、この両者の会話をさせることをチームの中では大事にしています。

　1社ではどうにもならないので、他のサービスと連携しないとサービスは実現できません。横の連携も非常に重要です。なぜ横の連携が大事なのかというと、それぞれ持っているデータは、誰のデータかということがあると思います。どの会社が取っているデータなのか、その中にある個人データは簡単にデータ連係基盤につなぐことはできません。例えば、駐車場データを取りたいと思っても簡単には取れません。何か価値につなげましょう、そのために何をすべきかと駐車場の管理会社を説得するところからやっていかないとできないと思いますし、難しいところです。

　図４は、藤井教授、森村教授とご一緒している「Be Kobe Fun！」です。ユーザーに対してアプリを提供し、店舗に対してマーケティングダッシュボードを提供しています。ユーザーが移動するとポイントがたまって、それをクーポンに変えるといったことが基本的な流れですが、その裏で店舗が自店の事情に合わせて、クーポンや情報を配信することもできるようなソリューションを考え、作りました。

　半年間にわたり実証実験をしました。2024年3月末で一旦終わり延長する予定です（後に9月末まで延伸）。アプリのダウンロードが約5,000人まで達して、協力店舗も増えてきています。データが集まりいろいろな断面で分析できるようになってきました。われわれは回遊創出、消費創出にチャレンジしていますが、移動の回遊量は1km以上が64％、2時間以上滞在が59％増え非常に伸びました。一方で消費に結び付ける、つまり実際に店舗でクーポンを使って消費していただく流れでは、情報閲覧も少ないですし、行動変容のクーポン獲得が非常に少ない。ここに対しては、UX（User eXperience）の力もありますし、人に刺さる仕掛けが何か必要だと思います。リコメンドエンジンの技術をよりよいものにしていきたいと思います。データ分析することで、どこに課題があるのかが見えてくると思います。行動変容意向率も見ていますが、いろいろ手を打つと上がってくるので楽しいです。引き続き、いろいろトライしていこうと思います。

　可視化の話も、一目で効果を見せるのは非常に大事だと思います。図5は、滞留などを見ています。われわれが積極的にクーポンを配信しているハーバーランドやメリケンパーク、東遊園地は色が濃くなっていて、回遊効果が見られます。逆に北野の辺りは全くクーポンを出していないので、あまり見られないといったことも分かります。

「誰に」「どのような価値を生む」のかを考えてデータを整備する

　私の目指す姿としては、車両データも強みになりますし、今、「Be Kobe Fun！」で集めている人のデータや世の中にあるデータをミックスして、社会の時間、エネルギーの無駄を最小限化していきたい。ウェルビーイングで安心なまちづくりに貢献していきたいと思っています。

　ポイントとしては、個々のデータによって個人に良い影響がある。面白いのは、個々のデータが集まることで、社会的な価値を生む。あるいは社会をより良い方向に変えることができると思っています。例えば、事故未然防止、混雑緩和、カーボンニュートラル、店舗のDX、あるいは神戸での地元資産を活かした地域再開発など。「Be Kobe Fun！」もそうですが、私自身、神戸にずっと住んでいますが行ったことのないエリアがあるので、地元に根付いているお店などを積極的に周知して経済を再起動したい、そういったことができるのではないかと思っています。

　もう1つ、データを使う側です。「On Demand Date Collection」でもありましたが、使い勝手が悪いと使われないので、軽く検索できて必要なデータを取ることができる仕組みも大事だと思います。そして、課題は何か、誰に何をしたいかが、先にあるべきです。一方で、どういったデータがあるかも知っておくべきだと思います。層別して、縦と横との対話だとか、横の共創が非常に大事だと思います。事業創造の仮説も作れると思います。しかし、経営するということでビジネスのスケール感の検証は大切です。実物でPoC （Proof of Concept：概念実証）をしてみることが大事だと思います。

講演3のディスカッション

森村　田中さん、ありがとうございました。Q＆Aに進みたいと思います。チャットに「データの収集においては各社で計測項目や計測形式を設定されると思います。ただ、プラットフォーム上での有償無償での一般利用を考えると、各社のデータ項目や形式はそろえることになると思いますが、データの国際標準は定められているのでしょうか」という質問です。

田中　国際標準はないです。先ほど紹介したOtonomoは、「このように出してください」と既定していますので、それは標準化できていると思います。ただ、本当に自社グループだけでやりたいときには囲います。自社でデータの構造を決めて、サプライヤー間では合わせますが、そこが大きな課題だと思います。

　API（Application Programming Interface）が公開されていて、いろいろなものを取ることができると思います。もう1つの動きでは、いろんなデータ提供事業者が集まって、何かデータ活用できないかを考えるコンソーシアムがあります。いろいろ見ながらチャレンジするしかないと思います。

　一方で、私がやっていることは小さく始めて、「いいね」となったら、仲間も集まってくると思います。そういうアプローチの方が早く進むのではないかと思います。

森村　新村先生、藤井先生のお話も、本当に取りたいデータはないので、取りにいこうという話をされていました。一方で、ある通信会社では、いろいろなデータを各社が持ち寄って、それを統合してデータの利用可能性を高めるためデータプラットフォームを整える動きがあるようですが、あまりうまくいっていないといわれています。うまくいくためには、どういうことが必要か何かアイデアをお持ちですか。

田中　誰に価値を提供しようとしているのか、「誰に」をしっかり捉えて、もので見せるところが大事なのではないかと思いますが、そこが難しいポイントなのでしょう。われわれは、日々トライ・アンド・エラーでやっていくしかないと思います。あるいは、学術識者の方にアドバイスをもらいながら、しっかりアーキテクトしてといったところも大事だと思います。

森村　なるほど。ありがとうございます。次の質問をお願いします。

質問者１　車両情報のデータは、個人的なデータにもなると思いますが、国によってその収集基準、法律など、例えばヨーロッパは厳しいと思います。そういう違いはあるのでしょうか。

田中　あります。やはりヨーロッパは厳しいです。そもそも個人データを取るなということが、ルール化されています。先ほどの質問にもありましたが、国際標準という意味でいくと、欧州だとルールを決めることもやっているので、そこはかなり難しいというか、集めにくいと思います。では、メルセデスやBMWは何もやっていないかというと、個人に対してきちんとオプトイン、オプトアウトという形で許諾を取得しているので、うまく集められていると思います。

　一方で、個人情報を含む情報は、車側でマスキングをしてしまう。先ほど、エッジ側のAIでナンバープレートをマスキングしたと言いました。もちろん一番センシティブなドライバーの生体情報系などは、個人を特定できない形にして収集するなども考えられているみたいです。生体情報系は、まだまだ難しいみたいです。

質問者1　分かりました。次の質問は、今回はデータ収集について一方向のお話が多かったと思います。収集したデータの双方向の利活用といえるような、例えば、あおりすぎているようだったらブレーキをかけるとか、通学する生徒が多ければ速度を30～40kmに落とすなど、止めるとか、ハンドル操作するような車を制御する方向にいく話は、もう少し将来の話になっていくのでしょうか。

田中　何度もその話は出てきます。ただ、制御に介入すると、車がどう動くか、その周りのシチュエーションを全部理解した上で制御しないといけないので、かなり難しいみたいです。当然、車両メーカーでも考えられていると思いますが、制御介入はなかなか難しい。一方で、盗難防止系は進んでいます。盗難車と分かれば、徐々にスローダウンさせることも可能ですし、何かの機能を無効化するなどされています。

　１対１の話になりますが、ドライバーの調子が悪いときにセンターにつなぐと、その車の制御に介入して、徐々にスピードを落として、路肩に停車するようなことです。これも考えられているだけで、今はスピードダウンぐらいまでしかできていないと思います。

質問者１　分かりました。ありがとうございます。バスで運転が少しおかしかったら、徐々に止まるとか、商用だったら確かにありそうだと思いました。

森村　「On Demand Date Collection」について質問があります。ユーザーが「こういうことをしたいから、こういうデータが欲しいです」と指示を出されるようですが、ユーザーが指示できるようになるまでに、何か苦労はなかったですか。

田中　こういった車両開発や地図更新をされている方に、どういうことだったら使ってもらえますかと意見を聞きました。簡単なダッシュボードがあって、UI（User Interface）も簡単になっていて、この期間でこういうイベントがあったら、その前後5分ぐらいの映像データが欲しいといった指示が可能なダッシュボードもセットで作ってほしいというのがありましたので、追加で開発し使ってみてもらいました。

　新たな価値につながるまでにはなっていなくて、車の中のデータを自動車販売店が使うといった、狭いところでしか活用が進んでいないというのが課題だと思います。

森村　なるほど。ありがとうございます。次の質問お願いします。

質問者2　「Be Kobe Fun！」の事業について、人流やお店のデータを取り始めて、見えてきたことがあったり、お店側がターゲットを絞ってクーポンを出せたりするのは、すごく面白いと感じました。神戸市は、人の流れもある程度あるし、店もいろいろあると思いますが、日本全体で考えたとき、人がまばらなところが圧倒的に多いと思います。全国規模で考えたときに、そういった市町村でも、同じようにデータから地域振興を考えていくことは可能なのか何かアイデアはございますか。

田中　われわれも別部隊で地域や地方をフォーカスしています。位置情報や行動情報を得るためのアプリの提供が一番の課題になります。それができたとして、それを元に今、移動の効率化に関わるところをやろうとしています。今、地方では路線バスの廃止などの問題があります。それでも移動しなければいけない学生や高齢者の方がいらっしゃいます。そこをしっかりとケアしたい。それで、人の移動データを分析しながら、オンデマンドをどのようにするか。軸になるルートを作るとか、どれぐらいの規模のバスをオンデマンドで回せばいいかとか、交通計画に活かしています。

　行動変容について藤井先生も触れられました。例えば10時半にお医者さんに行く人と、11時に買い物に行く人がいたら、買い物を少し前の時間にずらしてもらえば相乗りができて、効率化につながります。オンデマンド運行側の効率化にもつながるので、そういう行動変容をしていただいて地域としてよりよい移動社会、快適な移動社会ができるようなアプローチをしています。移動社会にしか、われわれはまだフォーカスできていないので、このような回答になります。

　もともとのデータを取るところが難しいので、まだ車で移動されている高齢者の方が車に乗っているうちにドライブレコーダーのデータを取って、その人の行動データを分析して、「オンデマンドバスがあるから、安心して免許返納してね」というような社会ができたらいいと思います。

講演4　カスタマーサクセス部門におけるデータ活用について

 

 

筧　卓士氏
（日本マイクロソフト株式会社カスタマーサクセス事業本部　コーポレートデリバリー第一本部　シニアカスタマーサクセスアカウントマネージャー）

利用可能なデータを手がかりに顧客の文脈特定的な問題を理解する

　私は、日本マイクロソフトでカスタマーサクセス事業を担当しています。カスタマーサクセスでどういったことをしているのか紹介します。その後に、実際にどんなデータを活用して、どうやってお客さまに提案活動をしているのか、その中で出てきている課題を含めてお伝えできればと思います。

　私は、現職でマイクロソフトのカスタマーサクセス事業部に所属しています。前職のアカマエテクノロジーでも同じような仕事をしていました。カスタマーサクセスとして7年ほど従事しています。さらに前がオラクルとかSAPで、テクニカルサポートとして、データベースのサポートエンジニアをやっていました。技術領域としてはデータベースやデータウェアハウス、ミドルウェア製品などを担当していました。

　カスタマーサクセスアカウントマネージャーは、社内では略して「CSAM（Customer Success Account Manager）」と呼ばれています。業務はポストセールスに責任を持って、お客さまのビジネスやIT目標を理解した上で、リレーションシップを構築して、さらに価値を実現するためにサポートします。営業は、新しい製品なり機能を紹介していきます。そういったところと連携しながら、お客さまのDXを成功に結びつける取り組みとして、技術的なブロッカーがあれば、そのブロッカーを解除する支援を提案するなどの業務をしています。

　具体的には、まず、お客さまに弊社の製品を購入いただきます。Office製品を導入したり、クラウドのAzure上に何らかのアプリケーションを開発・運用したりすると、通常は製品に対してトラブルや不明点を、弊社のサポートセンター宛てにお問い合わせいただきます。企業様では、従業員から寄せられる様々なトラブルを、IT部門の方がとりまとめて問い合わせをされることがあります。そこに対して有償のサポートサービスとして、企業向けのサービスを営業が提案し、有償サポート契約を結んでいただくと、CSAMが企業様向けにアサインされて、お客さまの導入窓口としてサポートします。

　役割は、大きく2点あります。1つはサポート部門のフォロー支援で、通常お客さまからいろんな問い合わせをいただきます。Officeも今はクラウドで運用されていて、例えば弊社側のデータセンターでメールがうまく送信されないとか、あるいはTeamsでうまく会議ができないとか、そういった問い合わせをサポート側で受けます。問い合わせの内容で、お客さまのビジネスに影響を及ぼすようなインシデントがあれば、私は窓口担当としてお客さまに今どういう状況で障害が対処されているのかを報告し、お客さまのフォローアップをしながら温度感を鎮める調整役をしています。

　基本的にお客さまのフラストレーションがなければ、私がプロアクティブに出て行くことはありません。導入・展開支援がどちらかというと私のメインの仕事になります。ポストセールスという営業的な考え方もありますが、最終的なゴールは「カスタマーサクセス」、つまり、お客さまとの関係を構築して満足度を上げることです。例えばOfficeを購入いただいたお客さまが、100個の機能があって、そのうち10個の機能しか使っていなければ、残りの90個の機能を使ってどうやって生産性を上げていくか、というところを含めて提案します。ちなみに、90個の機能を使うことはあくまでも手段です。

　提案していく中で、われわれの製品に知見があるお客さまもいらっしゃれば、そうでない方もいらっしゃいます。サポート支援の中でエンジニアをアサインして、お客さまの不安や課題、例えば、お客さまのやりたいことを、お客さまのIT計画に沿って実現することによって、満足度を上げていくというところが主な役割となっています。

　この導入・展開支援は、例えば、2025年までにDXをここまで推進したいというお客さまのIT計画があれば、その計画段階で弊社の営業がListen＆Consultというフェーズとして入ります。お客さまがDXの中でどんなことを実現したいのか、というヒアリングフェーズから入っていく中で、お客さまのIT担当者が出てこられて、具体的に技術的な話をします。どのようなソリューションが適切かをある程度見極めた後、POC（Proof of Concep）のような実施検証を含めて、今度は製品担当営業や技術営業の方にバトンタッチをして、お客さまとゴールに向けて検証を含めて進んでいきます。そこで最終的にお客さまが新しい製品を購入する決断を下されて運用開始になるときに、どうやってお客さまの本番環境に展開していくのか、そういったところの運用課題や技術的なボトルネックをヒアリングします。お客さまにとっての課題解決のためのバリューなどを確認していきます。その中で、われわれが各製品のエンジニアに、「お客さまがこういうことをやりたいからこういう支援をしてほしい」というリクエストをします。こういったプロアクティブ支援を、ユニファイドサポートというサポート契約の中で提供しています。

　この導入・展開支援をどんな形でどういうタイミングで提案しているのかを、データの有効活用と課題を交えてお話しします。お客さまから様々なお問い合わせをいただきます。例えば、図１は、あるお客さまの1年間のお問い合わせデータです。製品ごとに、何件ぐらい年間に問い合わせが来ているか見ることができます。このケースでは、Exchange Onlineというメールソフトのサービスに問い合わせが一番多かった状況を示しております。お客さまの問い合わせ内容を確認すると技術不足によるスキルトランスファーが必要だということを確認しました。そこで、私はお客さまにExchange Onlineで困っていることはどういう課題か、定例会や打ち合わせの中でヒアリングしていきます。また、メールサーバーに関する新しいプロジェクトであった場合は、どういったところがお客さまにとってボトルネックになるのか、あるいは新しい機能を使いたいから勉強会をしてほしいなどを聞き取りしながら、導入・展開支援として、エンジニアと日程を調整してアサインする取り組みをします。

　また、問い合わせの月単位の件数を見るケースもあります。この場合は、2023年10月から急に件数が増えています。問い合わせは、A、B、Cと重要度が分けられて、Bはアージェントで、割と急ぎの問い合わせが多いことが分かります。急ぎの多いところは何かしらITプロジェクトが活発に動いているかもしれないというInsightが働くので、どういうプロジェクトが今動いているのかを含めて、お客さまに導入・展開支援を提案することもします。

　2つめのケースは、製品利用状況の視点からお客さまのデータを見ることもあります（図2）。上の段は、弊社のクラウド製品の中で、AIや分析のサービス、データベースなど様々な製品の利用状況を示しています。例えば、セキュリティ製品の利用状況が少し減っていることが確認できた場合、もしかするとわれわれの製品がお客さまの要望にマッチしなくて、他社に移行しているところもあるのではないかと考えて、どういったところがボトルネックなのかをヒアリングして、導入・展開支援を提案することもあります。

　図２の下の部分では、ある製品をどれぐらいのアクティブユーザーが使っているかを示す月間利用状況のグラフで、こういったデータも活用しています。

　一方で、お客さまの製品ライセンスをわれわれはデータとして持っています。例えばお客さまに1,000ユーザー分のライセンスを買ってもらっているにも関わらず、アクティブユーザーが100とか200で推移していて、あるタイミングでは1,000近くなるけれども、また200に戻るような状況が発生していると仮定します。本来われわれのゴールは1,000ユーザー分買ってもらっている以上は、1,000ユーザーに使っていただきたいという思いがあります。なぜ使えていないのかをヒアリングしながら、われわれが提案したユースケースがマッチしないのであれば、他のユースケースを探して、もう一度利用度を上げる（利活用の提案）といったこともCSAMの活動としてやっています。

サービス提供側のデータも顧客の価値創造に活かす

　お客さまのデータを分析するだけではなくて、CSAM自身の行動データも記録されています。これはあくまで組織全体にどれくらい負荷がかかっているかを確認するという点もありますが、最終的なゴールはお客さまに寄り添った活動をするためにCSAMとしてどういう行動をすべきかということで、分析のために従業員の行動データが取られています。

　例えば、図3は、CSAMのAさんの1週間の行動で、AさんはA社、B社、C社を担当していて、A社には導入や展開に20時間使い、B社は2時間、C社は5時間。A社に関しては問い合わせのフォロー支援なども10時間費やしていました、ということがデータに取られています。これは、CSAMが従業員の勤怠管理システムに、どういう活動をどれぐらいしたかを1週間単位で入れています。そのデータをもとに、可視化できるようになっています。

　このようなデータを見て、会社や組織の視点からInsightするときに、ＡさんがA社に対する負荷が高い。AさんとA社が何かしら問題を抱えているかもしれない。あるいはB社の稼働が低いけれど、お客さまの満足度に貢献できているのか、というInsightが働くと思います。また、1週間の中で会議時間が約10時間あるので、社内会議が多すぎてお客さま対応の時間が十分確保できていないと考えられます。

　この結果を含めて組織側としては、バックアップ体制を入れるべきかどうかという判断にもつながりますし、不要な会議を削減するにはどうすればいいのかという検討にも入ると思います。またこの例は、1週間の稼働時間が58時間というサンプルになります。本来は週40時間が適切な働き方だと思います。負荷状況を考えて採用枠を1人設けるかどうかの検討にも働くと思います。

　ただ、このデータ分析には難しい点があります。このデータは各CSAMが手入力するデータであるため、本当に正確なデータかどうか判断できません。基本的に社員全員が正しいデータを入れている前提になりますが、恣意的データになり得る可能性もあります。なぜなら、そもそもCSAMの担当各社の稼働時間は、そのサポート契約によって決められます。例えば、A社は年間100時間、B社は300時間使ってくださいなど、サポート契約の中でCSAMが動ける時間は決められています。会社からは、契約書に書かれた時間を有効活用しているかどうかを見られます。例えば、稼働時間が余っていると、契約終了間際になって急に労働時間が増えるなど、データが一部恣意的な形で動いてしまうこともあります。この辺りは課題だと思います。

　経営側は、このようなデータを鑑みながら採用枠を決めることもあります。このケースから手入力のデータは、信頼性や前提条件によって影響されるところがあると言えます。

　図4も従業員の行動データです。これはＡ社への活動データで、A社へのサポート契約期間に対して業務がどの程度進んでいるのか進捗状況をあらわしています。例えば、サポート契約期間が82％まで進捗している中で、稼働時間が年間110時間に対して10時間しか使われていません。通常では導入・展開支援はサポートサービスを契約する際に、どういった支援をするかお客さまとあらかじめ決めます。このケースでは、決めた支援数が9つで、そのうち5つのプロアクティブ支援しか達成されていない状況です。こういったデータも、従業員各自が活動状況をセルフチェックします。チェックした上で、このお客さまへの対応ができていないと判断すると、A社に対してIT計画を再度ヒアリングします。もともと想定していた導入・展開支援が、お客さまのIT計画見直しや経営状況などによって変わった場合は、その代替案を急いで提案する必要があります。あるいはサポート契約期間が終わりに近づいていたら、次年度に向けた契約更新に着手しなければいけません。

　これはCSAM自身のロールとして、担当のお客さまのサポート契約を更新するのも1つのKPIになっています。かつ、どれぐらいの導入・展開支援を提案できたかというのもKPIなので、急務になります。行動データを自身でチェックしながら、自分のアクションを鑑みるところで使っています。

役割ごとに保有するデータの質が違うことを理解し連携する

　図5は、データの活用が難しいポイントだと思っています。CSAMのセールス・ロールが、昨年から1つ変わりました。今までの技術営業とCSAMの連携は、お客さまに対しては営業、技術営業とCSAMが、情報共有から始まって導入まで進んでいく中で、営業から技術営業、技術営業がCSAMという形で役割が明確に分かれていました。例えば、技術営業がお客さまからあるAzureクラウドの移行の話を伺ったところで、CRMの案件登録をして、移行のプロジェクトの可能性が高まったということで、案件のステータスをコミットにしていきます。そうすると技術営業が、私に「サポート契約の中で何か支援できませんか」という相談に来て、支援ができそうであれば、CSAと呼ばれるエンジニアをアサインして案件をクローズします。つまりCSAMは、あくまでサブ的な位置づけで活動していました。

　今は技術営業とセールスエコシステムという形で連携します。オーナーシップも変わる動きになって、技術営業がプロジェクトの可能性が高まると、案件制度とコミットを変更し、営業のオポチュニティーのオーナーシップはCSAMに変わりました。CSAMが案件をドライブする立場で、自分たちが使えるリソースを検討しながら、CSAMが案件を完了させるまで担当する仕組みになっています。

　ポイントは、CRMに登録されているデータの精度や、あるいは今までは営業とCSAMという縦割りの組織で動いていましたが、連携の必要が出てきたということがあります。加えて、CSAMはお客さまに非常に寄り添っているので、1人当たり2、3社、多くても7、8社です。一方で営業は、多くて20～30社を担当するケースがあります。CRMにあるデータの精度も営業の優先度によって変わることもあり、CRM案件に入っている内容が薄かったり、誤ったりするケースがあります。

データを活用して組織を管理する

　お客さまとプロジェクトを進めていく中で、Internal workということで、営業と話す機会が増えてきました。本当はデータを使って自動的にプロセスを回していければいいんですが、コミュニケーションなどで稼働が増えてきました。まだまだデータを有効活用できていない、というのが正直なところです。

　こういった状況を受けて、データ活用における組織変革の必要性をお話しします。従業員の行動データは手入力していると話しましたが、手入力ではないもので可視化できるソリューションを持っています。CSAMと共同作業者の関係を可視化するツールがあって、弊社製品であるTeamsで自分がどういう手段で、1週間にどれぐらいコミュニケーションを取っているかという情報です。個人的なデータになりますが、自分の連携している頻度が高い人が分かります。私の場合、お客さまや社員が関係者になります。私たちが主に利用するコミュニケーションツールは、Teamsでチャットを使ったりメールを使ったり、Teamsの会議です。お客さまと何時間ぐらい会議ややりとりをしたかなど、どんな手段でコミュニケーションをとっているのかをおおよそ可視化することができます。例えば、頻度が最も高いのが社員である場合、お客さまに寄り添った行動ができていないと振り返ることができます。

　このツールは、組織のトップやマネジメント層だと、部署全体でどうなっているのかを見ることができるので、ここは部署全体から見ても、お客さまと寄り添う時間が少なくなっていると分かれば、組織を変えていかなければいけない、という働きが出てきます。

　組織変革の必要性では、図6の左側が、CSAMのロールで、いろんな作業があります。フォローアップ支援以外にもサポート契約の更新や行動データを取るなど、いろんなことをやっていて、様々なツールやデータを使用しています。右側の行動データやコミュニケーションデータを見ると、お客さまと十分に接することができていないという課題がありました。

　当社の解決としては、本来CSAMは、お客さまに寄り添うことが一番メインになるので新しい部門を立ち上げました。もともとカスタマーサクセスが各国単位でしたが、支援センターをリージョン単位に持ち、カスタマーサクセスの定型業務の一部（オフロードできるところ）をその支援センターが代行するというものです。そして、CSAMはよりお客さまに向けた行動を優先してやっていきます。これもデータ活用によって組織を変えて、よりわれわれのゴールに進んでいく取り組みと言えます。

　私は今、大学でストラテジーの授業を学んでいます。当社マイクロソフトがすごく動きが早いと思うところは、組織がより多くのことを実現するための戦略的な組織変革への着手です。こういった変革を起こすために、社内データも常に有効活用されていると思います。

　技術的な課題もまだ残っています。CSAMがやるべきこととCSAMの行動データは分かっていて、ゴールはお客さまの価値を最大化するための提案活動をして、サポート契約を拡大していくことです。しかし、われわれがどういう行動をすれば、どのようなゴールが生まれるのかが、まだデータ化されていない。ここは成功体験を共有しながら地道な活動をやっています。この中で私自身は今、データの活用の限界を感じています。

　今は生成AIが出てきて、よりInsightできるようになったと思います。こういった課題において、データ活用における今後の展望ですが、これはあくまで私の願望です。今、お客さまのデータはすでに十分ある状態です。CSAMの行動データとともにトラッキングされて取れている状態で、あとは成功事例です。これはお客さまに、いつ、どんなタイミングで、どんな行動をとったことで成功に導いたのか、というところです。これらをデータ化することができて、一方でその外部データとしてお客さまの中期計画や組織変更、IT事例のニュースなどを取り込めば、われわれは、よりお客さまに寄り添った行動ができるのではないかと考えています。

　データを活用する組織になるために理解すべき点は、データの質と信頼性です。このデータを有効活用するには、データそのものに高い質と信頼性が求められるということが非常に重要な点です。データがあれば何でも正として捉えるのではなくて、本当に高い信頼性があるのかを認識する必要があることもポイントになります。お客さまに対してコンサルティングを行っているところは、お客さまのデータを分析しがちですが、自分たちの行動データを活用とか分析することが、組織のあり方などを考える上で非常に重要になると感じました。

講演4のディスカッション

森村　ありがとうございます。チャットに2つ質問があります。１つ目は「CSAM部署が顧客利用データを分析するためにInsightを実施する頻度は定期的あるいは都度のいずれになるでしょうか」、2つ目は「顧客に対するCSAM時間の消費率が適正であると判断する根拠はどういったものがあるのでしょうか。例えば、契約期間の消化時間との比較とか、それ以外に何かあるのでしょうか」です。

筧　まず、データ分析の頻度については、定例会を月1回しているので、絶えず分析しているのが正直なところです。特に契約更新していただく際には、終了の約半年前から他のお客さまのIT計画も並行しながらやるので、データは常に見ています。

　2つ目は、CSAMの消費率は適正だと判断される根拠は、この比較以外にあるかというと、今のところはここ以外にはないので、あくまでCSAMが適正な時間をつけることを前提に、ボードメンバーは組織のあり方を考えていると思います。

　ただ、日本の契約は3月末決算が多く、サポート契約もそれに合わせて変わることが多いので、3月末にCSAMの消費時間が一時的に上がることを、組織のトップも理解した上で、組織の見直しやあり方を考えていると思います。

森村　ありがとうございます。私からの質問です。CSAMの役割としてヒアリングやヒアリング結果、もしくは定量的に得られているデータから、組織や従業員の特徴を理解されていると思いきや、これは相手のユーザー企業の文脈的な情報を、いかにひも解くかといったことをされていると思いました。これは誰でもできることではないと思いますが、CSAMに求められる資質や能力には、どういうものがあるでしょうか。

筧　私は、お客さまに多くを語ってもらえるようなコミュニケーションスキルの高さが求められると思います。もともとCSAMという言葉自体は2018年ごろに出てきて、それ以前は、テクニカル・アカウント・マネージャーという、テクニカルに精通した人がこの役割をしていました。今CSAM担当になる方は、技術的なスキルよりも営業出身者とか、お客さまから課題や思いを引き出すようなコミュニケーションができる人がキーマンだと思います。そういった方のほうが、お客さまが自発的に話すような環境をうまく作られるケースが多い、というのはあります。

森村　属人的な何かに依存しながらCSAMの成果が上がっていくと思う一方で、そのばらつきを何とか最小にしたいと思います。組織として、ばらつきをなくすようなCSAMのサポートはあるのでしょうか。

筧　サポートはありますが、実際に属人的になっているところはあります。どうしてもお客さまとは１対１でハンドリングして進めていくので、個人商店的な動きはあります。ただ、全体のバランスはマネジメントの方で、CSAMの稼働時間を見たり、社内でも上司との１on1でコミュニケーションをとったりしていますので、そこで課題などを把握します。属人的なところがあるので、どうしてもお客さまとうまく合わないケースは当然あります。そういった場合は、配置転換をしたり、担当を替えたりしながらやっています。マネージャーは各CSAMがどういうキャラクターかを見ていて、それをもとにアサインを決めていると感じています。

森村　なるほど、ありがとうございます。

質問者3　技術営業とCSAMで役割分担しているところがあると思います。技術営業がCSAMの能力を持っていたら、もっと何かいい感じに回るような気もしました。分けている理由があると思いますので、その辺を教えていただけたらうれしいです。

筧　技術営業は、製品導入前のフェーズで頑張っていただく。CSAMは、ポストセールスなので、あくまで導入が確定した後にそこをアップセル、クロスセルするプロセスの役割です。CSAMがテクニカルなスキルを持っているとすれば、導入前の技術営業が今回申し上げた技術営業。導入後の技術営業がCSAMという捉え方もできるかなと思います。

　ただ、今はどちらかというとCSAMは、技術営業ではありますが、その技術営業のテクニカルスキルが必要かというと、そこまではなくて、そこはCSAと呼ばれるデリバリーをしているところに、裏でサポートしてもらっています。そういったリソースを使いながら営業活動しているのが正直なところです。

質問者3　ありがとうございます。アカウント営業がさらにいて、プロダクト営業もこの他にもいるように思いました。御社ぐらい大きかったらできると思いますが、小さい会社だったら難しいと思いつつ聞いていました。

筧　そうですね。ありがとうございました。

森村　優秀なCSAMがいて、そういう方が抜けると、ビジネスとしては打撃を受けると思います。CSAMの知識や能力を継承できるような形にしておく動きはあるのでしょうか。

筧　抜ける場合は、当然引き継ぎ作業をやらなければいけないんですが、そこはまだ社内でプロセス化されていなくて属人的になっています。しっかり引き継ぎをするケースもあれば、資料1枚で終わるケースもあります。そこは切り替わった後に、できるだけサービスレベルを落とさないように、マネージャーと連携しながら一緒に走っていく感じです。もし、お客さまの評価が低かったり、フィードバックが返ってきたりした場合は、バックアップ体制をしいて、当面は2人体制でお客さま対応をするなど社内リソースを調整しながら、できるだけサービスレベルを落とさないようにする組織体制は整っていると思います。

森村　最後におっしゃっていたAIの活用は、そこのばらつきをなくそうという動きの一環なんでしょうか。

筧　 AIは、ばらつきをなくすということよりも、お客さまの成功をいかに最大化できるかというところで、活用できればいいと思います。

森村　今回はデータとは何か、データを集めるとは何か、データからビジネスを作るのは何か、というお話を4名の登壇者にそれぞれケースを交えお話しいただきました。貴重なお話をありがとうございました。ご参加いただいた皆さまの学びとなっていましたら幸いです。ご参加いただいた皆さまもありがとうございました。