この本読みました。
の読書録の続きです。
内容の要約も書いているので、この記事と合わせて読んでみてくださいね。
刺さったフレーズ
さらに重要なこととして、人々の所有物が増えていった。このことについて、ルソーはなんといっただろう。「最初に誰かが、杭や溝で土地に囲いをして、これは俺のものだ、と言うことを思いついた」。そこから、すべてが悪い方向に進みだした。もっとも、土地、動物、さらには人間まで個人の所有物にできることを、人々に納得させるのは難しかっただろう。なにしろ狩猟採取民は、ほとんどすべてのものと共有したからだ。そして、所有の始まりは、不平等の拡大を意味した。誰かが亡くなると、その人の所有物は次の世代に受け継がれた。この種の継承が当たり前になるにつれて、貧富の差が広がった。
Humankind 希望の歴史 (全2巻)
ここで言っているのは、個人を対象にしていますが、もっと範囲を広げてみると、企業や組織にも当てはめて考えることができると思います。
企業は持っている資産を共有することはありませんし、倒産するまで資産を所有し続け、また、資産を活用し競争力を磨いて業界の中で盤石な地位を築いていきます。
例えば情報資産という観点において、技術的なスキルやノウハウを長期間にわたって脈々と引き継いで、磨いていきます。
資産を所有し続ける結果として、企業間で強い・弱いという不平等（＝競争力）が生まれていくと考えることができます。
ところで、「情報資産」を強みにしている会社というのは、個人のスキルを磨くという観点では都合の良い環境です。
ある企業が強みの源泉にしているスキル領域と個人が伸ばしたいスキル領域が合致したほうが、スキルの取得は効率的にできます。
データサイエンスを生業にしたいなら、古くからデータサイエンスを武器にしている企業に身を置くべきで、給料がよさげな大企業に勤めていてもデータサイエンスの領域で一角の人間になるのは難しいか、時間がかかるというのは納得できますよね。
データサイエンス協会によれば、データサイエンスは3つのスキル領域で規定されていて、ビジネス力（コンサル力）、データサイエンス力、データエンジニア力です。
私はコンサルティング会社のデータサイエンティストとして働いていますが、中にいて感じるのはコンサル力が強く、またこのスキルを重要視する文化があるように思います。
※ただし最近はデータサイエンス力が強い人がたくさん集まってきていて、フルパッケージよろしくって感じですが、、、
わかりやすく極端に言うと、コンサル力がベースとしてあって、その上にアドオンする形でデータサイエンス力やデータエンジニア力が加わっていくというような考え方をしています。
コンサル力を一言でいえば、分析とビジネスにつなげるスキルです。
分析をしてはいるが、「ビジネス貢献できた！」と自信をもって言えない、そんなモヤモヤをいただいているという人には是非身に着けてほしいスキルです。
手っ取り早く身に着けたい人はコンサル会社の門をたたくか、コンサル出身の人の下で働くのが良いと思います。
そんな急すぎるよという人がほとんどだと思いますが、そういった方は、どういったスキルなのかということを理解して足りない部分を日々の業務に取り入れもらうところからチャレンジしてみてほしいです。
ということで今回は、コンサルティング会社で効率的に取得できるデータサイエンティストのコンサル力って何なのか？という点について記事にしてみました。
コンサルスキルは4つ
顧客は売上だったり、コストだったり何かしらのKPIを改善したいという目的があります。
データサイエンティストは分析をして対応策を立案したり、機械学習で直接的にKPIを改善するためのAIを開発するという形で貢献していきます。
この文脈において、コンサル力を考えてみると、以下の4つに分解できるかと思います。
- ビジネスを理解し、いくつかの分析テーマを立案すること
- 各テーマに対して分析計画を立てること
- 分析を実行して、ビジネスアクションを抽出すること
- ビジネスアクションをとってもらうこと
それぞれについて詳しく見ていきましょう。
分析テーマを立案すること
分析プロジェクトは改善したいKPIがどういう要素で成り立っているかを理解し、いくつかの分析テーマを立案することから始まります。
例えば、なにがしかのサービスを想定してみましょう。
サービスを業務の集合体としてとらえれば、営業機能、マーケティング機能、運用保守機能、コーポ機能などに分解することができます。（組織図に紐づけるイメージ）
そして、それぞれの機能に分析として貢献できるポイントを見出していきます。
そうすると複数のテーマが勝手に浮かび上がってきます。
この例は抽象的ですが、マーケティング機能などに絞って、業務を分解して考えていくという方が、実態に近いかもしれません。
このフェーズではヒアリングしたり、企画書を作成したりなどやることはたくさんありますが、個人的に一番気にしたいのは、顧客側で分析をどこまでできているのか？という点です。
分析が一定程度進んだところで、それはもうわかってますが、みたいな反応があると目も当てられません。
「うちの組織は勘で物事を進めてしまっているんです・・・」というような顧客の”盛った”発言にをうのみにしてチェックをおろそかになっているケースは散見されます。
何もやってないというのは稀です。さすがになんかしてます。
その点は注意しておきましょう。
分析テーマ立案はいかなる時も考えてお必要がある
テーマ立案するのは初期のフェーズだけでなく、プロジェクトが走っている最中でもあります。
そう頻繁に起きることでもないのですが、顧客のビジネス状況が変わったり、分析結果からもっと筋のよい方向性を見つけた、逆に、筋が悪いということが分かったタイミングなどでは仕切り直しということでテーマを再検討していく必要があります。
いずれにせよ前提条件が変わっているのに、同じテーマを盲目的に継続するようなことはやめましょう。思考停止です。
潮目の変化を察知したタイミングでは、必ずテーマの再検討をしましょう。
計画を立てること
テーマ化することができたら、タスクに分解してスケジュールに落とすこと、体制を組成することをしていきます。
個人的にはタスクに落とすところが最も大事で、スケジュール、体制はタスク内容や量に対して従属的に決まっていきます。
状況にもよりますが、タスクは大きく二つに分解されてデータの授受や基盤の構築など分析環境に関する事と、どう分析していくかという手法やアプローチについてに分解されます。
注意したいのは、手法やアプローチについてです。
個人的には基礎集計を”しっかり目”にやるような、フィージビリティが高いアプローチをとることがおススメです。
機械学習モデルを構築するようなケースであったとしても、最初は基礎集計をしっかりやったほうが得策です。
いきなりモデルを作るというのは論外として、モデル構築前に基礎集計をやっているケースでも、その実としてグラフや表を量産しているだけで解釈がほとんどないケースは散見されます。
こんなのは分析ではなく、作業です。
”しっかり目”にやるというのは、「仮説検証しよう」、「分析結果をビジネス的な示唆が出るレベルで解釈しよう」ということになります。
計画段階でクラスタリング分析や機械学習など高度な分析を標榜していたとしても、基礎集計をしっかりやることで、そんな難しい分析する必要あるのか？という考えに至ることはよくあります。
ビジネスアクションを抽出すること
計画を立てることができれば、いよいよ分析に突入します。
具体的には、前処理などデータのハンドリングをしたり、集計用の分析マートを作ったり、可視化して分析結果を解釈したりしていきます。
特に注力したいのは分析結果を解釈して示唆を抽出することです。
依頼した人からすれば成果（ビジネス活用への示唆など）が唯一重要で、それを判断するのは可視化結果の解釈です。
その過程にある集計用マートなどの成果物ではありません。
可視化結果の解釈において大事なことは、当初想定していた仮説や通説に引っ張られないことです。
先入観を持たずにファクトを解釈することが大事です。
計画段階でもくろんでいたことが崩れそうなファクトが出てくると、それを隠したり、無理な解釈をするケースが見られますが、そういうことは絶対にしないでください。
計画が崩れてしまうことをネガティブに感じて、焦ってしまう気持ちはわかりますが、当初立てた計画なんて精度が低かったと捨て去る勇気が大事です。
ただし、インパクトが大きな示唆については、データが間違っていないか？をチェックすることは忘れずにしましょう。
「やっぱり間違っていました」なんてことが起こってしまうと、それ以降の分析結果に対しても信用できなくなりますからね。
ちなみに、類似した記事を過去に書いているので、そちらも参照していただけると幸いです。
ビジネスアクションをとってもらうこと
分析プロジェクトを通してわかったことからいろんなアクションが抽出されます。
分析結果から立案したアクションを整理して、顧客側で検討しやすい形にしておくことは最低限やりましょう。
そこから一歩進んで、誰と相談しながらアクションを具現化していくかなど施策を推進していくうえでの論点をつぶしていきます。
データサイエンティストの役割じゃないだろというつっこみもあるかもしれませんが、どこまでやるかは自分がどこまでコミットしたいかであったり、スキルと相談しながら決めていけばいいと思います。
一方、”データサイエンティスト”として確実に貢献できるようなケースもあります。
ここでは具体例として、効果試算と説明行脚の二つを取り上げたいと思います。
効果試算
Aという施策が分析結果から立案されたとき、やった方がいいというレベルの根拠では意思決定できないので、効果試算をしたいというケースはまぁまぁあります。
予算が必要だったり、体制を組成する大きな話であったりすればなおさらです。
効果試算をするには仮定・前提は必要ですし、どこまでの精度を求めるかなどで工数も大きく変わってきます。
期待値を把握し、必要十分なものを作っていくことが肝要です。
分析者は性癖として精度を求めてしまいますが、顧客の心の声は「そんなに精緻じゃなくていい気もするけど、やるって言っているし、ロジックも良くわからないし、まぁいっか」と心の中では思っていたりします。
あくまで期待値にあったレベルの物を作ることが重要だと思います。
精度やロジックの妥当性にこだわって、納期が遅れたりしては本末転倒です。
ちなみにですが、
過去を振り返ると私は効果試算には懐疑的な人でした。
試算するには仮定に仮定を積み重ねる必要があり、信頼できる試算結果を出すのは結構難しいからです。
また、怪しい数字を出すくらいなら別の分析をした方が良いという考えを持っていました。
ですが、分析結果からやったほうがいいと断言できるアクションがとられない一方で、やめた方がいいアクションンが実行されることを目の当たりにした経験を境に、「実行させるまでがデータサイエンティストの仕事」と思い、考えを改めるようになりました。
今では多少精度が悪くてもいいから、効果試算をするようにしていて、場合によっては試算結果を突きつけて意思決定を迫ることもあります。笑
説明行脚
周りを巻き込んでいく必要があるケースでは分析結果の説明行脚をしていくことがあります。
突っ込んだ質問が来た時の応対や、解釈をしっかり伝えるという観点では、話し手であることが望ましいと思います。
この時にあくまで分析者という中立的な立場をとろうとする人がいますが、何か物事を動かしていくという局面においては意見を持つべきですし、中立的な立場は存在しないと考えてほしいです。
意見を持っていればこそ、制約や課題が見つかったときにではどうすればいいか、分析で対応する方法はないか、という思考ができます。
ちなみにですが、行脚をすることでいろんな立場の人とディスカッションすることにより分析テーマが見つかったり、別口の案件が拾えたりするので積極的に関わっていくことをお勧めします。
まとめ
今回はデータサイエンティストのコンサル力とは何なのか？ということを考えてみました。
今回改めて言語化してみて、コンサル力はほとんどすべての分析プロジェクトで活用可能な、汎用的なスキルだと感じています。
ちなみにですが、コンサルスキルが身についていることを実感してからは、キャリアに対して不安※を持つことが少なくなりました。笑
※今の職場以外で自分は通用しないのではないかという不安
もし、コンサルスキルを身に着けたいと思うなら、コンサルティング会社でデータサイエンティストやるのが手っ取り早いです。
そんな急すぎるよという人は、どういったスキルなのかということを理解して足りない部分を日々の業務に取り入れもらうところからチャレンジしてみてほしいです。
以上、刺さったフレーズと活用についての考察でした。読書でキャリアを開拓しましょう！
コメント