LIFULL Creators Blog

LIFULL Creators Blogとは、株式会社LIFULLの社員が記事を共有するブログです。自分の役立つ経験や知識を広めることで世界をもっとFULLにしていきます。

「データサイエンスの社会実装」を成功に導くプロジェクト・マネジメントについて考える

 こんにちは、LIFULLでData Analystとして働いている竹澤です。社外では、MediumのTowards Data ScienceでContributorとして寄稿したりしています。

 2020年私は主にデジタルマーケティング領域で効果検証の自働化や異常検知ロジックの開発、DXプロジェクトの立ち上げに携わってきました。

 今回はデータアナリティクス/データサイエンス・プロジェクトにおけるマネジメント論の整理を試みます。あくまで私見の塊(いわゆるオレオレ)ですが。

想定読者としては、Data Analyst、Data Scientist、DXプロジェクトのPMなどデータサイエンス及び分析プロジェクトに関わる全ての人を考えています。

はじめに

 突然ですが、あなたは「ビジネスにおけるデータサイエンスの本質的価値とは何か?」という問いに対してどう回答するでしょうか。

 私は個人的に、以下の言葉でその価値を定義しています。

”データサイエンスの価値は「プログラムに対する意思決定の権限委譲」である”

 なぜ、意思決定を権限委譲できることをビジネスの価値と定義できるか。

その理由は、「ビジネスは、Decision Making(意思決定)とExecution(実行または製作)の2つで支配されている」という論拠がまず根底にあります。

 そして抽象度を極限まで上げた場合、頭を動かして「考える」時間と手を動かして「実行」したり「作る」時間に分けられるということです。

 その上で、人間にとって難易度が高いあるいは時間を要する意思決定が存在したとして、それらをアウトソースできることは十分価値があると考えています。

具体例として、製造業の検品においてディープラーニングを用いた異常検知(画像認識)はまさに人間の目視による判断をより高精度でリプレイスするケースなど。

 あるいは似た言葉として、トヨタ生産方式(TPS)で提唱されている「自働化(ニンベンのついた自動化)」のニュアンスに近い概念だと考えたりします。

 以上が情報技術の専門家ではない私が、純粋に問題解決の1ソリューションとしてデータサイエンスという大きな仮説に賭けてきた背景です。

なぜ書くか

 前述した通り、私はデータサイエンスの問題解決能力を信じていますが一方で現実世界では、それを否定するようなファクトが目に付きます。

 つまり、現状の課題として自社を含めた日本のビジネス現場におけるデータサイエンスを用いた問題解決が思うように進んでいないと考察しています。

 今回はその原因の1つしてデータサイエンスプロジェクトにおける「マネジメント手法の未整備」にあると仮定し、その解決策を検討します。

 その上でまずは、データ分析プロジェクトという大きな括りの中におけるデータサイエンスプロジェクトの位置付け、各プロジェクトの進み方を確認し、プロジェクトがクローズするような潜在的リスクを検討していきます。

 その他、ITプロジェクトにおけるPM論は既にある程度体系化されていますが、データサイエンスプロジェクトはそうではない現状に対する問題意識があります。

 また最近は特に、データサイエンスプロジェクトの遂行過程に潜む不確実性を対処するには、モデリングの能力以外のリソースの必要性を実感しています。

 以上から、過去の業務経験を抽象化することで未来のプロジェクトに応用可能な、汎用的フレームワークへと昇華することを検討してきました。

 まだ全く完成系ではないですが、未来への足跡として今回は現時点での限界(一次結論)を残します。

分析プロジェクトの種類と目的の違いについて

 ここでは、プロジェクト・マネージャー(以下PM)の視点から個人的な分析プロジェクトの分類の提案とマネジメント・スコープの明確化に取り組みます。

 まずは「分析プロジェクトの分類」について見ていきます。

 結論から言うと、私は「データアナリティクスプロジェクト」と「データサイエンスプロジェクト」の2つにデータ分析による問題解決を区別しています。

