データ分析グループの失敗の原因と、正しい運用へと導くポイント
これらの失敗は、何が原因で起きたのか――中山氏はその原因を「新しい組織形態」にあると解説します。データ分析グループは近年になって新しくできた"組織の形"であるため、最適な運用方法がまだ無い状態、手探り状態であるとも言えます。そのような状況なので、当のデータ分析者、またはデータ分析者を取り囲む面々も何が最善であるのかを知らないのです。本来あるべき姿として中山氏が掲げたものは、"研究からアプリ運用までを一気通貫するPDCAを回す"ことであり、"他職種の領域と重複"しながらも、膨大なデータを取り扱っていくのに適した環境・形態に無かったと中山氏は分析します。
このような組織形態を実現するためにはどうすれば良いか。中山氏は「エグゼクティブのサポートが必要である」とコメント。カバーする範囲を明確化し、システム面においてもデータ分析者の書いたコードがサービスに影響を与えないようにアーキテクチャを設計する等して、「（整備士やパイロット等、業務を分担しながらも効果的に運用が回っている様を例えて）データ分析は空軍のようなもの。会社として十分なお膳立てが無ければ、ワークしない」と体制面のサポートが何より重要だと強調しました。
Emotion Intelligence社で起こった事例 - 失敗と改善の歴史
前述の状況を踏まえて、セッション後半は中山氏の所属するEmotion Intelligence社でどのような問題が発生し、どのように対処をしていったのかが詳細に語られました。こちらについても順を追って要点を列挙します。
0. マネジメント無し
データ分析は3人。マネジメントされてないことで全員が目の前の「見えている」アラートやトラブルに工数を拾ってしまい、製品開発に時間を割けなかった。
1. ペイオフマトリクスの導入
コストとインパクトの二軸でタスクを評価、優先度の高いものを優先的に対応する手法を導入。書籍『日産 驚異の会議』を参考とした。しかし「イノベーションのジレンマ」が発生してしまう。このフレーズは「大企業が合理的に意思決定を行なうことで、イノベーションが産めなくなり、負けてしまう」ことを表したものだが、たった3人の組織であっても合理的に意思決定を行なうことで、同様の状況に陥ってしまっていた。この点については「データ分析グループのマネジメントにおいては、合理性を多少であれば無視することが必要」と中山氏は言及。「人的資源が豊富・経営が安定・多少のミスは許容出来るといった大企業の体制があったので、日産は成功したのであり、さまざまな環境が異なるベンチャー企業ではそもそも成功するはずが無かった」と解説。
2. 三段ペイオフマトリクスの導入
ペイオフマトリクスを発展させる形で、「研究」「開発」「運用」の3つに分割。各ペイオフマトリクス間でのタスクの優先度比較は行わないことでイノベーションのジレンマを回避を狙った。こちらについては最初は正しく機能したものの、「研究」とされたタスクは検証方法が分からず「要ブレークダウン系」で脇によけられていく形に。気づけばよけられて溜まっていったタスクが「ビジネスのコア」であることに気付いた。
3. GitHub issueへの移行
三段ペイオフマトリクスで発生した「本質的な問題」を解決するために、GitHub Issueでそれらのタスクを管理してみることに。しかしこれが大失敗。GitHub Issueは誰でもツッコミが入れられるため、また、管理したタスクは本質的であり抽象度の高い問題であることもあって、誰でも一言言ってしまう、いわゆる「自転車置き場の議論（bikeshed discussion）」に陥ってしまった。GitHubのフォーマットではこの種の課題を解くことは難しいと判断。更にはこの議論で、エンジニアとデータ分析者のメンタルモデルの違いが顕在化。やってみないと分からない、打率をベースにビジネスを考える「データ分析者」と、合理的な判断をする傾向が強く、完璧をベースにビジネスを考える「エンジニア」という側面が浮かび上がる形となった。
「フラットな組織」の限界とマネジメント体制の重要性
以上、様々な問題に直面し、対応策を講じてきた中山氏は「Issueは管理しただけでは解かれることは無く、Issueを解く人がいなかったことが問題でした。また、職種間の利害対立を調整する人が居なかったというのも大きかったです」と失敗の要因を分析しました。
ここまでの取り組みはマネジメントがされていない状態（中山氏曰く「フラットな状態」）で推し進めて来たものでありましたが、諸々の反省点を踏まえ「マネジメントの失敗である」と認識、各部署にマネージャーを置き、利害対立はマネージャーが調整・解決を行なう「普通の会社」に変えることで対応しました。
データ分析グループ内で人と役割を分けてイノベーションのジレンマを回避したり、Amazon Redshiftを活用したデータレイクの構築でデータ分析者がエンジニア（のコード）に現実的な時間でアドホック分析を行える環境を整える等の対策も講じたことで、状況は改善できたと中山氏はコメントしました。
最後に中山氏は「データ分析を行なう組織の成功には会社のサポートと「適切な強権」が不可欠であり、イノベーションのジレンマはどこでも起き得るもの。それを回避するためには『普通の会社』になることも悪いことではありません」と総括してセッションを締めました。
