データ分析チームにおけるプロジェクトマネジメント
データ分析を行う上でも、他のITシステム導入プロジェクト同様、プロジェクトマネジメントは非常に重要である。ここでいうプロジェクトマネジメントとは、プロジェクトのゴール設定と、その実現に向けたタスクの定義と、タスクの進捗管理・遅延リカバリのための対策の定義である。
データ分析という世界においては、その発生起源が比較手に新しく、また用いられる手法が新しく、いわゆるレガシーシステムや古いプログラミング言語に依存しないため、きちっとしたプロジェクト管理がさほど必要ではない、あるいは好まれない傾向がある。
多分この点は、使っている技術が柔軟なプロジェクトの変更を許容している面も多分にあるが、携わっている人の嗜好上、プロジェクトの目的や手法を柔軟に変えたいという理由も多分にあるのである。言い換えると、その時々の状況や気分でやっぱこうしよっと、とアプローチを変えたほうがいい結果が出るよねというアナーキストがデータ分析者には多いのである。
だからデータの世界には永久ベータ版が多い。ここでいうベータ版とは必ずしも試作品という意図で言われているのではなく、より良いバージョンがすぐ出るからいちいち品質管理に工数かけないからちょっと不具合あるかもだけど、出しちゃうよ、それでいいよね、という意味である。
90 - 00年代のガチガチのソフトウェア開発プロジェクト管理をすた世代にとっては、日本人だけでなく、どこの国の人にとっても、品質管理をしていないソフトウェア・サービスを世に出すということは信じがたいことであり、自身の怠慢を世にさらけ出していることに他ならないので、絶対に許されないことなのだが、今は2020年。それをよしとする作り手と消費者が多くなってきた。ましてや総じて若い世代が多いデータ分析の世界は物心ついた頃から永久ベータ版がスタンダードな世界で生きているデジタルネイティブが多いのである。
と、ゆるいプロジェクトマネジメントを肯定するような話を書いてきたが、私個人は大いに否定派である。理由はいたってシンプルで、ゆるいプロジェクト管理、あるいはノー管理でプロジェクトを進めた結果、膨大な手戻り作業が発生したのを多々目にしているからである。
ではクラシックソフトウェア開発風のプロジェクト管理が是かというとそうでもない。要件定義書、詳細設計書、テスト仕様書、単体結合テストのエビデンス取り、種々の会議の議事録取り。。なんてやっていたら一向にプロジェクトは終わらない。というかデータ分析において仕様なんて固められるわけがない。レポーティングは別だけど。
なので正解はその間にある。なんいていうと、曖昧感が満載で参考にならないという反論があるのは承知で、実際そうなのだが、こればっかりは経験をもとにさじ加減を調整するものなので、誰でも再現可能な方法論というものに落とし込むことは出来ないのである。
ただ方法論化できる部分も無くはなく、ありきたりな答えだけど:
1.データ分析の目的を明確化し、プロジェクトが迷走したら、なんでやってるんだっけ?解決したいビジネス課題ってなんだっけ?に立ち戻る
2.タスクとアウトプット、責任者と優先順位を定義・文書化する
3.週次などの定例会議で責任者に、タスクをやったかやってないか、やれてなかったらなんでか、一つづつまめに進捗を把握する
いわゆるコンサルティング会社のPMOの役割である。しかしながらデータ分析者はこういう嫌われる、面白みのない、しかし重要な作業をやりたがらないので、それが出来るとあなたのデータ分析の世界における市場価値は実は非常に上がり、世界中どこに行っても重宝がられること間違いなしである。