そもそもなぜ分類が必要かというと、問題解決の種類によってプロジェクトの全体像や体制、必要なリソースが大きく変わるという結論に経験上至ったからです。

 以降では、両者の違いをより鮮明にしていきます。

データアナリティクスプロジェクトとは

 前述した通り、私はデータサイエンスの価値を、「プログラムに対する意思決定の権限委譲」と定義しています。

 よって、シンプルに上の定義域に収まると認識している問題解決はデータサイエンスプロジェクト。それ以外をデータアナリティクスプロジェクトとしています。

 データアナリティクスプロジェクトの特徴は、データ分析を使ったアドホック的(一時的)な問題解決であることです。

 具体例としては、統計的仮説検定によるABテストの効果検証やKPIダッシュボードの作成などが該当します。ここでは「意思決定の支援」までが責務となります。

 詳細はこちらの記事に譲りますが、「意思決定の支援」においては組織の意思決定に求められる品質には「正確性・速さ・納得感」の3つがあります。

 なので、その3つのうちどれかを引き上げることが目的(価値)となります。

データサイエンスプロジェクトとは

 データサイエンスプロジェクトの特徴は、継続的かつ定期的に訪れる意思決定をプログラムが肩代わりするような問題解決であることです。

 具体例としては、コンテンツのレコメンドシステム開発やサーバーメトリクスに対する異常検知、画像認識技術によるモノの判別自動化などが該当します。

 つまり、「誰にどのコンテンツをどの順番で見せるか?」というレコメンドTaskのように、定型的な意思決定の機会が何度もイテレートするTaskがサービスのバリューチェーン上に存在するとき、それらを代行するシステムの開発が目的です。

 そして、データサイエンスプロジェクトの責務が「意思決定の代行」であることはプロジェクトの難易度の高さに直結します。

 まずは、品質(Quality)の問題。「同じ時間で人間(既存機能)よりも高い精度」あるいは、「より短い時間で人間(既存機能)と同水準の精度」のどちらかを満たすタスク遂行能力がアウトプットの品質としてほぼ常に要求されます。

 また、機械学習ライフサイクルのスケール化を目的とするMLOpsの領域は、業界全体でベストプラクティスを探っている途中にあります。

 以降ではデータアナリティクス/サイエンスプロジェクトそれぞれのプロジェクト・マネジメントにおけるMethodologyを整理していきます。

データアナリティクスプロジェクトにおけるPM論

 まずは、私のようなData Analystといった職種の主な責務であろう、データアナリティクスプロジェクトにおけるマネジメントについて見ていきます。

 私はLIFULLに入社してから約1年半、CausalImapctを使ったTVCMの効果測定やABテストに対する有意差検定、事業KPIをモニタリングするためのDashboard作成など多様なアナリティクスプロジェクトに伴走してきました。

 本質的にはその役割を、「今回のTVCMはうまくいったのか?」や「このUIの変更はサイトKPIにポジティブだったか?」などの問いに定量的(統計的)なアングルから新たな知識を創造する、「意思決定の支援」業務と捉えています。

 そのため、上記は全てアドホック的(一時的)に発生する問いに対しての問題解決なることが多く、消費期限(使用期間)が長くても半年ほどです。

 以降では、データアナリティクスプロジェクトを以下3つの観点から整理します。

  • プロジェクトのプロセス(進み方)
  • プロジェクト遂行に必要なリソース(スキル)と主な担当職種
  • プロジェクトがクローズ・振り出しに戻るリスク

 なお、後述するデータサイエンスプロジェクトでも同じ整理をします。

