トレンドコラム

ソフトウェア開発のプロジェクトマネジメントというテーマでは、業界として長年に渡ってノウハウが蓄積・共有され、今日の開発に活かされています。しかし、新しい分野であるデータサイエンスに関してはそうではありません。また、そのような企業内のノウハウが公になることもほとんどありません。
とはいえ、必要なマネジメントの下で計画的にアウトプットを出せて初めてビジネスの場へ投入できるという考えは、ソフトウェア開発だけでなくデータサイエンスプロジェクトにも言えることでしょう。

この分野の議論がより活発になればという思いから、NTTPCが蓄積しているノウハウを公開します。

マネジメントの特殊性

データサイエンスチーム、あるいはデータサイエンス案件のマネジメントは、ソフトウェア開発のそれとは異なります。その差異は、少なくとも次に挙げるような根本的な特性の違いに起因すると考えられます。

	データサイエンス	ソフトウェア開発
アプローチ	サイエンス	エンジニアリング
キーとなるアルゴリズム	統計的	ソフトウェア工学的
モデル	データが決定	人間が決定
特徴選択	人間又はニューラルネットが行う	（ある意味）人間が行う
アウトプットの精度（再現性）	100%未満	100%

従って、ソフトウェア開発のマネジメントを経験した人がデータサイエンスチームや案件のマネジメントで直面するであろう問題は、次の通りです。

• 理論的な正しさの追求と現実のデータの複雑さとの間で試行錯誤を繰り返すことになり、計画を立てづらい。新たに計画を立てる際に、過去の情報を利用しようとしても、そもそも問題設定とデータが異なるため、結果的に計画と実績とが乖離するリスクを加味する必要がある。ソフトウェア開発でいうところのファンクションポイント法やユースケースポイント法などの工数見積手法が存在しない。
• 統計学の手法や統計的アルゴリズムに習熟した人材を集めることが難しい。ソフトウェア開発の世界では安い単金で人を集めることが事実上可能であるが、データサイエンスではそういうわけにもかず、高額な人件費を支払うか、「できる人」だけでなく「できそうな人」までスコープを拡大して人を集めることになる。また、このような状況では十分な育成スキームを用意できていないので、「できそうな人」の学習能力に依存しており、その点が無視できないリスクとなる。
• モデルはデータが決定するため、良質なデータを十分に用意できるかが、成否を分ける重要な要因となる。ソフトウェア開発では設計段階で十分にモデリングをし、そのモデルに対してデータが入出力可能となるよう実装するが、データサイエンスにおいては、個々のデータがモデルを形作る。つまり、モデルがデータを規定するか、データがモデルを規定するかという違いがある。
• 主に、機械学習 ( マシンラーニング ) では人間が、深層学習 ( ディープラーニング ) ではニューラルネットが、データのどの特徴を使うかを評価・選択する。特に機械学習での特徴選択は、技術というよりは技能 ( 職人技 ) の色合いが強く、メンバー間でのスキル・トランスファーがやりづらい。
• データサイエンスにおいては現実のデータがモデルを形作るため、結果が常に一定になるとは限らないし、観測範囲内で結果が一定になるようであれば、それは過学習が疑われる状況であり、是正が必要になる。そのため、ソフトウェア開発と同じ感覚で「できました」と言いづらい。

反面、両者に共通する部分もあります。お客さまがどういうアウトプット、どういう価値を欲しているか、実はお客さま自身が正確に把握していないことが多いということです。ソフトウェア開発の場合はアジャイルがその問題を解決しますが、データサイエンスにおいても、アジャイル開発に似た考え方が有効です。
これに関しては後述します。

データサイエンティストを知る

データサイエンスチームをマネジメントするには、データサイエンティストに対する理解が不可欠です。

一般論

一般的に、データサイエンティストには

の3つのスキルが揃っていることが要件とされ、具体的には

といったスキルが必要になります。

「そんなスーパーマンはいない」と思われるかもしれませんが、それはデータサイエンティストという言葉がバズり始めた頃からよく言われていたことです。

