【連載】機械学習システムによる、継続的なビジネス成果を生み出すとは~データ活用の社会実装と業務に繋げるアナリティクスアプリケーション開発~

データ活用をシステム面から支援するデータエンジニアリング本部(通称:DE本部)の魅力に迫るべく、ブレインパッドに転職した中途入社社員の声をお届けする連載企画。今回は、データ分析の社会実装を担うアナリティクスアプリケーション開発部の紹介です。

こんにちは。人事部の島﨑です。

インフラ老朽化問題に対峙するDX「護岸(河川の堤防)の劣化検知サービスの実装」、
材料開発・研究を加速させるDX「材料分析・データ解析クラウドサービスの開発支援」、
LPガス業界の後継者・人手不足にアプローチするDX「配送最適化サービスの実装」、
月3,000時間の登録作業短縮に成功した、不動産業界のDX「賃貸物件の画像分類システムの実装」...
など、さまざまな業界が抱える課題の解決や革新に向けて、ブレインパッドは”ビジネス実装”をとても大事にしている会社です。

一方、世の中の機械学習プロジェクトの現状は、そのほとんどが社会実装されずに終わるとも言われていますが、当社はデータサイエンティストやエンジニア等が双方にデータのプロとして連携してきた歴史があるからこそ、多くの事例を生み出すことが出来ているのだと理解しています。
今回は上記リリースをはじめ、機械学習システムの実装事例をいくつも生み出してきたアナリティクスアプリケーション開発部(通称:AA部)の紹介記事となります。鈴木部長自ら、機械学習/分析システムの実装の”今”はもちろん、これまでの歴史や今後についてなど、さまざまお話しいただきました!

ブレインパッドのAA部について

──本日はよろしくお願いします。さっそくですが、アナリティクスアプリケーション開発部(通称:AA部)について教えてください。

AA部は、機械学習をはじめとしたデータ活用を業務に繋げるアプリケーションを開発し、世の中に価値を提供することをミッションとしたチームです。
意外と知られていないと感じるのは、機械学習システムがリリースされた事例は世の中にたくさんあっても、それがビジネスとして価値を認められているのかどうかの事例はまだまだ少ないということです。
機械学習システムは、リリースして終わりではなく、リリース後に運用しながら価値を生み出していくのが、スタート地点になると私自身は思っています。

──機械学習システムのリリース後がスタート地点になるとは、どういうことでしょうか。

システムを作って終わりではなく、機械学習のロジックを使って継続的なビジネス成果を生み出すことがシビアに求められるように市場が変化しているということです。
下記図は、機械学習プロジェクトのプロセスを簡単に表現したものになるのですが、私がブレインパッドに入社した当時(2016年頃)は、機械学習プロジェクトは研究的な立ち位置が多く、実地検証がメインでした。
その後、AIや機械学習といったものが世の中に広まっていく中で、徐々にプロトタイプの開発まで進むようになり、数年前からビジネス活用を前提としたプロジェクトが増えました。今現在は、本格開発・運用フェーズまで支援範囲が広がっています。
業務で使われ続けるシステムを実装し、またビジネスとして評価を受けて初めて、私達のミッションである”世の中に価値を提供すること”が叶った状態になると思っています。

AA部の歴史

──市場の変化に合わせて、求められるフェーズも変わってきたということですね。エンジニア組織がどのように進化してきたのかも教えてください。

はい。私が入社した当時、研究開発的な機械学習プロジェクトが多かったというのは前述の通りですが、組織的にもデータサイエンティストとエンジニアの体制はほぼ出来ていない状態でした。データサイエンティストがそのままシステム領域まで対応しており、別の開発を対応しているエンジニアが兼任でサポートするといった感じです。
実は、私がブレインパッドに応募したのは自社製品の「Rtoaster(アールトースター)」のエンジニア募集だったのですが、機械学習プロジェクトの専任エンジニアとして入社しました。

──え!Rtoasterの開発エンジニアに応募されてたのですね!初耳です!

いつの間にか機械学習プロジェクトのエンジニア配属になっていました(笑)。
というのは冗談で、採用過程で私の適正を見ていただき、機械学習プロジェクトで専任エンジニアを必要としていたこと、またシニアなエンジニアメンバーがいなかったことから、ポジション変更を提案いただいて、快諾したのが配属の背景になっています。
これまで分析のモデル開発で終わっていたプロジェクトに対して、エンジニア専任としてシステム開発・運用体制を構築していく必要があったのですが、当時はやることも全く決まっておらず、0からのスタートでした。

──機械学習プロジェクトにおける開発体制をつくるところからスタートされたのですね。