プロジェクトのプロセス(進み方)

  • ヒアリング: ステークホルダーにInterviewを行い、要求や解決すべき真の問題と制約条件(非機能要件)を見極めるために情報収集をする
  • 要件定義: 今回の問題解決の全体像を整理するため、背景・目的・課題・原因・解決策などをドキュメント化。ステークホルダーや納期もここに記載
  • データ抽出: 検証や分析に必要となるデータを、DBやDWHからSQLを使って抽出。検証内容によっては、社外のデータを使用する
  • 分析集計: LIFULLでは、分析イシューを現状調査・課題発見・効果検証・予測判別の4つに分類し、適切な解決策(統計手法)を選定
  • 結果説明: TableauなどのBIによる結果の可視化と、その解釈を記載。ビジネスサイドに伝わる言葉でのStory Tellingが求められる

プロジェクト遂行に必要なリソースと主な担当職種

  • プロジェクト管理機能: Project Manager(Data Analyst)
  • データ分析機能: Data Analyst(Data Scientist)
  • 分析レビュー機能: Data Analyst(Data Scientist)

 ただし、A/Bテストの効果検証などの比較的小規模な案件の場合、データ分析者が要件定義などの上流設計から分析まで一気通貫で行うことを想定しています。

 実際にLIFULLでも、上記のアナリティクスプロジェクトと分類される案件のうち8割は、1人の人間がレビュー以外の全プロセスに実行責任を負っています。

プロジェクトがクローズ・振り出しに戻るリスク

  • 問題設計のリスク: ステークホルダーが真に行いたい意思決定が曖昧なまま分析を進めると、付加価値のない分析に人件費をかけることになる
  • 説明可能性のリスク: 分析結果をステークホルダーが咀嚼しきれない問題を解消するために、解釈性に優れた解決策(統計手法)の選定が求められる
  • 役割分担のリスク: 分析の品質(正確性)を担保するために適切なレビュワーの配置や、検証内容が複数ある場合の最適な役割分担を設計する必要がある
  • 計画進捗のリスク: 書くまでもないが納期を守るために、同時並行で進む他のプロジェクトも管理する必要がある。自分の力量にあった納期の設定が大切

 上記では、あえてジェネラルな問題解決における落とし穴を列挙しました。

 その意図は、個人的に汎用的な問題解決能力こそが分析のValueを最大化すると考えているからです。(もちろん統計などのある程度の理解は当然だとして)

 また、予算が大きいTVCMの効果検証などの事業上重要かつ手持ちの統計手法で解決可能な問題を見極めるスキル、つまりイシューから始める力も重要です。

 以上で、データアナリティクスプロジェクトの進み方や、潜在的なリスクへの対処に必要となるスキルについての考察を終わります。

余談:統計的因果推論の価値について

 LIFULLのData Analystたちは、特に近年注目度の高い(統計的)因果推論の領域にフォーカスし、様々なチャレンジをしてきました。

 その背景には、「派手な予測モデルより、因果関係の実証の方がビジネスの現場で必要とされる頻度が高いだろう」という仮説(スタンス)があったからです。

 例えばA/Bテストにおいて、p値を用いる必要がある頻度主義の仮説検定ではなく、ベイズ主義に基づく仮説検定を導入しました。

 また、前後比較に対する回帰分析を用いた差分の差分法(DID)。時系列データに対するグレンジャー因果検定やCausalImpactによる効果測定を行いました。

 このように、Webサービス開発や事業運営で遭遇する効果検証に対して、多様な統計手法を適応することで組織への価値提供に努めてきました。

データサイエンスプロジェクトにおけるPM論

 次に、Data ScientistやML Engineerといった職種の主な責務であろう、データサイエンスプロジェクトにおけるマネジメントについて見ていきます。

 ここではいわゆる「機械学習プロジェクト」を想定して、整理していきます。

 ただ繰り返しになりますが、私の中のデータサイエンスプロジェクトの本質は「プログラムに対する意思決定の権限委譲」にあると考えています。

 なのでアルゴリズムの中身がML/DLかは必要条件であり、人間の意思決定のリプレイス(単なる「作業」の自動化ではない)に価値があることを強調します。

 また筆者である私は、現時点で機械学習プロジェクトを完遂した経験(プロダクション環境におけるデプロイ・運用保守)はまだありません。

 なので今回は、自社における未来のデータサイエンスプロジェクトに備えることを目的としてPMが把握すべきリスクをまとめます。

 特に私が実務経験のない効果検証以降のプロセスは、「仕事ではじめる機械学習」の著者である有賀さんのMLOps の歩き方などを参考にさせて頂きました。

