スーツ姿のプロダクトマネージャー

ITで新しいプロダクトを生み出したいすべての人を応援するブログです。

30過ぎのデータサイエンティスト見習い(4) SEのスキルが1ミリも活用できない

データサイエンティストとして、最も難しかったのは「いかに問題を見つけて、機械学習のタスクに落とし込むか」ということを肌感覚で身につけることでした。

前回の記事で書いたように、初めから「文書分類のタスク」とわかっているところから仕事を始めるのと、顧客やビジネス上のニーズを起点として、機械学習の活用ポイントを見極めることは、難易度が全く違います。

また、よりコンサル的な見方をすると、顧客課題を紐解いていったとき、たとえ顧客が機械学習やAIを使うことを望んだとしても、使うべきではない場面に出会うこともしばしばあります。

このような判断を初期段階で行うためには、課題・ニーズと技術の接点を見つけるスキルが必要になります。一見、アプリケーションSEの得意技である「業務要件を起点としてシステム化要求事項に落とし込んで、設計を行う」というスキルが役に立ちそうな気がします。しかし、このSE経験こそが大きな足枷になってしまったのでした。*1

f:id:ku2t:20180228173303j:plain

 

例えば、私が実際に検討した案件で、このようなテーマがありました。(内容はいろいろ変えています。)

  • 機器に取りつけられた温度等のセンサーの観測値を使用して、その機器が故障しているかどうか自動判断したい。

このような課題が持ち込まれたとき、みなさんはどう考えますか?

技術的にはアプリケーションSEの視点しかなかった私は、こんな感じで考えました。

  1. 「観測値をバッチかオンラインでひっぱてきて、何かしら判定して画面かログに吐く小さいシステムか。」
  2. 「観測値がいくつになったら故障とするか、仕様を決めないと。聞いてみよう。」→明確な条件を引き出せず、過去のデータを活用することに。
  3. 「故障が起きたときのデータ見て、それに似た値だったら故障という感じかな。」

これは機械学習やAIを使ったアプローチとしては壊滅的でした。本当にお恥ずかしい話です。これではただのルールベースで組んだ業務システムです。

しかし、注目すべきは、上のアプローチがルールベースであることが問題なのではありません。問題の定式化、ヒアリング観点、といった問題の捉え方やアプローチが、データサイエンティストのそれと大きく異なっていたのです。

折角ですので、一つずつ掘り下げてみます。

 

落とし穴1:「観測値をバッチかオンラインでひっぱてきて、何かしら判定して画面かログに吐く小さいシステムか。」

提供すべきシステムの全体像を捉えようとすることは、機械学習やAIのタスクであっても重要です。しかし、一番はじめに考えることか?といわれると、実はそうではありません。

機械学習の処理や学習モデルというのは、システム全体から見ると一つの部品にすぎません。そのため、システムの形を先に固めるということは、その中の部品の要件をある程度制限してしまうことになります。

機械学習の学習モデルが担うのは、まだシステム化できてない人の判断を処理として実現することです。

今回は、「故障を捕らえたい」ということでしたので、考えるべきことは、

  • 機器の故障はどのような要因で起きるのか。
  • 故障が起きたことを、今はどのようにして捕らえているのか。そして、その情報でどういった対処をしているのか。
  • 故障が自動的に捕らえられるようになったら、その情報をどう活かすのか。人に知らせて対処するようにするのか、自動的に停止させるのか。それとも、記録として残しておいて、定期的に確認するのか。
  • 過去の故障記録はとってあるか。どれくらいの頻度で起きるのか。
  • 故障が起きたとき、顧客にはどのようなインパクトがあるのか。それをどう是正したいのか。

といったことです。故障という事象はどのようなものか、そのインパクトはどうか、そして今はどう管理していて本来はどうしたらよいのか…ということをいろんな角度で考えます。

もちろん、考えただけでは答えはでないので、現場を調べたり、データを調べたりする必要があります。加えて、対象となる機器の業務分野や用途を調べるべきでしょう。

今システム化(自動化)できていないということは、人がシステム外でやっているか、何もやっていないかのどちらかなので、その情報を正確に把握する必要があります。あわせて、機械学習で重要となるデータの発生源と、出力させたい現象の背景を押さえておかなければなりません。

ヒアリングで得られた情報の例として、いくつかパターンを考えてみましょう。

パターン1:  「現在は人は考えてやっていて、実はある数値が100を越えたら故障とわかる。」

この場合は、機械学習を用いるのでなく、ルールベースで組めばよいことになります。

パターン2: 「故障は発生後5分以内に100%捕らえなければ重大事故になる。これを実現するために50人体制で監視していて、見逃しはここ数年ない。」

この場合は、そもそも機械学習でできることは、うまくいっても人による監視の補佐程度です。というのも、機械学習による判断・予測モデルというのは、ある意味確率的な出力をするものなので、100%の精度を担保するのが難しいからです。しかし、人の監視作業を効率化したり、二重チェックをやるというのであれば、可能性があります。

パターン3: 「今はルールベースで判定するシステムを使っている。全故障のうち半分程度しか捕らえられないので、人が監視・記録している。」

このような場合は、まさに機械学習を活用できる可能性があります。人による判断が業務に組み込まれていて、さらにその記録が残っています。また、システムの活用イメージも具体化しています。

パターン4: 「故障はクレームが来てから交換している。いつの時点で故障が起きたのか記録していない。AIを用いて自動的に対処できないものか。」

おそらく、多くのデータサイエンティストは「まずデータをためるところからやりませんか?」といいつつ後ずさりするでしょう。教師データがないことも大きな問題ですが、業務上の課題が別にありそうだからです。

 

