今、スタートアップ界隈で「イネーブルメント」への注目が徐々に高まっている。イネーブルメントとは、組織がスピーディーかつ継続的に成果を出すための仕組みづくりに用いられる概念だ。

この7月にはLayerXが元メルカリの名村卓さんを「イネーブルメント担当」として迎え、開発組織内にイネーブルメント専門チームを立ち上げた。

名村さんによると、同チームの役割とは「プロダクトチームに最適な選択肢を提供すること。それは従来の一般的な開発体制では、十分に機能してこなかった役割」なのだという。

なぜ今、このような新しい機能を担うチームが求められているのだろうか。イネーブリングチームの存在意義と今後の展望について、同チーム所属の3人に話を聞いた。

プロダクトチームが、プロダクト開発だけに向き合える「理想的な環境」をつくる

ーーイネーブリングチームの役割とは、どのようなものでしょうか？

名村：一言で言うと、プロダクトチームがより高いパフォーマンスを発揮できるようにするために、最適な選択肢を選べる状態をつくることです。

自分はイネーブルメントの概念を『Team Topologies』という書籍で知りました。このような目的を専門的に掲げるチームの存在は聞いたことがなかったので、興味を持ったんです。

ーーなぜ、開発組織におけるイネーブリングチームの必要性を感じたのですか？

名村：良いプロダクトを作るためには、プロダクトチームの開発スピードを落とさないことが極めて大切だからです。

しかし実際には、プロダクトチームは日々生まれる新しい技術の検討をしたり、サービスの拡大に伴い発生するさまざまな問題への対処をしたりしなくてはなりません。

こうした業務はプロダクト開発のスピードを落とすだけではなく、エンジニアのモチベーションを下げることにもつながってしまう。

でも、もしイネーブリングチームがこれらの周辺業務を担えるのであれば、プロダクトチームがプロダクト開発だけに向き合える理想的な環境をつくれるかもしれないと思いました。

ーーそれはイネーブルメントの専門チームを新たに設立しなければ、できないことなのでしょうか？

名村：従来の開発体制でもできないことはないと思いますが、今言ったことをプロダクトチームがやろうとすると、チームの規模がどんどん大きくなってしまいます。

するとチーム内のコミュニケーションコストが増えたり意思統一が図りにくくなったりして、開発スピードは落ちる一方です。

名村：個人的には、プロダクトチームはあまり大きくしない方がいいと思うんですよね。10人で「こういうものを作りたい」と思ったら、10人で完結できる状態。

つまり、プロダクトチームが自分たちの判断だけでプロダクト開発を完結できる状態が、スピードと質を両方担保する上でベストです。

だからこそ、プロダクトチームの外にイネーブルメントのチームを置き、分業した方が目的達成には効果的だと考えています。

ーー外から最適な選択肢を提示することによって、プロダクトチームが生産性高く開発できる状態をつくることがイネーブリングチームの存在意義なのですね。

名村：はい。その状態をLayerXではつくれると思っています。

エンジニアサイドがビジネスサイドに対して受け身になっている会社が多い中で、LayerXはエンジニアドリブンなカルチャーを維持している稀有な会社です。

エンジニアのモチベーションが高く、かつプロダクトのスケーラビリティも高いLayerXでイネーブルメントを推進すれば、今よりもずっと世の中へのインパクトの大きなプロダクトを生み出す会社になるのではないかと期待しています。

提案するだけでなく自分たちも開発する、徹底したコミットメント

ーーイネーブリングチームは現在3人体制とのこと。お三方は、これまでどのような活動をしてきたのでしょうか。具体的に取り組んだことは？

名村：一つは、プロダクトチームに対する技術戦略の提案です。

会社全体のビジネス戦略とプロダクトの発展形を考えた時に、今後直面するであろう技術的なボトルネックを回避する方法を提案しています。

また、自分たちがただアドバイスをするだけではなく、システムのベースとなる部分を作成して、デモンストレーションをしながら説明することも。最新技術の導入方法のアドバイスも含めて、僕と泉さんはこうした活動を中心に行っています。

泉：イネーブリングチームはプロダクトチームとのミーティングを頻繁に行なっているのですが、立場はどのメンバーも対等で、フラットに意見を交換し合っています。

自分たちはプロダクト開発の現場から一歩引いて全体を見ている組織として「視野を提供している」イメージが強いです。

名村：中川さんはLayerXでの開発経験が長く、プロダクトドメインの知識が豊富なので、それを生かしてプロダクト開発のサポートに直接入ってもらうことが多いですよね。

中川：はい。自分はイネーブリングチームに入るまで、2年ほど経理・コーポレートDXを推進する『バクラク』の開発に携わってきました。

『バクラク請求書』『バクラク経費精算』『バクラクビジネスカード』などプロダクトの種類が三つ、四つと増えていく中で全体に必要な変更が難しくなったり、必要な情報が散らばったりして、非効率な部分があると感じていて。それでも目の前の機能開発を最優先に進めることもありました。

名村さんがこのイネーブリングチームを立ち上げてこのチームに所属してからは、これまで自分が開発現場で感じていたことや抱えていた課題なども役立てながら、組織全体の開発を最適化することに注力しています。

ーーイネーブリングチームはプロダクトチームに対して単にアドバイスをするわけではなく、実際に手を動かすことも多いのですね。

