プロフィール

株式会社バンダイナムコネクサス
CDAO / IPビジネスエンハンス部 IPクロステックオフィス オフィス長
西田 幸平（にしだ・こうへい）氏

株式会社バンダイナムコネクサス
IPビジネスエンハンス部 IPクロステックオフィス
山田 元太（やまだ・げんた）氏

株式会社バンダイナムコネクサス
IPビジネスエンハンス部 IPクロステックオフィス
釼持 立樹（けんもつ・たつき）氏

データ人材が豊富に在籍　グループ横断のデータ活用推進も

最初に、CDAO / IPビジネスエンハンス部 IPクロステックオフィス オフィス長の西田氏から、同社の会社概要が説明された。

西田：4つのユニットと関連事業会社に分かれています。バンダイナムコネクサスはデジタルユニットの会社なので、「ゲームの分析しかやらないのでは」と思われる方もいるかもしれませんが、弊社は各グループ会社と個別に連携してデータ活用を推進しておりますのとグループ横断でデータ活用を推進する「データユニバース」という取り組みにも携わっており、決してゲームばかりではありません。

西田：我々が所属するIPビジネスエンハンス部のIPクロステックオフィスは、IPにまつわる分析や事業横断の分析をすることが多い部門です。

我々は、組織全体として多様なデータ人材を抱えています。そして組織をデザインしているメンバーもデータ人材ですので、常にロールやキャリアパスをアップデートしています。色々な職種がありますが、ここまで細かいのはなかなか珍しいのではないでしょうか。それぞれの得意を生かせるし、伸ばせる。そして何かあったときに人に頼れる組織になっています。

データ分析と意思決定をつなぐために

つづいて、IPビジネスエンハンス部 IPクロステックオフィスの山田氏から「データ分析と意思決定をつなぐための思考法　『データ屋』が当事者になるために」というタイトルで講演があった。

具体例①：マーケティング施策の影響を分析する「MMM」が一時停止

山田：具体的なプロジェクトを紹介します。

まずは、「MMM（マーケティング・ミックス・モデリング）」という分析手法を実装するプロジェクトです。MMMとは、各マーケティング施策が目的KPIにどの程度影響したかを推定する分析手法です。とくにバンダイナムコエンターテインメントでは、モバイルのアプリが長く運営されており、周年などに大規模なキャンペーン施策を打つことがあります。そこの広告効果をいかに正確に測るか、次の施策にどう活用していくかを目的にMMMを実装しました。

この分析がどんな問いに答えられるかというと、ある商材の売上やインストール数などのKPIをどれだけ伸ばすか、それぞれの広告媒体にどの程度予算を振ればいいかが分かります。

ほかにも、たとえばイベントや劇場版の公開など、広告の効果を後押しする施策があるなかで、それらを差し引いて、プロモーションそのものにどれだけ効果があるかを判定するために使ったり、広告媒体と予算を変えると、どれだけパフォーマンスが変化するかを推定したりもできます。

バンダイナムコグループとしては、IPビジネスに対応した分析が必要でした。また、直接インストールを促すための媒体とテレビCMなど認知拡大を目的とした媒体を同時に評価することが難しかったため、この分析手法を開発しました。

山田：しかし、このプロジェクトは今一時停止しています......。データ分析は通常、目的設定→データ収集・検品→モデリング・推定→レポーティング→意思決定の流れで進みますが、今回は最終的な意思決定につながらなかったためです。

なぜこうなってしまったのか自分なりに振り返った結果、分析前の段階である「データ収集・検品」のステップに根本的な課題があったのではないかと反省しています。

山田：私たちのMMMには、①広告出稿のデータ、②ゲーム内のイベントデータ、③ゲーム外のイベントデータという大きく3つのデータが必要でした。そのなかで、広告出稿とゲーム内のイベントデータまでは収集の自動化ができているものの、ゲーム外のイベントデータだけがなかなか集まらなかったんです。なぜかというと、ゲーム外のイベントデータは、各プロモーション担当者による手動入力が必要で、業務負荷が非常に高かったためです。そのうえ、タイトルや部署ごとに管理方法がバラバラで、機械的に進めるのが難しかった背景もありました。

