何も分からないままマネージャーになった人へー分析プロジェクトのフレームワーク（全体編）

有期でかつ非日常的ルーチンではなく、一回限りの仕事を一般的にプロジェクトと呼びます。特にコンサルやSIでは全ての仕事がプロジェクトです。データサイエンティストの仕事もほとんどがプロジェクト単位で進行します。これを進行管理するための技法としてプロジェクトマネジメント(PJM)があります。

PMBOK（PJMを体系化した本）によるとPJMとは

プロジェクトの事業主体や関係者の当該プロジェク トに対する要求事項や期待を充足する、または、それ以上の成果をあげるために、最適な知識、技術、 ツールそして技法を適用すること。  

とあります。我が国おいては多くの場合システム開発によく用いられます

何故炎上するのか

現代のように、PJMのフレームワークが整理されている中でも、IT系プロジェクトの7割が炎上すると言われています。青色の銀行のシステム開発の件をニュースで見た方も多いでしょう。これは何故でしょうか？

仮説1 そもそも相手が巨大すぎた

青色の銀行のシステム開発はまるでザクラダファミリアのようで今もてる現代のマネジメント手法では歯が立たない。そもそも管理下におけることがマネジメントの原則。いわゆる無理めの案件

仮説2 PJMがない

プロジェクトマネージャーは沢山いたのだろうけど、PJMという全員がコミットするべき憲章がなかった

この仮説から賢くPJMを回していくには、無理めの案件には手を出さない、全員のPJMへのコミットを徹底させることが重要ではないかと考えます。この立場ですとプロマネはPJMという共通の概念を徹底する共同体の意思決定権を持つ代表という位置づけが近いでしょうか。代表取締役と取締役の関係に似ています。プロジェクトマネージャーという肩書きの都合の良い事ばかりいうおっさんはいらないということです。

仮説1は要するに危うきに近づくなということです。炎上率は全くの体感ですが、顧客が金融系=官公庁>>>>大手大企業>>>デジタル系ネット系/ITスタートアップの順で炎上しやすい気がします。

データ分析プロジェクトはどうなのか

進め方や管理の仕方についてはIT系と若干異なる所があります。

• 完成品の仕様を約束できない（分析してみないと分からないため）
• データがないと着手できない
• 比較的小規模なプロジェクトが多い（これはラッキーなこと）

これより炎上ポイントも若干IT系と異なります。出来上がったモデルに対しての納得度が得られない、手法が分からない等のどちらかというとソフト面が炎上の要因になることが多いです。

もちろん、バグ及び仕様変更（分析内容の追加や変更）等システム開発案件同様の要因がありますが、こちらは冒頭で述べたように比較的小規模なプロジェクトが多いので経験を積んだメンバーいればなんとかなる場合が多いです。特にバグについてはデータサイエンティストの書くコードはプログラマと比して圧倒的に少ないかつ冗長であるためデバッグが容易です。冗長であるのは、分析の工程とプログラムを一致させて見やすくするためです。プログラマのように早く処理する、メモリ効率など一切考えません。（プログラマからこの職にきた人はここで大きく戸惑うようです）

実際の進め方

実際の進め方のフレームワークとしてプロジェクトの進行フェーズを4つにわけそれぞれ解説しています。

まずは大まかに紹介しますと

提案フェーズ

• 主に営業とともに同行し顧客ヒアリング等を行います。
• 前節でも述べたようにソフト面の炎上が多い事からこのフェーズの合意形成や期待値コントロールは大変重要です。
• プロジェクト成否の7割がこのフェーズにかかっています。

キックオフフェーズ

• 実際にデータを受領します
• 受領データを眺め、不備欠損等のチェックを行います。要するにinputの検品みたいなものです
• 提案フェーズに作られた提案書を元に詳細な分析工程の設計を行います。

分析フェーズ

• データクリーニングや必要データの結合、加工を行いマスターデータを作成します。このマスターデータを以後原則変わりません（成果物の再現性のため）
• 基礎集計を行います。単指標分布、目的変数とのクロス集計。
• モデル作成を行い、モデル評価をします。

成果物作成フェーズ

• 報告書の作成に取りかかります。これはテクニックですが、分析フェーズと並行しながら章立てをしておくと楽です。
• スコアリングデータの作成

となります

（筆者作成）

次回以降、4つのフェーズの更にサブタスクに分解しご紹介していきたいと思います。