エンジニア一人一人が主体的に考え行動し、アジャイルに働ける組織づくりを目指しつつも、なかなかうまくいかない現実と理想のギャップに悩むマネジャーも多いだろう。

そこでエンジニアtypeでは、2023年6月21～25日に開催したテックカンファレンス『ENGINEERキャリアデザインウィーク2023（ECDW2023）』で、トークセッション「エンジニアが『自律的に働く』開発組織のつくり方」を実施。

同セッションにはAbemaTVでCTOを務める西尾亮太さん、ソニックガーデン代表取締役社長の倉貫義人さん、エムスリー執行役員 CTO／VPoPの山崎 聡さんの3名が登壇し、三社の実践例を交えながら自律型の開発組織づくりを成功させるポイントについて語った。

株式会社AbemaTV
CTO
西尾亮太さん

2011年に株式会社サイバーエージェントに入社。Amebaスマートフォンプラットフォーム基盤、ゲーム向けリアルタイム通信基盤の開発を経て、16年に『ABEMA』の立ち上げに参画。18年より株式会社AbemaTVでCTOを務める

株式会社ソニックガーデン
代表取締役社長
倉貫義人さん(@kuranuki)

1974年生まれ。京都府出身。大手SIerにてプログラマーやマネジャーとして経験を積んだ後、2011年に自ら立ち上げた社内ベンチャーのマネジメント・バイ・アウトを行い、ソニックガーデンを設立。「納品のない受託開発」という斬新なビジネスモデルは、船井財団「グレートカンパニーアワード」にてユニークビジネスモデル賞を受賞。会社経営においても、全社員リモートワーク、本社オフィスの撤廃、管理のない会社経営などさまざまな先進的な取り組みを実践。著書に『ザッソウ 結果を出すチームの習慣』（日本能率協会マネジメントセンター）『管理ゼロで成果はあがる』（技術評論社）『人が増えても速くならない』（技術評論社）などがある

エムスリー株式会社
執行役員CTO／VPoP
山崎 聡さん(@yamamuteking)

大学院博士課程中退後、ベンチャー企業、フリーランスを経て、2006年、臨床研究を手掛けるメビックスに入社。09年、メビックスのエムスリーグループ入り以降、エムスリーグループ内で主にプロダクトマネジメントを担当する。18年からエムスリーの執行役員。20年4月からはエンジニアリンググループに加えて、ネイティブアプリ企画部門のマルチデバイスプラットフォームグループと全プロダクトのデザインを推進するデザイングループも統括。20年10月より初代CDO（最高デザイン責任者）に就任。22年4月より現職

何のために「自律型の開発組織」をつくる？ 目的は明確に

山崎：一人一人のエンジニアがすべきことを考えて事業を前進させていく組織をつくりたいと考えている会社は、昨今ますます増えていますよね。

エムスリーにおいても、現在およそ90名のエンジニアが在籍していますが、指示待ちではなく、エンジニア各自がどんどん主体的に動いていく組織カルチャーをつくっています。

西尾：AbemaTV（以下、ABEMA）でも、自律型の開発組織を目指しています。

ABEMAの母体であるサイバーエージェントグループ全体では、社員のオーナーシップを重視する文化があり、自由と責任に基づいた組織設計がされています。

それでも、エンジニアが自発的に考えて取った行動が、最終的に事業成果につながっていく……という流れをつくるのは難易度が高いことを実感しています。

エンジニアが自律的に働き、なおかつそれを企業の成長につなげるためには、全員が同じ方向を見て走れるだけのミッションやビジョンの浸透が必要不可欠だと感じます。

山崎：確かに、エンジニアは基本的に「ものづくりができれば楽しい」という職種でもありますからね。だからこそ、成果の出ないものづくりより、成果の出るものづくりに導いてあげられるかがポイントになりそうですね。

倉貫：エンジニアが自律的に働いてはいるけれど、経営陣やユーザーから求められていない機能を作っています、謎の研究を続けています……という状態になってしまうと、会社に貢献はできていない状態ですからね。

まずは、経営層やマネジメント側が、「エンジニアにどこまで自律してほしいのか」「何のために自律的に働いてほしいのか」ということを明確にしておく必要があると思いますね。

時間をかけた採用、組織体制の見直し…成功のポイントは？

山崎：事業・会社の成長にコミットするかたちで、エンジニア一人一人に自律的に働いてもらうためには何が大切なのでしょうか？

倉貫：まずは、自律したい人と、自律してほしい人との「自律」に対する認識をそろえておくこと。

「エンジニアが自律的に働く開発組織」というのは何のためのどういう状態か、その認識を合わせたら、次はそれをいかに実現できるか手段を考えてみます。

そして、私が特に大切だと思うのは、環境整備よりも人材採用の方。

当社はほぼ全員がフルリモートワークで働いていますし、コアタイムなしのフレックス制で、上司が部下を管理したり、マイクロマネジメントしたりするような働き方は一切していません。

こういう環境でなぜ業務を問題なく遂行できるのかといえば、採用にすごく時間とコストをかけていて、「自律的に働ける人」を集めているからだと思っています。