ただ、最大の要因は、現場の人にとって余計な仕事が増やされている感覚になったことだと思います。現場の最優先は「キャンペーンを最大限盛り上げること」なのに、データ分析屋が突然やってきて、「分析したいからデータをください」と言う。しかもそれが自分たちの目標に直結しない分析となると、どれだけ優秀で熱量のある担当者でも腰が動きません。結果的に、MMM分析が非常にコストの高い取り組みになってしまい、それが一時停止につながったと考えています。

具体例②：デジタルセール分析で「仕事が楽に」

山田：その反省を生かしたプロジェクトが、セール関連の企画を支援するプロダクト作成と分析モデルの作成です。

家庭用ゲームは、定価から割り引かれた価格で販売されていることがあります。そこでの割引率やどのタイトルをセールに乗せるかを決定することは、売上を伸ばすうえで重要な施策です。一方で、担当者の習熟度やセンスによる部分が大きく、一律の基準で評価できない課題がありました。また、データ収集の工数負荷も大きいという課題もありました。

そこで、まず、セールにおいての売上を最大化する割引率の決定と、効率的な振り返りを支援するツールを作りました。現在トライアル運用中で、実際の業務に落とし込むにはどうすべきか、もっと欲しい機能はないかなど、協力して進められていると思っています。

山田：業務効率化系のプロダクトも作りました。今までセール業務のときはExcelを使っていましたが、Googleスプレッドシートに置き換えることで、データ入力から集計作業を可能な限り自動化し、入力補助できるようになりました。たとえば、割引率を入力すると、もともとの定価から価格や粗利が計算され、前回の割引率や売上などが分かるようになります。

また、セールごとに売上予測と実績を振り返るダッシュボードも作りました。これらは日々、担当部署の方にも使っていただいているので、大変嬉しいです。

山田：分析モデルのアーキテクチャはシンプルですが、担当者が普段通り業務をこなしているだけで、分析に必要なデータが集まる状態ができました。これによって、データ分析をしている人が突然担当者に対して「こんなプロダクトどうですか？」と提案する状態に。それが冒頭のMMMのプロジェクトと違うところです。

ここで「ツールのおかげで仕事が楽になった、相談相手にしていいだろう」と思ってくれたと僕は信じています。色々相談してもらえる関係が築けて、同じ業務の当事者になれたのではないか、と感じています。

話をまとめると、事業側は「データ分析がしたい」わけではないということです。言葉にすると当たり前に聞こえますが、データ分析を主業務とする私たちは往々にして忘れがちです。どんなに優れた分析手法を開発しても、「これで売上が上がる」「作業時間が削減できる」といった具体的なメリットがしっかり伝わらない限り、事業側になかなか活用してもらえません。

そして、当事者意識を持つことは簡単な一方、当事者だと認められるのは難しいということ。MMMのときも自分なりには本気でやっていましたが、結局僕の独りよがりで、意思決定の主体に「彼は、同じ業務をより良くする仲間なんだ」と思ってもらえていないうちは、活用されないのが当たり前です。最終的に意思決定に変える土俵に立つことを大事にした方がいいと思います。

PoCが事業に広がるまで

つづいて、IPビジネスエンハンス部 IPクロステックオフィスの釼持氏から「現場ヒアリングから、全社ツールへ　PoCが事業に広がるまで」というタイトルで講演があった。

ヒアリング問題、PoC問題、技術的問題の“乗り越え方”

釼持：私はクリエイティブチェックツールの実装、構築、ビジネス反映に携わっています。クリエイティブチェックツールとは、日々制作される広告のクリエイティブや商材パッケージに対して、たとえば、キャラクターの素材がきちんと使われているか、意図しない修正が加えられていないか、権利表記を間違えていないかなどをチェックするツールです。

今回のチェックツールの始まりは、データを活用した広告運用を改善できないか、というヒアリングがきっかけです。私たちは、グループ会社のデータの課題を解決する役割があるので、グループ会社からさまざまな相談をいただきます。ただ、これに関してはもともとグループ会社が持っていた課題が出発点ではないので、本当に構築すべきツールなのか、今後各グループ会社に展開性があるのかなどは、全く不透明な状態からのスタートでした。現状、一部のグループ会社では全社ツールとして展開予定で、技術を活用して事業部の商材に特化したチェックツールも構築・展開する予定です。

