▶平日 毎朝7時に公式LINE@で新着記事を配信しています。友達申請はこちらから！
▶ICCの動画コンテンツも充実! Youtubeチャネルの登録はこちらから！
「イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント」【K16-8D】セッションの書き起し記事をいよいよ公開！10回シリーズ(その9)は、Google徳生さんに、Googleの組織づくりについてお話いただきました。Amazon Web Serviceに在籍していたソラコム安川さんと、GoogleとAmazonの組織の違いについての議論が盛り上がりました。是非御覧ください。
ICCサミットは「ともに学び、ともに産業を創る。」ための場です。毎回200名以上が登壇し、総勢800名以上が参加する。そして参加者同士が朝から晩まで真剣に議論し、学び合うエクストリーム・カンファレンスです。次回 ICCサミット KYOTO 2018は2018年9月3日〜6日 京都市での開催を予定しております。参加登録は公式ページをご覧ください。
▼
登壇者情報
2016年9月6日・7日開催
ICCカンファレンス KYOTO 2016「ICC SUMMIT」
Session 8D
「イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント」
（スピーカー）
大宮 英紀
株式会社リクルートライフスタイル
執行役員
菊池 新
株式会社ナビタイムジャパン
取締役副社長 兼 最高技術責任者
徳生 裕人
グーグル株式会社
製品開発本部長
平栗 遵宜
freee株式会社
執行役員 開発本部長
（モデレーター）
安川 健太
株式会社ソラコム
取締役CTO
▲
▶「イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント」配信済み記事一覧
【前の記事】
【本編】
安川 ちょうどグーグル社の話が出ましたので、続けて伺いたいと思いますが、スライド上の右上の図がグーグル社の組織ですね。
イメージ図から考えるGoogleの組織
徳生 左上のアマゾン社との違いは何だろうと先ほどから思っていたのですが。
安川 より細かくチームが分かれているというイメージでしょうか。
徳生 後は、縦割りになっていないところが違いかもしれません。
実際にこのような感じで、指揮系統は、例えば製品ごとにトップがいて、Searchであれば、ジョン・ジャナンドレア（John Giannandrea）がいて、YouTubeであればスーザン・ウォジスキ（Susan Wojcicki）というように、それぞれのプロダクトのトップは決まっています。
安川 この辺りでしょうか。
徳生 そうですね、この図でいうと創業者やCEOに該当するのかもしれませんが、仮に一番上が検索のトップだとしたら、その下にVPクラスが何人かいて、そこからチームがいくつかぶら下がっているという形です。
皆さんの会社と同じで、プロジェクトはレポートラインと関係なく出来上がることが多いのですが、レポートラインの人が、メンバーの成長などに責任を持っています。
得てしてレポートラインよりもプロジェクトの方が流動的に変わっていくので、半年くらい経つと、後追い的にレポートラインが変わるというような形も多く見られます。
その中で、他のチームや他のディレクター、他のVPに割と気軽にメールを打て、コミュニケーションを取ることもできます。
そういう意味で、この図にあるアマゾン的か、この図にあるグーグル的かと問われれば、グーグルの方に非常に近いと思います。
GoogleとAmazonの組織づくりの違い
安川 なるほど。私はアマゾンにいた経験もありますので、AWSのサービスチームで考えると、この絵は割と正確だと思います。
AWSというセクションがあり、その下にデータベースサービス、コンピューティングサービスというように分かれていて、その中に各種AWSのサービスがあり、更に各サービスの中のコンポーネントチームがあるというような感じです。
グーグル社の場合は、私のイメージでは、非常に小さなチームが動的に作られるのではないかと思っていますが、その点は合っていますか？
徳生 そうですね、2005年に初めて入社した時のことが強く印象に残っているのですが、その前に200人くらいのベンチャー企業にいまして、結構クセのある会社で、鍋蓋式と言いうか、社長が1人いて、その下に200人が並んでいて、その間の調整は、200人の調整能力で何とか成り立っているというような会社でした。
その会社のような体制は200人くらいが限界だと思っていたのですが、2005年に当時7,000人のグーグルに入社した時の印象はまさに「変わらない！」でして、各人、各プロジェクトが信じる道を突き進み、各人の調整能力で会社全体が成り立っている、という印象がありました。
ですので、先ほどの開発にあたっても、10人のチームが、全てのレイヤーの機能を作るということは弊社では非常に少ないので、いろいろなところと調整する必要が出てきます。
調整というと響きが悪いですが、他のチームが何を作っていて、どんなものがあるかを知ることはコストですが、そのことを勉強しておかなければ、モノを世に出すことはできませんし、そのことを知っていれば、よりよいソリューションを提供できる可能性が高まります。
ですから、ソフトウエアエンジニアにしてもプロダクトマネージャーにしても、成果を出していくためには、そういったプロアクティブ・アラインメントというか、自分自身できちんと調整しながら、そことあそこと組んだ方がより良い成果が出せるということを見極めていく能力が、非常に重要になってきます。
そういう意味では、このような形で、時には平のプロダクトマネージャーがチームのディレクターに直接メールを出して、何とか話を勧めなくてはならないというようなシチュエーションは結構出てきます。
安川 なるほど。
テックトーク等で社内で何が起こっているか共有
菊池 プロダクト間のコミュニケーションは結構活発になさっているということでしょうか？
徳生 プロダクト間というのは例えば、検索とアンドロイド間などですか？
菊池 はい、そうです。
徳生 それは意図的にしていかないとなかなかできないので、例えば検索とアンドロイドのVPが定期的に話し合うミーティングなどがあるので、方針的に揉めそうな話があればそこに持っていて議論することができます。
菊池 エンジニア同士ではいかがですか？
徳生 そうですね、まずは現場で話しますね。
ただ、目指す方向性が各プロダクトのゴールと逆だというようなことも稀にあるので、そういう時には、上にすぐ問題を上げてしまった方が話が早いと思います。
平栗 私からもひとつ伺いたいのですが、例えば、平のソフトウエアエンジニアが、社内でどういうプロダクトが、どういう開発状況で進んでいるかということを把握するための情報の整理というのはなさっているのでしょうか？
徳生 情報の整理については、どのチームもドキュメンテーションはしっかりしようと努力してはいますが、半分くらいはドキュメントに残らない形でのコミュニケーションが展開されているというのは、どこでも変わらないと思います。
幸いなことに、リフレッシュサイクルがそこそこ速いので、古いものを学ばなくても、新しいものを聞いていればある程度の全容がわかる。テックトークなどで追っていったり、後はマネージャーがそういった情報をチーム内でシェアしたりします。
「こんな話があったのに知らなかった」という場合には、本人が勉強不足だったケースがあるかもしれませんし、マネージャーが知っていたにもかかわらず情報の共有が徹底していなかったケースもあるかもしれません。
社内で何が起こっているかを理解するということは、コストとしては高いですが、非常に重要な要素だと思っています。
（続）
続きは 【最終回】エンジニアハピネスを生み出す組織とは？ をご覧ください。
https://industry-co-creation.com/management/10360
編集チーム：小林 雅／榎戸 貴史／戸田 秀成／鈴木ファストアーベント 理恵
【編集部コメント】
続編(その10)では、最適なチームサイズやプロダクトの継続的な改善等、イノベーティブなプロダクトを生み出す秘訣について議論しました。是非ご期待ください。他にも多く記事がございますので、TOPページからぜひご覧ください。
更新情報はFacebookページのフォローをお願い致します。
