熊崎 宏樹:眼の前の仕事を上手くやる、という技芸レベルの話では実はそれほど他社との決定的な差はなく、組織として上手く行ってるのはとにかくスケールする事を意識しているのがポイントではないかと思っています。 組織構造のデバッグが上手 仮に全社員が優秀で与えられたタスクを誠実にこなしていても、組織を大きくしていくと部署間で細かい矛盾が起きたり正義が衝突することは珍しくありません。また衝突しなくても特定の問題を解決する部署が事実上存在しなかったり問題自体が放置される事は一般的な組織において珍しくありません。 Googleが組織として上手くやっているなと感じるのはそういった組織内での矛盾を早期に見つけて自発的に解決しようとし続けているという点です。技術の創造と設計という本から図を引用しますと このように組織内での分担は膨らんだり縮んだりするのが自然の流れですが、現状の自組織が何を見落としているかを積極的に見つけ、組織の再編によってデバッグする事でみんなが働きやすくなるようにしているようです。単に組織再編だけなら大抵の組織で行われている事ですが、それによって構造レベルのバグを取り除くという力強い意志を感じています。大量のサービスが時に惜しまれながら終了しているのはもしかしたらその片鱗かも知れません。 日本の会社については詳しくないので伝聞からの推測ですが、組織レベルでの目標を見失わずにメタなレベルでのデバッグを繰り返し行っている会社としてはリクルートがそれに近いのではないかと想像しています。 文化の洗練に多大なコストを支払っている また大企業において、間接的に数百人という部下を抱えるクラスの人の発言は本人不在のままでも部下の間で繰り返し再生産され伝言ゲームが行われ、出席していない会議においてすら影響を及ぼすものですがGoogleの偉い人は何万回再生産されても構わない正しい事を文字通り部下全員に向けて直接発信しています。よくニュースサイトで「スンダー・ピチャイCEOが全社員向けに伝えたことによると…」などといった文字列が出ますがこれは本当に文字通りヒラ社員隅々まで受け取ることになるメールで直接語りかけています。CEOレベルでなくてもVPなどのそれぞれも結構な頻度で部下全員に何を目指して行くべきかを伝言ゲームではなく直接的かつ具体的に伝え続けています。 Googleの偉い人が具体的に何をやっていたのか、というのを元VPレベルだった人がブログに公開していましたが、文化を維持して高めて行くのに弛まぬ努力が必要なので「まるで職場の花に水をやるように」忍耐強く繰り返し力を加え続けることが重要であったとの事でした。こうして一歩間違えば壊れたレコードとでも評されてしまうような複雑な事を適切にやり遂げるのは特定の年数働いて自動的に昇格しただけの人間には荷が重すぎます。文化を動かし発展させることができる人間をどのように見つけ出すのか僕には想像も付きませんがそれを上手くやれているのがGoogleを他にない会社にできている要素ではないかと想像しています。 超人が頑張れば3人分ぐらいの仕事ができるかも知れないにせよ、100人の部下の生産性を1割高められれば10人分の仕事が出来たと換算できるので、組織が大きくなるにつれ「自分以外のみんなの生産性が上がる」という事自体に掛けるべき比重が上がっていきます。それが組織をスケールさせるという言葉の意味であり、昇進するに伴い適切に難度の高い仕事を優秀な人に割り当てていく継続的な仕組みの良し悪しがゆくゆくは会社の命運を左右することになります。「Work Rules」とか「Googleのソフトウェアエンジニアリング」などの本には嘘は書いていないので書いてあることを真似れば確かにGoogleっぽい会社を作ることは可能かも知れませんが、それはあくまで会社のハードウェアの話であって、文化という究極のソフトウェアは書籍化しようが社長がトップダウンに推し進めようが一朝一夕では模倣出来ませんし、そこに真の組織的強さがあると感じています。 Googleは明らかに僕より賢い人が作り上げた仕組みなので僕の貧弱な知力では解釈して説明できるのはこれぐらいですが、何かの参考になれば幸いです。

鈴木 一生:今よりも少し前、まだ Google が社会的影響力のある巨大企業というより、革新的でクールな会社というイメージが強かった頃の話になります。 ミッションが明確で、職位を問わず各人が go / no-go を判断できること Google は創業以来 «organize the world's information and make it universally accessible and useful»（世界の情報を整理して誰もが便利に利用できるようにする）というミッションを掲げていますが、これが従業員に深く共有されていました。 その結果としてプロジェクトで次に何をやるかといった議論を行うときにポジションを問わず短時間で同じ結論にたどり着くことが多く、無駄な議論に時間を費やしたり、方針が二転三転することが少なかったです。 データ主導型開発 プロダクト開発の初期から成否を図るメトリクスを定義し、意思決定をデータに基づいて行います。たとえば画面のデザインを変更する際、まず一部のユーザに試験的に新デザインを表示し、それによってメトリクスがどのように変化したかを分析。その結果を元に新デザインを全ユーザに提供するか、それとも旧デザインに戻すかを決めます。 今では A/B テストは広く使われていますが、Google はかなり早い時期からプロダクトの開発フローに組み込んでいた記憶があります。データドリブンの開発を行うには、メトリクス計算に必要なデータの収集ロジックをプロダクトに埋め込むとともに、データを蓄積し解析するインフラ（昔だと MapReduce とか）も必要となります。開発を急ぐと後回しにされてもおかしくない分野ですが、常に高い優先順位で取り扱われていました。 他にも 従業員が基本的に優秀で「この人と議論しても時間の無駄だな」と思うことが極めて少ない、助言を求めると気前良く対応してくれる人が多い、（創業者が経営に直接関与していた時期には）意思決定が早くコミュニケーションがオープンで従業員の経営層に対する信頼度が高かった、昇進プロセスが極めてフェアで直属のマネージャーの影響が限られたなど、様々な理由があると思います。 今は Google も巨大企業になり事業分野も広がったのに加え、経営者や人事評価プロセスなども変わったため、必ずしも当時の「組織的強み」が今日まで残っているとは限りません。また、上で挙げた強みは相互に影響しあっているため、一つだけ取り出して自社に取り入れても機能しないと思います。