釼持：このクリエイティブチェックツールの取り組みを進めるうえで、苦労した点やつまずいた点を3つお話しします。

1つ目が、ヒアリング問題。ヒアリングしても、課題が曖昧で、課題を解決しても現場の業務が改善するかわからないといったケースです。

2つ目が、PoC（Proof of Concept：概念実証）問題。作った後にイメージと違ったと言われたり、PoCが本開発につながらなかったり、PoCで想定した精度が出ず、精度を追い求めてPoC自体が終わらなかったりする課題シーンです。

3つ目が、技術的問題。最近多いと思うのですが、生成AI活用が目的になって、実際やってみたら精度が想定通りでなく、「思ったものと違う」と言われたり、想定したユーザーが求める基準とアウトプットのレベルが合っていなかったりする場合です。

釼持：それぞれの問題に対して、私が実践して要因を考えてみた結果、「これかな」と思う突破方法をお話しします。

釼持：まずは、ヒアリング問題。一発のヒアリングで正しい課題が出てこないのは大前提として、私はヒアリングを何回も重ねて、業務全体を理解し、具体的な課題シーンの共通認識を持つことをゴールにしました。

具体的には、ざっくり業務の流れを把握します。とくに誰が担当するかを意識してヒアリングし、業務全体を整理します。全体像を整理しながら、シーンを意識し、各業務を深掘りして、いつ、どこで、どのように困っているかを明確にします。

そして業務フロー全体を整理したうえで課題の仮説を立て、改めて現場にヒアリングして仮説が正しいかを確認する。この手順を徹底すれば、ヒアリングの精度が向上したイメージです。

具体的には、現場の業務を「ユーザーのシーンレベル」まで細かく分解し、どの場面で何がボトルネックになっているかを図で可視化して、現場の人と認識を合わせることを重視しています。

たとえば、広告運用の改善でヒアリングした際、最初は「PDCAが回っていない」という曖昧な課題しか出てきませんでした。しかし業務を詳細に分析すると、「クリエイティブのチェックに時間がかかりすぎて、そもそもPDCAを回す時間がない」という具体的な課題が浮き彫りになりました。これが、現在のクリエイティブチェックツール開発のきっかけとなっています。

釼持：つづいてPoC問題。PoCは技術検証というイメージが強く、実際に技術検証のフェーズだと思いますが、意思決定の観点で、期待値を合わせるのをゴールとして設定することを強く意識すると、うまくいくことが多かったです。期待値をベースに、PoCの定義（＝目的）と評価軸の認識を、意思決定者・利用者ですり合わせます。

チェックツールでは、まず利用者の期待値を整理していきました。最終的なゴールは、工数削減やインシデント防止という目的のなか、利用者の期待値と我々開発側の期待値にずれが起きないように、事前にPoCの定義と目的を定めました。ここのコミュニケーションを丁寧にすることが重要で、ここを疎かにすると、失敗することが多かったです。

実際にPoCを進めるうえでは、生成AIを使って簡単にアウトプットを詰めたり、構築する機能の優先度を決めたり、優先度の高いもののみでデモ画面を作って利用者の定性評価を集めたりしました。

結果、イメージ相違によるアウトプットの戻しがなくなりました。また、事前に利用者と期待値をそろえたため、精度に固執しない純粋なフィードバックが返ってくるようになり、PoC検証後のすり合わせと開発以降がスムーズに進みました。

釼持：最後に技術問題。技術手法を考えるうえで、どう作るかではなくて、どう使われるかというところに思考をシフトすることが重要だと思っています。たとえば、技術選定から入るのではなくて、現状や課題から逆算して技術を決めたり、全部のAI化を目指すのではなくて、ユーザー価値のインパクトが大きいものから優先して対応する工夫をしています。

チェックツールを構築するなかで起きた例をお話しすると、素材が正しく利用されているかをチェックする機能を作る際に、キャラクター認識モデルを構築して検知しようと考えていました。しかし、いざやってみると、実用レベルに耐えられるものではありませんでした。利用者側の意図や実際のシーンを自分の中でイメージできていないことが原因です。

