機械学習プロジェクトの実地検証＆開発フェーズを推進するポイント

機械学習プロジェクトの流れ

機械学習プロジェクトは、企画、PoC、実地検証、開発という順序で取り組むのが一般的です。

そもそも、なぜこのようにいくつものフェーズに分けて取り組む必要があるのでしょうか？その理由は、機械学習プロジェクトがさまざまな「不確実性」を含んでいることにあります。

機械学習モデルはアウトプットに不確実性を含んでいるため、それを組み込んだシステムも通常のソフトウェアシステムと比べて不確実性が高くなります。企画段階で機械学習モデルを含んだサービスやシステムについて大まかな設計をしても、それが本当に実現できるのか判断できません。

そこで、PoC、実地検証、開発のそれぞれのフェーズで段階的に不確実性を解消していくアプローチをとることになります。

実際、機械学習プロジェクトの8割近くは失敗すると言われている¹ため、フェーズごとに機械学習プロジェクトの成否を見極めることで無駄な投資をしてしまうリスクを減らすことが重要です。

それでは、実地検証、開発のそれぞれのフェーズで気をつけるべきことや、実施すべき内容について具体的に紹介します。

【関連】アナリティクスエンジニアが、DX実現に向けて考えていること

注釈

1.Gartner, Inc. 2018年2月13日付プレスリリース「Gartner Says Nearly Half of CIOs Are Planning to Deploy Artificial Intelligence」による

実地検証フェーズでの取り組み

PoCフェーズでは、おもに機械学習モデルの精度検証を行い、モデルを活用することによってビジネス的な価値が生み出せるのかどうかを検証しました。しかし、PoCフェーズではあくまで過去のシミュレーションの中で評価を行っているに過ぎません。

実地検証フェーズでは、機械学習モデルを組み込んだ小さなシステム（プロトタイプ）を開発します。このプロトタイプを複数のユーザーに使ってもらい、使いやすさや性能を検証します。

実地検証フェーズで実施すべきことをまとめると、以下になります。

• 現場で活用できる小さなシステム（プロトタイプ）を開発する
• 性能を検証するため、本番レベルのデータ、環境、アウトプットを用意する
• 現場で使ってもらう、または通常業務と並列に動作させて使いやすさや性能についてフィードバックを得る

実地検証フェーズでは、改めて機械学習モデルの性能を検証することになりますが、PoCフェーズで設定していた評価指標の他にも、実際に使ってみると考慮しなければならない観点が見つかることがよくあります。

こういった観点はヒアリングしても導き出せないことがあるため、それらを改めて浮き彫りにすることも実地検証フェーズの大切な目的です。

開発フェーズでの取り組み

実地検証フェーズの結果、現場で使えるシステムが開発できそうだと判断されれば、開発フェーズに移行します。このフェーズはデータサイエンティストも協力する必要はありますが、主に機械学習エンジニアやソフトウェアエンジニアが担当する領域になります。

実地検証フェーズで開発したプロトタイプとは違い、本番用のシステムを構築するため、導入後の新しい業務フローを実現するためのすべての機能を開発します。

実際の業務ではミスやトラブル、イレギュラーがつきものです。それらを網羅的に考慮して実際の業務運用に耐えうるシステムを構築しなければなりません。

開発フェーズで実施すべきことをまとめると、以下になります。

• イレギュラーなオペレーションを含めた導入後の業務フローを改めて整理する
• 実地検証のフィードバックに基づく要件の再定義
• セキュリティや拡張性、保守性など、システムを運用する上で重要な観点を考慮したアーキテクチャ設計、開発、テスト、リリース

業務で利用するシステムとなると、実地検証フェーズでの「ひとまず動くようなプロトタイプ」ではなく、使い続けられる品質が求められます。つまり、一般のソフトウェア開発と同様に、セキュリティや拡張性、保守性、パフォーマンスなどの品質を考慮した設計が重要になります。

教科書通りに進まないプロジェクト

ではA社では、実際にどのようにプロジェクトが進められたのでしょうか。

私がA社のプロジェクトに参画したのは、PoCフェーズが完了して、本格的に開発プロジェクトが発足したタイミングでした。つまり、これから実地検証フェーズが始まるというタイミングでの参画でした。