これは、歴史が浅い＝高等教育の成果がまだ出てきていないことに起因していると考えられ、しばらくはコンピューターサイエンスや数学・統計学を中心に、近い分野の学問を修めている者でカバーする状況が続きそうです。

統計的手法による分類

UCLAにてデータサイエンティストを統計的に分類する研究が継続的に行われています。分類の対象は米Microsoftのデータサイエンティスト 793名（有効回答者数532名）で、12のアクティビティから9つの役割に分類できるとのことです。データサイエンティストのサブカテゴリ分類として把握をすることで、チームビルディングに役立て、チームとしてデータサイエンティストを実現するのが現実的と言えるでしょう。

12のアクティビティ

• 既存データへのクエリ実行
• データ収集プラットフォームの構築
• データの準備
• データの分析
• 実験
• 洞察に対するバリデーション
• 洞察の喧伝
• 他者との協働
• 洞察の運用可能化
• 洞察に基づく活動
• データサイエンスと関連するその他の業務
• データサイエンスと無関係なその他の業務

9つの役割

◆ジェネラリスト

◯Polymath ( 物知り )

◆スペシャリスト

◯Data Preparer ( データを準備する人 )

◯Data Shaper ( データを形作る人 )

◯Data Analyzer ( データ分析者 )

◯Platform Builder ( プラットフォーム構築担当者 )

◆マネージャー

◯Data Evangelist ( データ伝道師 )

◯Insight Actor ( 洞察の当事者 )

◆片手間

◯50% Moonlighter ( 50%のパートタイマー )

◯20% Moonlighter ( 20%のパートタイマー )

採用か育成か

前述のデータサイエンティストを採用するのか、それとも育成するのかは、これからデータ分析を行っていこうとする企業が必ず直面する課題と言えるでしょう。

ここで、日本企業特有の問題として人材の流動性が低いことが挙げられ、これが「採用よりも育成」というバイアスを生み出します。実際、これからデータの分析・活用をやっていこうという企業において、十分な成果が出るか確信の持てない分野に対して、外部から人を登用するのは、かなりハードルが高いのではないかと思います。 まして昨今、データ分析のスキルを持つ人は引っ張りだこであり、かなりのプレミアムを積まないと採用は実現できないでしょう。これは、年功序列が色濃い日本企業では特に難しいと思います。
このような前提を踏まえつつ、採用と育成を単純比較したのが、次の表です。

	採用	育成
コスト	短期的には高コスト	短期的には低コスト
所用期間	短い	長い
リスク	低い	高い

育成のリスクを「高い」としたのは、モチベーション，アビリティ，マインドセットなどの観点を考慮した、育成のリスクに起因します。

優秀なデータサイエンティストを採用するには

"優秀な"データサイエンティストを採用したいと考えた場合に、次の観点がポイントになることを念頭に置くべきでしょう。

給与とキャリア形成

• 同業種の間で比較して魅力的な給与を提示できるか
• データサイエンティストとしてのキャリア形成に関して明確なプログラムを用意しているか

カルチャーとコミュニティー

• 他のデータサイエンティストとの交流の機会があるか
• その中に「パイオニア」はいるか

会社・組織の目的意識

• データへアクセスし、実験を行い、失敗を重ねながら、モデルを構築できる裁量はあるか
• 会社組織の重要な部分に、データサイエンスのアウトプットを取り入れていく戦略や指針はあるか

チームビルディング

データサイエンティストが一人いれば、とりあえずデータサイエンスの営みは開始できます。しかしながら、エンタープライズの規模の案件を一人でこなせるデータサイエンティストは一握りしか存在しません。すなわち、基本的にチームとして体制を構築・強化していく必要があります。

チームビルディングは、5つのフェーズで実施・拡充していくと良いでしょう。なお、ここでのデータサイエンティストは「9つの役割」で言うところの Polymath を想定しています。それ以外の役割の者を割り当てる場合は、必要な人を揃えることで、ジェネラリストである Polymath のような機能を複数人で実現することになります。

フェーズ	チームメンバー
1	データサイエンティスト
2	データサイエンティスト×2
3	データサイエンティスト×2，ビジネスアナリスト
4	データサイエンティスト×2，ビジネスアナリスト，データエンジニア
5	データサイエンティスト×2，ビジネスアナリスト，データエンジニア，デザイナー