正直に結果を利用者に説明・相談し、再度、ヒアリングや深掘りを行うと、このチェック作業は厳密さがポイントであることがわかりました。そこで、実際に利用者側で行っている確認方法をルールベースで自動化して実装したところ、その方が利用者の実用レベルにも合って、より利用者に使ってもらえるような機能になりました。

“正しいコンフリクト”をうまく協働できるようなチームに

最後に、再び西田氏がまとめと役割分担について発表した。

西田：技術力の高いデータサイエンティストやエンジニアと協働して進めていても、問題は出てきてしまいます。とくに難しいのは、純粋な技術的問題ではなく、「技術はできたけど事業で活用されない」といった境界領域の問題です。この問題は、誰がどのように解決すべきかが曖昧になりがちです。

西田：それぞれが与えられたロールにおいて中心に据えるべき責任があり、究極、「誰も間違えていないけど、うまくいかない」というケースがあると思います。

たとえば、事業側は「大体でいいので、意思決定の参考数値が欲しい」、でも分析側は「大体という精度では出したくない」と考える。分析側が「5％の精度を上げるために必死になる」のに対し、事業側は「5％の精度を出すために、結果が来年になるのならやらなくていい」と主張します。

理想的には1人の人材がこのバランス感覚を持てればよいのですが、1人で対立する価値観のバランスを保つのは非常に困難です。そのうえで、技術力もビジネス力も高い人材はかなり稀なのが現状です。

西田：そこで我々はプロジェクトの座組で解決しています。ロールごとの責任範囲をしっかり定め、チーム全体でカバーできるようなプロジェクトチームの組成を行っています。ただ、必ずしも統一的なロール分担できれいに100％かみ合うとは現時点では思っていません。結局、パーソナルな相性や思考性、スキルセットにもよるところがあり、タスク分担をきっちりやるより、各ロールのメインがどこかという点に主眼を置いています。

自分で何ができないか分かる、ほかの人が何をできるかが分かる。このように正しく認識する力がPMの大事な素養の1つだと思います。弊社のメンバーも、自分が何が得意で何ができていないかという認識は甘いところはあると思いますし、必ずしもこの分解が答えとは思っていませんが、プロジェクトを成功させるために必要な人やスキルをフェアに見積もって、プロジェクトメンバー全体でカバーするという思想であれば、体現方法は何でもいいと思います。

【Q&Aセッション】 

Q&Aセッションでは、株式会社バンダイナムコネクサスのデータ分析・PM担当者3名がイベント参加者から投げかけられた質問に回答した。

Q. 現場からフィードバックは取りに行くのか、活用度で察するのか 

山田：プロジェクトの質によりますが、業務効率化ツールなどはスプレッドシートなので誰が見ているかわかり、活用度を察することもあります。また弊社では満足度調査を定期的に実施して、実際にどのように思われているかを把握しています。 

西田：弊社ではこのようなことをチェックする取り組みが多く、現場の方々がどのように言っているか、利益貢献額をどのようにシミュレーションされているかなど、チェックする機会はかなり多くあります。

釼持：PoCのときも集めますし、リリース前にも再度フィードバックを収集することもあります。開発後はツールにログを仕込んで利用状況を把握し、該当者に直接聞きに行くこともしています。

Q. 部署には何名ぐらいいるか。プロジェクトを組むことが多いか、1人で進めることが多いか

西田：基本的にはプロジェクトを組んで進めることが多いです。ビジネスにしっかりと知見のあるPM、技術PM、データサイエンティストを含めて全体で4人程度が一般的ですね。プロダクト分析なら1人張り付きのパターンもあります。 

山田：私が触れた2つのプロジェクトでいうと、MMMプロジェクトではデータ収集に対してエンジニア1人と私、分析に対してはデータサイエンティストと私という、2人ずつの体制でした。基盤が成長してきたタイミングで3人体制、多くてもエンジニア4人体制でやっていました。

セールの分析に関していくと自分ともう1人のエンジニア。分析においてはデータサイエンティストが1人。1人月みたいな言い方になるかもしれないですが、そのくらいで進めていました。

