DXプロジェクトの核、
機械学習プロセスを成功させるためのチーム編成とは

[執筆者]
桶原 葵

私は現在、主にPoC後のシステム化案件を担当しています。

以前、弊社栗原執筆の記事「機械学習プロジェクトを推進するにあたって大切なこと ~DX推進時の「企画・PoC 」フェーズの落とし穴にはまらないために~」で、「企画・PoC(Proof of Concept:概念実証)」フェーズでの注意点を紹介しました。

そこで今回は、PoCで適切な企画ができたという前提のもとで、機械学習プロジェクトのシステム化を効率よく進めるにはどのようなチームが必要かという点について筆者の経験をもとにお話しできればと思います。

淀みなく遂行することの難しさ

機械学習プロジェクトは一般的に上記の流れで実施されます。

この流れを淀みなく遂行することができれば、機械学習プロジェクトは成功といえます。
ただ、淀みなく遂行するのがなかなか難しいという問題があります。というのも、各プロセスで必要とされる技能が異なってくるためです。

例えば、

  • PoCでは対象分野の最先端の分析手法を理解し応用する能力
  • 開発では拡張のしやすい様にシステムを作り上げる能力
  • 運用ではシステムの問題をいち早く検知し対応する能力

といったものが必要になります。結果、それぞれのプロセスをそれが得意な企業や人に別々に依頼するという状況が散見されます。
「得意な企業や人に依頼しているのだから問題ないのでは?」と思われるかもしれませんが、これは誤りと考えています。なぜなら、こと機械学習プロジェクトで開発するシステムでは上記のプロセスが「互いに有機的に」つながり合っているからです。

これは機械学習プロジェクトが上記プロセスを一通りこなすだけで完了するものではなく、下記のようにプロセスの反復でフィードバックを得つつ、少しずつ改善を加えて完成度を高めていくという性質を持っていることによります。

この性質により、各プロセスでの変更が全てのプロセスに影響してしまいます。

そのため、変更が発生した場合、各プロセスを別の企業に依頼すると、プロセス間でコミュニケーションロスによる担当者間での認識のずれが生じます。これが一度のプロセスであれば大きなズレにならないかもしれませんが、反復のプロセスでは小さなズレがさらにズレを生み、雪だるま式にズレが大きくなっていきます。
結果、いつまでも機械学習プロジェクトの成果物が使える状態にならないといったことや、最悪、システム化前にプロジェクトの予算凍結といったことに発展してしまいます。

実際、PoC時に利用できる環境やデータセットと運用/開発時に利用できる環境やデータセットが異なることにより頓挫してしまうプロジェクトや、運用負荷を考慮しないまま行われたプロジェクトで運用負荷が増大し、反復のプロセスを回すことができなくなってしまうプロジェクトを数多く見てきました。

こういったことを起こさないようにするためには、どうすれば良いのでしょうか?
ここからは、筆者の経験をもとに機械学習プロジェクトを進める上で適切なチーム編成について紹介したいと思います。

機械学習プロジェクトのチーム編成

機械学習プロジェクトで筆者が経験してきたチーム編成には下記の様な編成があります。

  1. 「PoC担当者のみ」でプロジェクトを担当するチーム
  2. 「PoC担当者-開発者-運用者混成」でプロジェクトを担当するチーム
  3. 「プロジェクトの単一プロセスのみ」を担当するチーム
  4. 「全プロセスを俯瞰できるメンバー」でプロジェクトを担当するチーム

ここではそれぞれのチーム編成でのメリット、デメリットを示した上で筆者の考える適切なチーム編成について紹介します。

1.PoC担当者のみでプロジェクトを担当するチーム

こちらは、筆者が主にPoCを担当していた時に経験したチーム編成です。この編成では、基本的にPoC-開発-運用までを分析官のみで担当していました。
この編成のメリットは、分析官内で知識レベルが揃っているためコミュニケーションロスが少なく、素早くシステム化まで持っていけることです。

