Data Informedな経営とはどういうものか考える
Amazonに入社して以来、5年ちょっとで100件を超える面接をしているのだが、その中でよく聞かれる質問に、"Amazonはどういった特徴の会社か"、というものがある。色々な回答があり得ると思うのだが、私がよく挙げる特徴の一つは、Data Informed decision makingをする会社だ、という点だ(私は個人的にData DrivenよりもData Informed、という言い方が好きだ)。
データに対する拘りと、また、それを一種の公共財のように社内で扱う仕組みは、入社時に大変感銘を受けた点だ。それまで投資銀行やPrivate Equityで働いているときには、"このデータありますか"、"ないです"、といったやり取りを飽きる程してきた気がするのだが、Amazonではデータがない、という返答は基本的に聞かない。その代わり、"このデータはXXXという場所にYYYというformatで格納されているので分析に時間がかかる"、とか、"データをとるためのInstrumentationを構築する必要があるのでXXXまでにデータを準備する"、というような、極めて具体的かつデータが取れるということを前提にした回答が多い。
私みたいなProduct Managerでも、SQLが書けたりPythonが書けたりすると多くのデータにアクセスできる、というのはとても便利であり、仕事の広がりを感じるところである。こういったデータを積極的に活用するようなAmazonの環境は、勿論、AWS Cloud Infrastructureの進化という面が非常に大きい(当然、AmazonはAWSを社内のほぼ全ての局面で使っている)。データを収集したり格納したり、それを活用するにあたっては、S3, EMR, Redshift, Glue, Athena, DynamoDB, Kinesis... 数えればキリがないほど便利なサービスが提供されている。これらはAWS Accountがあれば即座に使え、また、IAMを通じて連携が可能なサービスである。また、Sagemakerを始めとして、こういったデータを活用するためのサービスも数多く提供されている。
一方で、Amazonという会社は、こういったAWSの各種サービスが一般的に利用できるようになるずっと昔から、データというものにとても重きを置いて走ってきた会社である。思うに、何かを達成する場合には、"Will"と"Capability"の両方が備わっていなければならない。Cloudのサービスは、どちらかというとCapability、という話である。こういったCapabilityを使ってどんなInnovativeなことが出来るかは弊社のSolution Architectsなどのプロの方に譲るとして、私は"Will"の話を本稿でしてみたいと思う。
1. 存在しないデータは存在しない
出来の悪い哲学書のようなタイトルだが、Amazonではデータが存在しない、という事態が想定されていないように思う。データが手元にない場合、それは、必要なInstrumentationsが足りないか、Raw Dataを活用できる形にTransformするような基盤が構築されていないか、乃至は、統計的な手法を使うなどの努力が足りていない、などと考える。(実際はもう少し詳細に、例えばUnstructured info -> (encoding) -> data -> (data modeling/visualization) -> structured info -> (interpretation/inference/pattern recognition) -> knowledge -> (abstraction) -> wisdomというようなFrameworkなどを使って私は考えている)
一例を挙げるならば、私は新しい事業が好きな人間なので、あまりデータ基盤が整理されていないような状況のチームで働いていることが多い。こういった場合、できるものでなんとかしよう、ではなく、こうあるべきである、という最終形からWork backwardする。その中で例えばSoftware Engineerの時間を投資してInstrumentationsを作る必要があれば予算を取りにいくし、統計的なinferenceができるようであればそのようにする。"ここはデータがとれなそうだから諦めよう"ではなく、"どうやったらデータがとれるか"ということに注目しながら仕事を進めていくというのが基本的な考え方だと思う。
こうして集められたデータはMetricsとして週次や月次や四半期毎に然るべき立場の人にレポートされ、ビジネスやProductの健康度を図るツールとして利用される。尚、一度作ったMetricsはstaticなものとは考えられず、常に改良されていく。そもそもProductのライフサイクルと共に追いかけるべきデータは変わっていくはずなので当たり前といえば当たり前かもしれないが。そしてみんなこう言ったデータの改良にとてもオープンである。
尚、一部にはエクセルでデータを格納したり分析したりすることに対して揶揄する風潮も見えるが、私はエクセルなどによるデータ分析を一概に悪いとは思わない。できることからできる範囲で手を付けていく、という点で、データを活用するというWillがあるのは素晴らしいことだ。エクセルだろうがCSVだろうが、データはデータだ。そして、それをどうやってScalableにしていくか、というのは、まさにAWSがCapabilityとして様々なSolution/Toolを提供できるところだと思っている。
2. 業務上必要なデータは基本的にアクセス可能であるべき(PIIは除く)
プロフェッショナルファームにお勤めの方などは、案件をご一緒する事業会社さんに頼んだデータがなかなか出てこなかったような経験があるのでは無いだろうか。Amazonでは基本的にデータは開放されていて、Redshift ClusterのようなResourceがセットアップされていて(大概の場合されている)、かつ、クエリが書ければ、即座に大量のデータにアクセスすることが可能になっている。(勿論、PIIには重大な注意を払っており、住所やクレジットカードなどの個人情報、また、個人の特定に繋がるような情報はこの限りでは無い)
これは実務的な要請、という面もある。例えば過去のお客様の商品購入のトレンドというようなデータは確実に社内の多くの部署でアクセスが必要なものだ。もしこういったデータが開放されておらず、一々この購入履歴を管理するチームがデータを引っ張ってくるのだとすると、それはそのチームにとってとてつもないoverhead costになる。そういった不必要なコストを下げるという意味でも、データをオープンにしておくことの意味は大きい。
ただ、Amazonの場合、こういった実務的な理由とは全く別の次元で、データは必要な範囲で多くの人とシェアされているべきだ、という純粋な信念があるように思える。データを開放し、様々な人が様々な観点からデータを見ることによって、よりお客様にとってよいProductの開発ができると信じているのだと思う。これは私が好きなAmazonの企業文化の一つだ。
実際にProduct Managerとして、自分のコアな業務にあまり関係がないが、お客様のPain Pointを減らせるようなアイデアを思いつくことがある。こういった場合に、もし関連するデータへのアクセスが全くないと、次のステップに繋げにくい。当該業務を主に担当している部署に全くのデータなしで手ぶらで飛び込むわけにもいかないからだ。しかしながら、Amazonのようにデータがある程度開放されている環境であれば、関係するデータを自分でクエリを書いて取ってきて、初期的な分析をして筋がよいかどうかくらいの見極めはできる。その上で関連部署に持っていけば話はスムーズに進むことが多い。少なくとも自分はそうやって働いているし、自分のところに持ち込まれる他部署からの話の多くも、初期的なデータ分析は既になされているものが多い。
3. 経営陣がデータを尊重する
データを活用する上で一番やってはいけないと私が思っているのは、Leadership teamがデータを軽視することだ。シニアになればなるほど、長年の経験などから、データと反する直感を持っていることも多いだろう。そういった人が、"データには出ていないが私はこれが正しいと思う"、というような話を始めるとまずい。まずもって今後データを活用するような流れは起きない。あなたがシニアであればあるほど、データを尊重するべきだ。
Amazonで生まれた多くのビジネスも、直感的には???となるものが多かったと言われている。これは私が社歴の長い人に聞いた話(なので少し話の詳細はぼかす)だが、昔、とある大型プロダクトの提案をとてもエライ人にもっていったそうだ。データからすると、このプロダクトはとても有望だった。Six Pagerを使った長い長いミーティングの最後に、そのエライ人は、"これは私の直感と反するが、データが有望と示しているならやってみよう"、といって提案を前に進める決断を下したそうだ。結果として、当該Productは大きな成功を収め、今もRevenueを創出し続けている。経営陣がデータを信用して前に進むという決断をする姿勢は、Data Informedな会社を作る上で極めて大事だと思う。時に直感が実は正しかったとしても。
データが経営判断の材料として重視されないことが続くと、それは組織に大きなダメージを与える。まず、データを準備している側としてはなんのために働いているのか分からなくなる。これはモチベーションを大きく下げる要因であり、優秀な人材から会社を離れていくだろう。また、トップがこういった態度をとると、周りもデータを軽視してもよい、と思うようになる。結果として、質の落ちた分析部隊がトップの意向にそうようなデータばかりを出すことになる。トップの不用意な発言や態度によって、こういった組織体質を作り上げてしまうConsequenceは、失敗の本質を読むと非常によくわかると思う。
4. 一方でデータは多角的に検証されているべきだ
なんだか前項と相反することを書いているようにも思えるが、出てきたデータをそのまま信じてしまうのもよくない。というのも、データを纏めている本人にも（多くの場合自分でも気づかない）何らかの考え方のBiasや癖があることが多いからだ。したがって、データに対しては健全な批判精神を持って臨むことが望ましいと私は思う。
よくAmazonで言われるのは、お客様からのフィードバックなどのAnecdotesとデータがReconcileされない時は何かがおかしい、ということだ。こういった場合はどちらかが間違っている(乃至は両方間違っているのかもしれない)。データをとる最中に一部のデータがDropしているのかもしれない。分析で使っているモデルに何かしらの問題があるのかもしれない。クエリのJoinの仕方が変なのかもしれない。もしかしたらAnecodatesの解釈が若干違っているのかもしれない。大事なのは多角的な角度からデータを検証することだと私は思う(Anecdotesだって立派なデータだ)。そして、データを準備する側も、データに対する健全な批評を受け入れることが大切だ。
従って、前項との関連性を念頭に述べると、経営陣がデータに対して疑義を呈する際は、その反対意見自体がデータを元にしているものである必要がある。Amazonでよくあるのは、"それは私が顧客から聞いた話と違っている。この間XXX社のYYYという人と話した時にZZZというデータへの言及があったので検証して欲しい"、や、"他のレビューで出てきたXXXという数字と整合性がないがどう考えればよいか"、といった疑問の挙げ方である。こういった形だと、きちんとした論点として次回のミーティングなどでフォローアップすることが可能であり、かつ、データを見直したり、多角的に検討する機会を与えてくれる。
5. 専門家を雇い、信頼する
私もデータ分析をする人間であるが、道を踏み外さないよう一つ信念として持っているのは、専門性に対するRespectである。私は残念ながら法学部卒、MBAホルダーというガチガチ文系人間なので、データベースに対する専門的な知識や、高度な統計の知識や、MLやDeep Learningのテクニカルなドメイン知識を持ち合わせていない。勿論、色々と勉強はしている。痒いところにも手に届くAWSのサービスを組み合わせれば、POC的なものを作ることくらいはできる。が、そこ止まりである。餅は餅屋に。高度な仕事は専門家に。カエサルのものはカエサルに。
そもそも私が当然のように使用している社内のBig Dataのインフラも、多くの場合はこういった高度な専門知識をもった人たちが作り上げたものだ。個人的には、何か出来上がったものを使いこなすのと、何かを一から作り上げるという行為の間には、埋めがたいギャップがあると思っている。SQLやPythonがかけてちょっとした分析ができるからといって、自分で一から分析用のデータベースをきちんと構築したり、データパイプラインをベストプラクティスに沿ってきちんと構築したりできるわけではない。私のような人間には特に、このあたりの線引きが極めて大事だと思っている。
そして、私のように専門家ではない人間が、こういった専門家の皆さまからのインプットを受ける際に重要なのが質問力だと思う。前項で書いた通り、その意見をRespectしつつも、そのまま鵜呑みにはしない。ともすれば難しい専門用語で、"参りました"、と降参したくなることもあるが、そこはぐっと堪え、わからないことは格好つけないでわかるまで聞く。議論になりそうな範囲の議題は簡単に調べておいたり、また、過去に同じような議論をしたことがないか程度の勉強はしておく。尚、質問力はProduct Managerとしても大事だと私は思っていて、特に私のようにエンジニアとしてのバックグランドがない場合、デザインの段階などで正しい質問をする能力が生死を分ける(若干おおげさに聞こえるかもしれないが、結構本気で言っている)。
6. 完璧なデータなんてないのである程度の思い切りが必要
AmazonのLPには、Bias for ActionやAre Right, A Lot、といった、不確実な状況の中でリスクをとって決断することをリーダーに要求するものがある。これはデータを真の意味で活用する上でとても大事だと思っている。
意思決定に100%の解を与えてくれるような完璧なデータ、というものは存在しないと私は思っている。したがって、意思決定をする際には、かならずどこかでリスク(不確定性)をとらなくてはならない。これを理解しないまま、データが足りない、といって決断を遅せてしまうのは悪手だと私は思う。
とはいえ、闇雲にリスクをとればいいというものではなく、そこにはバランスが必要である。例えば、Amazonでよく使われるFrameworkに、One way door decision vs. Two way door deicison、というものがある。これらについては私が語るより、我らがFounder自身の声を聞いていただいた方がよいだろう。
尚、Jeff Bは毎年Shareholders Letterを書いているが、(私がAmazon社員だというBiasを加味しても)とてもQualityの高い、示唆に富む内容になっているため、興味のある方には一読をお勧めしたい。Amazonらしく、英語も極めて平易な単語を使って書かれたものになっている(弊社は無駄に格調高い言い回しを好まない)。
この記事が気に入ったらサポートをしてみませんか？