はい。私の入社当時は、エンジニアも分析に対する理解が足りず、データサイエンティストもシステム開発のセオリーが分からなかったため、うまく連携が取れていない状態でした。また、クライアント側においても機械学習のシステム化を実践できる企業はほとんどいない時代だったため、ある意味、失敗が許された時代とも言えるのですが、顧客と社内双方にプロジェクトの進め方から整理する必要がありました。
初めは設計書(ドキュメント)ベースで整理しようとしましたが、試行錯誤の結果、ルールで縛るのではなく、データサイエンティストとエンジニア双方の考え方をプログラム的に共有できた方が連携できると考え、データサイエンティストと共に学びを共有しながら、サンプルプログラムを作成しました。

──サンプルプログラムとは、どのようなものなのでしょうか?

サンプルプログラムは、マイクロサービスのアーキテクチャをベースとしたプロトタイプ開発を2週間程度で完了することができるものです。また、顧客の要望に変更があったり、良い結果が得られなかった場合は、いつでもPoCフェーズに立ち戻れる仕組みにしました。機械学習プロジェクトは通常の要件が定まっているシステム開発と違い、不確実性が高い機能の開発になるため、ユーザの意見を元に、フィードバックループを繰りかえすことができるのは、とても重要なプロセスになります。

──データサイエンティストとエンジニアが共通のプロトタイプを使いながら、いつでも分析のPoC段階から修正できるようにしたということですね。

そうです。プロトタイプをベースにしたプロジェクトの進め方は、顧客との調整においても最適でした。まずプロトタイプによって顧客側でもシステムのイメージを掴めることができるようになりました。次に、クライアント企業内でもいろんな立場の関係者がいるため、関係者間の合意を得やすくなりました。
ただこの”合意を得る”という部分は、各関係者の要望通りにとにかく作れば良いということではなく、各関係者のビジネスニーズを満たしているのか?、現場業務との整合性は取れているのか?といった点も見落としてはいけません。
機械学習システムの不確実性が高いとはそういったものを意味しています。

──機械学習システムの”不確実性”について、もう少し具体的に教えていただけますでしょうか。

例えば、レンタルビデオ会社の支援で需要予測システムを開発した際、予測モデルとしては品質の良いものができたのですが、実際に店舗の人に使ってもらおうとした際、「売れる商品の予測が当たったとしても、その通りにできない」と指摘を受けました。仮に、商品が2つ売れると予測結果が出たとしても、メーカーに「2つだけ商品を購入したい」とは言えないということです。メーカー側はなるべく購入して欲しいため、「人気商品になるので、最低4本は購入してください」と交渉があるかもしれませんし、店舗側も品揃えとして人気商品だけを陳列する訳にはいかないかもしれません。
このように、店舗、メーカーそれぞれの観点を考慮しながら、機械学習システムをどうビジネスに組み込むのか?といった決定はクライアント企業の判断によっても変わります。
一方で、いろんな要望を汲んでカスタマイズを増やしてしまうと、分析モデルが意味をなさなくなる可能性もあります。機械学習プロジェクトは、このバランスを取ることが難しく、それ故に不確実性が高いと言えると思います。
実際に、機械学習プロジェクトでは、プロトタイプを作っては、業務に必要なモデルとしての精度・処理速度をユーザと何度も検討することになります。ただ単に、アジャイル開発をすれば良いのではなく、機械学習システムが顧客によって良いものになっているのかどうかを見極めながらの開発になるため、あえて私はアジャイル”的な”開発スタイルとも呼んでいます。

データエンジニアリング本部 アナリティクスアプリケーション開発部長 鈴木さん

──プロジェクトの進め方、ビジネスの要求整理だけでも大変なハードルがあるのだと理解できました。技術的には、どのように進化してきたのでしょうか?

初期の段階では、クラウド技術を活用している会社も少なかったため、Google Cloud、AWS、Azure等、各クラウドサービスの検証をよく行っていました。
その後プロジェクトが増える中で、システム運用における、データ運用やセキュリティ観点等をクラウドのPaaSのサービスではカバーしきれない点と、クラウドロックインによるさまざまな環境での技術再活用が難しいことがあり、Kubernetes を利用したコンテナオーケストレーションツールや、Web APIを使ったマイクロサービス化を行いました。

──KubernetesやWeb APIを採用したのは、なぜですか?

Kubernetesについては、クライアント企業の利用する環境がさまざまな中で、各プロジェクトで使用した技術の転用ができるためです。プロジェクト毎に使用するクラウドが異なると、その都度、技術検証が必要になりますが、Kubernetesを利用したコンテナオーケストレーションツールを使うことで、クラウドネイティブの要素技術を採用した変化に強いサービス基盤を構築できます。Web APIは、API毎に機能が独立しているため、機能修正を行っても影響範囲が少なく済みます。汎用性が高いもので作ると、ベースから作り直さなければならず、フィードバックループを素早く繰り返すことができなくなるため、Web APIを使うことで、一部の修正で対応できるようにしました。
今は支援実績も増え、リリース後の運用改善フェーズのプロジェクトも多くあるため、ビジネス成果がより求められる中で、より良い方法や技術については、常に模索し続けると思っています。

