データサイエンティストへの歩み②　勉強したことがお客様の価値になるデータサイエンティストとしての喜び（後編）

LTSデータサイエンティストチーム リーダー

データサイエンティスト協会は、データサイエンティストを「データから価値を創出し、ビジネス課題に答えを出すプロフェッショナルのこと」と定義しています。企業のデータを収集・分析し、企業における事業課題や、まだ見ぬ可能性の発見など、幅広い価値を提供する人たちを指します。

LTSのデータサイエンティストチームでは、企業内のデータに着目し、データ収集・データベース設計、アルゴリズム・モデリング開発、解析結果の実務適用まで幅広いサービスでお客様を支援しています。

今回はそのチームの若手メンバー2人に、データサイエンティストを目指したきっかけは何だったのか、どのように勉強したのか、課題や障壁を感じた部分はあったか、今後挑戦したいこと、などを伺いました。データサイエンティストを目指したい、勉強を始めたいが何から手を付けたら良いか分からない、という人におすすめの記事です。

データサイエンティストとツール

「ツールに縛られない」は多種多様なものを知っている前提

鈴木：
スキルアップのために、自分が使えるアルゴリズムの種類を広げていけばいいのかと言われると、それだけでは足りないと思います。例えば、今多く出ているツールをどれだけうまく活用できるか、ということも大事です。BIツールや機械学習プラットフォーム、SageMaker^※3、Azure^※4、をはじめ、無料で使えるものもある中で、それらをどう活用するのかがポイントですね。

舟山：
難しいですけど、それはありますね。一方で、LTSにおいてデータマネジメントの分野では「ツールに縛られない」ということも大事にしています。ツールはあくまでもHOW＝手段です。様々な技術が複数回にわたり検証された結果、安定性を持って提供できるようになって初めてツールという選択肢が出てきます。言い換えると、最先端の技術は不安定なので、ツールでの実現は適さないんですよ。

鈴木：
「ツールに縛られない」は、ツールでは対応できない最新技術も取り扱うことができるし、逆に既存のツールも使えますよ、という意味にもなるんですよね。なので、お客様が求めるツールがあれば活用するし、そうでなければ他の方法を提供すればよいと考えています。

舟山：
うん。ツールに縛られないことを念頭に置いてはいるものの、お客様から求められるのはやっぱりツールが多いんですよね。「こんなツール使える？」とか聞かれますよね。

ツールを使いたい・導入したいという要望は、どっちかというとデータ活用よりも業務改善寄りなんですよ。お客様の業務効率化を目的としたITツール導入をサポートする役割になるので、データサイエンティストの領域ではなくて、SIerの領域のものなのではないかと思います。彼らはそれをソリューションとして持っていて、提供し活用・改善することで価値を生み出します。我々はそのもっと前のフェーズをやっているので、ツールを使いこなすことがデータサイエンティストかと言われると違うかもしれませんね。もちろんお客様に求められたら対応できますよ。

日々変化する技術をお客様の課題に適応させる

プログラムが書けるデータサイエンティストは強い

舟山：
やっぱりデータサイエンティストは、プログラムを書けないといけないなと、個人的には考えています。時々刻々と変わる技術を、目の前のお客様の課題に適応していくためには、プログラミングスキルが必須です。

お客様から技術面に関して「これを使って」という要求は殆どありません。なので、どんな技術を使っても良いんですよ。技術自由度の高いプロジェクトでは、プログラムを書ける、書くイメージが湧いている、ググった内容を書ける、というスピード感で対応していきます。

鈴木：
そもそもプロジェクトが始まる段階で、技術やツールが求められるのっておかしいですよね。技術やツールは目的達成や課題解決のための手段なので。どういう課題があってそれをどのように解決するのかというところを、ディスカッションを通じて明確にして、その先に、ツールが必要なのであれば使うし、プログラミングを書く必要があればやる、という感じです。

プログラムが書けるとエラーにも対処できる