今思うと、この時点ですでに問題があったのですが、これから実地検証フェーズが始まるという段階で、3ヵ月後には検証のための1次リリースが完了するというスケジュールが決まっていた状態でした。

このようにタイトなスケジュールになったのは、A社のご意向もあったものの、プロジェクトメンバーに機械学習のシステム開発に精通しているメンバーがいなかったことも要因でした。

ブレインパッド側のチームはデータサイエンティストを中心として構成されていたのですが、あくまで機械学習モデルを構築する専門家であり、機械学習モデルを組み込んだ複雑なシステムの構築に詳しいとは言えませんでした。本来は、機械学習エンジニアと呼ばれる職種もプロジェクトに加わり、データサイエンティストと協力してスケジューリング、および開発することが望ましいと言えます。

その後、スケジュールに間に合わせることが難しいと判明してからも、当初の予定を先送りにすることは難しく、なんとか期日までにリリースする必要がありました。

実際に業務で活用するためには、モデルの予測値をそのまま出力すれば良いわけではなく、さまざまな機能を実装する必要がありましたが、最小限の機能に絞って開発を行うことでなんとか期日に間に合わせることができました。

しかし、急いで開発したことによる問題が後に顕在化することになります。

密結合したシステム

1次リリースでは開発速度を優先するため、PoCの検証用のコードを流用して開発を行いました。

問題になったのは、この検証用コードの流用によりシステムが複雑化し、保守性が低くなってしまったことです。

実際の業務では、データの入力ミスやデータ連携エラー、予期せぬ不具合などにより、想定外のアウトプットを出したりシステムが一部停止してしまったりすることがあります。しかし、密結合したシステムになっていると、どの部分で問題が発生したか調べるのに時間がかかってしまったり、不具合を修正する際にも影響範囲を調べるのにさらに時間がかかってしまいます。

また、2次リリース以降では追加機能の開発やシステムの適用範囲を広げることに取り組んだのですが、その際の追加開発やテストに時間を要することになりました。

モジュール化がしっかりされた疎結合なシステムであれば、関連する機能をつかさどる部品だけをテストし、その後影響のある範囲をテストすればいいのですが、密結合なシステムでは追加開発した部分だけではなく、変更していない部分についても影響が出る可能性があるため、常に全体をテストする必要があります。

結果的にテストにかかる時間が増えてしまうのですが、これはシステムが大きくなるほど顕著になるため、だんだん開発効率が落ちていくことになります。

開発コストを抑えるために

システムがこのような状態になってしまった場合、最終的な解決策はリファクタリング（プログラムの外部から見た構造・動作を変えずにソースコードの内部構造を変更・整理すること）しかありません。

このままプロジェクトを進めると、長い目で見ると追加開発のコストが膨らむ一方だと説明した上で、2次リリース以降にリファクタリングのための時間を取っていただくことになりました。これにより、3次リリース以降は比較的順調に開発を進めることができました。

本来は実地検証フェーズと開発フェーズをきっちりと分け、開発フェーズの要件定義/設計において保守性・拡張性に優れたアーキテクチャを検討することが望ましいと思います。

スピード感とチームの重要さ

タイトなスケジュールでプロジェクトを推進するといろいろと問題が生じることは、A社としても覚悟の上でした。それは、A社に「DXを是が非でも成功させたい」「そうしないとこの先生き残れない」という危機感があったからです。

私が関わったプロジェクトはA社のDX事例としては最初期のもので、このプロジェクトが成功するかどうかが今後のA社のDX推進に大きな影響をもたらすものでした。このプロジェクトがさまざまな困難がありながらも成功したとなれば、自社のDXが一気に加速するとA社のトップ層は考えたのだと言います。

またスケジュールに追われながらも価値あるAIシステムが構築できたのは、A社の経営陣をはじめ、プロジェクトオーナー、AIを実際に活用する現場の担当者の協力によるところが大きいと感じています。

