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

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

インターネットがビジネスに普及する以前から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）は、ヒエラルキーのないフラットな組織形態の一種です。それぞれのメンバーやチームが自律的にビジネス上の意思決定をできる点が、単なるフラットな組織とは少し違うと言えます。

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

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

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

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

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

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

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

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

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

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

──ホラクラシー型の組織は、自社の事業に向けたWebサービスやアプリを開発している企業でこそ実現可能性がありそうに思えるので、受託開発を専門とするフューチャーさんでうまくいっているのはとても意外です。
　顧客からの要請に応じてエンジニア組織の形を調整することはないのでしょうか？

宮原　クライアントの要望に忠実に対応するだけの開発なら、そういう必要もあるかもしれません。

クライアントの会社に立ち寄ってその業務に詳しくなる要員と、そうやって上がってきたクライアントの要望を解決する要員、という役割分担が固定化するケースですね。フューチャーにも、コンサルタントがクライアントと会話をして、エンジニアがそれを聞いて実装するという形になってしまっていた時期がありました。

そのような受身的な発想、いわゆるSIerの発想でエンジニアが仕事をこなすだけでは、クライアントの技術課題を解決するインフラは作れても、その課題が解決したら終わりです。現在の組織では、クライアントの話をエンジニア自身が聞き、その課題解決に取り組むことになります。

さらに言うと、ホラクラシー型に近い組織になったことで、エンジニアのマインドも変わってきました。

──エンジニア組織の形が変わることでエンジニア個人も変わるというのは、それだけ聞くとギャップがある話に思えます。どういうメカニズムがあるでしょうか？

宮原　クライアントは、極端に言えば、相対的には技術を知りません。技術が分かっているエンジニアの方から、クライアントのビジネスに合わせて話をすることで、エンジニア自身が技術でクライアントを誘導し、クライアントの将来価値を上げる仕事ができるケースが出てきました。

相手の要望に忠実に対応する仕事の進め方が徐々に減り、個々のエンジニアがクライアントの課題解決に貢献しようとする状態と言ってもいいと思います。

さらに「同じ技術課題を抱えた境遇の人が、目の前のクライアント以外にもいるのではないか？」という視点も生まれるようになりました。これは言い換えると、「自分たちが持っている技術をどんな使い方で利用すれば、市場からより評価されるのか？」を意識できるようになったということです。

こうした考え方の変化は、クライアントの業種が異なっても通用します。チーム内は協調的なので、そうしたナレッジがシェアされることで、チームみんなの意識も上がっていきました。今のフューチャーのエンジニア組織が、自律的なホラクラシー型になっているのは、こうしたエンジニアの進化の結果でもあると感じています。

──なるほど、まさにチームが1つの会社のように機能しているイメージなわけですね。しかし裏を返すと、エンジニアにも経営者目線が必要という話にも聞こえます。

宮原　クライアント側に立つという意味ではそうかもしれません。

ポイントは、クライアントが考えていることを知り、市場から求められる技術の使い方を見出せるのは、エンジニア自身しかいないという点です。それをヒエラルキー的に上から押し付けるのは無理ですし、それをするのはIT企業であることを否定するようなものだと思います。

エンジニア個人としては、いま会社や社会が必要としている技術は何だろうか？ 将来はどんなスキルセットが求められるだろうか？ といった観点で考えることが、最初のステップになる気がします。

コードを書き続けていればいいか、マネージャーの役割になるかというよりは、マネージメントとエンジニアリングを一人の中で共存させるという発想に近いかもしれません。

チーム間の移動を容易にすることで成長を促す

──そういうエンジニアだけが残った可能性もありそうに思えますが、採用や研修に何か特別な点はありますか？

宮原　技術指向があるかどうか？ という前提はありますが、すでに備えている技術力よりは、ポテンシャルを評価して採用しています。

現在では、毎年エンジニア組織に1チーム1人くらい、合計で15人くらい新人が入りますが、研修での成長率によってエンジニアチームへの配属が決まります。プログラミング未経験でも、研修中に競技プログラミングを始めたり、自分からエンジニア組織に入りたいと言ってくる人ですね。

──200人もいると、ホラクラシー型のカルチャーに合わない人もいると思いますが。

宮原　まったく合わない人はそもそも入社に至りませんが、他の会社で受託開発の経験が長いと、最初は苦労する場合もあるようです。特に中途採用で、それまでヒエラルキー組織でやってきた人は苦労しているように見えます。

組織の形を継続的に進化させてきた結果とはいえ、ホラクラシー型に近いので、年次が上でSIerから転職してきた人の中には、最初のうち何をしていいか分からなくて苦労する人が、どうしても出てしまいます。

──それでもうまくいっている要因は何でしょうか？

宮原　入社してしばらくは個別にメンターが就くので、そうしたケアはメンターが行います。メンターは、業務のチームとは別に、その人のタイプを見ながら何人かを推薦して、選ぶようになっています。

それから、なるべくチーム間の異動が簡単にできるように心がけています。人の割り当てに流動性がある状態を維持することで、エンジニア組織のカルチャーが伝わりやすくなることをすごく大事にしています。

──エンジニア個人からすると、チームが不意に変わることに対する抵抗があったりしませんか？

宮原　エンジニア個人の環境に変化がないということは、チャレンジする要素が少ないということです。成長率を測るための手段がなく、個人の伸びしろが見えなくなっている状況です。エンジニア組織として見れば、血行不良の状態だと言えます。

そういうとき、エンジニアの選択肢は「転職」になりがちです。しかし、それは会社としてはあまりうれしくありません。そのためにも、チーム間での異動をなるべく簡単にしているという面はあります。

チームが、結果的に1つの独立した会社のようになっているので、その間で移動すると事実上の転職と同じ効果が得られると言ってもいいかもしれません。

本人の希望を聞いた上で、別のチームとの掛け持ちを増やしたり、徐々に異動したりできる流動性が維持されていれば、エンジニア組織の血行不良もリファクタリングできます。

進化の先にある理想のエンジニア組織

──ここまでお聞きしてくると、エンジニアがオープンに情報発信が可能で、かつホラクラシー型の組織というのは、ある意味で最初に質問した「理想的なエンジニア組織の形」の1つにも思えます。

宮原　かといって、一足飛びにオープンかつホラクラシーな組織にすればいいのかと言えば、そういうことではないんですね。

フューチャーは受託開発の会社であり、さまざまな種類の仕事があることから、テーマごとにチームに分けるアプローチを採り、ホラクラシー型に近いエンジニア組織になってきました。事業会社や、自社製品を扱っているエンジニア組織であれば、また別のアプローチになるでしょう。

とはいえ、どんなエンジニア組織でも、成長していく過程ではいくつかのジレンマに直面する段階を迎えると思います。オープンな組織でやっていけるのか、それともクローズな組織にすることでノウハウを蓄積するのか。あるいは、ヒエラルキーを残すのか、それともホラクラシーに近づけていくのか。いざ組織の形がシフトするときのエンジニア組織としての感情、心理的な葛藤と呼ぶ方が適切かもしれません。

そうしたジレンマに対処し、エンジニア組織を疲弊させる症状を捉えて、それをリファクタリングしていった先にある進化が、そのエンジニア組織にとっての理想的な形なのだと思います。

この「進化の先にある理想のエンジニア組織」という考え方は、他のエンジニア組織にも応用できる形で体系化できそうなので、自社の技術ブログにも書きました。

──このエントリーでは、エンジニア組織のジレンマのひとつに「権限委譲 vs. アカウンタビリティ（説明責任）」という項目が挙げられています。これは対立項には見えないのですが、やはりジレンマなのでしょうか？

宮原　エンジニア組織が大きくなってくると、例えば、採用や人事をエンジニア組織でやりたいといった要求が出てくる段階があると思います。それはそれで悪いことではないのですが、採用や人事のような大きな権限をエンジニア組織が持つからには、エンジニアにはその権限に対する会社へのアカウンタビリティが求められるでしょう。

一方で、エンジニアの多くは、そうしたアカウンタビリティを発揮することを嫌がる傾向があると思います。それを避けるために権限委譲も求めないとなってしまうと、組織としての進化もそこで止まってしまいます。

これは、そういう意味でのジレンマですね。

──なるほど。エンジニア組織が成長していく上では、いろいろな形のジレンマがあるのですね。今日はお話をありがとうございました。

取材・執筆：鹿野桂一郎（技術書出版ラムダノート）

---

1. Webでは、毎年12月になると、テーマに沿ったブログ記事をクリスマスに向けて書きつなぐ「アドベントカレンダー」がいくつも立ち上がります。↩