舟山：
プロジェクトの実態でいくと、データサイエンティストという響きはかっこいいですけど、やることの一部はデータアナリストやマシンラーニングエンジニアと同じで、プログラムの中身を見て「これのせいでエラーが出ているな」というものを見つけて指摘しなきゃいけないんですよ。プログラミングを書いた経験がないと、こういう時に対応できないことがあります。

鈴木：
また、チームとしてプロジェクトをけん引していくリーダーレベルであれば、尚更、プログラミングを書いた経験がないと、メンバーのフォローは難しいですよね。

舟山：
私たちのチームは技術の素養を重視したメンバーが多いんですが、今後それを実装していくことを念頭に置くことも必要かなと思います。ビジネスに関する知識だけではなく、プログラミングを書くことを含めた技術面も、両方必要だということです。

鈴木：
そうですね、大変ですけどね。

データサイエンティストが活躍するプロジェクト事例

事例から見るデータサイエンティストが提供できる価値

実業務で使えるものを作る

鈴木：
私が経験した事例の一つに、製造業では発注の効率化や最適化の案件がありました。過去の欠品、入荷数量、発注数量、出荷数量の実績を考慮して、今後の需要数の予測することで機会損失を減らし、在庫数量の最適化を目指しました。

この場合、作るものは予測モデルですが、同時に、最終的には現場の発注担当者の方が週次でいくつ発注するのかという数量を算出したり、その数量の根拠を分かりやすく表形式にしたり、実業務に紐づいたアウトプットも作りました。

なので、予測モデルを作っておしまいではなくて、そのモデルから出る出力結果を現場の方が使いやすい形で可視化したり、帳票の外部設計を作ったりしながら、その結果を用いた業務を、プロジェクト後もしっかりできる状態を作ることを心掛けました。

お客様がどんな情報を使って、何を判断したいのかをヒアリングし、その判断ができるようツールやモデルのインタフェースを設計し、判断に至る情報をお客様が取得できる…という流れの事例が多いです。

お客様が目指す姿に近づくためのものを作る

舟山：
提供できる一番の理想形は「お客様が解決したい課題を解決した状態」だと私は考えています。それは鈴木さんの話と同じで、何かを作るだけではダメなんですよね。それを、現場の人が使える状態でないと意味がない。例えば、データから「64」という数字が算出されたとします。でも、現場の人がこの「64」という数字だけで行動に移すことができなければ、その数字に価値はないんですよ。

もっと具体的な話だと、クレジットカードの与信判断で、個人からのクレジットカード利用の申し込みに対して、与信作業の効率化のためのリスクスコアを算出するモデルがあるとします。そこで「64」という数字が現場担当者に返ってきたとして、それを良いのか/悪いのかを判断するためには、閾値の水準が必要になります。

60が閾値だとしたら、64はアウト。でも、アウトの人が多すぎても業務にならないので、現場担当者から閾値を上げたいという声が上がる。これらは、算出されたデータを業務でしっかりと使えるようになるためのすり合わせ作業なんですよね、とても大事な。この作業がないと「データを業務に利用する」という状態になりません。

私たちは、手段としてデータ分析やモデル、出力結果を提供できますが、その結果に基づいてお客様が具体的に行動に移すことができ、目標としている状態になることができるまでコミットすることで、初めて価値を提供できたことになるのかなと考えています。その価値を提供するためには、予測されたモデルや出力された値だけではなく、データを業務に紐づけることが大事です。

お客様の課題解決までの道のり

ファーストプロジェクトを経て、セカンドプロジェクトへ

鈴木：
AIが流行し始めた年以降に各業界で「PoC地獄」と呼ばれるいつまで経ってもビジネスの価値につながらない（業務で利用できない）状態が発生していました。それは、作ったモデルを業務で使用する想定ではなかったということが原因としてあると考えています。業務で使用するには、現場の声を取り上げることが大切なので、そのようなことができていなかったPoCはうまくいかないよな…と思います。

舟山：
お客様の課題を解決するプロジェクトには、大きく2段階あると認識していて、ファーストプロジェクトとセカンドプロジェクトです。ファーストプロジェクトでは、課題を頂き、お客様の業務をよく理解し、その業務から生成されるデータが何かをよく理解し、それを踏まえて課題を解決できそうなモデルを作成します。モデルを作成して初めて、お客様の課題が解決できるかが分かります。

