ダッシュボードが切り開く、モデル現場装着の最短路～データサイエンティストでもアプリケーション開発ができる、MLOps新時代の到来～ 

POCプロジェクトの落とし穴 

もう一度、なぜ分析技術が実務適用されないか、その重要な背景を1つ紹介させてください。それは、データ分析プロジェクトにおけるPOC（概念実証）の進め方に大きな落とし穴があると私は考えています。
POCとは、研究的にモデル開発をし、データ活用の取り組みが収益を生むかどうかを検証するプロジェクトで、データ分析プロジェクトの最初期に行われます。その結果を経営層といった上位層に報告し、本格活用の意思決定を行います。この取り組み自体は良いのですが、私が危惧しているのは、POC終了時点での成果物がパワーポイントの報告資料であることが大半だという点です。これにより、多くの関係者の誤解を生みます。

具体例として、ユーザーの行動データを活用し、ユーザーの優良顧客予測を行うPOCを行った状況を考えさせてください。ユーザーに対して、優良顧客度合い（スコアリング）を算出し、その数値を元に施策を行えば、年間で数千万円のコストインパクトがあると試算できたとしましょう。

POCフェーズの締めとして、経営陣や部長陣といった決裁権を持つ方々に対してこのようなプレゼンテーションを行いました。経営陣はROIが十分であることを感じ、無事プロジェクトの継続の意思決定がされました。

しかし、ここで大きな落とし穴があります。
聞き手（経営層）はこの時点ですでに業務アプリケーションのようなものが出来上がっていて、それを操作した結果を見せられていると思われるケースが多いのです。特に経営層といった上位層の方々ほど、「これでうちにAIが入った」と満足に浸ってしまいます。実態としてPOCフェーズ終了時に実態としてあるものは、データサイエンティストの雑多なプログラムであり、業務担当者がそれを操作できるものには、到底なっていません。

プレゼンテーションする側も、経営層から良い評価を受けてその場を終わりたいわけですから、雑多なプログラムが出来ただけで、現場に適用できるものは到底できていないということを、わざわざ言うメリットがありません。多くの決裁者はROI試算が載ったプレゼンテーション（＝パワーポイントの資料）だけで満足してしまうのです。また、決裁者だけでなく、データサイエンティストもこの時点で自らの職務を果たしたと満足する者も多いです。すなわち、自分が作成したプログラムをどこか別の部署かシステムベンダーに渡して、あとは好きに作ってもらえば良いと考えます。

こういったPOCプロジェクトの報告資料だけを見て、一見AI導入が成功したように見えてしまうことが、モデルが現場に装着されない、リアルな実態だと私は考えます。 

ウォーターフォール開発　vs　プログラム納品 

それでは、空想ではない真のROIを実現するにはどうすれば良いのでしょうか？
ここからはより具体的な技術要素を交えて解説していきたいと思います。

まず、ウォーターフォール開発から考えたいと思います。ウォーターフォール開発はコストが膨大となり、試算した利益が遠のいてしまう可能性が高くなります。

現代のアプリケーションは運用方法や装着方法、継続性から考えてSaas型、いわゆるWebアプリケーションです。従来の方法でWebアプリケーションをウォーターフォール開発として作るには、まず多くの職種の人材、あるいはこれらを兼ね揃えた「フルスタックエンジニア」が必要です。例を挙げると、以下のようなチーム構成になります。 

• フロントエンドエンジニア（職務：画面作り、スキル：JavaScriptフレームワーク, html, css） 
• サーバーサイドエンジニア（職務：データフローの設計、スキル：DB設計,Rest-API開発, バッチ処理） 
• インフラエンジニア（職務：環境構築、スキル：クラウドサービスの活用, Docker, テスト設計、CICD） 
• プロジェクトマネージャー（職務：スケジュール管理、スキル：プロジェクトマネジメント, PMBOK） 
• データサイエンティスト（職務：モデルの精度改善、スキル：機械学習、数理最適化モデル構築） 

これらの職能もそれぞれ1人ではなく、場合によって複数必要な場合もあるでしょう。このような人材を用意し、何カ月、あるいは何カ年で完成させることが良い選択肢なのでしょうか。果たしてそのための人件費やクラウド費用やデータベース費用といった設備投資はいくらになるのでしょうか。さらに拍車をかけるのが、ウォーターフォール開発とは設計書があって初めて成立します。POCが終わった時点では、システム設計書は一切ありませんし、モデルというのは、変数をアップデートしながら改善していくものですので、要件は刻々と変化していきます。

また、POCではデータサイエンティスト自身がプロジェクトを先導していましたが、ウォーターフォール開発の中では、データサイエンティストは一つの部品でしかありません。さらには要件が変わっていくモデル開発パートはウォーターフォール開発の中では、面倒な要素でしかありません。さらに、これら人々が連携しないといけないため、具体的に動くものが見えるまで非常に時間がかかります。 