スコープ:書かないこと

 今回はあくまで、プロジェクト・マネージャー(PM)視点でのプロセスの抽象化やリスクの列挙になります。

 なのでData Scientist視点でのモデリング過程の詳細や、Software Engineer視点でのエンジニアリングにまつわる技術的な諸問題は取り扱いません。

 また、自社でWebサービス(アプリケーション)を持つ事業会社における、インハウス開発を想定しています。なので、QCDにおけるCDへの配慮等は手薄です。

プロジェクトのプロセス(進み方)

  • 要件定義: まず機械学習をしない方法も検討した上で、Problem/Solution Fit(PSF)の理論的な妥当性を確認。またプロダクション環境での非機能要件とステークホルダーの体制の明確化、利用するローデータの確認も忘れない
  • 概念実証(PoC): 学習データに対するEDAの結果をもとに、前処理や特徴量選択を行い、アルゴリズム候補を選定。RMSEなどの精度指標を用いたオフライン検証によって、最終的なモデルを(複数)選択
  • 効果検証: プロトタイプ化した機械学習モデルを本番環境へデプロイ。本番トラフィックの一部を利用してA/Bテストなどを行い、ビジネスKPIを基準に既存手段との比較・評価を繰り返して本番適応の意思決定をする
  • 本番開発: リファクタリングやワークフローのパイプライン整理、またシステムデザインや各クラウドコンポーネントを最終決定。単体テストと統合テストだけでなく、入力データの分布等に変化がないかも確認が必要
  • 保守運用: 機械学習モデルの精度やビジネスKPIだけでなく、レスポンスタイム等のシステムメトリクスなどの指標も監視する。また、CI/CDのみならず継続的トレーニング(CT)が実行できる環境を整備する

プロジェクト遂行に必要なリソースと主な担当職種

 前述の通り、以下では事業会社における機械学習プロジェクトでの理想的なプロジェクト体制について検討していきます。

  • プロジェクト承認機能: Project Owner(Business Manager)
  • プロジェクト管理機能: Project Manager
  • アルゴリズム開発機能: Data Scientist(Machine Learning Engineer)
  • 本番開発機能: Machine Learning Engineer(Data Scientist)
  • 保守運用機能: Software Engineer(Machine Learning Engineer)

 補足としてアルゴリズム開発以降の後半3機能は、こちらの記事におけるDevelop・Deploy・Driveの3プロセスの責務に対応するイメージです。

 そして、とても重要だが十分にその必要性が検討されていない機能(体制)は、1番目と5番目の役割です。

 「プロジェクト承認機能」とは具体的に、デプロイ先のプロダクトが生み出すビジネス成果(コンバージョンなどのKPI)に責任を持つBizDevの人です。

 また「保守運用機能」とは、機械学習システムをデプロイ対象となるプロダクション環境のドメイン知識を持った開発者を指しています。

 これらの人々は社内のMLチームの”外”にいる場合が多いですが、彼らの積極的合意がなければ、不確実性の高いMLモデルの本番適応は難しいです。

 なので彼らをいかにプロジェクトの適切な段階で巻き込むことできるかが、小さな(大きな)失敗を許容してもらう上では非常に大切です。

 その他にも、仮にビジネスKPIを改善できたとして、MLのデプロイはシステムに対してほぼ確実にさらなる技術的負債や不確実性を積むことになります。

 そうなるとプロダクション側の開発者に旨味がなく、また運用保守の精度を保証する術も無いため、最終的な受け入れ拒否に繋がりかねません。

 こうした問題への対処や交渉のために、2番目の「プロジェクト管理機能」の存在が重要になります(こちらも軽視されがちですが)。

 総じて、スクラム的な顧客一体型の開発体制やPMの配置が、プロジェクト後半の受け入れ拒否のリスクを最小限に抑えたる上で重要かと思います。

