根回しはオランダにもある

日本で働くうえで物事を円滑に進めるために「根回し」という、意思決定をする本番の会議の前に、個別の事前会議をキーマンと持ち、合意を取り付け、各キーマンの意向も取り入れ、本番の会議はそれのおさらいをするだけの出来レースになるという行為が行われる。よくこの根回しは日本独自の文化であり、非効率的、ムダが多く海外とくに欧米ではそのようなことは通用しないという意見があるが、実際にはオランダでもやっている。

もちろん頻度や程度は日本よりは軽いが、根回しはグローバルに有効な手段として存在するのである。特にビジネスコンサルティング出身の人はよくやる。複数人の合意を取り付けなければいけない案件であれば、全員を一度にミーティングによぶより、個別に撃ち落としていくほうが効率がいいし、対外それらの複数人のキーマンというのは似たようなポジション（Directorなど）で、お互いがライバルで、同じ会議だとお互いの意見を意識しあってしまったりして、ディスカッションの方向が良からぬ方向にいくリスクもある。そうなるとその人たちのほうが政治的パワーが上なので、軌道修正がむずかしくなっていしまう。

なので、個別セッションで個々人の意見を取り入れ、一個一個承認を得ていく日本式の「根回し」は有効なのである。

ロビー活動というのがあるが、これも同じである。ロビーの語源はホテルのロビーに出たり入ったりするということだと聞いたが、ようは政治というロビールームと、外部の経済界を行ったり来たりしながら、経済界のやりたい方針を政府の方針に入れ込み、かつ政府が利権を持てるように経済のほうにもインプットをするという人や活動のことを指す。これこそ根回しだけを本業として日夜動き回っている人が長く欧米にも存在することの証左である。

オランダ人のプロアクティブネス

オランダの人のメンタリティーにはプロアクティブネス、つまり自発的に物事をやるというのが染み付いている。中でも具体的な例が自分の誕生日パーティーを自分で開催するという発想である。
オフィスでもよく同僚が自分でケーキを持ってきて、チームメンバーに会議案内を送って、プチ誕生日パーティーをやっている。六年もオランダに住んでいると当たり前に感じてしまうが、オランダに来た当初は軽く驚愕したものである。
なぜなら日本では大人が誕生日パーティーを自分からやるというのはまずないし、やっても若干目立ちたがりのやつ、みたいな冷たい目線で見られがちである。
そもそもその日本の発想が間違っていて、自発的に物事をやること、引いてはリーダーシップの育成を阻害すると思うが、オランダは何でも自分でやっちゃう文化なので、誕生日会も自分でやる。
これは自己アピールの能力の育成という意味でも素晴らしい。自分の存在を周りに知ってもらうには非常に良い手段であって、それが認められていることも、自己肯定感のアップにもつながるのだろう。

続Overlap分析

前述のOverlap分析で非常に助けになるのがGoogle Location Serviceである。住所などのインプットパラメータを受け取ると、Google Place Idという世界中のいかなる場所であっても特定可能なIdを返してくれる優れものである。いわば世界中の住所の、標準化された規格に則った背番号である。

https://developers.google.com/maps/documentation/geocoding/overview?_gl=1*azzd11*_ga*OTk4MTMxMDc5LjE2ODYwMjE3MDc.*_ga_NRWSTWS78N*MTY4NjAyMTcwNi4xLjEuMTY4NjAyMTgwMS4wLjAuMA..

これは地理データを扱うデータ分析者にとっては夢のようなデータで、あらゆる地点の重複・非重複の判別が、国や地域の言語の差や、郵便番号のような企画の違いに翻弄されることなく、全く同じアプローチを一気に世界中のあらゆる国に当てはめてしまうことができる。

データ分析の歳代のボトルネックがデータ準備であることは言うまでもないが、データ準備で気をつけるべき点の一つが「統一化されたデータ定義」であるのだが、その実現の妨げになる最大の難関の一つがケースバイケースの異なるロジックの当てはめである。郵便番号は国ごとに桁数も違うし、数字だけですべてが表される国もあればそれプラス「−」が入る日本のようなケース、あるいはオランダのようにアルファベットが入って「1111AB」のようになるケースなど様々である。