現場担当者の方はAI導入のためにどういう業務の仕方をすればよいかということを真剣に考え、マニュアルの作成やデータの整備に取り組んでいただけました。プロジェクトオーナーの方にいたっては、AI関連の書籍を自ら読んでキャッチアップし、開発したAIシステムの中身をご理解いただけていました。

また、ブレインパッドのメンバーも現場の業務をしっかりヒアリングし、ときには現場を実際に見せていただくことで、業務に対する肌感を磨くことに努めました。現場で業務を見ないと、本当は何が大変なのかがわかりません。また実際にシステムを使っていただくと、ヒアリングでは分からなかった課題が見えてくることもあります。

私もこの経験から、どんなプロジェクトでもまず現場の業務を理解することを大事にしています。

このプロジェクトは、機械学習プロジェクトの定石を外れて進んでしまったことにより、システムにいろいろな課題を残してしまったと捉えられるかもしれません。しかし、AI開発者と現場とのプロジェクトチームとしては素晴らしいものでした。また、ビジネス的な観点としても成功と言えるものであり、実際にA社内部では高く評価されています。

もちろん定石通りに進められることがベストではありますが、それより起こったトラブルに対して開発メンバー側と活用する側がチームとして協力して解決していくことが重要であると感じました。これも現場を信じて任せてくださったA社の経営陣の覚悟と熱意のおかげだと考えます。

データサイエンティストに求められる他職種のスキル

ここまで、機械学習プロジェクトにおける実地検証フェーズと開発フェーズについて、教科書的な一般論と具体的な事例に基づく解説をしてきました。DXなどではスピード重視になるプロジェクトも多く、必ずしも教科書通りに進みません。しかしその際も、アーキテクチャーについてはできる限り早い段階（できればPoCフェーズの前の企画フェーズ）で検討しておき、実地検証フェーズの直後にフィックスするのがよいでしょう。

最後にこのプロジェクトを通じて私自身が気づいたことを述べて締めくくりたいと思います。

データサイエンティストはシステム開発の専門家ではありません。データ分析や機械学習モデルの構築にあたってpythonプログラムを書きますが、実際のシステムではエラーハンドリングや例外処理といったことが重要になります。そういった処理は、機械学習モデルの開発だけの場合はほとんど出てきません。しかし、機械学習システム開発プロジェクトにおいては、機械学習モデルだけでなく業務アプリケーションも開発する必要があるため、システム開発に関わる知識がデータサイエンティストにも必要であると痛感しました。

またデータサイエンティストが分析を進める中で、汚いデータを処理しなければならないことに不満を持たれている方もいるかもしれません。しかしデータにはまず発生源があり、それにさまざまなオペレーションや処理が施されて、分析用のデータが生み出されます。そのオペレーションや処理を理解していると、より良い分析をするための前処理やオペレーション改善の提案などができるようになり、より高く評価される人材になれます。これは一般的にはデータエンジニアのスキルと言えますが、データサイエンティストもこうしたスキルを持つことで、市場価値が高まると言えるでしょう。

まとめ

本記事では、プロジェクトの現場で起きるさまざまなエピソードを交えながら、実例に基づき、機械学習モデル開発を推進するにあたってデータサイエンティストが取り組む内容や求められるスキル、大切な心がけをお伝えしました。

データサイエンティストには、AIを含めた最先端のテクノロジーをキャッチアップするだけでなく、今以上に業界ドメイン知識とビジネスプロセス知識が求められています。私自身、今後の自分のキャリアパスを考える中で、データエンジニアを経験してみるのもよいと思えるようになりました。

本記事を読んでいただいているデータサイエンティストの方々には、職掌を狭く考えずに、ITエンジニアやデータエンジニア、コンサルタント、場合によっては営業など周囲の職種のスキルから貪欲に学ぶことをお勧めしたいと思います。

関連記事

• 機械学習プロジェクトを推進するにあたって大切なこと～DX推進時の「企画・PoC」フェーズの落とし穴にはまらないために～
• アナリティクスエンジニアが、DX実現に向けて考えていること
• 【前編】データサイエンティストの強みをどのようにビジネス価値につなげていくか～キーワードは「2つの実コウ性」～
• DXプロジェクトの核、機械学習プロセスを成功させるためのチーム編成とは