一方で下記のような問題が発生していました。

  • 開発の問題
    • 開発の知識がエンジニアと比較して少ないため、失敗のしやすい処理構成になってしまう
    • 新しいものを作る場合に常に0から開発する必要があり開発効率が悪い
  • 運用の問題
    • 処理が失敗した際のリカバリ手順が煩雑でリカバリまでに時間がかかる
  • その他の問題
    • 分析官のための開発サポートミドルウェアの導入により、新機能開発がミドルウェアにより制約を受ける

上記のようなデメリットが蓄積し、システムの失敗が多発し、最終的には業務が既存機能のリカバリをするという運用業務ばかりを担当するという結果になってしまいました。分析官が得意な分析〜新機能提案業務ができなくなり、苦手なリカバリばかりを担当するようになってしまったのです。

これは企業にとっても担当者にとっても、なかなかの悪夢といえるでしょう。

このチーム編成は機械学習プロジェクトの初期には魅力的な選択肢ですが、PoC担当者にスーパーエンジニアがいない限り上記のように技術的負債を積み上げることになります。
そのため、可能な限りこのチーム編成(特に分析官1人チーム)は避けるべきだと思われます。

2.「PoC担当者-開発者-運用者混成」でプロジェクトを担当するチーム

こちらは筆者がPoCと運用業務を兼任していた時に経験していたチーム編成です。

この編成のメリットは、それぞれの専門をもつメンバーが揃っていることにより、システム化を見据えた機械学習プロジェクトを素早く回せることです。

一方で下記のような問題を抱えています。

  • 知識共有の問題
    • 専門外の分野について最低限の知識共有が必要になるため、プロジェクト初期の立ち上げ時期に少し時間がかかる
  • リソースの問題
    • チームに専門分野をもつメンバーを張り付けるため、ある程度の余剰人的リソースが必要

上記のような問題はありますが、筆者はこの編成において最も良いパフォーマンスを発揮できました。

これは、専門性を持つチームメンバーと素早くコミュニケーションをとることでリカバリ等を素早くこなし、些事に気を取られることなく専門分野に集中することができたためです。また、異なる専門性を持つメンバーとの知識交換により知識レベルが上がった点も大きかったと思います。

初期の立ち上げに少し時間がかかる点、別々の専門性を持つメンバーが必要という問題はありますが、このチーム編成は非常に良い選択肢だと思います。

3.「プロジェクトの単一プロセスのみ」を担当するチーム

こちらはプロジェクトの開発プロセスのみを担当した際に経験したチーム編成です。PoCと運用のプロセスは別の企業が担当していました。そのため、自分の担当外のプロセスについては最低限の知識しか持っていない状態でした。

規模の大きいプロジェクトでは、こういった形で上記のプロセスを別々の企業が担当するということが多々あります。

この編成のメリットは、その時に必要なプロセスだけに予算をつけることができることによるコスト削減効果が大きいことだと思います。

ただ下記のような問題を抱えてしまいます。

  • 責任範囲の問題
    • 担当企業の責任範囲が担当プロセス内に閉じているため、プロセス内で個別最適な結果しか得られず、全体最適な結果は得られない
  • プロセスの境界やプロセスを横断した業務に関する責任範囲が明確ではないため、ここに起因する問題が多く発生する
  • コミュニケーションの問題
    • 知識の共有が取れていない別企業の担当者間でのコミュニケーションに非常に時間がかかるため、スケジュール遅延が多発する
  • プロセスの境界にある業務に関する認識の齟齬による手戻りが発生する

これらの問題は厳格なルール等を定めることで一見避けることができそうですが、発生しそうな問題の全てを事前に把握しておくことは不可能に近いため、多くの場合は後の工程で問題が表れます。

特に上記プロセスの反復である機械学習プロジェクトにおいては、経験上大きな問題に発展する可能性が高いです。

そのため、プロセスごとに別企業が担当するというこのプロセスは基本的にオススメしません。

ただ、自社に専門性を持つ人材を抱えていないということもあると思います。こういった場合には、プロセスごとに別企業へ業務を依頼するのではなく、複数企業から人材を集めてプロジェクト全体を担当するチームを作ることで、こういった問題をある程度回避できます。