Google Place Idはこれらの課題をすべて払拭してくれるという点で非常に画期的である。

ただし気をつけなければいけないのがコスト。1000コールで$5がスタートで自身のコールしたい頻度と都度のボリュームで当然コストは変わる。

日次でコールするのか月次でコールするのかで30倍の差である。

https://mapsplatform.google.com/pricing/

そのため事前に綿密なデータ収集プランが必要になってくる。

Overlap分析

実在する店舗を相手にしたビジネスにおいては、競合他社も同一の店舗に対してサービスを行っているかを分析することは非常に意義がある。食べログやトリップアドバイザーのようなアグリゲーターや出前館のようなフードデリバリープラットフォーマーの店舗リストを入手することができたら、自社サービスを展開している店舗とのoverlapを把握することは、自社サービスの次の展開を考える上で非常に有益である。

さてまずどうやってデータを入手するか。現在の世の中にはデータスクレイピングサービスベンダーというのが山ほどいるので、データ入手のプロセスはアウトソースできる。あるいは簡易なデータスクレイピングツールも色々あるので、それらを活用してデータを入手できる。

次にデータを入手した後にどうやってoverlapを把握するか。これがなかなかの困難である。なぜならば、同じ店舗の名前や住所は、プラットフォームによって違う表記になることがよくあるのである。日本のデータにはあまり馴染みがないが、例えば同じマクドナルド渋谷店でも、

• 出前館：マクドナルド渋谷店
• UberEats：McDonald's渋谷店

と異なる言語表記で表されることは多くある。ヨーロッパは言語が違えどアルファベットはほぼ同じ、ほとんどの名前は英語表記で統一されているのでやや難易度は低いが、日本の場合はヨーロッパよりも難易度が高いと思われる。

さて、名前や住所が店舗を特定する上で必ずしも頼りにならないとするとどうすれば良いのであろうか。緯度経度（longitude/latitude）が住所の代替手段となる。大抵のウェブサイトは、地図に店舗の場所を表記するために緯度経度情報が載っている。目に見えない形であっても裏のhtmlあるいはバックエンドシステムのAPIはこの情報を返してくる。

緯度経度データが取れれば、あとは昨今のデータウェアハウスは二点の緯度経度をインプットにした直線距離をアウトプットしてくれたり、同じ場所であるか判定してくれるファンクションを備えているのでそれを使えば地理上の同一地点かどうかは判断できる。

• Google Biq Queryの例：

  cloud.google.com

前後するが地理上の同一/近似地点かどうかを判断しても、名称はその上で必要である。なぜなら同じ地点であっても、ショッピングストリートやショッピングモールであった場合、どの店舗かをさらに特定する必要があるからである。そのためREGEXなどを用いて何とかして名称データをきれいにする必要がある。

なお、名称の近似値をスコア化し、閾値を敷いてYES・NO判定するのにLevenshtein Distanceなどを使う。

そして名称・地理地点が同じであれば同一の店舗を意味していると判断する。

Fast paced companyで働くということ

私が勤務している会社はいまやヨーロッパはおろか世界でも名が通ったテック企業なのだが、いわゆるfased paced companyで、物事の進みが異常に速い。じっくりゆっくり時間をかけて稟議している暇はなく、どんどんとことが進んでいくし、複数の重要案件が並行してものすごい速さで進んでいく。データの需要は旺盛で、みんながみんなデータを今すぐ欲しがるので、四六時中あれくれこれくれという依頼が、Slackのダイレクトメッセージやグループチャット、Eメールにビデオ会議といろんなルートからやってくる。全部に対応するチームのキャパシティーはそもそも無いし、一番の問題は真面目に真摯にぜんぶの依頼に対応しようとすると、自分がやろうと目標を立てた仕事ができなくなってしまうということである。

そしていつしか受け身で仕事を捌く体質になり、受け身で捌いた仕事は依頼者は評価されるが真摯に対応したこちらは全く評価されずに、お前何か仕事してるの?と冷たくあしらわれてしまう始末である。完全な悪循環。

なので根本的に仕事に対するスタンスを変えないとまずく、自分がこれをやるんだという確固たる意志と、自分の時間の割り振りの優先順位付けが非常に大事になってくる。