では次にプログラムをそのまま現場の方に渡して、実行方法をレクチャーする選択肢について考えてみましょう。コストはかかりませんが、現場の実担当者に、pythonの実行環境を立ち上げ、コンソールからpythonプログラムを実行していただくようにすんなりと、レクチャーできるでしょうか？

簡単に思えるかもしれませんがこの方法もハードルが高いです。例えばパラメータを変えて実行したい場合に、エンドユーザーがpythonのスクリプトを開いて、パラメータを編集できるでしょうか？さらには、実行環境は、ノートPCでいけるのでしょうか？機械学習や数理最適化は多くのメモリが必要なため、サーバーで実行する必要があるケースが大半です。そうなると、Webアプリケーションを構築する必要がありますが、ウォーターフォール開発ほどのコストはかけられません。 

データサイエンティストは簡単なアプリケーションでさえ作れなかった

この2つの方法を打破するために、データサイエンティストに簡単なものを作ってもらえないかという話は以前からありました。しかし、データサイエンティストの大半がモデル開発は行えるが、アプリケーションに対して十分な知識と技術を持ち合わせていません。Webフレームワークと呼ばれるpythonを使い、Webアプリケーションを作るためのライブラリは昔から存在したのですが、データサイエンティストが扱えるものではなく、エンジニア向けでした。エンジニアもデータサイエンティストも同じpythonを使うのですが、これらの職種で目的が大きくことなるため、データサイエンティストがWebフレームワークを覚えることにはとても高いハードルがありました。さらに、Webフレームワークを覚えれば、Webアプリケーションを作れるようになれるのかと思いきや、それ以外にも、フロントエンド、クラウドといった分野の知識も必要です。意外に思うかもしれませんが、Web上で、たった一つのボタンを作り、それを押して結果が表示されるアプリケーションを作ることでさえ、大半のデータサイエンティストはできなかったのです。ここが世間の期待と大きなギャップを生んでいる要因の1つだと私は考えます。

フルスタックエンジニアに頼らない、アプリケーション開発の新時代 

ここからは、タイトルにもある通り、新しい現場活用方法であるアプリケーション開発の新しい手法、「ダッシュボード開発」について説明します。ダッシュボード自体は、これまでも伝統的なBIツールを用いることで誰でも作成することはできました。しかし、伝統的なBIツールには致命的な欠陥がありました。それはBIツール上にpython環境がないことです。

BIツールは、Web上に多くの可視化されたグラフを並べることができ、該当するURLを展開することによってクイックに結果を共有できます。しかし、BIツールを使うユーザーはマーケターのようないわゆるコードが書けない職種の人らを対象にしたツールでした。これが意味することは、簡単な集計可視化しかできないこと、すなわち、データサイエンティストが構築したモデルの実行環境にはなり得ないため、モデルの結果を展開することができませんでした。モデルの実行環境と、BIツールの環境は別に構築する必要があり、これは先に述べたSIに近い形になります。BIツールによって結果を共有することは簡単なのですが、データサイエンティストが作成したモデルの結果は渡すことができず、惜しいところに手が届いていないと感じていました。 

こういった、一般ユーザーとデータサイエンティストのモデルの結果受け渡しの実現について、それに答えるツールがここ数年いくつか登場しました。ツールの機能を一言で表現するのは難しいのですが、あえてまとめるとデータサイエンティスト向けWebフレームワークの登場とBI機能の融合です。

これにより、データサイエンティストでも簡単にボタンやフォームといったインターフェースの作成とモデルの構築をツール上でできるようになり、ダッシュボードを展開でき、現場担当者にWebのURLを送るだけで結果の共有ができるようになりました。これは、非常に画期的な進化だと思いました。これにより、従来のアプリケーション開発の常識自体が、根本的に変わっていくような空気さえ感じます。データサイエンティストの複雑な分析の結果を直接的にエンドユーザーに渡すことができるようになりました。そこには、集計可視化、機械学習、数理最適化と技術を問わず可能です。データサイエンティストのプログラムコードが直接的にビジネス貢献できるとても良い時代が来たと思っています。

ダッシュボード開発による現場装着の実例 

ここでは、実際にデータサイエンティストの私が材料探索の最適化プロジェクトで上記ダッシュボード開発を行い、フルスタックエンジニアの支援も、大規模SI開発も一切行わず、実務現場にモデルの結果を装着した例とその進め方を解説します。
※材料探索のプロジェクトの進め方や具体的な分析手法はこちらにまとめてあります。

アプリケーション独自のデータ項目の定義書を基幹システムと切り離して決める。 