以上、妄想的に4つのケースを考えてみました。データサイエンス的な観点で問題を捉えようとするほど、実際の業務や現場課題を紐解かなければならないということが分かるかと思います。

実は、優秀な業務系、アプリケーションSEも、業務の紐解きをきちんとします。しかし、顧客から「~の場合に、の情報に基づいてを出力するシステムを作って」と具体的にリクエストがくると、ついついシステムの中身を考えがちです。というのは、左記の表現は、SEにとってはそれ自体がシステム化要求事項に見えてしまうからです。

これが一つ目の落とし穴でした。

 

落とし穴2:「観測値がいくつになったら故障とするか、仕様を決めないと。聞いてみよう。」

データを使ったアプローチとわかっていてもなお、「システムの処理はロジックで設計される」という感覚が染み付いていました。このため、要件や顧客との会話の中で、境界条件や制約事項を聞き出そうとしてしまいます。

業務の課題と狙いがクリアになったら、次は実データをビューイングしながら機械学習の問題に落とし込むことが必要です。

しかし、SEの思考様式が強いと、自然と分割統治法的に問題を分解するクセが出てしまいます。

これが二つ目の落とし穴でした。

 

落とし穴3: 「故障が起きたときのデータ見て、それに似た値だったら故障という感じかな。」

さて、メインディッシュ、機械学習の問題に落とし込むフェーズです。このフェーズでも、現場観察やヒアリングを絡めてヒントを得るもありますが、基本的にはデータサイエンティストの頭の中で組み立てるものです。

しかし、これが未経験者には大変難しい。

データを活用せよと言われても、はじめはどこから考えてよいかわかりませんでした。そして、ついつい故障を捕らえたいのであれば、故障のデータを見てみようとするのです。

今回の顧客課題を機械学習の問題として考えると、データの流れから異常を捕らえる「異常検知」のタスクになります。そして、異常検知をやる場合には、データの特性によって、概ね以下の2つのアプローチが考えられます。

  • 過去に故障の発生時期・対象機器を記録したデータがあって、センサーデータとうまく紐づけられる場合には、分類問題として解く。ただし、故障(異常)の発生頻度が著しく少ない場合には、この限りではない。
  • 過去データはすべて正常なデータのみで、故障の記録はないか圧倒的に少ない。この場合には正常データを分布推定などの技術を使ってモデル化し、新しいデータが正常なデータ群とどの程度離れているかで異常度を推定する。

実は異常検知は、技術的な一筋縄でいかない分野なのですが、実問題として製造分野を中心にニーズがあるものです。このため、世の中のデータサイエンティストの多くは、いろいろなタスクをやってきたはずで、アプローチはすぐに思いつくはずです。

 

機械学習の基本手法は、カテゴリ値を予測する「分類」、数値を予測する「回帰」、データをまとめる「クラスタリング」、データを圧縮する「次元圧縮」、データのバラツキをモデル化する「分布推定」などがあります。

業務上の課題をこれらの手法に結びつけて、機械学習の問題として解く必要があります。難しい理由のひとつは、直線的に結びつけができないことです。*2

これらを結びつけるためには、手法の本質を十分に理解した上で、業務上の課題の方を抽象化して接点を見つける必要があります。

この抽象化には、対象課題を分割するだけでなく帰納的に考える場面が出てきます。データ分析は、生データの分布からモデル化する帰納的なアプローチです。

ところで、ITシステムのアプリケーション設計では、機能を分割し、処理の流れを組み立て、処理の条件分岐を整理することが中心になります。これは演繹的なアプローチであり、SE経験が長いほど統計的な考え方から遠ざかってしまうことになります。

私は、統計的な問題の捉え方、機械学習の問題設定を身につけるのに大変苦しみました。これが三つ目の落とし穴でした。

 

 では、どうすれば?

これまで、私が落ちた3つの穴について書いてきました。

しかし、駆け出しデータサイエンティストだったころは、何が自分のボトルネックになっているのかわからず、延々と悩みました。分からないところが分からないというだけでなく、思考様式の違いを是正するのに大変時間がかかったということです。

どれも難問でしたが、経験と失敗を重ねることで、徐々に解消していきました。だれもが言うことですが、実問題に手を出して、経験を積むことが上達の近道です。実務だけでなく、コンペに参加するとか、オンライン講座を受けてみてもよいと思います。

Kaggle: Your Home for Data Science

オプトDSL・DeepAnalyticsコンテスト一覧検索

Coursera | Online Courses From Top Universities. Join for Free

 

また、本をこの順番で読めばもっとわかりやすかったのに!…ということもよくありました。今は機械学習の本が整理されていますし、手法の羅列だけという本は少なくなりました。友人のデータサイエンティストが「この分野の本は、新しくなればなるほど整理されてわかりやすくなる。」と言っていましたが、まさにその通りだと思います。

 記事タイトルにあえて「1ミリも活用できない」と書きましたが、それはデータサイエンスの中心的な考え方の獲得に関する部分のことです。

もし、SEが統計的な考え方、データサイエンス、機械学習のアプローチを獲得できたら、その時は非常に強力なスキルセットになるでしょう。その理由は、機械学習のモデルこそ、システムで活かされるべきものだからです。

 

続きはこちら(最終話)

*1:私はSE時代、業務系SEとしてアプリケーション設計やプロダクトの企画・開発のマネジメントをやっていました。

*2:Webマーケティングなど、ある程度事例が蓄積されている分野では、システム要件そのものに機械学習的な要素が含まれているのでわかりやすいです。しかし、まだ機械学習を活用できてない分野ではそうはいきません。