そもそも全ての仕事をこなそうと思ってはいけなくて、自分のやりたい（「やるべき」ではない）仕事のプライオリティ123はこれで、それをまずやってから、あるいは一段落したら、他人からの依頼を捌く、という割り切りがひじょうに重要である。さらに難易度が高いのは、自分のチームメンバーに対してもどうようの意識付けを徹底すること。大多数の人間はセルフスターターではないのであり、他人に頼まれるとついつい応えたくなるものである。

結果的にこの自分あるいはチームに対する意識改革で一番効果的なのは、単純に一枚の優先順位付けリストを作っていつでも見えるところに貼っておく、あるいは都度都度そのリストを見直して、何を優先するんだっけ?という問いを立てることだったりする。

データ分析からビジネス課題の解決までの道のり

データ分析がいかにうまくできても、ビジネス課題の解決に活かされないければ、元の木阿弥である。しかしこれが非常に難しい。どれだけ多くの時間と労力がデータ分析に費やされ、しかしビジネスの意思決定者に聞く耳を持たれず、聞く耳を持たれたとしても戦略の方向性やその時々の重要課題の違いにより、浪費され使われずに忘れ去られていることか。。。

無論私にとってもこれは非常に大きな課題である。正直に言って、自分の分析が本当にビジネス課題の解決に使われたケースを思い出す方が難しい。

なぜこのような現象が起こるのか。私が思うに、データ分析者はデータの分析までで仕事が終わってしまう、終わってしまっていいと思っていることが多く、その先のエクセキューションはビジネス部門に頼っていることが多いのである。もっとも組織の役割分担を考えれば、それは真っ当なことなのであるが、それでビジネスに活用されないと嘆いているぐらいであれば、役割分担など忘れてしまって、ズイズイとビジネス部門の役割である例えばセールスの現場への指示と結果のモニタリングを、全てやるというのではないが、あくまでプロジェクトをリードする立場として入り込んでしまうのが得策である。というかそうしないとこの課題は解決できない。

要するに、データ分析者であるという役割や立ち位置は忘れてしまって、何が何でもこのインサイトに基づいてプロジェクトを成功させる、前に進めるという気概が必要である。結局のところ仕事というのは、最後は何処までこだわってやり切るかである。

分析チームを率いる

分析チームを率いるかいかなるチームを率いるかを問わず、チームを率いるというのはすごく難しい。チームは大概意図しないことに時間と労力を費やしてしまい、期末に思ったような結果が実現されないものである。昨年の経験を踏まえると、それは実はチームを率いるリーダー、つまり私自身が本当に何を実現したいのかわかっておらず、わかったような気になって指示をしていたため十分なエネルギーを伴って伝えられておらず、メンバーは半信半疑だったということがよくあるのである。

つまりまず自分が次の四半期でチームとして何を達成したいかをまず自分自身で理解する。

OKRのO，Objectiveを明確かつ簡潔に定義する。しかしこれが難しい。難しさは実は自分の仕事への挑み方に起因する。受け身でビジネスから要件が降りてくるのを待っている考え方だと、要件が変わるごとに右往左往するし、それをみたメンバーはリーダーにネガティブな印象を抱くし、そもそもリーダーとして主体的に考えるクセがつかない。与えられた責務とリソースと自分のキャリアプランまでも考慮して、主体的にある意味傲慢に自分勝手に「チームはこれをやりたいのである」と高らかに宣言する。そこで日本人らしい謙虚さや他人への配慮は無用である。海外においてはそれは害になることのほうが多い

OKRを定義することはすなわちYealy planningとほぼ同義であるが、その動機の違いに敏感にならないといけない。精緻にエクセルでサマリーレベルからタスクレベルまできれいに階層的につながったプランを定義して進捗管理を行うことが目的ではなく、チームの全員が完全に何をするか理解することが目的なのである。緻密なプランニングはすなわち誰も何するかわかってない状態を誘発しがちである。

簡潔にわかりやすくチームが向かう方向性を示すことが大事である。そのためにはOKRの作成過程にチームメンバーを巻き込むこと、ニ週間に１回などの高頻度で一人づつと話し合いを持つことが大事である。期中で話し合いを持って方向性を修正してもかまわない。全員がfully on boardでon the same pageになることが大事である。