釼持：チェックツールやアプリの構築をやっているところでいうと、大体人数は同じぐらいで、PM1人とエンジニア2〜3人ぐらいで、計3〜4人ぐらいでやっています。

Q. 学習データ、加工データについて、同じゲームの販売データがないのではないかと思うが、どのような学習データを使うのか 

山田：これはセールの割引率の話だと思います。ゲームの割引率を次回レコメンドするモデルに関しては、1回セールに乗ったプロダクトだけが対象になっています。過去少なくとも1回のセール状況、「何パーセント割引で、いくら売れた」、「ふだんの売り上げ」などのデータを使って、2回目、3回目以降にまたセールのラインアップに載るときに予測を出すということです。

おっしゃる通り、全く同じタイトルがない場合の予想がなかなか難しくて、登壇中にも触れましたが現在活用トライアル中です。分析モデルを拡張することで対応できないか、それで使えるかどうかを現場の人と頭を悩ませながら取り組んでいる現状です。

Q. 社内で顔を売るためにどのようなことしているか、信頼関係を築くためにしていることは 

山田：特別なことはしていませんが、とにかく仕事を通じて価値を提供しつづけていくしかないと思っています。現場の人が何に悩んでいるのか、どんなことができたら嬉しいのかを考えて、技術PMとして自分の得意な領域で貢献していくことが大切なのではないでしょうか。

一番大切なのは、ビジネスを動かす側の皆さんをリスペクトすることだと思います。私たちは、たまたまデータや分析モデルについて詳しいのですが、コンテンツを作ってユーザーに届けてくれる側の人材が持つ能力とは違う分野ですからね。

釼持：山田さんと同じように、特別なことをしている意識はありません。ただ、課題を持つ現場の人とは1対1で会議を設定して深く話を聞くことはしています。信頼関係構築というより、どちらかというと私自身が課題を聞きたいから取り組んでいることの1つです。

Q. ビジネス側がデータでの解決が難しいことを要求する場合、どのように期待調整をしているか 

西田：組織的な方針として「こうする」のようなものはないと思います。現在できる最善の方法で分析し、その結果と併せて懸念点も含めて報告するという基本的な対応を取っているくらいです。

山田：誠実に答えるしかなくて、我々の限界がこれだ、ということを率直に伝えます。それ以上の精度が必要なら、どのように取り組むか、どんなデータが必要なのかを真正面からお伝えするしかないと思っています。

西田：後は、事業側がフォローしてくれることが多いですね。

Q. リモートワークで現場の方と同じ目線になることが難しいのだが、そういった経験はあるか 

山田：ビジネスを進められている方とプロジェクト進行することが多いなかで、データ分析やプロダクト作成の役割を担うことになりますが、使ってもらわなければ意味がないし、利益貢献できなければ価値がありません。そういった意味で、相手のビジネスがどのような構造になっているかについて自分なりに仮説を持っておくことが大事だと思います。

もしそれが的外れだったとしても、形にしておけば訂正してもらえますし、会ったときに「何か考えてきてくれたんだな」という印象を持ってもらえると思います。

同じ目線になれたかどうかは、相手からちゃんとレスポンスが返ってくるかで判断していますね。ただ自分ができているとはいえないのも正直なところで、リモート・対面に関係なく、最初のすり合わせに苦労することは多いです。

西田：リモートよりは、対面の方が絶対に進みますもんね。同じ目線になったと感じるタイミングは、相手に対して報告したときというより、相手と一緒に報告したときに感じることが多いかもしれません。そういったときに、改めてフィードバックをもらうことが多いので、このときに同じ目線になりやすい感覚があります。

Q. AI時代にデータ分析は淘汰されるのか、最終的に大事なのは人間力なのか 

山田：「ChatGPT」や「Claude」がこんなこといってましたと報告しても、会社の大きな意思決定の際に納得する人はいないと思うんです。有効活用するのは大事ですが、その結果を自分の中で腹落ちさせて、自分の言葉でどう話せるかが重要だと思います。自分の得意なことでAIを有効活用しながら、さらにぶつけていく姿勢が大事ですね。