──継続的なビジネス成果を目指すなかで、鈴木さんが感じているプロジェクトの難しさとは、どんなところにありますでしょうか?

不確実性の高い機能の開発になるという点は、今も昔も変わらず、機械学習プロジェクトならではの難しさだと思います。レンタルビデオ会社の事例にあったように、予測モデルが「この商品しか売れない」と結果を出すことはできても、メーカーとの交渉や品揃えの観点をカバーすることはできません。逆に、人の考えを取り入れるような仕組みにすることもできますが、機械学習システムを導入して業務が増えてしまったら本末転倒です。
機械学習は万能だと思われがちですが、人を超えるAIはまだできていないのが現状です。機械学習でできること・できないことを適切に説明し、ビジネスの仕組みとしてどのように組み込むと良いのかを顧客と一緒に見極めていくことがとても重要になりますが、そうした説明を言語化できるのは、機械学習プロジェクトを繰り返す中で、失敗も含めて経験がある人でないと難しいかもしれません。”継続的なビジネス成果を目指す”という点では、より短期間でリリースすることが求められるようになっているため、プロジェクトの難易度は、より上がっていると思います。

──短期間でのリリースが求められることによって、何が難しくなっているのでしょうか?

1つはプロジェクトの体制構築です。プロトタイプ開発がメインの時代は、開発に4-5年かけても問題ありませんでしたが、今は1-2年で成果を求められるようになりました。そうすると、これまで1-2人のエンジニア体制だったのに対して、プロトタイプ開発で3-4人、本格的な開発フェーズで20人程度のエンジニアが必要になっています。AA部のメンバーも、ここ3年で20人弱の組織に成長し、データ・MLパイプラインに強いメンバーもいれば、インフラに強い、アプリケーション開発に強い等、さまざまなメンバーが在籍しています。
次に、チーム開発に伴って難しくなるのが”コミュニケーション”です。これまでは少人数での開発だったので、フィードバックを繰り返すことで自然とチーム内の生産性を上げることができましたが、短期間でチーム開発を行う場合、コミュニケーションの不一致が起こりやすくなります。中規模以上のプロジェクトが増えていくなかで、チーム内の生産性をどのように上げていくのか?については、今の私達の課題だと思っています。

AA部の今後について

──現状の課題についてもお話しいただきましたが、今後の展望についてもお聞きして良いでしょうか?

クライアント企業側でも自ら分析モデルを開発するケースが増えてきたため、社内のデータサイエンティストだけでなく、顧客側のデータサイエンティストやユーザと一緒に実ビジネスへの適用を推進していきたいと思っています。専門的な知識が無くても機械学習の利用が一般的になってきたのは良いことですが、まだまだシステムと機械学習を両輪としたアプリケーションを開発し、プロダクションレベルの品質に引き上げることのできる企業は少ないと思います。あとはやはり社内のチーム作りでしょうか。

──よりクイックに機械学習システムを実装するためのチーム作りでしょうか?

そうですね。世の中的には、機械学習プロジェクトにおけるアプリケーション開発を行う会社は増えたものの、プロトタイプレベル、もしくは、機械学習向けのクラウドサービス等の製品を導入するだけで顧客の要求をしっかり満たしていない開発レベルのものが多いと感じています。不確実性の高い開発はリスクも高いため、大規模なシステム開発を得意としている会社には難しく、逆に小規模でアジャイル開発を得意としてる会社だとしても、システムのスケーラビリティ、パフォーマンス、セキュリティ、相互運用性といった品質を保つような開発プロセスが確立されているとは限りません。
”システムのリリース”をゴールにせず、”ビジネス×エンジニアリング”で価値を生み出す組織として、一緒に学び、進化し続けることができる人と一緒に働けると嬉しいです。

──本日はありがとうございました!機械学習プロジェクトは技術的に難しい印象もありましたが、クライアント企業のビジネスを理解し、業務で利用され続けるアプリケーション/システムを実装しなければならない難しさについてもよく理解できました。今後もインタビューを実施していきたいと思います!

ブレインパッドでは、アナリティクスアプリケーション開発部はもちろん、さまざまな職種を積極的に採用しています。ご興味がある方はお気軽にご連絡ください!

■データエンジニアリング部の紹介資料
speakerdeck.com

■ ブレインパッドの求人一覧
www.brainpad.co.jp