まずは、データの定義書を決めます。すなわちどういった項目をアプリケーションのインプットとするかです。これには慣れが必要ですが、大切なことは、基幹システムとアプリケーションの入力データ形式を一致させないことです。基幹システムの多くは正規化が多く施されているため、人間にとって非常にわかりづらい形式になっています。そこで、人間が理解できるような観測データ形式のフォーマットをデザインし、それをアプリケーションの入力データとします。

さらにポイントが、このアプリケーションへの入力段階では、機械学習用の特徴量を作らないことです。業務の担当者に負荷がかからない形で、データを整備することが使いやすくなるコツと言えます。

モック画面を作り、フィードバックをいただく

そして、次に、ボタンを押しても何も反応しない画面（モック）を作ります。これはあくまでディスカッション用であって、完成形ではありません。これをプロジェクト開始時に作成します。これによって顧客がこれを使って業務をするというイメージを先に持っていただきます。そこで、足りない点に対してフィードバックをいただきます。

モデルの作成と結果のダウンロード画面を作る

次は、データサイエンティストお得意のモデル開発です。入力データの形式に沿って、自由にコードを書きます。そしてそのスクリプトを画面のボタンをトリガーに実行できるようにします。伝統的なアプリケーション開発では、こういった処理をする際に、APIサーバーを経由して行いますが、その必要はありません。APIを用いずともWebアプリケーションを作れることが、新しいwebフレームワークの大きな特徴と言えます。また、リリースタイミングも１次リリース、２次リリースといったようにSI工程を意識したような進め方はしません。ツールがアップデートしたタイミングでいつでもリリースします。事実、毎日リリースしていました。POCフェーズのため、細かいデザインには、注力せず、結果の出力機能をスピードを優先して取り組むことが大切だと思います。 

POCの報告は、資料だけでなく、アプリケーションも用いる

POC終了時の上位層向けの報告ですが、報告資料だけでなく、その場でアプリケーションを操作し、結果が出力されることを実演しました。経営層向け報告は紙の資料で十分と述べましたが、それは単に発注側から、そのような形式の報告しか経験していないだけかもしれません。経営層とはいえ、実際にデモンストレーションを行うことでより興味を持っていただけたようにも思います。もちろん、アプリケーションは完成ではなく、まだまだ改善を続けているのですが、今現在でも実際に使われており、経営層と現場層の両者にとって有益となるプロジェクトを達成できたと感じています。私自身、今後も重要な分析報告において、紙の資料だけでプレゼンテーションするのではなく、デモンストレーションを交えて再現性のある報告をしたいと思っています。

まとめ 

いかがでしたでしょうか？本記事では、データサイエンティストがモデルを開発しても、それが現場で使われるためには様々なノウハウが必要という話から始め、POCプロジェクトのアウトプットが紙の資料でしかないため、周囲の誤解を生むこと、さらに、その先に進むために、ウォーターフォール開発とプログラム納品という両極端な手法の2極化があることを紹介しました。それらの欠点を解決するべく、第3の打ち手としてダッシュボードによりデータサイエンティストのスキルセットで、短期間でモデルを現場適用する方法について解説しました。データサイエンティストが実務に直接貢献できる良い時代が来たように感じています。ただ、もちろんこれがベストプラクティスで、全ての開発をこれで行えば良いというわけではありません。特に基幹システムと連携し、数百万人が利用するようなミッションクリティカルな開発の場合は、この手段では耐えられないようにも思います。ただ、それもウォーターフォール開発として1から作り直すのではなく、ダッシュボード開発の延長線上に実現し得ないか検討中です。この領域に到達してはじめてフルスタックエンジニアと連携し、SI工程に進むのが良いと思います。これまでのソフトウェア開発の常識に捉われない、柔軟な発想を持ったプロジェクトリーダーが求められています。

また、ダッシュボードはいわゆるテストが全て通った検証済みのシステムではないため、外注する場合には、それによる契約形態の整備といった法的な整備も必要なようにも思います。この記事が、DX推進が机上のシミュレーションとプレゼンテーションだけで終わり、現場に接続されないことに対してお悩みの方々、あるいはそもそもどうのように進めるべきかお悩みの方々の一助となれば幸いです。
私は、データサイエンティストとしてキャリアをスタートしましたが、データサイエンティストは時代の流れとともに、評価が非常に揺らいでいる職種と言えます。
日本全土にモデルの現場装着が進み、データサイエンティストがプレゼンテーションのレポート屋でもなく、ウォーターフォール開発の部品でもなく、データサイエンティストのアウトプットが直接的にビジネス貢献できる時代を作っていきたいと思っています。

これからもこういったリアルな実態と、改善の工夫をお伝えしていきたいと思います。