西田：分析者としていうべきではないかもしれませんが、分析で活躍している人は分析以外の能力がすごく目立つことが多いと感じます。もちろん純粋な分析力だけで優秀な人もいますが、「この人はすごいな」と思う人に限って分析力以外が優れていると感じることが多いですね。そういう意味でも人間力は重要だと思います。

Q. 期待値が定性的な指標になるケースの対処方法 

西田：私たちの思想としては、定量的になんとかしようとします。定量的な指標にして事業側の人に確認するプロセスがあるので、基本的に定量的なものに落とし込まれていると思います。直接的に定性的な指標に落とし込めなくても、親子関係にありそうな指標をいくつか持ってきて評価するなど、何らかの形で定量化しますね。

Q. 組織的なデータ活用促進について。データの可視化までは組織的にできているが、現場のメンバーレベルでデータ活用が促進できていない場合の取り組み

釼持：前職でダッシュボードを作ったことがありますが、結局使われなくなりました。どれだけコミュニケーションを取っても追い込まれていないと、なかなか使ってもらえませんでした。 

西田：我々の進め方で多いのは、使ってみて成果が出て周りに広がっていく攻め方です。トップダウンで下ろしても、実際に使ってみて頂かないと現場で使うモチベーションと一致するかはわかりません。 

山田：データ活用にあまり詳しくない方と一緒に、何かしらのタイトルの分析や企画を一緒にやって、使うイメージを持ってもらうことをこれから増やしていこうと思っています。

Q. 利用者側とできないことを決めるプロセスで工夫・意識していること 

釼持：精度が70%程度になる場合、その70%という精度と利用者の体感を含めて、どのくらい工数が削減できるかを算出しています。それでできないことはあるけれど、これくらいの削減インパクトがありますという風に、最終的に利用者として嬉しいことにつなげることを意識しています。 

西田：できないことを定義するには、相当ビジネス理解が必要です。相手がやりたいことや悩みをしっかり理解していないと、伝えるべきできないことを見落としてしまいますよね。しかも最初に明らかにしておかないと致命的になります。

Q. プロジェクト内の組織ロール設計において、ビジネス担当者と技術担当者間のコミュニケーション活発化について 

山田：おっしゃる通り、コミュニケーションの頻度を高くすることでプロジェクトの進行が良くなると思いますが、コミュニケーションには頻度以外に種類という要素もあると思います。たとえばビジネス担当者が最も話しやすい、聞きやすいコミュニケーションの仕方と、エンジニアやデータサイエンティストなど技術職がすんなり入ってくる話し方は別だと思っています。

PMに必要な能力として、これが最も大事だと考えています。同じことを話していても、その人が最も聞きやすい話し方は何なのかを考えることがコミュニケーションで非常に重要です。頻度×そのレベルを意識的に変えられる人は、PMとして優秀になると思います。自分もまだまだできていませんが、そうなれるように頑張りたいです。

【イベント内で回答できなかったQA】

Q. 相手から依頼されてこちらが事前設計や分析をしても相手が数字に関する理解がなく、効果があったのに無いと判断されます。分析結果やプロセスを理解してもらうために意識してることを教えてください。

データ分析の目的は分析すること・評価することでなく打ち手をfixすることにあります。 そのため、ファクトベースで打ち手を判断するマインドと実行力のある事業側キーマンを探すという方法をとっています。

Q. バンダイナムコグループはデータ活用してこう的な土壌ができてるのかな。 そもそもデータ活用していく予算をとるのが大変です。

IRでも発表していますが、バンダイナムコグループ全体でデータ利活用を重要戦略と定めて進行しています。また、個別のグループ会社の取組についても一定の成果認識があるため、予算化が進んでいます。 やはり事業側のキーマンと一体化し成果創出するのが予算確保のカギになるという手ごたえがあります。事業に紐づかない取組は維持が難しいです。

Q. 皆さんが大事にしてるスタンス教えてください

グループ内の各事業に向けたデータ利活用を提供する専門チームとして、以下の4項目のバリューステートメントをもっています

