データサイエンスは常に変化し続け、新たな研究・技術、分析基盤、サービスが続々と生まれています。
データサイエンス業界に入ってそろそろ3年、社会人開始から7年、色々な事業内容把握・分析を経験しました。その中で、私はコンサルティング業界に属する企業で、日々お客様へ価値のあるサービスを提供しようと奮闘しています。
そこで、その経験を少しでもシェアできればと思います。
現在、日本企業において、データサイエンス組織が上手く立ち上がっている会社がまだまだ少ないと感じます。かつ、自社でも大きな組織改編を行う予定です。そこで、組織のあるべき姿を考えることが多くなってきたので、今回はそのまとめを書きます。
考える軸
まず、第一に組織は戦略に基づいて決めるべきでしょう。
そのため、組織の経営戦略によりあるべき姿が大きく異なりますので、以降の考察の前提が大きく異なることがあります。ご注意ください。
そして、組織の在り方で考えたい項目としては以下の通りです。
ヒト・モノ・カネ
過去・現在・未来
その中で、今回は現在・ヒト（組織）について集中して記載します。
もちろん、モノ・カネは考慮が必要です。例えば、カネ（費用）は事業部門持ちか、データサイエンス部門持ち、どうすべきでしょうか。
カネの扱いによって、責任の所在や本気度が変わってきます。失敗原因となりやすいのは、費用がデータサイエンス部門持ちになることです。他部門メンバーの評価が個人成果しか勘案されず、データサイエンス部門での成果が評価と連動しないため、メンバー・マネージャーが他人事になりやすいです。
モノに関しても、多くの課題があります。ただし、今回は詳しく説明しません。例えば、データ自体か、データを入れる箱か、取り扱い方かですね。具体的には、事業形態別によるデータの取得方法、データベース・BI・分析サービスの利用、データの取り扱い方（DMBOK等各種ルール）などです。
ヒトに関しては、個人・組織（チーム）の軸で考えることが可能です。個人（のスキルセット）はデータサイエンス協会が定義しているスキルレベルを参考にすればいいでしょう。
ただし、調査した結果、組織目線ではほとんどまとめられていないということがわかりました。組織の成功事例・失敗事例が世に出ることは、競合他社との比較優位確保の観点からあまりありません。特に、失敗事例は出ません。そのため、データサイエンス組織開発の知見・資料を参考に今回記載させていただきました。
※つまり、成功事例として出るような内容は、その会社の何らかの意図が含まれる可能性があるということです。
目次
まずは、組織の基本的な形を3パターンで考えていきます。
企業組織の基本構造
データサイエンス部門との企業組織とのかかわり方
データサイエンス部門の組織の在り方
メインの在り方、メインとのかかわり方、データサイエンス部門自体の在り方をパターンで分類します。
どのようなパターンを採用すべきか参考にしてください。
続いて、企業のデータサイエンス成熟度を考えます。
企業のデータサイエンス利用レベル
それを考慮しなければ、構想上は理想的な組織であっても、現実には組織構築・運用が不可能であれば無意味です。
例えば、試行錯誤を許容できるか、つまり、ミスを許容できるかどうかが問われます。
その成功には、企業文化、つまり中の人の頭の中をスッキリさせないと難しいということです。
最後に、上手くいっている企業さんの例を挙げます。
データサイエンス組織の例
個別の企業名を挙げることはしませんし、守秘義務に当てはまらないくらいの粒度でしか書けませんが・・・。
上手く行くには、成功事例を真似るより、自社が失敗事例に当てはまらないか注意して運用していくと良いでしょう。
企業組織の基本構造
最初に、企業組織の基本構造を確認していきます。
組織開発の知見がある方は、当たり前の項目となります。
- 職能別組織
- 事業部制組織
- マトリクス組織
職能別組織（機能別組織）
製造業での採用が多いです。高品質の製品を大量に効率よく生産するために、組織が構築されています。
前職（製造業：製薬企業）はこの形態でした。
プラス面は、部門が事業別に分かれていないため、部門内での知見の共有がしやすいことです。ただし、メンバーは多種多様な事業（製品）に対応しなければならないため、ドメイン知識の深度はどうしても浅くなる傾向にあります。
事業部制組織
カンパニー制とも呼ばれます。ウチの親会社のSIer（最近買収されました）ではコレです。私たちは、1事業部門内でいろいろしています。傾向として、製造業以外での採用が多いです。IT企業はほぼこの形態ではないでしょうか。
プラス面は、事業部ごとに経営人材を存在させる必要があるため、経営人材が育ちやすい傾向にあります。かつ、メンバーに各事業のドメイン知識が集積していくため、ニーズの変化などに合わせ素早い対応が可能になります。
マイナス面は、事業別に組織が形成されるため、技術・知識が寸断されやすく、共有が必要な場合はマネージャー以上にはコミュニケーションに負荷がかかります。ただ、事業部ごとに全然違うことを行っているとこのマイナス面を無視することが可能です。ただし、大企業である強みは生かしづらいのかもしれません。
マトリクス組織
職能別組織と事業部制組織を併せ持ったパターンです。どちらの組織の観点でも評価され得る柔軟な組織です。ただし、コミュニケーションが複数管理されるため、管理費用が増大する傾向にあります。
※日本ではあまり見ないような気がします。
以上、基本的な組織体制を説明してきました。こちらはあくまで基本形態ですので、ビジネスや現場に合わせて組み合わせや一部入れ替えをしてから組織構造として導入される企業さんがほとんどであることに注意ください。
このうち、よく採用される職能別組織または事業部制組織では、データサイエンス部門とのかかわり方が異なります。
職能別組織だと、別部門だと別世界（別会社に近い何か、必要な言葉すら違う）ですし、事業部制組織だと、別事業部は別会社です。
つまり、Yesと言ってもらう相手・人数・組織・風土が異なります。そのように、企業としての組織の在り方によってコミュニケーション方法すら違うため、この内容はデータサイエンス組織の在り方で考慮する必要があるのです。
データサイエンス部門との企業組織とのかかわり方
続いて、関係性を考えていきましょう。
今のところ採用されることが多い3種類の組織構成を説明します。
- 集中管理型
- 部門別独立型
- 中央集約型
もちろん、今回挙げる3種類はメジャーな方法であるだけで、あなたの会社のあるべき姿とは異なります。
さて、説明していきましょう。
集中管理型
データサイエンス部門の導入初期によくあるパターンです。
人数が少なくても導入が可能で、より多くの事業に適用する前に組織内での実績を立てるため、採用されることが多いです。
プラス面は、管理メンバーの人数が部門別独立型より少なくなります。ただし、この体制は各部門のドメイン知識の習得が難しく、協力が得にくい＆分析の重要ポイントが分からないことで、成果が出しにくいです。
部門別独立型
データサイエンス組織（DS）をある部門に専属させます。
プラス面は、ドメイン知識の獲得は容易になりますし、部門の具体的な課題点が把握しやすくなります。結果、成果を出しやすくなります。
マイナス面は、分析技術の共有が難しくなりがちです。特に課題になりやすい点としては、データエンジニアリングの方針が共有されないことで、全社で共通して使えないデータベースができるという悲しい出来事が起こります。
加えて、部門別にデータサイエンス部門メンバーを割り振るため、相対的な人数が少なくなります。メンバーの昇進や昇格のコントロールが非常に難しくなり、メンバー自身の将来的なビジョンを描きにくくなると思われます。
※配属された後それ以降昇格の機会はないと見えやすく、「この仕事をずっと続けていくのか？」と思われがちです。
中央集約型
Center of Excellenceとも言われます。
データサイエンス部門の導入に成功している企業の多くはこの形態を取っていると思われます。中央集権的に行う部分と、ドメイン専門化していく部分が混在します。
上記で紹介した2つの組織のメリット、ドメイン知識の取得容易性、管理の容易性を高めます。
導入の前提として、各部門からのデータサイエンスの価値理解と、企業の体力が必要です。なぜなら、データサイエンス部門のメンバー数が10人以上と多くなり、かつチームリーダー層やコミュニケーションを統括するマネージャーも必要となってきます。
結果的に、採用・維持のコストがなかなかお高く、成果を出しやすいテック系企業の採用が多いです。
この組織ですと、機械学習エンジニアやDevOpsエンジニアの採用なども視野に入ってきます。専属で機械学習エンジニアを採用できるかどうかは、導入企業のレベル感を把握するために良い指標かもしれません。製造業でここまで揃えられる企業は中々ありません。
※機械学習エンジニアといっても、集計・BI管理などの基礎分析まで行う職種もありますのでご注意を…。
以上のように3形態を説明してきました。
私の所属する企業では、事業部制組織でかつ1事業部がデータサイエンス組織になっているため集中管理型に近いです。しかし、各事業部のうちデータサイエンス組織・研究機関を持っている事業部も存在するという複雑な構造です。
そのように、あくまでも事業の実態に合わせた組織構成が必要でしょう。
データサイエンス部門の組織の在り方
データサイエンス部門の組織在り方、つまり分業の方法を確認していきます。組織は分業の形態であり、分業が必要なければ組織は必要がないと私は考えています。
プレイヤーにはデータアナリスト（DA）、データサイエンティスト（DS）、データエンジニア（DE）が含まれます。
各プレイヤーの定義は下記の通りとします。
データアナリストは、DEが構築した分析基盤を基に、過去を理解するための分析を行います。
データサイエンティストは、生データを基に適切な分析基盤を選択して、将来を予測するための分析を行います。
データエンジニアは、分析基盤など分析インフラを構築・運用を行います。PoCが完了したプログラムの実装も行うことがあります。
データ分析の代表的なフローとして、IBMのCRISP-DMが存在します。
そちらを基に説明していきます。
垂直分業
いわゆる機能別分業です。一般的な企業で採用されることが多いです。
機能別にリーダー – プレイヤーが存在し、すべての機能を見るマネージャーが存在します。プレイヤーのレベル感に応じてタスクを割り振りやすく、未経験者の導入には適していると考えられます。かつ機能別に人員が割り振られることから、専門性の向上による効率化が起こりやすいです。
垂直分業も上手くいくと、エントリー（ジュニア）レベルの知識・技能のしきい値の増加が起こります。そのため、未経験者でも情報科学や統計学（およびそれに類する学問の）専攻者に占められやすいです。
ただし、各機能別に管理系職種が存在することとなり、手を動かす人が相対的に少なくなることから、管理コストが高まりやすいです。そのため、データサイエンス業務に価値が生まれやすいIT業界などで採用されてます。
加えて注意してほしいことは、大企業のような行き過ぎた垂直分業です。
例えば、タスクごとに作業内容を明確に定義して、工場のように処理していくような企業さんも存在していました。そうすると、効果的なデータ分析に必要となる分析要件の共有などがしづらくなり手戻りが増えること、作業が固定化されてレベルアップしないなどの課題があります。
水平分業
プロジェクトベースの組織、つまりコンサルティング業界で採用されるケースが多いです。
その中でも、並列的水平分業と直列的水平分業が存在します。
並列：チーム型
チームで1案件を進めていきます。
直列：機能リレー型
直列は製品の製造だとわかりやすいです。部品Aを作って、部品Bを作って、組み合わせて製品が完成するような工程です。
ただし、データサイエンスの業務は並列になりがちです。なぜなら、専門家部隊を作るまでコストを払っていられないが、業務はしたい要望や需要（供給）に変動があるためです。運用ルールが明文化されていれば分業は可能だと思います。
この方式ですと、メンバーはすべての機能での自走が求められます。つまり、未経験者お断りのような状況になりやすいです。現実は、プロジェクトに投入してみて上手く行く（生き残った）人はメンバーとして機能するなかなか辛い状況になりやすいです。
プラス面は、コスト計算がしやすいことです。1案件に対しどれくらいのコストをかけて、いくら売り上げがあがったか直観的にわかります。かつ、組織体制も簡単に増加・減少させることができます。案件のメンバーが増えればリーダーが増え、リーダーが増えればマネージャーが増える。メンバーが減ればその他も減らせばいい。急激な組織拡大に対応しやすい形態です。
そのように、チームの在り方として、論点が色々と考えられます。
あなたの組織はどうあるべきでしょうか？
企業のデータサイエンス利用レベル
続いて、現行の企業組織の状況を知るために、レベルを確認していきましょう。
レベル感として、多くの企業が定義を出しています。
下記はNTTデータ系列のクニエさんより
データマネジメント構想策定支援サービスより
私は、下記のように定義しました。
レベル0：データサイエンスの効果を実感する
レベル1：ルールを作って集める
レベル2：過去を理解する
レベル3：現在を理解する
レベル4：将来を予測する
事業部・職能別にレベル感が異なってもかまわないと思います。どの部署に導入するのかは、その企業の状況次第です。
現在は1～2のレベル感が多いかなと感じます。ただ、レベル0のデータサイエンスの効果を実感せずに導入実施を試みている企業さんが多いことも気になります。
導入したいから投資する・・・ではなく、他の事業・研究開発等に投資するよりデータサイエンスに見込みがあるから投資するであると成功しやすいです。
戦略ベースで実施していきたいところです。成果が出ていれば、経営陣も、各機能（営業・製造他）の管理職やメンバーも導入に前向きにならざるを得ません。
以上で出てきた論点を基に、論理的にかつ感情にも配慮して行いたいところです。「自分が従事していた大切な業務を機械に取って代わられる？ありえない。」のように、人は感情で動くものです。そこを忘れないようにしていきたいですね。
データサイエンス組織の例
下記に、実際にデータサイエンスを活用し成果を挙げている企業の例を記載します。
企業A
形態：事業部制 + 中央集約型 + 並列的水平分業
IT・エンタメの企業です。
各事業部ごとにユーザー層が異なるものの、提供するサービス自体は非常に似通ったものです。そのため、中央集約型で知見を共有しながらデータサイエンス組織を運用しています。ただ、データサイエンス業務の需要が安定しないため、並列的水平分業制を採用しています。
企業B
形態：職能別組織 + 集中管理型 + 垂直分業（並列的水平分業を含む）
研究開発を中心とした製造業です。
1つの製品により莫大な売上が見込めるため、研究開発に重点が置かれやすい業界です。提供する製品の種類も分野としてはほぼ1つであるため、ドメイン知識の深化はしやすいと考えられます。ただ、データサイエンス組織導入の初期段階のため、明確な成果を少人数で挙げなければなりません。そのため、少数の経験者をトップグループにして、集中管理型でかつ垂直分業、育成メンバーは特定の機能で並列的水平分業を行う形態が採用されています。
企業C
形態：事業部制 + 集中管理 + 外部委託
ITサービスの総合企業です。
サービスの種類が多く、かつドメインがバラバラなため、データサイエンス業務の需要も時期によって大きく異なります。そのため、少数の経験者をデータサイエンス業務の管理に当たらせ、需要に応じて外部委託を行う形態を取っています。つまり、ドメイン知識の取得は社内の経験者に任せることができ、かつ作業は外部に委託して、その管理・検証は経験者が行う形となり、社内でデータサイエンスメンバーをほとんど抱えなくていい状況です。
今後は、他のコンサルティングプロジェクト（経営、組織、人事、法務他）と同じように、こちらの形態が増えてきそうだなと思います。
さいごに
さまざまなデータサイエンス組織をまとめ、分類し、評価してきました。
一つ言えることとしては、データ分析にしても、データ分析組織にしても導入ありきで考えてはならないということです。データ分析は大企業こそ生きてくる、1%の改善が巨大なインパクトを持つ企業でこそ生きるので、中小企業で頑張っても意味がない可能性があります。最低限、過去・現状を知るためになど、あるべき姿を制限した導入方法の考慮も重要でしょう。
少しでも参考になれば、ツイッターなどで記事のシェアを行っていただけると嬉しいです。
筆者はデータ分析に関するコンサルティングを行っていますので、その他に書いて欲しい内容があればコメントを頂けると助かります！
参考図書
組織構造を考えるにあたっての名著。基本型を知ることができる貴重な本でした。
[…] 具体的には、データサイエンス部門の組織形態、あるべき姿を考えるで記事を書いたので参照されたい。 […]