中川：3人とも開発量は尋常じゃないですね。自分たちはプロダクトチームと別組織ではありますが、プロダクト開発にはかなりコミットしていると思います。

泉：ちなみに、名村さんはめちゃくちゃコードを書きますよね。

中川：しかも、すごいスピードで。

泉：そうなんですよね。こんなに速くコードを書く人を初めて見ました。気付くともう「これもう終わったよ」「これ作っておいたよ」って涼しい顔で言われるので、ちょっと焦ります（笑）

でも、それを受けて自分ももっと頑張らなきゃって思えるので、すごくいい刺激になっていますね。

名村：ありがとうございます（笑）

ーーイネーブリングチームの活動を始めてから約2カ月がたちました。すでに感じている手応え、変化はありますか？

名村：今までプロダクトチームの中で後回しにされていた部分を引き受けたり、一つのプロダクトで行っていたことを他のプロダクトでもできるようにしたりといった、当初想定していた動きはすでに始まっています。

中川：プロダクトチームからは気軽に相談してもらえていますよね。今まで「こうした方が良いのでは？」と思っていても、誰にも相談できなかったことを言える人たちだと思ってもらえている印象です。

名村：確かに「今まで悶々と抱えていた疑問を受け取ってもらえる場所ができた」と認識してもらえているかもしれないですね。その点でチームの存在は認知されつつあると思います。

名村：ただ、本当にイネーブリングチームの存在感を示せるとしたら、プロダクトチームに選ばれる技術をちゃんと提供してからだと思います。

一般的な企業には開発チームの中にプラットホームチームと呼ばれる組織があり、そこでつくられた新しいプラットホームへの乗り換えをプロダクトチームは余儀なくされることが多いです。

しかし自分たちは、プロダクトチームに強制的な技術選択を迫ることは決してしたくありません。「これを絶対に使ってください」ではなく「こういう便利なものができたので、もし使えそうなら使ってください」くらいの感じですね。

あくまでも開発の主役はプロダクトチームです。彼らが自らの意思で選択できる状態を維持しつつ、イネーブリングチームは「プロダクトチームにきちんと選んでもらえる選択肢をつくる」役割に徹することが大切なのだと思います。

「今よりもっと良くできる」これから先も現状に満足することはない

ーーイネーブリングチームとしての直近の目標を教えてください。

名村：「どんな人でも楽しく開発できる状態」を目指したいです。豊富な経験やスキルがないと開発に参加できない状態ではなく、どんなレベルの人でもとりあえず開発は始められるという状態を作りたいんです。

ーーなぜそのような状態が必要なのでしょうか？

名村：昔から優秀な人を採用するよりも、みんなが優秀に働ける環境をつくる方がよっぽど効率的だと感じていました。

優秀と呼ばれているエンジニアを採用し続けるのは大変ですし、いくら優秀でもカルチャーマッチしなければすぐに辞めてしまう人も多い。

一方で、そこまで技術力は高くなくても、ポテンシャルとやる気があって会社のカルチャーに共感してくれるエンジニアであれば、「一定の環境」さえ整っていればパフォーマンスは出せるようになれます。

だったら、会社としてはそういう環境を用意することに力を注ぐ方が、長い目で見れば理にかなっている。そこで、経験や技術力にかかわらず「どんな人でも楽しく開発できる仕組み」をつくるためにドキュメントを用意するなど、イネーブリングチームが貢献できる部分は大いにあると思います。

ーー各社のエンジニアがイネーブルメントに取り組もうとする場合、何から始めればいいと思いますか？

名村：まずは先ほどお話しした『Team Topologies』を読んでみてください。この本には、チーム間のインタラクションの方法がきれいに整理されています。

また、イネーブリングチームの話をすると「プラットホームチームとの違いは何？」という話になりやすいのですが、その疑問もこの本が解決してくれると思います。

泉：あとは、イネーブリングチームの立ち上げまでは行かなくても、エンジニア個人で生産性向上に取り組んでみたいと考えている人は、まずは「不満のしきい値を下げる」ことから始めてみるのがおすすめです。これは以前、藤原俊一郎さん（@fujiwara）が仰っていた話なのですが、とても共感できる内容だったので紹介させていただきたいなと思いました。

例えば、普段開発をしている中で、慣れてしまっている不合理なことはたくさんあると思いますが、そういう問題に意識的に目を向けて「どうやったら改善できるか」を考えることで、ちょっとずつでも前に進むことができますよね。

ただ、それを片っ端から改善しようとするのではなく、あくまでもプロダクトの理想系を意識した上で改善に取り組んでみてください。「不合理」と「理想」の両方に目を向けて現場を理解することが、課題解決のヒントになると思います。

名村：本当にその通りで、例えば「提案してからリリースまでの間にどのぐらいの無駄が発生しているか？」を立ち止まって考えてみることは非常に重要です。

放っておくと開発期間はどんどん伸びて、自分の感覚も麻痺していってしまいますからね。何においても「今よりももっと良くできるのでは？」という意識を持つことが大切だと思います。

ですから、この先もこのイネーブリングチームが100%満足することはないと思います。自分たちが「やりきったな！」「完全にいい組織になったな」と思ったらダメ。

課題を見逃さない目を常に持ち続けることが、会社の可能性を広げることにつながると信じて、プロダクトチームのためにやれることを探し続けていきたいと思います。

取材・文／一本麻衣　撮影／桑原美樹　企画・編集／栗原千明（編集部）