・親しみやすさとホスピタリティ
一人一人という頼られる存在である
・ビジネスインパクトを生み出す影響力
見える化・分かる化だけでなく決める化を約束する
・データにまつわるあらゆる技術力の高さ
昨日不可能だったことが今日可能になる喜びを提供する
・ビジネスのあるべき姿すら再構築する構造化力
本質的な課題解決のための議論・追求を惜しまない

Q. ぶっちゃけ、こちらがどんなに数字とロジックで整理しても現場が意味不明（というか土台の言語が違う）時が多く苦しんでます。これは苦しみながら、自分が変わるしかないですよね…。頭では分かってるけどしんどいです。みなさんの心持ちを聞きたいです

分析ベースの言語でなく事業ベースの言語でのコミュニケーションが必要だと思います。データはあくまで道具にすぎず、事業の改善にフォーカスするためには、事業側の言語に合わせる必要は一定出てきてしまうので…… 一方で事業とデータの溝が深すぎるとどうしようもない部分もありますので、なるべく数字に興味がありファクトベースのマインドを持っている事業キーマンとの連携を狙うことをお勧めします。

Q. データサイエンティストの価値をどの様に評価されていますか?

一般的な技術者向けのMBOで管理しています。その中でも、事業に対して接続性のある成果を価値として認識しています。 また、PJの中でのデータサイエンティストの価値は、PJによって創出された利益をベースに考えています。

Q. 入り込むことの重要性も感じながらも、相手の主体性が無くなってしまうみたいなことってありませんか？ あなたの仕事だよ、みたいな

BNXでは、分析結果を導出するだけでなく示唆・知見やそこから導き出されるビジネス上の打ち手の候補の洗い出しまで分析官が担当することもあります。ただ、ご指摘の通りすべての意思決定をこちらがしてしまう状態は健全ではなく、分析PJで一緒に動く事業側担当者には、ビジネスプロセスの明確化や意思決定ポイントの改めての言語化を依頼しています。

Q. ご講演ありがとうございました。生成AI等のシーズの発展が激しい中で、 これまでできなかったことがすぐにできるようになっていることも多々あるかと思います。 そのような中で、できることとできないことの線引きもデータサイエンティストとしても胸を張って言うのが難しくなっているような気もしています。 実際に現場の方もネットの記事やプレスリリースで「ほらに多様なこと他では出来てるじゃん」とおっしゃることも多くなってきています。 そのような中でどのようなコミュニケーションを意識していらっしゃるかお伺いしたいです。

他社事例を無邪気に持ち出されることはありますが、その前にベースでの信頼関係を構築するように努めています。BNXの担当者が他社事例をレビューして「たぶんこういう取組なのだと思う」という意見を返し、それを踏まえて今後のデータ利活用のプランを決めていく、などの関係を作れるように意識しています。

Q. ビジネス部門側に何がしたいかを決めてもらう時に、データ分析官が寄り添って一緒に考える、と言ったケースはありますでしょうか？

多くの場合存在します。ビジネス側の課題を幅広く聞きながら、データ分析と相性の良い部分から解消してみてはいかがでしょうか、と提案していきます。

Q. テーマのスピード感が知りたいです。どういう頻度でPDCAを回しているかを聞きたいです

早いPJは半年くらいで実用化に至りますが、遅いPJだと3年程度かかります。1回のPDCAに、最速で1週間～長いと数ヶ月かかります。

Q. 皆さんの業務の個人目標において、データ分析というツールを用いて、 ユーザーがXXとなったというようなユーザーストーリーで目標を立てておりますか？

ユーザーの業務がどのような状態になっている、という目標を立てるケースは多いです。そこまでできそうにないPJでは、もう少し前段の目標を置くことはありますが、基本的にはユーザにもたらした変化・それにより得られた事業成果を目標に置いています。

文・編集＝五月女 菜穂（株式会社kimama）

※所属組織および取材内容は2025年8月時点の情報です。

株式会社バンダイナムコネクサス
https://bandainamco-nexus.co.jp/

株式会社バンダイナムコネクサスの採用情報
https://bandainamco-nexus.co.jp/careers/

株式会社バンダイナムコネクサスのTechBlog
https://zenn.dev/p/bnx_techblog