• ビジネスアナリスト：お客さまのビジネスを理解し、データサイエンスのアウトプットをお客さまの価値へとつなげるための分析ができる人
• データエンジニア：データサイエンスに関わるツールやシステムの選定・開発・構築，データの収集・前処理・ETLなど、エンジニアリングの領域を担当する人
• デザイナー：システムとして開発しデプロイするにあたってのUI/UXを担当する人

ワークフロー

データサイエンスチームの典型的なワークフローは、次の通りです。

1. 課題設定
2. データへのアクセス
3. ETL
4. 品質チェック
5. クリーン/マージ/結合
6. 探索とフィルタリング
7. 実験
8. レポート
9. デプロイ
10. システム結合
11. 再学習

あるいは、オープンでスタンダードなメソッドとして、CRISP-DM (Cross-industry standard process fordata mining) あるいは ASUM-DM (Analytics Solutions Unified Method for Data Mining/Predictive Analytics)を参照するのも良いでしょう。

課題の選定

データサイエンティストは引っ張りだこであるというのは採用のトピックでも述べましたが、それだけ、データサイエンスによる解決を待つ課題が偏在しているということです。 きっとデータサイエンスチームの人手は足りず、優先度を付けて対応することになると思います。優先して取り組むべき課題は、次の観点で選ぶと良いでしょう。

• インパクトとその計測可能性：同じリソースを投入するとして、そのアウトプットがいかに大きなインパクトをもたらし、またそれを計測することが可能であるか
• データへのアクセシビリティ：必要なデータにアクセスできるか
• 変革の実行可能性：データサイエンスのアウトプットがもたらすことができる変革を、組織として実行に踏み切れるか

期間の見積

「マネジメントの特殊性」で触れたように、データサイエンス・プロジェクトを計画する際に、スケジュールをどう組めば良いのか、非常に悩むと思います。そこで、典型的な期間を次に示します。全体としてはおおよそ2～10ヶ月で一巡するスケジュールを組むと良いでしょう。

工程	期間
課題の選定とプロジェクト化	2～3週間
データエンジニアリング	2～6週間
データサイエンス	2～12週間
デプロイメント	4～20週間

アジャイルなメソッド

ソフトウェア開発において、一般論として、ウォーターフォール型の開発手法は不確実性に対して脆弱であり、それを克服するのがアジャイル開発です。データサイエンスにおいても、これに近いマネジメントを行うことで、アウトプットをお客さまの価値に変えるためのリードタイムを短縮することが期待できます。ポイントは次の通りです。

• 実験を経たソリューション決定
• 反復的な報告と説明
• カスタマーやスタッフのニーズに沿ったデザイン
• クライアントと密連携できる小規模かつ多分野のチーム
• 時間とコストを品質よりも優先

マネジメントにおけるその他の課題

データサイエンスチームをマネジメントするにあたっての課題は、データサイエンティスト，チーム，組織など、人やその活動に関するものだけではありません。他にもデータをどう管理するか、セキュリティの管理をどう考えるかといった課題があります。すなわち、
●データ・ガバナンス
●データ・セキュリティ
といったテーマでの議論が別途必要になります。これらはまた別の機会に取りあげたいと思います。

まとめ

データサイエンスチームのプロジェクトマネジメントに関して、マネジメントの特殊性、データサイエンティスト、採用か育成か、チームビルディング、ワークフロー、課題の選定、期間の見積、アジャイルなメソッド、マネジメントにおけるその他の課題といった観点で解説しました。
冒頭で申し上げた通り、この分野の議論はまだまだニッチですが、ビジネスである以上、将来いずれその重要性が広く認識される分野であるのは、ソフトウェア工学が辿ったのと同じであると考えています。ぜひ、日本国内でも議論がより活発になればと思います。

参考文献

Miryung Kim, Thomas Zimmermann, Robert DeLine, Andrew Begel (2017) "Data Scientists in Software Teams: State of the Art and Challenges," University of California Los Angeles, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING.