進化の先に理想のエンジニア組織がある─成長のジレンマを解消して進化するフューチャーの組織論

• ジレンマを解消しながら進化する組織
• 専門家とオーナーシップのトレードオフ
• 組織をリファクタリングしてホラクラシーに近く
• 組織の形が変わることでエンジニア個人も変わる
• チーム間の移動を容易にすることで成長を促す
• 進化の先にある理想のエンジニア組織

インターネットがビジネスに普及する以前から30年にわたり、日本を代表するさまざまな企業に向けたITコンサルティングを通して、企業経営の戦略システム開発を手掛けてきたITの専門家集団、フューチャー株式会社。

企業のパートナーとしてのIT構築を専門としていることから、エンドユーザーの目に触れる機会は少ない会社ですが、OSSやクラウド技術に積極的にコミットしていることで、その高い技術力に注目しているITエンジニアの方は多いでしょう。

「30年の歴史がある日本最初のITコンサルティング企業」と聞くと、悪い意味で旧来の日本型の組織をイメージしがちですが、フューチャーでは200名からなる優秀なエンジニアがフラットな組織の中で活躍しています。

顧客がいて納期もあるような業務で、エンジニア個人の力をいかにしてエンジニア組織として束ねることができるのか？ その難問に対するヒントを求めて、フューチャーのエンジニアチームを現在の形へと導いてきた宮原洋祐さんにお話を伺いました。

ジレンマを解消しながら進化する組織

──単刀直入にお聞きしますが、エンジニア組織に理想の形はあるのでしょうか？

宮原　社会的に「きれいで理想的」と評価される組織の形はあるかもしれません。しかし、現実の世界では、そういう「理想の組織の形を作って、それで終わり」というわけにはいきません。組織には、どうしても変化が求められるからです。

特にエンジニア組織では、エンジニアならではの考え方や感情に基づいた心理的な壁のようなものが常にあります。それによるジレンマを解消したり、トレードオフを織り交ぜながらバランスを取ったりすることで、エンジニア組織の形は段階的に進化していくと考えています。

逆に言えば、理想のエンジニア組織の形があるとしたら、その進化の先の結果論なのではないでしょうか。

──ジレンマやトレードオフには、具体的にどんなものがあるのでしょう？

宮原　例えば、個々のエンジニアが技術ノウハウを社外に発信することをどう考えるのかは、エンジニア組織が最初に直面するジレンマのひとつだと思います。

OSSが典型的ですが、ITエンジニアには、技術に関してオープンな活動を好む傾向が比較的強いと思います。一方で企業という立場で考えれば、技術ノウハウをオープンにすることにはリスクもあるので、クローズドな姿勢に軸を置きたくなる組織も多いでしょう。

──その点、フューチャーさんはかなりオープンな傾向ですよね。各社の所属エンジニアによるアドベントカレンダーでも、特に活発に見えます^{{$annotation_1}}。

宮原　あれも会社からの指示ではなく、みんなが自発的にやっているんですよ。今年は有志で公募したら一瞬で枠が埋まり、調子に乗って2枚目も作りました。

フューチャー Advent Calendar 2019 - Qiita
フューチャー2 Advent Calendar 2019 - Qiita

フューチャーはお客さまありきでビジネスをしているので、エンジニアもR&Dのようなセクションではなく、全員が顧客と納期がある業務に就いているわけです。にもかかわらず、あれだけ外部発信をしたいというカルチャーがある。オープンに舵を切っているので、そうしたカルチャーを好むエンジニアが集まっているとも言えるでしょう。

もちろんクローズドな方向に舵を切ると決めて、技術ノウハウをしっかりと蓄積することで、そのようなカルチャーを好むエンジニアが集まるケースもあり得ると思います。

専門家とオーナーシップのトレードオフ

──いずれにせよ、人が増えれば、組織は変化を余儀なくされそうですね。

宮原　はい。人が増えていくフェーズでは、経験上、主に効率の観点でエンジニア組織はトレードオフを迫られます。オーナーシップを重視して、チームなり個人なりで成果を競い合うか。それとも協調することによって、技術ノウハウが組織に蓄積されることを重視するか。そのトレードオフですね。

エンジニアによってはフルスタック指向を好む人もいて、そうするとオーナーシップ重視に傾きがちですが、組織としては技術ノウハウがたまりにくかったりします。そもそも組織が大きくなるにつれて、全員がプロジェクトに対するオーナーシップを抱くことが難しくなる面があります。

かといって、個々のエンジニアがある特定のスキルに対する専門性を発揮できる組織にすればいいかというと、それはそれでうまくいくとは限りません。実際、フューチャーでも、プロジェクト横断的な専門家チームを増やしてみたものの、思うようにいかなかった経験がありました。

特にまずかったのは、プロジェクト横断的なレイヤーを増やしたことです。するとどうしても、その中で専門の専門へとさらに細分化していきます。「ぼくはクラウドが専門だ」、さらに言えば「AWSだけをやる」といった感じです。

技術アセットがたまるメリットはあったのですが、プロジェクトに対するオーナーシップが欠如することでフルスタック指向のエンジニアに違和感を与えてしまい、チームとしてうまく機能しなくなってしまいました。

──その状態はどうやって乗り越えたんですか？

宮原　ある程度のテーマ性に応じてチームを分け、そのチームの中でいくつかのプロジェクトに取り組む、というように組織を変えていきました。ここでいう「テーマ」とは、クライアントの業種であったり、扱う技術の種類であったりです。

現在、そうしたテーマ性を持ったチームが全部で16あり、それぞれ5人から30人のエンジニアで構成されています。そのチームも新たに生まれたり、統合されたり、役目を終えて発展的解散したりと、活発に動いていて固定的ではありません。

テーマ性を持った1つのチームは、協調的なエンジニア組織として機能するので、その中で技術ノウハウも蓄積できます。そういう意味では、1つのチームがまるで1つの会社の機能を全て持っているイメージです。

実際、各チームを分社化してもいいくらいだと考えています。

──機械学習のような専門分野でも、チームごとにエンジニアがいるのでしょうか？

宮原　専門性が極度に要求される分野については、テーマ横断的なレイヤーとしてチームを分離し、そのチームが全社的に協調型で取り組んでいます。

もともとミドルウェアの分野はそうした横断的なチームで扱っていました。今は機械学習、それにセキュリティについても、テーマ横断的なチームで扱っています。

さきほど、専門のレイヤーを増やした結果うまくいかなくなった時期の話をしましたが、いま思い返すと、そのときの試行錯誤が荒治療になって、「どの分野にテーマ横断的なチームが必要か」が判明したという面はあるかもしれません。

──それぞれのチームには、ほとんど1つの会社のような自律性があるわけですね。

宮原　はい。結果として、今ではホラクラシーに近いエンジニア組織が出来上がったと思います。

組織をリファクタリングしてホラクラシーに近く

──ホラクラシーという組織形態について説明していただけないでしょうか。

宮原　ホラクラシー（holacracy）は、ヒエラルキーのないフラットな組織形態の一種です。それぞれのメンバーやチームが自律的にビジネス上の意思決定をできる点が、単なるフラットな組織とは少し違うと言えます。

強烈な課題認識や目的意識が共有された上で、それに共感した個々のエンジニアが、自身のできること／やりたいことを取捨選択しながら自発的につながって、プロジェクトが形成されます。個々のエンジニアが緩くて強いゴムのようなつながりになるので、仕事や環境や技術の変化に柔軟に対応ができることや、自身のチャレンジを自ら設定できる点が特徴かと思います。

ただ、収益性や技術的な成長といったビジネス上の要請はあるので、チームごとに自分のチームのプロモーションをしたり、自分たちがやっている仕事を別のチームに向けて言語化したりするといった自律性は必要です。

ヒエラルキーがないので、管理されることを好まないエンジニアにとっては働きやすい組織だと言えます。一方で、ゴールイメージが希薄だと、延びるとすぐ切れてしまうつながりになり、うまく機能しない組織の形でもあります。

組織をホラクラシーにするか、それとも一定のヒエラルキーを残すかということも、ある段階でエンジニア組織が直面するジレンマのひとつです。

フューチャーの場合、ホラクラシーを目指してこうなったというより、会社としてエンジニア組織のカルチャーは定めつつも、あくまでもエンジニアが主役になって顧客の課題解決に取り組めるよう、組織をリファクタリングしていったことで、結果的にホラクラシーに近づきました。

──単なる組織変更の繰り返しでなく、リファクタリングであるということは、変更の効果を測定するユニットテストのような指針があるのでしょうか？

宮原　あまりいい指針でないのは承知の上で言うと、直接には「エンジニアの出入り」がそうした指針に相当すると思います。実際、専門レイヤーを細分化するように組織を変更して、結果としてうまくいかなかったときは、エンジニアが会社に定着する率が著しく低下しました。

また、エンジニアが外部に発信するブログ記事など、アウトプットの総量も気にしています。冒頭で「オープンかクローズドか」というジレンマの話をしましたが、フューチャーでは守秘義務の範囲内で外部発信が自由なので、エンジニアに余裕があれば、記事などの発信量は増えます。反対に、仕事が面白くなかったりすると、発信量は減ります。

アウトプットは、エンジニア個人に対する評価としても重要ですが、その総量をまた「エンジニア組織が今うまくいっているか？」を表す指標として利用しているということです。

組織の形が変わることでエンジニア個人も変わる