急成長『Box』の技術チームを率いるサム・シュアレス氏が挑む、新たなマネジメント手法「ホラクラシー」とは？

2015/04/17公開

エンジニアとして過去に6回の起業を経験。そのうちの1つがGoogleに買収され、のちにGoogleドキュメントとして世界中のユーザーに使われるようになる――。

そんな華々しい経歴を持つシリコンバレーのエンジニア兼実業家、サム・シュアレス氏。現在は、順調にユーザー数を伸ばしつつあるクラウドデータ共有サービス『Box』のエンジニアリング担当シニアバイスプレジデントを務めている。

そんなサム氏が、4月7日～8日に開催された新経済サミットのトークセッションに参加するために来日したタイミングに合わせ、エンジニアtype編集部はサム氏への直接取材を行った。

数々の起業に成功してきたサム氏がサービスも組織もスケールアップの段階である『Box』をどのように成長させ、そしてこれからどのように拡大しようと考えているのだろうか？

25年間に渡りシリコンバレーの最前線で活躍を続けるサム氏の口からは、Google在籍時の貴重な経験談やシリコンバレーの最新の組織論「ホラクラシー」など興味深い話が次々と飛び出した。

緻密な計画作りは、多くの場合徒労に終わる

エンタープライズ領域でシェアを伸ばしているオンラインファイル共有サービスの『BOX』

―― 『Box』のユーザー数や導入社数は、現在どういった状況でしょうか？

2005年にリリースされたBoxは、今では世界で4万5000以上の企業や組織に導入され、ユーザー数は3400万人以上にのぼります。サービスとしても成長を遂げると同時に、私が入社当時は80人だったエンジニアリング部門のメンバーが、現在では300人規模になりました。

―― メンバーがこの2年で80人から300人以上に増えたのは、職場環境としても大きな変化ですね。現在の組織体制はどのようになっているのでしょうか？

エンジニアリング部門はプロジェクト毎に少なくて2人、多くて9人程のスクラムを組みます。どのようなメンバー構成にするかは現場のエンジニアたちに任せていますし、プロジェクトが進行する中で有機的に構成を変えることも認めているので、ユニークな組織体制といえるのではないでしょうか。

Boxの開発において、「セキュリティ」と「サービスの堅牢性の担保」に注力しながら、いかに迅速なリリースを行うことも常に心掛けています。そのため、開発においてはスクラムプロセスを採用。エンタープライズ向けのサービス企業では珍しいのではないでしょうか。

―― スクラムプロセスは最初から採用していたのでしょうか？

その通りです。プロダクトを開発する中で、優先事項は頻繁に変わりますし、それに対応しなければいけません。多くの企業では、かなり先まで計画を立てプロセスを遂行していきますが、計画通りにいかず、掛けた労力が無駄に終わることも多くあります。

そこで、我々は効率よく、柔軟性を保ちながらソフトウエアの開発を行うためにスクラムプロセスを採用しました。

―― 長期的な計画を立てないとのことですが、ビジョンの共有はどのように行っているのでしょうか？

年の初めに、私と製品担当の責任者で、ビジネス面、技術面含めた組織のハイレベルな戦略を定めます。その戦略を元にいくつか戦術的で具体的な目標を10〜15のプロジェクトとしてリスト化。さらに、チームごとに補完的な目標を追加していくことで、ビジョンの共有を行っています。

エンジニアが秘密裏に新UI開発プロジェクトを発足

―― プロジェクト単位における各チームは、どのような組織体制なのでしょうか？

チーム内の組織体制もエンジニアたちに任せています。リーダーが指揮を執るチームもあれば、フラットな関係で仕事をするチームもある。

1つ共通しているのは、常にマネジャーがいて、業績や人事の管理をしているということです。ポイントは、マネジャーが必ずしも指揮を執るわけではないということ。エンジニアがリーダーになる時もあります。

我々の組織図は、私のような立場の人間がエンジニアの上にいるのではなく、エンジニアの下にマネジャーがいる、という考えで成り立っています。

マネジャーももちろん大切ですが、会社として最も重要だと考えているのがエンジニアの存在です。

