データ分析コンサルティング企業で学んだプロジェクトマネージャーの方法論（1）

昨今注目されているデータ分析。
機械学習、統計学で自動化、人を超える・・・等、メディアではキラキラしてるところばかり切り取られて、なんだかなあと思っているれいです。

データ分析企業では今日も何もなくプロジェクトが進んでいます。

分析プロジェクトはシステム開発のプロジェクトに比べ、分析結果によってはその後の進め方の変化が大きくなり、プロジェクトマネージャーが上手くコントロールしないと炎上しやすい性質があります。
ただ、プロジェクトの方法論を学んだ後では、手掛けたプロジェクトは1件も炎上していません。
※炎上とは、スケジュール内で案件が完了せず人を追加してもどうにもならず、、という一般的なイメージです。

では、何を心がければ炎上しにくいのでしょうか。

お話の前提

・「未経験者を採用して鍛える」会社です
・「要件定義～分析方針決定～分析～納品まで一人称でできる人？なかなか居ないよ」な会社です
・「プロジェクトマネージャー？現場で頑張って覚えてね」な会社です
むしろ、この前提であるからこそ、他の会社でも応用可能な話になっている気がする。
つまり、潤沢な資金でスキルがある良い人を採用できる企業には当てはまりません。

プロジェクトマネージャーがすべきこと

まとめると、下記の4点です。
1・決めることを決める。放置しない。
2・心理的安全性を確保する
3・自分の手を動かすのは最終手段
4・自己学習時間を取ろう

論点は、コンサルティング会社の社内です。
プロジェクトメンバーとの関係性をいかにうまく作るかに注力することになります。
ここ辺りができている人はそう多くありません…。私もそうですね。

なぜここを重視するかというと、プロジェクトの完遂にはメンバーの自走が必要だからです。
目標が設定されていて、案件内容を理解しているPMに対して自分の意見が言えて、（通常の範囲内の）責任を持って仕事ができる。
成功する・しないはメンバー自身に委ねられるものの、走りにくさはない状態を目指します。

1・決めることを決める。放置しない。

案件の5W1H、ゴール、スケジュール、役割分担、タスクの5W1H…などなど、プロジェクトには決めるべきことがあります。

決まっていない事項自体がわからないことが一番炎上しやすいパターンです。
他の方（含む昔の自分）の行動を観察している限り、何となくフワッと仕事をしていることが割とありますね。それが炎上の種です。決めてください。

あとはコミュニケーションの問題です。
組織が違う場合、言葉の定義が全く違う場合があるので注意が必要です。
コミュニケーションしているつもりが一番厄介ですね。

ちなみに、決めることは、しなくていいことも決めることができるので、決めていれば気が楽なんですよね。
PMBOKで定義されているようなトップダウン型のプロジェクトなら良いですが、分析プロジェクトはボトムアップ型も多くパターンに当てはまりません。
そのため、プロジェクトごとに最適解が異なるように思われます。
きっちりとしたプロジェクトマネジメントと言えるのか、言えないのではないかと自問自答していますね。

2・心理的安全性を確保する

プロジェクトメンバー間ではちょっとふざけた話ができるくらいにはなりましょう。
手を動かす速度や時間より、まずは安心してプロジェクトに取り組める場所を作りましょう。

そして、問題があっても悪いのは全て気づかなかった私です・・・そんなスタンスです。
プロジェクトの責任者は私です。タスクの割り振りも含め、責任は私にあります。
あとは、最後にケツを持てるように準備しておきました。
作業も報告も巻き取りは可能ですし、1時間の報告ほとんどを実際に巻き取ったこともあります。

ミスするのは当たり前なんだから、もっとミスしていい。予備戦力として私が居る。くらいは言いたい（し、実際できるようにしないとマズい）ですね。

3・自分の手を動かすのは最終手段

PMが手を動かすのは止めましょう。できる限り。
自分で手を動かすとその場はしのげたように見えますが、それが常態化しやすいです。

ただし、人には苦手分野や苦手なタイミングがあります。
ある程度ルールが決まった中で効率よく作業をこなすことができるのは高学歴の方に多いです。
ただ、何もルールが決まっておらず、何をしていいかわからない場合は手や頭が固まる人が居ます。
その時は巻き取りましょう。
定期的にコミュニケーションを取っていれば、その人の何となく苦手な分野は分かってくるのではないでしょうか。
僕は本人に行動観察＋仮説ベースで聞きますけど。それはなかなかできないですよね。

4・自己学習時間を取ろう

プロジェクトはタスクを決めていれば順調に進んでいきます。
そこで重要なのは自己学習時間です。

1点の曇りもなく、プロジェクトの歴史や技術の説明をできるように自己学習しましょう。
資料は階層立てて保存して、これを順々に見ればわかる構造にまとめておくだけでOKです。
自分のイメージ感がわかない作業には、フワッとしたタスク切り出しをしやすいです。
具体的なドメイン知識はなくとも、作業イメージだけは持てるようなレベルで学んでおきましょう。

これまでの経験

上記のように、プロジェクトを上手く進めるコツは何となくわかってきました。
ではそれを実体験で学ぶにはどうしたらいいのか？と言うことが気になりますよね。

まずは、体験できる場に自分の身を移さないといけませんが、これは具体的な方法は割愛します。

プロジェクトマネージャーの直下で仕事ができる場合は、徹底的に真似ましょう。
自分のオリジナルの方法なんて全く不要です。
所作、言葉遣い、タスクの設定方法、、etc。

上手く行かない部分も含めて、真似てみましょう。
なぜうまくいかないのか、自分で行ってみて上手く行くようになった後から、オリジナルを考えてみてください。

