よくあるレビューの風景
担当者「〇〇と□□と△△を分析しました。レビューをお願いします」
責任者「お、いいですね〜。これ、どんな視点で分析したんですかね？ 大カテ、中カテ、小カテ、で言うと？」
担当者「資料の、この部分ですね」
責任者「うーん、この切り方だと、××が薄いですね。このカテゴリの周辺を変更してみましょうか」
担当者「はぁ」
責任者「これをこうして、こんな感じかな？ これまでの分析の文脈にのっかると、●●っていう分析もできるんじゃないですか？」
担当者「え？！ まじかー、これは気づかなかった・・・！」
専門的な内容ではなく大局的な視点で指摘して、面目躍如する責任者。
よくある風景じゃないでしょうか。
これは EDA は仮説生成が大事で書いた、広さ・深さ・構造を、責任者が修正しているお話です。
正直なところ、これを1人でやるのは無理ゲーじゃないか、環境がわるいとクソゲーになってしまうのではないか、と私は思っています。
要は、現場でデータ分析やAIの仕事をしている人が、上長に反論するための言い訳を考察してみたいと思います。
「広い」視点を、現場の作業者にやらせるの？
データが作成されるまでには、さまざまな人の行動や判断があります。それぞれの業務ですら、１人で仕事をしていません。仕事のプロセスの前後があります。
クライアントの業務をヒアリングしていても、
「え？ その発言、前後関係がつながってないんですけど」
みたいなことが多いです。
そんな状態で、データだけ分析担当に丸投げして、結果を出せ、って無理ゲーでしょう。
ここまではレベルが低いクライアントです。
デキるクライアントでも問題はあります。彼らの仕事は教科書的なベストプラクティスだけではありません。歴史的な経緯で一見非合理なプロセスを持っていることがあります。
「この業界、こんな感じだろう」
と分かったフリをして仕事をすると、
「なんで？ そもそもおかしくない？」
という EDA 以前のところにハマってしまうことも少なくありません。
業務の風景を「深く」想像することは超ムズイ
業務フロー・データフローを把握して、顧客にヒアリング。
まっとうにやるべきことをやっても、後から
「それ、聞いてないんですけど」
と重要な情報を聞くこともあるでしょう。
というのも、顧客の中で重要な情報が言語化されていない。なんとなくわかっているけど、業務の常識扱いされている。いわゆる「暗黙知」というやつですね。
言語化されていなければ、どう分析すればいいかわからない。
デザイン思考っぽく、現場を観察する、というやり方もあります。
でも、その手の専門家ではない人が観察しても、大事なポイントってわからないのではないでしょうか。個人的な見解ですが、実際に仕事して痛い目を見ないと、専門分野の重要な微差って理解できないし、気づかないと思います。だから、こんな記事を書いてます
。
洞察につながるような「構造」把握って、エンジニア・アナリストの仕事なの？
よくある技術系の人が書いた問題の構造化は、一般論で分解されています。大カテ・中カテ・小カテ・具体的な項目を上下関係で吟味すると、途中まではいいのですが、どこかで粒度の飛躍が起きています。
また、粒度が大きすぎるために、業務の場面がぼやけます。正しいんですが、生っぽさに欠ける。ありきたりの一般的なお題目が並んだり、可視化のアウトプットイメージがよくわからなかったりします。
「対案を出せ」って言われたら
上記のような言い訳をしても現場の仕事は楽にならないですし、対案を出して行動しないと環境を改善できません。
既出の記事とかぶりますが、ざっくり以下の方針があるのではないでしょうか。
① 得意な人と組む。
人材要件としては、以下ですね。
- データに関する、仕事のプロセス、関係者をまとめてくれる
- 暗黙知まで聞き出せる、超上手な質問をしてくれる
② 壁打ち相手を作る。
- 第３者視点で、自分になかった視点を提供してくれる
③ 小さく回す
- 気づけないのは仕方ない、人間だもの。その代わり、学習ループを高速に回す。
よくあるのは、「今できること」として③を採用しがちです。ただ、行き当たりばったりになるんですよねぇ。。。
①、②の人材がいなければ、マネジメント職の人ががんばるしかなくなります。
まぁ、マネジメント職に①、②をやらせようと
「あなたは、私よりお給料もらってますよね。いけてるところをみたいなぁ。え？ できない、なんていいませんよね？」
「で、できらぁ！」
と煽っても、後で恨まれるのがオチですよねぇ。
長期視点では、人材教育をする、
短期視点では、業務委託する、
あたりが現実的な路線ではないかと思います。