4.「全プロセスを俯瞰できるメンバー」でプロジェクトを担当するチーム

こちらは現在のブレインパッドで一般的なチーム編成です。

専門分野に濃淡はありつつも、全てのプロセスに一定以上、専門分野に通じたメンバーを集めたチームになっています。

この編成のメリットには下記のようなメリットがあります。

  • リソースを余らせることがない
    • 専門家を集めたチーム編成では、専門外分野に問題が発生した際にリソースの「空き」や「待ち」が発生するが、この編成では問題に全員で取り組むことができるためリソースが余らない
  • 素早いPoC-開発−運用プロセスのサイクル
    • 各プロセスでの課題解決速度向上による高速化

問題の1つ1つにリソースを集中することができるため、各プロセスでの課題解決速度が向上する

  • プロセス間コミュニケーション省略による高速化
    • チームメンバー間で全プロセスに関する知識が共有されているため、余計なコミュニケーションを省くことができる

これらメリットのうち特に「素早くPoC-開発−運用プロセスのサイクルの高速化」は日々めまぐるしく変化するビジネス環境に適応し、DXの「データの活用を通じてビジネスを変革する」という目的を実現するために重要になってきます。当社ではこの実現に向けてこの編成を採用しました。

ただ、下記のような問題を抱えています。

  • 人員確保の問題
    • 全てのプロセスに一定以上のレベルで通じたチームメンバーが必要だが、そういった人材は少ないため獲得が難しい
  • リソースの張り付き問題
    • この編成では全てのプロセスを少ない人員で全てのプロセスを回すことになるため、貴重な人材が特定のプロジェクトに張り付いてしまう(他の編成と比較して全プロセスのサイクルは速いが、ある程度の期間は必要)

どちらの問題も人材の少なさに起因するものです。企業の内外を問わず、全プロセスに一定以上の専門分野に通じたMLエンジニア、データサイエンティストを多く抱えているのであれば、ワンチーム体制でこの編成にするのがベストだと思います。

終わりに

以上が、ここまでご説明した4つのチーム編成を簡単にまとめたものです。
今回は、筆者の経験をもとに機械学習プロジェクトを成功させるためにはどのようなチーム編成が望ましいかという点についてお話しました。どの編成にも、メリット・デメリットはあるため、この編成にすれば必ず成功するというものではありません。ただ、チーム編成は確実にプロジェクトの成否に関わる一要因ですので、プロジェクト立ち上げ時に是非ご一考いただければと思います。

(参考)
機械学習プロジェクトを推進するにあたって大切なこと~DX推進時の「企画・PoC 」フェーズの落とし穴にはまらないために~
【ブレインパッドが支援したDXの成功事例5選を紹介!①】業種・職種を超えて変革を起こすデータ活用の力
ブレインパッドが支援したDXの成功事例5選を紹介!【②】~食の安心・安全貢献、ビジネスモデルの変革、伝統技術の継承など~

WRITER執筆者プロフィール

株式会社ブレインパッド

アナリティクス本部
AIソリューションサービス部
桶原 葵

大学院修了後、Web広告配信会社にて広告配信最適化業務を担当。2020年にブレインパッド入社後は、機械学習を用いた需要予測システムの開発案件やサプライチェーンの最適化案件案件に従事。

MAIL MAGAZINEメールマガジン

イベントやセミナーの開催予定、
最新特集記事の情報をお届けいたします。

TREND人気ワード・タグ

BEST PRACTICEベストプラクティス

業態・業種から探す

テーマから探す

データ活用のプロが考える、エンジニアリング視点の記事や、新規ビジネスの創出に関する記事まで幅広い特集を配信!

業界の最先端をいく、100名を超える当社に在籍のAIおよびデータ活用スペシャリストが原稿を執筆!

ベストなDXへの入り口が見つかるメディア

DOORS

BrainPad

MAIL MAGAZINEメールマガジン

登録が完了しました。

メールマガジンのご登録ありがとうございます。
最新特集記事の情報をお届けしますので、
お楽しみにお待ちください。

MAIL MAGAZINEメールマガジン

登録エラーです。