ビジネスとしてのデータサイエンス活用 ～データサイエンティストとして大切なこと～

# はじめに

こんにちは。(株) 日立製作所の [Lumada Data Science Lab.](https://www.hitachi.co.jp/New/cnews/month/2020/03/0330d.html) の末吉史弥（すえよし　ふみや）です。

2016年入社後、データサイエンティストとして、お客さまの課題解決に向けたデータ分析業務を日々行っています。特に機械学習や数理最適化を活用した、工場などの計画業務や操業の最適化に携わり、お客さま業務の全体最適化を支援しています。

2/25に開催された[Social Tech Talk #01](https://connpass.com/event/201433/)で**「ビジネスとしてのデータサイエンス活用」**というお話を発表させていただきました。その内容をご紹介するとともに、発表では話しきれなかった「こぼれ話」もお伝えしたいと思います。企業のデータサイエンティストがどんなことをしているのか、これからデータサイエンティストをめざす方々のご参考になれば幸いです。



## データサイエンティストって？

データを活用したサービスは現在、みなさんの身近なところにたくさんあります。スマートフォンの顔認証やECサイトのおすすめ商品などはその一例です。

これらのサービスは、いきなりすぐに提供なんてことはできません。たくさんの検証を重ね、その結果が実り、うまくいったものが世の中で利用されています。日立ではそのような検証を含め、お客さまのデータ活用を支援し、ビジネス課題の解決に貢献しています。

データを扱って新しい価値を生み出している人は、データサイエンティストと呼ばれています。日立にはたくさんのデータサイエンティストがおり、日々お客さまの課題解決に取り組んでいます。

もしかしたらデータサイエンティストと聞くとプログラムが早く書ける人、統計的な力が優れている人という印象を持っている人もいるかもしれませんが、それだけではありません。データサイエンティストには**「ビジネス力」**という力がどうしても必要になります。



## データサイエンスにおける3つのスキル

よく知られていることかと思いますが、データサイエンティストには大きく3つの力が必要です。

![Fig1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168812/6f9eaffe-ad39-328a-2741-8654f6756e46.png)
**● ビジネス力**：課題背景を理解した上でビジネス課題を整理し、解決する力
**● データサイエンス力**：情報処理、人工知能、統計学などの情報科学系の知恵を理解し、使う力
**● データエンジニアリング力**：データサイエンスを意味のある形に使えるようにし、実装、運用できるようにする力

この3つ全てのカテゴリに対応できる人材は稀有であり、日立ではチーム連携の活動で、データ利活用ビジネスを行っています。今回は、この3つのスキル中で、私が日々の業務で培ってきた**「ビジネス力」**にフォーカスしてお伝えしたいと思います。



# ビジネス力を活用するポイント

突然ですが、次のような課題を持つお客さまの分析プロジェクトを進めるにあたり、どういったところに気をつけるべきでしょうか。



## お客さまの課題例

お客さまは多品種多量で国内に複数の工場を持っており、納品先は世界各国で、工場間で部品を共有しています。**「営業側と工場側の要求を満たすように、工場側の生産量を決定するのに時間がかかっている」**という課題を抱えています。

![Fig2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168812/f2ff7ba7-ef1f-8136-46a0-97fd02fdb9c7.png)

このようなお客さまに対して、「さっそく分析して時間を算出しよう」「お客さまの課題を聞きだしてすべてAIで解決してあげよう」「生産量を決定するのだから工場の意見をもとにシステムを構築しよう」などと考えてしまうかもしれません。そうすると、思わぬ落とし穴にはまってしまうことがあります。

もちろんデータサイエンティストとして分析力は大事ですが、それだけではなく、ビジネス力を十分に発揮してプロジェクトに向き合わなければなりません。

それでは、ビジネス力を発揮するには具体的にどうすべきでしょうか。私がこれまでの経験から大切だと思っている**「3つのビジネス力活用ポイント」**をご紹介します。



## Point1: KPIを明確にして、目標値を設定してからプロジェクトを開始する

まず大切になってくるのが、KPI（Key Performance Indicator／重要業績評価指標）を意識するということです。失敗パターンを見てみましょう。

![Fig3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168812/f7673d81-4c4e-20f6-b1bd-112ab5a45f90.png)

お客さまの「生産量の調整に時間がかかることです」という課題を鵜呑みにしたまま、データを受領してすぐにデータの質や量を確認したり、時間に関して分析を実施したりすると、どうなるでしょうか。

いま現在のお客さま自身が生産量決定の調整に時間がどれくらいかかっているのか認識していないことや、どれくらい改善すればよいのかという分析の目標も定まっていないため、お客さまが分析結果に対して、評価ができなくて満足してもらえない結果になってしまいます。これでは、プロジェクト全体のゴールも見えず、行き詰まってしまいます。そこで、KPIを意識することが必要になってきます。

![Fig4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168812/01ccb9d2-9ea7-e0c1-6f6a-42134c20f31c.png)

お客さまから課題をいただいたときに、まず指標となるKPIを確認・合意を得て、現状どれくらい時間がかかっているのかを算出します。さらに、どれくらい削減したいのか目標値を明確にします。例えば、今は3時間かかっているから、これを20％削減したいというように指標と目標を決定します。

目標を定めた上で分析を行うことで、KPIを用いて分析結果を定量的に評価できるようになります。そして、お客さまも目標を理解しているので、分析結果にご納得いただけるようになり、プロジェクトが円滑に進みます。

データ分析をする者としては、すぐにデータを触りたいものです。ですが、すぐに分析を実行するのではなく、一度立ち止まり、そもそも分析で何がしたいのか、何をゴールにすればよいのかというところに立ち返り、KPIを明確にして、目標値を設定してからプロジェクトを開始することがポイントになります。



> ### 💡 こぼれ話
>
> ちなみに…分析作業の中でも、随所でビジネス力は必要になってきます。
>
> #### まずは生データとの闘い
>
>  [Kaggleのコンペデータ](https://www.kaggle.com/competitions) のように、マトリックス形式になったきれいなデータが最初から提供されることは、まずありません。生のデータは大抵が不揃いな状態でやってきます。同じものを指しているのに名称が微妙に違ったり、大文字小文字が違ったり、全半角のスペースが混在していたり（これが結構厄介）。フォーマットも表形式、テキスト、メモ、チャットデータ、と様々。それをすべて集めて、引き当てして、不足しているところを補って、足りない情報はひたすらお客さまへヒアリングします。
>
> 「AとAAが指すものは同じですか？」「この属性はこのデータに紐づきますか？」
>
> 何日も何日もデータと格闘して、ようやく解析できる状態になるのです。
>
> 
>
> #### データ整理はDB定義だけじゃない
>
> お客さまのデータを整理しながら、当然、DB（DataBase）の定義も検討します。商品名がばらばらならば、商品名マスタを作って名称を統一すればいいんじゃないか？って思いますよね。そのほうがデータがきれいに整いますし、理想形でしょう。しかし、上流ではそれでよくても、下流の工程にものすごく影響してしまうかもしれません。AとAAがおなじものを指すなら、どちらかに統一すればいいと普通は思いますが、下流の工程では絶対にAAでなければならないかもしれないのです。Aに統一することで、いままでデータをAAとして扱ってきたチームに多大な負荷をかけることになりかねません。
>
> システムを導入した後に、お客さまの業務が本当に回るのか。業務全体を俯瞰して、データを整理していく必要があります。分析のための理想を押し付けるのではなく、業務の運用も十分に考え、お客さまのための理想を追求する。ここでもビジネス力が問われます。
>



## Point2: お客さまと交渉を重ねて、分析スコープを合意してから、データ分析を実施する

続いてのポイントは、解決するスコープを絞るということです。失敗パターンはこちら。

![Fig5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168812/840f380d-b249-72e6-f0e7-cf4ee65114b9.png)

お客さまの課題を洗い出すときには、課題のプラスアルファで実現できそうな要望事項も出てくるものです。問題点リストには、課題も要望がどんどん蓄積されていきます。データサイエンティストが「お客さまのため」とか、「最新の技術を使って解決できるかも」と考え、すべてに対して解決をめざしてしまった場合どうなるでしょうか。

お客さまの要望の中には、同時に満たせないものやまだどうしたいか決まっていない問題も多く、それを優先すると本来解決したい問題の精度に悪い影響が出てしまうことがあります。これでは、お客さまの本当に解決したい課題の解決自体の妨げになってしまいます。

![Fig6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168812/704aa070-01b2-d70f-dc97-8a92753befa9.png)

そこで課題と要望を整理して、お客さまと交渉しながら、本当に改善が必要なのか、また、KPIに影響が出るものなのかを検討します。もちろんなるべくお客さまのご要望を取り込みますが、今検討すべきなのか、あるべき姿が決まっているものなのかをしっかり議論し、スコープを精査します。そして、今回のプロジェクトの中で解決したい問題に絞り、分析を実施することで、KPIの目標達成をめざします。

お客さまから聞き出したすべての課題や要望を分析スコープに入れて、いきなりAIで解決しようとは思わず、お客さまとの議論や交渉を重ねて、分析スコープを合意してから、分析を始めることがポイントになります。



## Point3: すべてのステークホルダーが納得する業務フローを設計し、システム化する

最後のポイントは、最適な業務フローを設計するということです。当たり前に感じるかもしれませんが、一筋縄ではいきません。

![Fig7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168812/84730a0c-aa0f-8b59-c172-d324ed0faf3f.png)

よくある失敗は、直接やり取りしている目の前のお客さまにヒアリングした情報だけを基に、業務を設計してしまうということです。そのお客さまの部署にとっては良くても、他の部署にとっては、業務上利用できないシステムを構築してしまうことにつながってしまいます。例えば、システムやAIの実行時間の関係から業務適用が難しかったり、そのためのインプットデータを作成する人が不在だったり、タイミングが合わなかったりということがあります。

実際、分析プロジェクトを行う場合は、その担当業務を行っている方だけに対して提案をしているので、そのほかの人を見落としてしまう場合が多く、また、データサイエンティストは特にデータの動きに注目しがちで、ほかの部署の利用について検討が漏れてしまいます。

![Fig8.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168812/13f6a1d0-5976-db01-df84-f88bc8ed8345.png)

そこで、お客さま業務に関するすべてのステークホルダーにヒアリングした上で、業務フローを検討します。そうすると、AIで解決するものと、業務見直しで解決するものの検討が必要である、という気づきが得られることもあります。

また、あるステークホルダーにとっては、システム化を進めることで、実は業務が少し増えてしまうことや、現在の業務からの変更に対応するための労力をお願いする必要も出てきます。その場合は、この取り組みで、全体として、どれくらいのどんな効果があるのかを説明し、了承を得ていきます。何度も丁寧に説明していくことで、すべてのステークホルダーが納得し、利用できるAIシステムを実現していきます。

このように、目の前にいるお客さまの目線だけではなく、関係するすべてのステークホルダーに目を向け、各ステークホルダーが納得する業務フローを設計することがポイントになります。



> ### 💡 こぼれ話
>
> #### お客さま全員に納得していただくまでの道のりは長い…
>
> ステークホルダーが増えれば増えるほど、業務フローを決定するまでの道のりが遠くなります。私が担当したプロジェクトでは、100名以上にヒアリングを行いました。お客さまの経営層に「これでは業務が回らないのではないか」とお叱りを受けたこともありました。それでも「絶対にお客さまが納得するいいものを作ろう！」という思いでブラッシュアップを続け、ご納得いただけるまでに至りました。ここで欠かせなかったのが、お客さま側システム担当部門との信頼関係です。よそ者からの働きかけには限界がありますので、お客さまに主体となって取り組んでいただけるように、お客さま側の推進部隊との関係性を築き、支え、一緒に取り組めたことが、成功につながったのではないかと思っています。
>
> 
>
> #### 適用するAIの精度を上げるために
>
> AIを業務に適用するにあたり、AIの精度が悪いと、想定している業務フローにそぐわず、結果的にお客さまの稼働状況に影響が出ることになります。適用しようとしているAIの精度に問題がないのか、問題があるとすれば、原因は何かを究明し、何としてもAIの精度をあげなければなりません。私の担当したプロジェクトの中で、入力データが不揃いだったため、AIのモデリングがうまくいかずなかなか精度が上がらないことがありました。地道にデータを整理したり、AIのアルゴリズムにお客さまの業務固有の条件をインプットとして取り込むことでAIの精度を上げていきました。
>



## システム化による成果

以上のポイントを意識しながら取り組んだ成果として、私が設計した業務フローの例をご紹介します。


![Fig9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1168812/d1208a3f-6781-f7b8-12fb-fe25fc081cb5.png)

- 効率化ポイント①（赤枠）：工場間の生産量調整に時間がかかっていたところです。AI導入によって効率化を行いました。
- 効率化ポイント②（青枠）：現行のフローでは、工場での生産量調整後に営業が調整結果を確認し、そのあと納品先にも確認していました。業務見直しを行い、生産量調整の前に工場ごとに生産希望データを作成し、事前確認することで効率化を図りました。

結果として、部分的な効率化ではなく全体の効率化を実現し、時間削減に加えて、現場負荷低減や生産量増加につながりました。



# おわりに

今回ご紹介したポイントに共通して言えることは、**「ビジネス力にはコミュニケーション能力がとても大事」**ということです。お客さまも気づいていないような、本当に価値あるソリューションを実現していくためには、対話を通じてお客さまを理解し、周囲の人々を巻き込んでいく力が欠かせない、と思っています。

お客さまの業務をしっかり理解することは、非常に重要です。特に多くのお客さまとやり取りする場合は、その前提条件が異なっていたり用語の解釈が違っていたりする場合があります。認識誤りを防止するため、お客さまへのヒアリングの際には念入りに事前準備すること、録音内容を振り返ることで、お客さまの用語や略語を理解しておくようにしています。

私はデータ分析自体ももちろん楽しいと思っていますが、さまざまなプロジェクトに関わる中で、目標に向かってお客さまと一緒に取り組むことの楽しさを感じるようになりました。実際にシステム化により、KPI目標値を達成した際にお客さまと一緒に達成感を味わうことができるのは、データサイエンティストならではのおもしろさだと思います。

これからも、目の前にあるお客さまの課題に真正面から全力でぶつかって解決していきたいと思っています。自分ひとりだけでできることはわずかでも、日立・組織・チームとして活動すれば、やがて大きなことが達成できると信じています。多くの人からすごいと言ってもらえるような、今まで世の中になかったようなソリューションやサービスの開発に携わり、大きなことをやり遂げ、社会に貢献していきたいです。

最後まで読んでくださり、ありがとうございました。