自律的に働ける環境をつくることによってその中で働く人が変わる可能性もありますが、どういう人材をそもそも集めるのかというところから考えることも大切だと思いますね。

山崎：なるほど。ちなみに自律的に働けるエンジニアを採用するために、具体的にどんなことをしているんでしょうか？

倉貫：まずはお試しで働いてもらってから内定を出すようにしています。

応募の後、短い方でも半年、長ければ2年くらい一緒に仕事をして、それから正式に社員として入社してもらうケースがほとんどです。

セルフマネジメントには、会社側とエンジニアとの信頼関係が非常に重要ですね。

そして信頼関係を築くためにはある程度の時間が大切な要素なので、入社前にお互いをよく知る期間を設けています。

山崎：西尾さんはいかがですか？ 先ほど「自律型の開発組織づくりは難しい」という実感も語られていましたが、そんな中でもご自身が工夫しているポイントは？

西尾：倉貫さんがおっしゃるとおり、採用から考えるというのは共感しますね。組織のカルチャーを醸成する上で、所属する人たちの価値観は大切ですから。

また、ABEMAの場合はソニックガーデンさんとは違って組織全体が一つのプロダクトを成長させることに向かっているので、一人一人がセルフマネジメントをして自律的に働くだけにとどまらず、同じゴールに向かっていくための道筋や仕組みづくりをすることも重要なポイントだと考えています。

一つ組織体制を変えた事例についてお話しますと、僕らは以前、「職能型」でチームを区切っていたことがありました。

例えば、iOSチーム、Androidチーム、Webチーム、バックエンドチームというふうに、「どのシステムを担当するか」で組織が縦割りになっていたんです。

でも、それだとエンジニアの考え方が部分最適になってしまったり、サービスやプロジェクトの全体を見渡せなくなったりして、何のためにこの仕事をするのかという本来目を向けるべきものを見失いやすくなるという課題がありました。

そこで、あるタイミングから、組織体制を「職務型」に変更。エンジニアの組織を、コンテンツ配信チーム、コンテンツエンジニアリングチーム、ストリーミングチームなど、「ユーザーにどのような体験を届けるか」をベースに構成するように変更してみました。

すると、エンジニア各自のミッションが分かりやすくなり、一人一人が自走できるようになっただけでなく、サービスをより良くするために必要な技術を各チームで発展させていけるようにもなったんです。

スモールチーム編成で、一人一人が「考えざるを得ない状況」をつくる

山崎：自律型の開発組織をこれからつくりたいと思ったとき、マネジャーやエンジニアが「最初の一歩」として着手すべきことは何だと思いますか？

西尾：まずはビジョンの形成ですね。自律の先にどこに向かうのか、何を成果として生み出したいのか、ビジョンを作り、共有して浸透させることだと思います。

一方で、既にそれが明文化されていてある程度浸透している組織の場合、チームの目標設定の構造をクリアにしていくことや、チームが自律的に動く際に他のチームと折衝しないような構造設計がポイントになるのではないでしょうか。

倉貫：私からは先ほど採用の重要性についてお話ししましたが、経験の浅い若手エンジニアについては特に、人材育成をしっかり行って自発的に働けるマインドセットを育てていくことも大切だと思います。

ソニックガーデンでは、昨年から新卒や第二新卒などの採用も始めたのですが、「親方」と呼ばれる先輩が弟子を迎えるかたちで新人について、彼らがセルフマネジメントができるようになるまでサポートしていきます。

いきなり自律型の組織の中に放り込めば誰でも自発的に動けるというものでもないので、エンジニアのレベルを見ながら段階的に道をつくっていく感じですね。

山崎：ちなみに、明日から始められることとしてエムスリーの施策を一つ紹介しますと、私たちの組織では「チームをなるべく小さく分割」することを実践しています。

冒頭、エムスリーには約90人のエンジニアが所属しているとお伝えしましたが、それを19チームに分けていて、1チームは5名くらいの編成です。

すると、チームの人数が少ないので、「誰かに任せておけばいいや」とはなりづらく、一人一人が自分の頭でやるべきことを考えざるを得なくなります。

チームの人数が多いと他人の意見に乗っかろうとか、誰かに任せてしまおうとか、そういう考えも出てくるかもしれませんが、5人くらいだとそれができない。

そんなふうに、ある種、強制的にエンジニア各自がビジネスの成長を自分ごととして考えざるを得ない状況をつくるというのも一つの手段です。

西尾：スモールチームと開発は非常に相性がいいですよね。5人程度というのはディスカッションが進む規模でもあります。

倉貫：開発って結局、意思決定の連続ですからね。大勢の人で話し合っているとなかなか結論が出なかったりするので、小さなチームをつくって意思決定を速くまわしていけるといいですよね。

山崎：採用、ビジョンの共有・浸透、人材育成やチーム編成の考え方など、大変参考になりました。

ぜひ、今日参加いただいた皆さんにもできることから実践してみてもらえたらと思います！

＞＞『キャリアデザインウィークECDW』のイベントレポート一覧はこちら

＞＞本編アーカイブ動画はこちら

文／宮崎まきこ