―― そういった開発体制を維持する上では、「働く環境の自由度」と、「チーム間のコラボレーション」が必要不可欠だと思いますが、エンジニアが働きやすい環境を維持するために、どのような工夫をしていますか？

エンジニアに、常にスタートアップの精神を維持しようと働き掛けることですね。つまり、楽しい職場、インフォーマルな環境、そして常にオープンであるということです。

具体例としては、オフィスの机は仕切りがなく、常にさらされた状態になっていて、見渡せば他のメンバーの様子を見ることができ、チーム間で自由にエンジニアが交流できるのです。

また、『スカーワークスプロジェクト』と呼ばれている、エンジニアが自ら立ち上げて秘密裏に行うプロジェクトがあります。

現在、新しいUI開発が進行中なのですが、当初私はこのプロジェクトの存在すら知りませんでした。先ほどお話した「あべこべな組織図」については、こうした事例からも理解していただけるかと思います。

こうすることで、社内の政治的な要素を排除し、タスクに集中できるという狙いもあります。

Google時代の経験から学んだオフィスに集まる重要性

Googleドキュメントの生みの親としても知られるサム氏は、同社でエンジニアリングリーダーを務めたことも

―― エンジニアの創造性を引き出すためにどうすればいいのでしょうか？

さまざまな要素があります。

まずは、私も含めリーダーがエンジニアが持つ創造性を理解し、受け入れる姿勢が必要です。私が依頼していないことも自発的に行い、時には秘密裏にプロジェクトを進めていても、それをうれしく思うことが大事。

リーダーとして、チームメンバーを細かくコントロールしたい、自分の指令だけを忠実にこなしてほしい場合、創造性は生まれないでしょう。

また、冒険をすることでエンジニアは創造性を発揮すると私は考えています。

Boxでは1年に数回、社内でハッカソンを行っているのですが、メンバーはビジネス面を考える必要がない、自由な開発にとても積極的です。そうした経験が日々の仕事にも還元され、エンジニアにとって大きな見返りとなります。

そして、もっと大切なことは採用時点から創造性に富む人を選ぶことです。

―― 創造性がある人を見抜くのは難しいように思います。

私は採用候補者に必ず「仕事以外に、趣味としてどういったことに取り組んでいるか？」ということを聞いています。なぜなら、創造性に富んだエンジニアは常に自分のプロジェクトを仕事以外に抱えているからです。

仕事には全く関係ないとしても、そこには何かしらのクリエイティビティがある。それが、現時点では価値を生み出さないとしても、きっと将来何かにつながるはずです。

―― これまでのお話から、Boxの開発体制はとてもオープンで、自由な印象を受けますが、リモート開発についてはどのように考えていますか？

エンジニアの自主性は尊重していますが、私はリモート開発には否定的です。Google在職時に、8つの地域にいるエンジニアを統括して開発を行っていましたが、コミュニケーションの点で非常に苦労しました。その経験から、リモート開発は非効率的だと学んだのです。

だから、Boxではサンフランシスコ全域でシャトルバスを運行して、毎日オフィスに通勤してもらうことにしています。これがBoxのエンジニア文化の醸成、そして生産性の向上のために必要だと考えています。

―― なるほど。最後に今後のBoxの展望をお聞かせください。

まずは、今まで話したようなスタートアップ精神を途絶えさせないように努めていきたいです。ただ、サービスが順調に成長し、会社の規模が拡大することにより、新たな課題も発生してきます。

例えば、人数が増えれば増えるほど個々人に与えられるタスクを細分化する必要がある。そうすると、それぞれが孤立化してコミュニケーションが失われてしまいます。そういう組織は、Boxが目指す、オープンで活発なスタートアップ精神に富んだエンジニアリングチームとは違ってきてしまう。

そこで、今はヒエラルキーを設けない、タスク中心の組織マネジメント手法「ホラクラシー」を倣って試行錯誤をしているところです。シリコンバレーでもMedium社をはじめ、いくつかの企業が導入しています。

実は、フラットな組織、オープンな職場、社内政治の排除など今までお話した内容も、ホラクラシーの手法の1つなのです。我々が理想とする組織体制にするための正しい答えはまだ出ていませんが、より良いサービスを提供するための組織づくりに努めていきたいです。

取材・文／長瀬光弘（東京ピストル）