プロジェクトがクローズ・振り出しに戻るリスク

  • 役割分担のリスク: モデル開発やETL処理のパイプライン化、インフラの選定、本番環境への結合とそのテストなどやることと求められる知見幅が非常に広い。しかし、PoCを乗り越えることすら不確実なため、プロジェクトの立ち上げ期からそのリソース確保や体制を確立することが難しいのが実情
  • 推定精度のリスク: いわゆるPoC死や効果検証フェーズでの敗北。新しいモデルの精度不足または既存手段を上回れないことの方が多い
  • 非機能要件のリスク: MLチームにとっては暗黙知的な本番環境で要求されるシステムの制約や、レイテンシーやクラウドの費用、セキュリティ要件を満たせるかなどの一般的な非機能要件も早く正確に認知する必要がある
  • データ依存のリスク: CACEの原則。機械学習モデルの振る舞いは、入力データに依存して決まり、データ自体(分布)も時間の経過に従い変化しうる
  • CI/CD/CTのリスク: ローンチ後にKPIや推定精度が下がった際に、どう解釈(説明)するか。常に最新のデータに適応した、最良のモデルであることを担保するための環境の整備が難しい

 上記以外にも、システムデザインの選定や決定的テストの難しさなどの私の知見不足でまとめられなかった難関は他にも多数存在します。

 これらに関しての解決策は、MLOpsの歩き方やGoogle社によるこちらの記事内でいくつか提案されています。

MLOps: 効率的な開発を阻害する要因

 プロジェクトがクローズとまではいかないものの、機械学習プロジェクトに「遅延」をもたらすお馴染みの課題は上記以外に存在しています。

  • テスト環境と本番環境の違い: Jupyter Notebookに書いた前処理や推定のプログラムをパイプラインにまとめたり、クラス化し直す必要がある
  • バージョン管理が必要な対象の広さ: 学習に使用したデータ・アルゴリズム・ハイパーパラメータ・評価指標をセットで管理する必要がある
  • パイプラインのジャングル化:MLパイプラインの乱立により、システムを占めるグルーコードの比率が肥大化し、メンテナンスが困難になる

 これらを解消するために、機械学習ライフサイクルのスケーラブルな運用を可能にするMLOpsツールが日進月歩で開発されています。

 ツールは大きくハイパーパラメータ管理、実験管理、パイプライン(ワークフロー)管理の3つのカテゴリーに大別でき、カテゴリーと具体的なOSSの対応についてはこちらの記事が非常に参考になります。

 一方で、ツールの比較・検討をプロジェクト中に行うような余裕は基本ないため、自社におけるMLOpsツールの選定をいつ行うかは工夫する必要があります。

 ツール以外にもデータサイエンスプロジェクトとアジャイル開発がどう溶け合うかなど開発スタイルに関する議論も個人的には面白いトピックだと感じています。

さいごに

 今回はプロジェクト管理の視点から、LIFULL発の「データサイエンスの社会実装」の成功確度を高めるアプローチを模索してきました。

 改めて執筆すると、技術的な理解の甘さを痛感しました。やはりテストやCI/CDは実際に手を動かしてみないと解像度が上げられないと思いました。

 LIFULLでは、キャリフルという社内副業制度があるので、エンジニアリングの職種に応募してDevOpsやマイクロサービスなどを手を動かして体感する機会をぜひ作りたいと考えています。

 今後もData ScientistやML Engineerたちにとって、伴走しがいのあるパートナー(PM)になっていけるよう毎日の業務で成長していきます。

 LIFULLのアナリティクスチームは、上記のデータアナリティクス/サイエンスプロジェクト両方の問題解決に貢献できるよう、これからも越境し続けます。

 ご拝読、ありがとうございました。

参照: