どうもこんにちは、Qiitaでは はじめまして。私です。普段は分析とかデータとかその辺の仕事をしてる者です。
Qiitaで分析とかプロマネの話をしていいのか悩んでたんですけどなんか大丈夫そうなのでここで書こうと思います、分析の話。
長文を読みたくない人のためのまとめ
こんなことをダラダラと書いてます
はじめに
分析スキルって一口に言っても色々あるけれども、私が面接とか人材育成とかの場面で人の分析スキルを推し量るときによく見ているのが、
- データのハンドリングスキル
- データの分析設計力
- 統計、機械学習のスキル
- 分析プロジェクトマネジメント
の4つの軸。特に「分析」というのは大抵は一つの目的に対して一つの分析結果を出すまでを一人で行うことも多いので、この分析自体を一つのプロジェクトとして完遂できる能力は極めて重要だったりする。
この記事では、この中でも4つ目、分析プロジェクトマネジメントのスキルについて記載していく。現実論、分析プロジェクトは依頼を受けてから分析を行いレポートをするまでで済まずに、その後の何かしらの実装にまで踏み込む事も多いけど、この記事では「分析してレポート出すまで」をきれいに回せる状態を目指す。
よくある分析の失敗例は、機械学習使ってモデリングしてみました！以上！とか、データたくさん出してグラフいっぱい出しました！以上！みたいな、計算だけして終わっちゃうケース。
最近は世の分析屋さんたちもみんなこぞってビジネスの成果を出すのが大事だって話をしているので、こういう数字出して終わり、みたいな分析官はきっと減っている事と思うけれども、一方で知見出すための方法も結構属人化してるところがあったりして中々学ぶに学べない、というのは結構あるのが実情だと思う。
で、この辺の課題感色々聞いていると、結局それって分析スキルっていうよりもPMスキルじゃんって思うケースはすごく多い。おそらく分析官は個人商店になりがちなので、特にこういう全体管理をできるようになって初めてを一人前、という気がする。
世の中的にもこんな本が出てきてたりとか（大城さん新卒1-2年目くらいにお世話になった元同僚なんだけど） して徐々にデータ分析のプロセス自体をちゃんと上手く回していこう、っていう動きはありそうな気がする。気のせいかもしれない。
とはいえ、この本だけで全部網羅できているとも思っていなくて、このあたり「私はこう考えてますよ」っていうのをちょっと洗い出してみるという記事。
あくまで今回は「分析環境はすでに整っている」という前提。分析環境をどう整えるか、というのは別の話なので今日は割愛。
分析官が身につけるべきPMスキルとは
PMスキルと言えば、世の中にもPMBOKという、世界標準のような知識体系がある。
なんかPMBOK、だいぶアップデートした第7版が出てるらしいですね。アジャイルを意識したやつ。まだちゃんと見てないので第6版を元に整理します。
PMBOK自体は書籍が大量に出てるし、検索すればあちこちに見つかるのでけど、10の知識エリアからなっている。
- 総合管理
- スコープ管理
- スケジュール管理
- コスト管理
- 品質管理
- 資源管理
- コミュニケーション管理
- リスク管理
- 調達管理
- ステークホルダー管理
実際のところ、必ずしもこれらすべてを一人の分析官が完全にこなせる必要は無い。「分析」という実務に加えてこれらを実行していくのは当然骨が折れる業務である。が、個人商店的な働きをしないといけない分析官はこのなかの大半の領域を自力でやらざるを得ないのが実情でもあろう。
分析をしたくても結局前処理に追われがちなのは「調達管理」の領域が上手く回る状態になっていない、ということが原因だったりするし、「最後の報告が大事！」っていうのはステークホルダー管理やコミュニケーション管理の領域。
この視点で見ていくと、分析官が考えるべき視点というのが徐々に見えてくるので順番に見ていく。
10の知識エリアに分析実務の領域をあてはめていく
統合管理
統合管理、っていうのは全体管理なので、個人商店的な働き方をするときはあまり考えなくて良さそう。複数人で分析業務を行う場合はこの限りではないが、そういうケースもさして多くなさそうなので今回はおいておく。
大きなプロジェクトだとプロジェクト憲章を書いたり、プロジェクト最中のマネジメントや、場合によっては受発注管理、事後の教訓管理などがあるかもしれないが、そこまでやるべき分析案件というのは少ないだろう。ということで一旦無視。
スコープ管理
ここで失敗するとすごく尾を引くのだが、意外とちゃんとできていないケースは多い。たとえばこのあたりを見ると
スコープマネジメント | 用語集 | ミツエーリンクス
・プロジェクトの目標を達成するために必要な成果物とタスクを定義する
・プロジェクト期間を通じて、必要に応じてその定義を見直していく
・必要な成果物とタスクが完成されていることを保証する
こんな事が書いてある。
分析プロジェクトにおいては、成果物はたいてい「レポート」であることが多いのだけれど、この「レポート」を細かく砕いていくと、XXのグラフ、とかYYの比較結果、みたいなものに分けられる。場合によっては「ZZが良いという結果」とかっていうレベルになるものもあるかもしれない。
レポート以外にも「モデル」だったり「施策に利用する営業先リスト」「広告配信のターゲットリスト」みたいなものが求められるケースや、ダッシュボードやAIシステムの実装であるケースもあるだろう。いずれにせよ、アウトプットのイメージやフォーマットは予め決めておくことが望ましい。
最初にこのスコープ設定にミスると、スケジュール管理ができなくなってしんどい思いをする。私の身の回りの例で言うと、「データ集計するだけで終わりだと思っていたらその後のダッシュボード実装までやらされた」とか「簡単な集計だと思ってたら次から次へと疑問が湧いてきて結局大量の集計をやらされた」とか。
依頼者が"良い結果"だけが欲しいのかフラットな意見が欲しいのか、データがほしいのか知見が欲しいのかそれともその先の提案まで欲しいのか、とかもスコープ定義の時点で理解しておかないと、後々依頼者が思ってたのと違う、みたいなこともありがちである。
後ほどステークホルダーマネジメントのところでも書くが、依頼者の期待値によってスコープを定めていく能力が分析者には求められることが多い。
分析の規模感によっては、スコープの定義後にWBSの作成までしておいた方が良いケースもあるだろうが、ここまでは不要なケースの方が多そう。繰り返しにはなるが、スコープは決めた後に依頼者に予め確認しておくのがトラブルを避ける上では有効になろう。できればテキストで残しておくのが良い。また、これらのスコープは進捗によって随時見直す必要もあるかもしれない。
スケジュール管理
言わずもがな、スケジュール管理は重要である。分析というのは試行錯誤を繰り返すことも多いのでこの管理は結構難しい。「データ出すだけなら2-3日で終わるだろ」って思った事が結果2-3週間かかるようなプロジェクトに変貌していった経験は多くの分析者が経験していることでしょう。
大抵は上記のスコープ管理がうまくいかない状態で始めて、スケジュール管理もグダグダになる。最悪なのは、スコープ管理に失敗してスケジュールがグダグダになって、気づいたら締切直前になって依頼者が欲しいデータが何も出来ていない、というような状況。（嫌な思い出が蘇ってきた）
分析プロジェクト自体はシステム開発のように大規模になることは無いので、そこまでナーバスになる必要は無いが、最低限「締切」と、ある程度時間がかかるなら「中間報告日」は予め決めておくと良いだろう。プロジェクトをフェーズ分けして、中間報告にフェーズゲートとしての役割をもたせる事もできる。
依頼者との関係によっては報告日がある程度決まっていたりとか、次の施策のスケジュールがある程度見えていたりとか、常に他のプロジェクトと分析プロジェクトの関係性を意識しておくとスムーズにいける。
特に、施策の効果検証のような分析というのは間が空けば空くほど価値が薄れてしまうので、「速報」と「詳細報告」の2段構えにするとか、詳細を「中間報告」と「最終報告」にわかるなどの工夫をすると信頼度を得やすい。このあたりはコミュニケーション管理の項でも述べる。
大抵の非分析官は、データの前処理部分にそんなに時間がかかると思ってはいないので、必要に応じて事前説明などもスケジュールに組み込んでおくと良いのかもしれない。また、分析環境の準備から始める必要があるケースなんかは更に時間がかかることになる。
分析官には、前処理に時間を要すること、試行錯誤を繰り返すであろうことを前提としたスケジュール管理能力が求められる。
コスト管理
コスト管理については、必要性が組織や環境により異なるが、分析官が意識すべきコストはおそらく下記の3点。
- 人的コスト
- 計算コスト
- データの取得コスト
受託分析であれば人的コストがそのまま全体コストになるが、社内分析官であればどちらかというと計算コストの方を意識する必要が出てくるだろう。人的コストは、上記スケジュール管理に基づいて行う事である程度管理はできるので、この項目では他の2つに少しだけ触れる。
分析にかかる計算コストは、扱うデータの量に最も大きく影響される。最近は分析環境をクラウドで構築する事も増えたので、よりこの計算コストが可視化されてきていて、分析官も意識する必要が出てきている。（というか意識せざるを得なくなってきている、、、という方が正しいかも）
ローカルPCで分析できるようなサイズ感であれば全く気にしなくて良いが、web解析などはそうはいかないことも多い。例えばGoogleのBigQueryやAWS Athenaなどは、読み込んだデータ量に基づいた課金体系になっているので、巨大なデータに対する試行錯誤をするとその分だけコストが掛かる。
コストセンシティブな組織だとうるさく言われる事も多いので、できるだけ試行錯誤するデータを小さくするような意識は必要だろう。ここを本格的に行っていくためにはデータマネジメントの知識も必要不可欠となるが、この記事の本題からは逸脱していくので今日は割愛。
データの取得コストについては、単純な人的コストとかではなく社外からデータを購入するケースのイメージ。わかりやすいのはアンケート業者にアンケート頼んだりとかすると、ここにコストがかかる。調達のところでも触れるが、適切なデータを適切に調達するスキルも場合によっては分析官に求められる能力になるだろう。
コスト管理という視点では、単発のプロジェクトとしてのコスト管理よりもデータ分析組織としての管理が求められるケースの方が多いかもしれない。いずれにせよ、管理が必要なのであれば、日々のモニタリングや予算の見直しなどの仕組みも準備しておく必要があるだろう。
品質管理
分析業務は個人商店のようになりがち、というのは冒頭でも言ったところだけれど、品質管理はかなり属人化していて、個人のスキルに依存しているケースは多い。個人的にはここの領域は挑戦していきたい領域。
分析というのは単発の報告で終わるケースが多いので、システム構築とかと違って仮に**データの処理にミスが有っても発覚しにくい。**そのため、品質という面ではおざなりになりがちで、そのままダッシュボードみたいなものに実装されてしまったりしても、意外と何ヶ月も何年も間違った分析が使われてしまったりする。後々別の分析をしていく中で違和感が生じて初めてミスが発覚する、というケースも多々ある。
特に分析官の作業は試行錯誤も多いので、後から追随して検証できる形で残らない事も多くて、品質管理は中々難儀なものだったりする。
具体的な方法論としてはレビュー体制を構築したり、ペアプロみたいな取り組みの中で品質を上げていくのができる事だろうが、個人商店的なやりかただと難しかったりもする。最低限Notebookのようなものは残して、追随できる状況は作っておくのが良いだろう。(Excelが分析に向かない理由はここにあると思ってる。)
現実的には細かく検証するというよりは、既存の指標と見比べながら違和感を潰していく、というのが落とし所だろう。これをやるためにも、基礎的な指標とその在処はできる限り頭に入れておく、という事が分析官には求められる。と同時に、基礎的なデータは事前に準備しておく、というのも分析官に求められる業務の一つであろう。
私が個人的に見てきたケースだと、分析をしてみたら明らかに人口より多い人数が観測された、なんてケースはよくあって、（年収1000万円以上の人は5000万人います！みたいな分析が出てきたこともある・・・）こういった明らかにおかしな数値が出てこないように、データ全体のレコード数や顧客の人数など、基礎的な数字は抑えておく必要がある。
資源管理
資源は人的資源と物的資源におおきく分類される。データ分析における物的資源についてはデータそのもの、計算リソースあたりが存在する。
- 人的資源：人
- 物的資源：データ、計算リソース
これらのリソースは自社内部にすでにあるリソースを利用する場合は"資源管理"に、新たに社外から調達する＝契約が発生する場合は調達管理に、パブリッククラウド等を利用する場合は"コスト管理"の項目に該当するだろうか。
人的資源
人的資源管理は組織やプロジェクトによって必要性はまちまちだろう。おそらく若い組織、小規模な分析しかしていない組織についてはあまり関係無いだろう。一方で組織が大きくなってきて、一つの分析プロジェクトに複数名が関わるようになってきたり、複数人で分析を分担して受託するようなケースだと組織管理の必要性も出てくる。
分析組織としての案件の受託体制の構築や案件管理、チーム育成などがここに含まれれるだろうか。ここは単発のプロジェクトで必要になるケースはあまりないので少し毛色が異なるかもしれない。
一方で、複数人でデータ分析を回すようになると、**組織としての案件管理をどうするか、育成をどうするか、というのは必ず課題として上がってくる。**これも方法論はたくさんあるが、一つ一つを解説するとこれまたキリが無くなるのでここでは簡単に。
この領域で考慮すべきはおそらく下記のあたり。
- 案件管理（依頼管理）
- リソース管理
- 育成
これらに加えて、可能であれば
- 組織の規約
ようなものも作っておくと良いだろう。
私の見てきた範囲だと、依頼管理、案件管理にはJIRA等のいわゆるチケット管理ツールのようなものを使っているケースが多い様子。最近のうちの組織はMondayというのを使っている。とはいえこういったツールを宣伝するつもりは全く無くて、重要なのはどういうツールを使うかよりも、どういう管理体制を作るか、という方だったりする。
また、リソース管理という面ではチケット管理ツールにも大抵実装されているが、リソース計画と実績管理がごっちゃになりがちだったりすることも多いので実態としてはExcelなんかで管理しているケースが多い気がする。（いい方法あれば教えて欲しい）
育成という側面で言うと、データ分析スキルの中でもデータハンドリングスキルに関しては世の中に便利なコンテンツがたくさんあるので、そういったものを使うのでも十分だろう。一方、**そのドメインに独特のものについてはある程度教育コンテンツを考える必要はある。 **たとえば、その組織の商品構成やその商品に特有のデータ構造などがここにあたる。
教育と言っても誰かが誰かに教える、という形式にこだわる必要はなくて、読書会のような相互学習会のような形式もあるし、案件の事例共有みたいなものでも得るものは多い。いずれにせよ、知識を共有する場というのが必要になってくる。
組織の規約というのは、たとえば言語やフレームワーク、ツールの選択なんかが入る。ひとりで作業しているときはあまり関係ないが、複数人でレビューしようとしたときにかたやPythonかたやR、ではお互いにレビューするのは結構しんどい。結果として、レビューという作業自体がなあなあになるだろう。
ましてやダッシュボードとなるべきBIツールが混在すると管理なんてものがなくなっていく。ここのある程度チームとしての標準化、規約というものはある程度作っておいたほうが、チーム全体の総合力は上がっていくだろう。
物的資源
物的資源管理管理についても、組織によって必要性がまちまちだろう。データ管理（データマネジメント）については、冒頭でも述べたようにこれだけでかなり大きな分野になってしまうのでここでは詳しくは触れない。気になる人はDMBOKを読んでください。あらゆるデータを正しく管理する、というのはデータアナリストにとって最も重要なところである。
計算リソースの管理が必要な場合も多いと思われる。社内にすでに存在するリソースを利用する場合は、それらのリソースの稼働率などを加味し、必要に応じた利用制限が求められるだろう。特にアドホックな分析用の基盤が他の処理基盤に相乗りしているようなケースだと、リソース管理がうまくいかないと事故につながるようなケースもありうる。
ソフトウェア管理も同時に発生することがある。DBの選択や基盤の設計、ライブラリのバージョン管理など、データを取り扱うためのルールも同時に整理しないと、複数人で使ったときに突然ライブラリのバージョンに互換性がなくなり事故に発生する、なんてことも考えうる。
適切なリソースモニタリング環境の導入とそれらの利用方法の理解、事故防止のための適切な品質管理など求められるものは多い。これらは分析官が独自に実行するよりも、インフラエンジニアと協力しながら利用しやすい環境を作っていくのが重要になるだろう。
コミュニケーション管理
上述のスコープ管理、スケジュール管理や後述のステークホルダー管理など、あちこちに関わってくるのがこのコミュニケーション管理の領域。「コミュ力」という言葉があちこちで使われるようになっているが、分析プロジェクトマネジメントという視点で言うと、これらのプロセス全体を俯瞰して適切に関係者とコミュニケーションを取るスキルというのが求められる。
PMBOKのガイド的には、「適切に会議の場を設定し、報告をしましょう」という程度のものらしく、ここではモチベーション管理のような広義のコミュニケーションについては述べない。
コミュニケーションに必要なのは、まだ私も体系化できていないが下記あたりで整理できそう。
- 報告の場、内容、タイミング、相手
- 連絡の場、内容、タイミング、相手
- 相談の場、内容、タイミング、相手
報告、というのは言わずもがな、分析結果の報告である。いつ、どこで、誰に、何を報告するのか、は事前に決めておくのが良い、というのはスコープ管理の項で述べた通り。速報を出すのか、中間報告は入れるのか、最終報告に何を出すのか、どういう内容ができれば報告ができるのか。というのは細かく期待値の調整が求められる。
連絡、というのはプロジェクトに遅延が発生するときや勤怠の管理など、事務的な連絡が主になるだろう。連絡ルールを細かく作る必要はあんまり無いと思うが、場だけは設定しておいたほうが良い。メールか、電話か、SlackなのかTeamsなのか、Slackならどのチャンネルなのか。これはかなり依頼側の文化にも依るところはあるので予め確認しておくのが良いだろう。
相談がおそらく最も頻繁に行われる行為だとは思う。アウトプットしたデータに違和感がないかの確認であったり、進め方や優先度付の相談、議論は分析の場では頻繁に行われる。これらは**文字ベースの非同期なコミュニケーションだけで済むケースもあるが、会議のような形で同期的に議論したほうが良い場合も多い。**プロジェクトの規模感にもよるが、2週間以上かかるようなものであるなら定例会議を入れておくのが無難なイメージ。
### リスク管理
分析業務においてリスク管理はかなり難しくて、特に若いメンバーだとおざなりになりがちな部分でもある。ここも私自身リスクマネジメントの専門家というわけでもないので、まだ体系化しきれていない部分でもある。とりあえずのところは、下記3種類に分類してみる。
- 分析プロジェクトが失敗するリスク
- セキュリティやコンプライアンスのリスク
- 分析プロジェクトがうまくいったのに他に悪影響が出るリスク
1つ目は比較的わかりやすくて、たとえば「スコープマネジメントに失敗する」とか「コミュニケーションに失敗する」とか。最終的にこの手のミスはスケジューリングの失敗になり、納期までに良い分析結果が出ない、という形で終わる。
また、データを見てみたら思ってたのと違った、とか、データが思ってたほどきれいじゃなくて時間を要してしまった、みたいなこともありがちだろう。これらは実際に作業に取り掛かってみないとわからない部分でもあり、そういった場合のリスクについては予め対処の仕方や相談方法などを決めておく方が良い。
セキュリティリスクというのは、データ漏えいのようなものを指す。クラウドストレージを利用した結果、誰でも見られるような場所に誤って置かれてしまうなどは最悪の情報漏えい事故になりかねない。データの授受の方法によってはマルウェアの感染リスクなどもあり、データの授受は慎重に行われるべきだろう。
コンプライアンスリスクという側面では、例えば個人情報を取り扱うケースなど、分析官と言えどすべてのデータを詳らかに見るわけには行かない。取り扱うデータによっては法律の理解は当然として、一歩進んで情報の権利者の心象まで考えながら取り扱う必要がある。
分析を実施するにあたって、業務委託やデータの授受が発生する場合などは契約関係のリスクもつきまとう。後々のトラブルを避けるためにも、自ら契約書を読み理解すると同時に、できる限り法務の専門家への相談もしておいた方が無難であろう。
分析プロジェクトがうまくいったのに他に悪影響が出るケースはかなり厄介で、これはかなりドメイン知識に依存するものだったりする。わかりやすいところで言うと、個人情報を扱って分析するケースなんかがそう。分析として良い知見が出たのは良いけど、個人情報保護法的にはそもそも見ては行けないデータだった、なんて事があとから発覚する、なんてなったら分析どころの話ではなくなって情報漏えい事件になってしまう。
他にも、我々の中でよく議論になるのが、「分析をした結果自社に不利な結果が出たらどうするか」とか。広告の分析してると、自社と他社を比較して分析結果を出すケースは多々あるんだけれど、どうあがいても他社に負けてる、というデータしか出せないことがあって、自社に報告するなら良いけどクライアントに報告するのははばかられる、みたいなケースはある。
分析官はフラットに客観的であるべき、というのはそのとおりだけれど、結果として自分たちに不利な結果をわざわざ顧客にばらまいてしまい自分の仕事をなくす方向に結論づけてしまうわけにはいかない。自社に不利な結果が出たらどう報告するか、どういう対策を打つかはセットで考える必要がある。
他にも、分析結果はいい感じに出たけどバカみたいに計算リソース使いました、とか。分析頑張ったら計算リソース食いつぶして他の本番環境が止まってました、とかは実際によくやるしそれで何度も怒られてきた経験がある。
重要なのは、この手のリスクをすべて事前に予見するのは多分不可能で、不可能なりに知見をチームの中で共有しながら同じミスを起こさないようにしていく、ということだろう。この場合はリスク登録簿のようなものを作るのもありかもしれない。また、分析を進めていく中で新たに見つかったリスクについても、適切に対処・エスカレーションされるような体制やコミュニケーションフローも必要だろう。
調達管理
データ分析における調達というのは、
- 人的リソースの調達
- 計算リソースの調達
- データの調達
の3点がメインになるだろうか。資源管理の項で述べたとおり、自チームからの調達は資源管理に属する。こちらについては契約等が発生するような組織外からの調達を意識しておけばよいだろう。
大きな組織の場合は契約が発生しなくとも、ある程度担当者とコミュニケーションして成果を共有するようなプロセスが発生するケースもあるかもしれない。
人的リソースの調達、というのは組織管理の部分とも関連するが、必要に応じて分析官やデータ収集のサポートエンジニアリソースを組織の外から調達する必要も出てくる。小規模な分析プロジェクト、小規模な組織においてはあまり意識しなくていいだろうが、規模が大きくなると分析自体も役割分担がされていく事がある。
計算リソースの調達も、小規模な分析プロジェクト、小規模な組織においては必要ないだろう。一方で大規模な分析においては、リソースを自ら調達する必要が出てくることも珍しくない。単発の施策であればパブリック/プライベートクラウドを利用したり、長期的に必要なものであれば物理的なサーバーの調達も必要かもしれない。
計算リソースの調達は分析官だけではスキル不足に陥るケースも多く、システム管理部署などのエンジニアと協力することも必要になるだろう。
そして最も厄介なのがデータの調達である。分析をやりたいと思ったときに、必要なデータがすぐに揃う環境というのはかなり稀である。社内からの調達で済むケースもあれば、取引先などからデータを調達するケースもある。
調達の具体的な方法は多岐にわたるが、大抵は関係者とのコミュニケーションが必要となる。大抵、データの保持者にとってデータを渡すこと自体がコスト、もしくはリスクであり、なぜそのデータが必要かという説明が求められる。そのため、データの調達には事前にどういった分析を行い、どういった知見を見出したいのかという企画力が求められる。
また、手に入れたデータが思った以上に汚くて前処理に困る、というケースも往々にしてあるだろう。ただデータをもらうだけでなく、可能な限り詳細な仕様のレベルにまで落とし込んで調達ができると、後続の工程がスムーズに行く事も多いだろう。
ステークホルダー管理
最後、ステークホルダー管理。これも他のエリアと共通することが多いが、分析におけるステークホルダーは意外と広がっていく。
- 分析の報告先
- チームメイト
- 計算リソースの管理者
- データの管理者
- その他ドメイン依存の関係者
総じて言って、ステークホルダー管理については経験上、**各関係者にとって「何が嬉しいのか」というのを把握しておくとスムーズに行くことが多い。**各関係者の前向きな協力を取り付ける、というのがステークホルダー管理においては重要である。
分析の報告者は言わずもがな。社内の意思決定者であるケースと、社外のクライアントであるケースがある。特に社外への報告の場合は、間に入る営業やコンサルタントのような役割があったり、社外とは言っても対面の担当者からその上司や担当者のチームメイト、果ては代理店のようなパートナーまで、広がっていく事は多い。
関係者が多くなる場合は、ステークホルダー登録簿のようなものを作るのも一つの手だろう。業界の慣習や意思決定プロセスに影響を受けることも多い。
リスク管理の項でも書いたが、（広告業界はありがちなんだけど）正しいデータ正しい分析をそのまま出すとクライアントにとって良くても社内の営業にとってはNGだったりもする。その上、クライアント側も担当者とその上司で意見が食い違ったりする。それぞれが求めているものを判断して、それぞれに刺さるようなレポートを作り上げるのは中々に匠の技となっていく。
SIerなんかは二次受け、三次受けになることも多く、より複雑さを増す。各レイヤーがどういうビジネスをしていて、どういう分析結果が出たら得なのか、というのは常に気を配っておくのが良いだろう。
チームメイトについては組織管理の部分でも少し触れたが、品質管理のためのレビュー体制を構築したり、時にはリソースを融通し合ったりというコミュニケーションが発生する。本当の意味で全く同じ評価軸で同じ方向を向ける仲間というのは大抵ここにしか無いので、常にフラットに議論できる環境を作っておくのが重要だろう。
計算リソースの管理者は、自社内にあるケースとクライアント側から与えられるケースとあるだろう。システム管理を誰がやっているのか、リソースが不足したら、リソースに不具合があったら誰にどうやって相談すればいいのか、というのはある程度抑えておかないと、もしものときに余計なタスクが発生することになる。自社であれ他社であれ、ある程度の組織図は頭に入れておくとスムーズに行くだろう。
データの管理者も社内のデータであるケース、社外からデータを調達するケースとどちらもあるだろう。大枠は調達管理の項でも書いたが、データの仕様について担当者に確認する、というタスクはかなりの頻度で発生するので、常に問い合わせ先は抑えておく必要がある。特にデータの提供者側は、提供するメリットが何も無かったりするので、ここのコミュニケーションは慎重に行う必要がある。
まとめ
ざっと10の知識領域について思いつくままに書いてみた。
実際のPMBOKを見ると、この10の領域に対して、5つのプロセス群、49のプロセスで成り立ってるらしい。これを全部ひとつの記事に書くにはちょっと余白が狭すぎるので、機会があればちゃんとまとめたいところ。というかPMBOKを基準にして整理するのが正しいのかもあんまよくわからんので私はこう思う、っていうのがあればコメントいただけると幸い。
現実問題、データ分析が上手く行かなかった、とぼやくケースはよく聞くのだけれど、大抵は分析がうまくいかなかったというよりもプロジェクトが上手く言ってない、というケースが多い。
本音を言うと、このあたりのプロマネスキルとかは分析者じゃなくて依頼者側でどうにかしてくれよ、って思うこともかなり多い。コミュニケーション管理とか。けど実際のところ、分析者がある程度前のめりでやらないと後々回らなくなることも多いのでやらざるを得ないことも多い。うまく役割分担できている組織を作れると良いんだけど。
ただ、考え方を変えると、**「分析が上手く回せるなら他のプロジェクトでも上手く回せる」**という意味でもあると思っていて、特に若いうちにこういうちょっと大規模な分析、ちょっと小規模なプロジェクト、というのを体験できるのは、実はかなりキャリアパスを考えた時にも有利だと思っている。
ということで、データ分析をプロジェクトとして捉え、プロジェクトマネジメントをしていく、というスタンスで臨むと色々景色が違ってくるのでおすすめです、というお話しでした。