ドメインがファットになった時、分割する時のリードもEnabling Teamが行うのか？
大谷旅人氏（以下、大谷）：名村さん、ありがとうございました。やはり小さなチームにするためにはドメインフォーカスした状態が必要というところで、私も自分の組織に置き換えながら拝聴していました。
ここからは質疑応答の時間といたします。一番上からいきましょうか。「ドメインがめちゃくちゃファットになった時に分割する時のリードもEnabling Teamが行いますか？ もしそうだとすると、Enabling Teamの認知負荷自体がすごく上がるなと感じますが、いかがでしょう」という質問が来ています。
名村卓氏（以下、名村）：基本的にはプロダクト側のチームがその課題感を得て分割をしていくので、Enabling Teamは分割しやすくする仕組みを提供するのがベースだと思っています。ただ、いざ分割したいとなった時にはEnabling Teamも一緒になって分割するのが正しい動き方かなと思っていますね。
Enabling Teamが「こういう仕組みを作ったので使ってくださいね」と言うだけだと、絶対うまくいかないと思っています。「こういう仕組みを作りました。絶対にうまくいくと思うので、次に開発する時にプロダクト側で適用する意思があれば、Enabling Teamで一緒になって開発して、新しい仕組みをそこに載っけていきます」みたいな感じです。
なので課題の主体はプロダクト側にありますが、課題の解決の仕組みと実行はEnabling Teamも一緒にやっていく感じですかね。課題が生まれてから仕組みを作るケースもあります。
大谷：逆にEnablement Teamから課題を探索するところもあるんですか？
名村：それはあると思います。例えば「今のプロダクトの課題感は何ですか？」「プロダクト開発で感じている、うまくいっていないことって何ですか？」と聞いて「こういうところが足りていないんですよね」「こういうところに今苦労しているんですよね」というのがあれば、Enabling Teamのバックログに入れて解決していくというのはありますね。
大谷：なるほど、ありがとうございます。
「オーナーシップを完全に持たせる」という理想とその難しさ
大谷：続けて、「完全なオーナーシップは理想ではありつつ、技能の規模が大きくなればなるほど現実的に他のチームと連携しないで済むことはないと思うところと、一定妥協判断も求められると考えているのですが、この問題に対する対応や妥協点に関してご意見や過去の対策を聞いてみたいです」という質問です。
名村卓氏（以下、名村）：そうですね。「オーナーシップを完全に持たせる」といっても、そのチームじゃないところのドメインのファンクションが必要になって、それを回収しないとうまくいかない場合、やはりそこで連携が入ってこのチームに依頼をしないといけないというケースがあると思います。こういうのはなかなか防げないので、起きないようにするのは難しいと思っています。
目指すべきは、オーナーシップを持っている主体が外部に対する変更も合わせてできることで、これが理想だとは思っています。わりと似た技術的なフレームワークをお互いに使って、外部からの変更を受け入れる許容がそっちのプロダクトチームにあるかどうかを見て、自動的なテストをしっかりして、外部からの継承も仕様に変化がないことがわかっている前提で受け入れられると、メインのチームがオーナーシップを持ったまま、いろいろなチームのコードに変更を加えられるかなと思っていて、それが向かっていく先としては理想だとは思います。
ここはあくまで理想です。現実としては、オーナーシップを持っている人たちはサービスの範囲に対して責任を持っているので、やはり外部からの想定しない変更はそうやすやすとは受け入れられないというのがあります。ここをどう解決していくかは難しい課題なのかなと思っています。
なのでその外部からの変更の受け入れにおいても、オープンソースみたいにいろいろな人が変更をプルリクで送ってきて、それを受け入れていくというカルチャーを会社全体にインストールしないと、なかなかこういうのはうまくいかないだろうなと思います。
あとは責任の範囲ですね。外部から受け入れて、それがダウンしたら「そこのプロダクトのチームの責任じゃん！」みたいにならないような、そういう仕組み作りは必要かなとは思っていますね。究極的にはそういうのが起きても問題が起きにくい仕組みを背後に持っていることが大事かなと思っていて、そこに対する解はいろいろトライするべきことはあるのですが、「これがいいですよ」というのは現状はない。現実で（はない）かなと思います。
大谷：なるほど。例えば、共通ライブラリや先ほどのTeam Cognitive Loadのアーキテクチャで共通で提供する仕組みを各Stream Aligned Teamに共有した場合に、勉強会をしたりガイダンスの提供も同時に行っていたりするんですか？
名村：まず、ドキュメントの整備はあるべきかなとは思います。オープンソースをあるチームが使おうとするとドキュメントが整備されていて、それを使いこなすことができるので、Enabling Teamも同じようなものを目指すべきかなと思っています。あとは、プロダクトチームがEnabling Teamが作っている領域に対する変更ができるというのも大事だと思っているので、そういうものをきちんと運用していく必要はあるかなと思います。
大谷：やはり地道なところもありつつもというところですよね。
名村：そうですね。
大谷：わかりました。ありがとうございます。
Enabling Teamの立ち上げで苦労したことは？
大谷：では続けて「LayerXにイネーブルメント担当として移られてからもうすぐ1年……」早いですね。「（1年に）なるかと思いますが、イネーブルメント組織の基となったチームがある状態からのスタートだったのでしょうか？ 立ち上げにあたって苦労した点などをお聞きしたいです」というところです。この質問はいかがでしょうか。
名村：そうですね。もともとEnabling Teamがあったわけではありません。僕が前職でEnabling Teamをやっていてすごく良い概念だなと思ったので、転職する時も「Enablementを中心にやっていきたいです」という話をしていました。
内情的にはいわゆる横軸の組織がいない状態でした。DevOpsはありましたが、プロダクトの開発に対する横軸のそういったチームがなかったので、そういうチームを作ったほうがいいよねというタイミングで、名前（の候補）はよくあるプラットフォームチームとか、そういう名前もあったのですが、そこであえて「Enabling Team」という名前にしてもらいました。
大谷：なるほど。組織化するにあたってなにか苦労した点などはありましたか？
名村：僕が苦労したところはないかなと思うんですけど（笑）。
大谷：すばらしい（笑）。
名村：僕自身がチームを立ち上げるのに苦労したというよりは、「こういうのが必要だよね」というのが必然に出てきて、そのチームができて「名前はどうしようかね」ってなってEnabling（Team）にしたぐらいのものなので、僕自身がすごく苦労してそのチームを立ち上げたというのはありません。
チーム自体が機能するための苦労みたいなものはいろいろあるのかなとは思います。
イネーブルメント組織の構築後、最適なアーキテクチャになった事例はあるか？
大谷：では続けて「イネーブルメント組織を構築したあとでコンウェイの法則的に最適なアーキテクチャになっていったような事例はありましたか？」という質問が来ています。これはTeam Cognitive Loadの先ほど説明されたアーキテクチャのようなものなのでしょうか？
名村：LayerXでは今はないですね。逆コンウェイなのかはわからないですが、Stream Aligned Teamの中にクロスファンクショナルな機能を持たせようとやっていくと、専門職チームみたいな、フロントエンドチームやバックエンドチームが生まれて、そこが機能の開発を横断してやっていくケースもあると思います。
それをあえて否定して、それぞれのスクラムのチームごとにクロスファンクショナルであるべき状態をできるだけ作るように、フロントエンドエンジニアが各チームにできるだけいるようにするとか、バックエンドチームの各ドメインのチームに必ず何人かいるようにするというのはあります。いわゆるコンウェイの法則とは逆で、クロスファンクショナルなチームがあるべきだという前提で組織を作っていったところはありますかね。
大谷：逆コンウェイになるんですかね。どちらなのかわからなくなってきましたけど（笑）。ありがとうございます。こうあるべきだという組織を作ってから、アーキテクチャがそれに従っていったところもあったのかなと思います。
優先度はどのような基準で決めているのか？
大谷：では、どんどんピックアップしていければと思います。「イネーブルメントチームに求められることは多い印象ですが、どのような基準で優先度を付けて進めましたか？」と来ています。優先度はどういった観点で付けたのでしょうか？
名村：今だとチーム全体のバックログがあるので、ふだんの日常的なコミュニケーションの中で生まれた「こういうのをやってほしいよね」「こういうのをやったほうがいいよね」みたいなのを全部バックログにバーッと並べていってそこにプライオリティを付けていきます。
Enabling Teamは、いわゆるスクラムを組んでいない、アジャイル開発をしていないチームで、わりと機動は流動的です。プロダクトチームはいわゆるスクラムで、アジャイルで開発をしていますが、Enabling Teamはどちらかというとそこに対して機動的に支援をしていくチームなので、あえてそういうスクラムを組まずにバックログに並べて、バックログにあるものが急にプライオリティが上がったりするのを完全に許容してやっている感じですかね。
各々が「今これが重要だからこういうふうにやらなきゃいけないね」というのをやったり、あとは全体のプロダクトの中で、あるプロダクトでこういう機能が急遽必要になっているよねと急にプライオリティを上げたりするのはわりと機動的にやっている感じです。
大谷：そうなんですね。その対応に対する効果やエフォートみたいなところというよりは、比較的属人的なのか主観で進められているようなところなんですか？
名村：主観もありますし、純粋に全体のプロダクト開発の中での緊急性みたいなところも両方あるかなと思います。
大谷：そういったところで判断するのが基本かなというところですかね。わかりました、ありがとうございます。
1人で立ち上げたチームのメンバーを3人増やす時に意識すべきこと
大谷：では最後に、イネーブルメント組織の話がやはり多く来ていますね。
「1人で0→1のバーティカルSaaSを立ち上げて、これからチームにするというフェーズです。仮に3名追加すると、それこそ情熱・品質が一時的に下がって生産性が下がるイメージしか湧きません。最大限この減速を回避するためにはなにか経験値とかは必要でしょうか？」と来ています。いきなりチームが増えた場合ですかね。
名村：1人で立ち上げていて、3人増やすということですよね。
大谷：2、3人増やすと。
名村：そうですね。なんでしょうね。品質・速度は下がるしかないだろうなと思いますが、まだ3、4人だったらコミュニケーションがかなり密にできるので、その温度感の共有は適宜コミュニケーションを取ってやっていくと良いかなと思います。
だけど、品質はどちらかというと最初に立ち上げる人にすごく依存します。最初に立ち上げる人が単体テストをきちんと書く人だったらきちんと書くことになるし、きちんと書かない人だったらきちんと書かない人になります。そういうのが文化として根付いて、品質が落ちていったり、きちんと維持されたりするところはあると思います。
現状、品質を保つために必要な認知負荷がどれぐらいあるかというところだとは思います。速度に関しては、やはり連携すると「ここをこう作るんだよね」とか、コードレビューが必要になってきてどうしても落ちてしまいます。求めるものに対してマイクロマネジメントをしないのが一番大きいかなとは思います。
スピードを維持するためにすごく細かいところまでやいのやいの言うよりは、できるだけどこまで信頼してどこまで任せるかで、その人のコンフォートゾーンを作りながらそこに対する自分の責任感を醸成したり、情熱を調整したりします。
気をつけないといけないのは、聖域みたいなものを作ると時に守りに入ってしまって、その人が自分の領域を渡したくないとなったりするので、そもそもそういう人を採用しないというのもあります。そこに変更を加える時は自分のレビューが欲しいとか、そこに対する意思決定に対して頑なな意思があって外部の意見を受け入れないことなどがあるので、そういうのが起きないようなカルチャーもきちんと作っておきたいなとは思います。
大谷：そうですよね。カルチャーも大事ですよね。
名村：任せられる領域をどれだけ増やしてやっていけるといいのかなと思いますけどね。
大谷：わかります。聖域を作る人もいますもんね。
Enabling Teamが持っている境界線は実はそんなにない
大谷：あと残り5分で、2、3個ぐらいしか答えられないのでまたちょっと上から質問を名村さんにお聞きしていければと思います。
まず一番上に来ているものだと、「イネーブルメント組織が担当する境界はどう見つけていますか？」と。「技術面で分割した発見を行うのか、ソフトウェア境界をそのまま適用するのか」という質問が来ていますが、これはどうなんでしょう？
名村：担当する境界ですかね。そうですね。Enabling Teamが持っている境界線は実はそんなになくて、あるとすると仕組みを作っていて、その仕組みの部分はEnabling Teamの担当領域ではあります。プロダクトに対する境界線は実はEnabling Teamにはなくて、プロダクトチームと一緒にやっていくのがいいと思っています。
なので、そのEnabling Teamが「このドメインは触りません」というのは実はなくて、わりといろいろなプロダクトチームのところに出張っていて「一緒にやりましょう」という感じでやっていくのが理想かなと思っていますね。
大谷：なるほど。
Enabling Teamにはどんなエンジニアが向いているのか？
大谷：出張っていくというところだと、その次に来ている質問にも関連するかと思うんですけど、そういうEnabling Teamに向いているエンジニアのイメージはどういう方なんでしょうか？
名村：基本的にはやはりお役に立ちたい人だと思うんですけど（笑）。
大谷：なるほど（笑）。
名村：なんでしょうね。いわゆるtoCのサービスだと、お客さんに直接使ってもらいたいとか、そういう意思が強いとか、いわゆるクライアントやカスタマーという会社のユーザーと呼ばれている部分に使ってもらう機能を作りたいとなると、やはり向いていません。どちらかというと、もうちょっと間接的にそういうことをやっている人たちを裏から支援して、結果として間接的にお客さんがハッピーになっているという感じです。
なので、身近なエンジニアや身近なマーケティングのパートの人たちに便利なものを提供したり、そういう人たちの負荷を下げたりするのがやりがいと思える人たち、そういう特性を持った人がいいのかなと思いますね。
大谷：誰かの役に立つことをなにかやるとか、そういった人の負債になっているものを解決するのが好きなエンジニアの方が向いているんですかね。イメージはどうでしょう？
名村：そうですね。特にイネーブリングチームは、社内に向けて価値になることを提供することが多いので、「社外に向けて提供したいんだよね」とか「より多くの人に直接インパクトを与えたい」という人は実はそんなに向いていません。意外と少なくてもいいから身近な人の環境を劇的に改善したいというように、それによって間接的に多くの人に影響を与えたいというモチベーションにはなってくるのかなと思いますね。
大谷：確かにそういう落ち着いた環境でやれると、それは非常にエンジニアとしても楽しみがありますしね。いいなと思います。
Enablingという価値観をもっと広めていきたい
大谷：では最後に名村さん、参加しているみなさまに向けてコメントを一言頂戴して締めとさせていただけたらと思うので、ぜひ一言お願いします。
名村：イネーブルメント組織、Enablingがわりと出てきたのはここ1、2年ぐらいの話だと思うので、概念的には昔からあったんですけど新しい解釈かなとは思っています。個人的にはすごくいいなと思っているので、こういう領域、Enablingという価値観を、うまくいった事例をもっと出して広めていきたいなと思います。こういうことを試してもらって、うまくいったらぜひ発表してもらって、「こういうふうにやるとうまくいきました」とかを知りたいなと思います。
僕もまだやっている真っ只中なので、果たしてこれが本当に良いのか、実はもっと良い方法があるんじゃないかというのはすごく思うところはあって、これが絶対というよりは、これが良いに違いないと思っているぐらいなので、そういうのをシェアしながらプロダクト開発に限らず組織のパフォーマンスを上げるというところで、もっとみんなでいろいろな手法を共有し合ってやっていけるといいなと思っています。
あとはLayerXは、イネーブルメントをやりたい人たちを絶賛採用中なので、もし興味があればご応募いただけるといいなと思っています。
大谷：ありがとうございました。