では、実際に手掛けたプロジェクトを紹介します。
意外と多分野に渡っていて楽しそうですね♪

プロジェクト内容

期間：2021.01～2021.03

【長期PJ】
1・ゲーム データ分析・運営方針改善
長期的に仕事を請け負うようになった顧客での、対象タイトルが2~3か月に1回位変更されるデータ分析案件。
因果推論や仮説検証などちょっと高度な統計学的手法を使うこともあれば、網羅的な探索的データ分析も行うことがありました。
結論、担当者さんに理解があるとやりやすい。そのためには、そのゲームや業界自体がどうあるべきか話せるレベルになりたいところ。

2・ゲーム データ分析レポーティング
定期的に上がってくるレポート（バッチ処理で自動化されたSQL抽出）への考察付記をメインに、その時々のイベントがあるのでそれに対するデータ分析を行っている。
結論、Jenkinsさん(自動化)はマジ神。

3・エンタメ 新規分析分野での総合コンサルティング
マーケティングデータが十分にあるので、データ分析をして売上を伸ばしたいとの要望。
そもそものデータがおかしかったので、よくよく調べてみると分析基盤の設計がおかしかった。そのため、再度要件の設定等を行った。
結論、誰にどう使われるか決めていないデータベースはヤバイ。

4・エンタメ 新規分析分野でのデータ分析
スーパーマーケット等リアルデータに近いデータ分析。
データ定義書などがなかった、かつデータの取得要件などの資料も散逸していたのでヒアリングや過去の知見自体の検証をしました。たのしかったです。
結論、資料を残さないと次の人は意味不明でしぬ。

5・エンタメ 長期売上予測モデル構築
R&D要素が強いECのマーケティングオートメーション案件。一言で言えば、反実仮想を機械学習モデルに学習させる案件。
機械学習エンジニアっぽく動いたので知識・技術がたまった。時系列ムズい・・が、精度は人間レベルまで行った。
結論、データの生成過程を考えてモデルを作りましょう。それと、時系列×大量のデータ＝深層学習が最適解とは限らない。

【短期PJ】
1・金融 最適金利予測モデル構築
モデル構築のはずがツール構築も行った案件。めっちゃ専門用語が多彩で理解が辛かった。
Googleのサービスを使えば、サーバーサイドの知識を使わずに機械学習モデルの実運用が可能になることを知った。すげえや。
結論、ドメイン知識が少ないと適切な要件整理が難しい。

2・メディア 分析部門改善
分析部門の業務フローなどを改善しようとしたら・・あまりできなかった案件。
大企業のマンパワーをフル活用しててすごい＆優秀なマネージャーが居ると強いなあと思った。
ただ、どうもデータ分析は業務の役割分担を進めれば進めるほど、、成果が出にくいのかも知れないというジレンマを感じた。人が介在すればするほどコミュニケーションコストばかり増えていく。
現職は、アドホックな分析メイン＆チーム数・人数を拡張し続けているので組織構成が決まらないのが弱点だなあ。
結論、現状認識のズレって補正が難しい。社外ももちろんだけど、社内もね。

3・海洋系 AI開発方針設定・第一号Poc実施
営業サイドで要件が何も決まっていないにもかかわらず、後よろしくをされた案件。一番炎上に近かった案件。
炎上が防げたのは、プロジェクトメンバーが内容を決めれば手が早かったこと（内容を決めるのは苦手・・というより経験がないから無理やろ）、顧客企業の担当者＆メンバーの案件への熱量が高かったこと。
内容を決めきれれば、あそこまで話が早く進むのはめっちゃ楽。
結論、タフな現場こそ力がつく！AI開発に重要なのは現状認識。あとは組織間コミュニケーションとそのコストだなあ。

これまでの失敗経験

では、失敗体験がなかったのかと言うとそうではありません。

特に2・心理的安全性を確保するは大失敗して、部下が辞めました。ハイ。

失敗する以前のチームメンバーは、新人研修で既に何かに優れている人を理由を付けて持ってくるというパワーを使った方法を使って集めていました。
そりゃ何もしなくても成功するし、30～40人規模の会社に入ってくるような人はハングリー精神もある。
失敗する理由がない。

ところが、その人はそうではなかった。
僕より経験をすごく長く、大手企業でデータ分析経験を持つ人だった。役職もマネージャー候補で雇っていたはず。
じゃあ仕事の流れを一通り・・・と言うところで、教育してくださいってことでカンタンに受けた。

結局、想定していたレベルに到達していないように思ったので、思いっきり詰めてしまった。ハイパーに。
「求めているレベルには○○が足りない」「Yes/Noを先に言え」「事実だけ言え」「事実・考察・感想を分けろ」等々。
まあ辞めるわな・・・申し訳ない。

そのように、自分の意向に沿わない人を理論で詰めていたってことを気付きました。
そういった失敗体験があるので、今後も注意していきたいですね。。

そうなったのも、下記3点の理由があります。
(1)僕自身が前職で外資製薬企業に居て、知らず知らずのうちにコミュニケーションが機械的、ドライだったこと
(2)前職では管理者研修やPM研修も受けさせてもらったこともあって理論面である程度自信を持っていたこと
(3)議論するのが当たり前だと思っていたこと

現実問題、そんな前提を持ってる人がほとんどいなかった(;^o^)

というわけでコミュニケーションは苦手ながらも大切にしています。
皆さんもぜひ、自分の前提知識を理解しながら仕事を進めていってください！

これにて、プロジェクトマネージャーの方法論（1）は終了します。ありがとうございました。

つづき

データ分析コンサルティング企業で学んだプロジェクトマネージャーの方法論（2）