正直、プロジェクトが始まる段階では、課題を解決できるか分からないんですよ。セカンドプロジェクトへ入ってやっと、先に作ったモデルをアップデートしたり、モデルにデータを投入したりします。もちろん、ファーストプロジェクトの最後の段階で、課題が解決できないという結果になっていたら、別のアプローチを検討します。ここは坂内さんにも聞いてみたいですね。個人的には、ファーストプロジェクトで結果を出すのは難しいと考えているんですが、どうでしょうか。

※LTSデータサイエンティストチーム リーダーとしてこの対談に出席していた坂内さんは、今回も終始メンバーたちを見守っていました。

坂内：
そうですねえ。モデルを開発したての時って、まだ「たまご」の状態なんですよね。ユーザーから見ると使いにくいところもたくさんあって、それを使いながら繰り返し改善していくことで良くなっていきます。なので、AIだからといって過度に期待せずに、「たまご」をこれから使って育てていくという前提で受け入れる必要があるかなと思います。

現行業務を整理し、AIフレンドリーな業務をつくる

舟山；
今流行りのDXと同じで、DXも業務プロセスが揃っていない、データが散らばっている、属人化しているものがある…、という状態だとDXは推進できず、それはAIやデータ活用にも同じことが言えます。現状を変えずに、DXやAIで業務を改善するということはできないんですよ。基本的には人がやっていた業務を、まるっと置き換えると必ず不整合な点は出てくるので、そこに対する調整は必要ですよね。AIフレンドリーな業務にしていかなければなりません。

この点における、お客様との認識合わせは大事だと考えています。プロジェクトが始まる段階で、現行業務を継続するメリット・デメリット、それをAIに置き換えることによるメリット・デメリットと比べて、AIを使うことによって現行業務のメリットを上回るメリットを得られるかどうかを確認します。

AIフレンドリーな業務とは言いましたが、もちろん現行業務はAIフレンドリーではないことが普通の状態だと思います。AIを入れることで、AIフレンドリーな業務にしていきましょう、ということです。データ活用のためには、現行の業務プロセスの整備が必要で、そこから支援することも多々あります。

鈴木：
ありましたね。過去に入った案件で、分析要員として入ったけれど、前段階の業務とデータの整理で終わってしまった、ということがありました。

データサイエンティストとしてのやりがい

勉強したことがお客様の課題解決につながる喜び

鈴木：
データ分析をする過程で、お客様の業務改善に一役買えた時は嬉しいなと思います。お客様の業務はお客様が一番詳しく、わたしの知見は圧倒的に及ばないのですが、それでもこれまでのコンサルティングやデータ分析の経験でいろんなお客様の業務を知っている者として、新たな観点で「このように業務を改善することで、よりデータを活用できますよ」と議論するのは楽しいなと感じますね。

あとは、デジタルリテラシーを活用してお客様のお役に立てたときも嬉しいですね。「AIを導入したいけれどどうしたら良いか」「データを活用したいけれどどうしたら良いか」「このデータはどのようにして見るのか」…など、自分が専門とする分野の知見について、お客様に頼っていただけるのも嬉しいです。

そういったお客様の声に応えるためにも、最新のテクノロジーに触れておかなければいけないと思うし、もっと勉強しなきゃとも思います。必要な経験や学習を、業務を通じて獲得できる環境というのはありがたいなと思います。

舟山：
そうですね。わたしも同じく、お客様にはない視座を持てるのは楽しいなと思うポイントですね。最新技術に触れられるという点でも同じです。

あとは、純粋に、自分で技術を勉強している時点では「仮説」だったことが、お客様のデータをもらい実装してみたときに「やっぱりそうだったんだ！」となると、めちゃくちゃ楽しいです（笑）。

鈴木：
あーそれ、分かります。感動しますね（笑）。

舟山：
やっぱり自分が勉強したことをお客様に価値として提供できる…それに尽きるんじゃないですか。

---

ライター