名村卓氏のキャリア変遷
大谷旅人氏（以下、大谷）：それでは本日のメインの名村さんのお話に入りたいと思います。LayerX 名村さん、ご登壇よろしくお願いします。
名村卓氏（以下、名村）：はい、よろしくお願いします。LayerXの名村と申します。今、LayerXでEnabling Teamという、Enablementをやっている組織にいるのですが、今日はそこでの経験と諸々含めてお話できればと思っています。冒頭のタイトルにもあった「開発スピードを落とさないために必要なイネーブルメント組織」について話します。
（スライドを示して）最初は簡単な自己紹介です。今僕はLayerXにいるのですが、前々職はサイバーエージェントという会社で、エンジニアとしていくつかのサービスの立ち上げをやっていました。1年に1回とか2年に1回のペースでたくさん（サービスを）立ち上げて、それからメルカリという会社に転職しました。最初はメルカリUSにいたのですが、そのあと日本に帰って来て、CTOという立場でやっていました。
立ち上げから大きくなったプロダクトの組織や開発の両方をこの2社で見て、メルカリでも最後のほうにソウゾウという会社でまた立ち上げをやりました。この立ち上げはどちらかというと巨大なメルカリのサービスに紐づくかたちで新規の立ち上げをするみたいな立ち上げを経験しました。
それまでずっとtoCをやっていたのですが、「バクラク」というtoBの会社であるLayerXに転職をして、今はエンタープライズ向けのプロダクトのEnablingの部分を担当しています。ということで、いろいろなケースを体験しているので、何らかの参考になる話ができればなと思います。
プロダクトをやっていく中でレベルを下げたくないのは「速度」と「品質」
（スライドを示して）今日話すことはタイトルのとおりで、過去に経験したプロダクト開発をベースにプロダクトを立ち上げるところだけではなく、持続的に成長する上で重要なEnablementという要素があるなと感じているので、その話をします。
さっそくですが、やはりプロダクトの立ち上げはすごく楽しくていいのですが、そのあとプロダクトを成長させていく過程でいろいろなことが起きます。やはりたいていのプロダクトは成長とともに鈍化するというか、だんだん（開発の）スピードが落ちてきたり、だんだん問題が出てきたり、いわゆる立ち上げの時の「楽しかった時」がなくなっていくみたいなのを経験することはすごく多いのかなと思っています。
僕もその両方を経験していたので、「プロダクトというのはこうやって大きくなってくると本来楽しくなっていくはずなのに、なんでだんだん問題が頻発するんだろう？」とすごく疑問に思っていたというか、なんでこんなことになるんだろうとは思っていました。
（スライドを示して）持続的にプロダクトをやっていく上で大事でレベルを下げたくないものの一番は、やはり「開発する速度」です。
速度はすごく重要なファクトですごく大事だなと思っています。やはり大きいプロダクトになってくると、昔は2、3ヶ月で出せていた機能が気づいたら1年経っても出ていないというのはよくある話なので、プロダクト成長をしても（開発の）速度が落ちないというのはすごく重要だなと思っています。
次に「品質」ですね。これは、立ち上がり時に品質が高い状態かどうかと言われると難しいのですけど。相対的に、立ち上がり時のほうが品質が高いケースもあるので、このあたりは後々話しますが、品質もすごく重要な要素だなと思っています。
あと、やはり欠けていてはいけないのが、「プロダクトに対する情熱をチームが持っているかどうか」で、それはやはりすごく大事かなと思っています。このあたりが重要かなと思っています。
チームの人数が少ないというのが何より重要
（スライドを示して）立ち上がり時に、なぜこのあたりがけっこう良い状態なのか。品質は立ち上がり時は、諸々課題があるケースが多いと思いますが、なぜ立ち上がり時にこういう要素を満たしやすいのかなと考えた時に、やはり「チームが小さい」というのがすごく大きくあるなと感じています。
立ち上げ時はMVPというか、一番小さい機能をすごくシンプルに出すので、もちろん開発速度も速いし、シンプルだからテストしやすいというのもあって品質も比較的維持しやすいと思います。立ち上がりのドタバタでテストしていないなど、品質が足りていないこともよくありますが、相対的に品質を維持しやすいです。
あとは各メンバーが全体の掌握をしていることが多いです。例えば、プロダクトマネージャーが全体の機能を把握していたり、エンジニアが全体の技術的な仕組みを理解していたりというケースがすごく多いです。全体を掌握している、イコールその速度も速いし品質もすごく維持できています。
チームの人が少ないというのは何より重要だなと思います。人が少ないことでやはり速度も速いし、意思決定も早いです。コミュニケーションもすごく密になるので、速度も品質も高くなります。コミュニケーションが密で意思決定も早いとなると、そこに自分事化みたいなのが生まれてくるので、自分のプロダクトに対する情熱が生み出されてくるという状態があるのかなと感じています。
プロダクトが成長する中で生まれる負のインパクト
（スライドを示して）これがプロダクトが成長するとどうなるのかというと、やはりすべての部分で負のインパクトが生まれる状況がよく出てきます。これはなぜかというと、当然ですが、プロダクトが成長するといろいろな要望に応えたり、マーケットフィットしたり、いろいろなお客さんの層を増やしたりするために機能が増えるためだと思います。
機能が複雑になるので、全体を掌握できなくなるし、やはり速度も品質も落ちてきます。人もチームも増えるし、チームが増えると意思決定のコストがめちゃくちゃ上がるので、今まで1つのチームでできていたことが、いろいろなチームを巻き込んで開発しないといけなくなります。
意思決定をするためにいろいろな人の合意が必要になるとか、いろいろなチームと調整するためのコストが上がって、速度が落ちてくる。人もチームも増えるので、個々のコミュニケーションがだんだん密ではない部分が生まれて、結果として品質に影響を与えたり速度に影響を与えたりします。
こういう中で意思決定のコストがだんだん上がってくると、「なんかこの会社は何をやるにも遅いな」「重いな」みたいな話になって、だんだんと情熱も失われて、日々のルーチンタスクに追われて、「俺は何をやっているんだろう」と思ったりして情熱がだんだん失われるみたいなインパクトが出てくるのかなと思っています。
誰しもが思う夢「プロダクト組織が成長しても情熱、速度、品質を維持したい」
何もしないともちろんこんな状況になるのですが、「プロダクト組織が成長してもこういう情熱や速度や品質を維持したい」というのは誰しもが思う夢なのかなとは思っていて、やはりここに対して挑戦し続けないといけないのかなと思っています。
これは結局のところ、チームと人が増えるというのが一番のポイントになっていて、機能の複雑化もありますが、何よりチームと人が増えてもそのパフォーマンスが落ちないということに何らかの仕組みを投入するなりして、挑戦し続けないといけないんだなといろいろなプロジェクトを通して感じています。
立ち上げ時の熱狂をプロダクトが成長していく中でも維持し続けることがもしできたら、すごく良いカルチャーや組織だなと思うし、結果としてすごく良いプロダクトが生まれる原泉になるので、そこを維持したいという思いで、いろいろと情報収集したり、いろいろな経験をもとに考えてきました。
僕が他の記事や話す時によく出しているのですが、Enabling Teamというのを今やっています。そのチームの名前は、『Team Topologies』という本を見た時にしっくりきたところから来ています。
今までのいろいろな開発組織を見てきて、プロダクトのチームがいて、共通基盤のチームがいてという、いろいろなプロダクト組織のあり方みたいなのをいろいろな会社で見てきて、どれもこれもうまくいかないなみたいなのを経験していく中で、この本を読んだ時に「なるほどね」と思ったことがありました。そのあたりをちょっとここでいくつかかいつまんで紹介させてもらえればなと思います。そこからEnablementにつながる話ができるのかなと思っています。
生産性に重要な要素である「Cognitive Load」とは？
「プロダクトが大きくなった時になんでみんな生産性が下がっていくんだろうね」とか「チームが増えるとなんで生産性が下がるんだろうね」という話がありますが、この『Team Topologies』の本の中にすごく重要な要素がありました。「Cognitive Load」という、最近よく話に出る「認知負荷」というものがあって、Team Cognitive Loadにきちんと焦点を当てて考えたほうがいいという話があります。
ワーキングメモリですかね。いわゆる「なにかを作りたい」とか「なにかを開発したい」と思った時に、脳みそのワーキングメモリというかキャパシティがあって、どれぐらいを何を使って開発をするかがいわゆる認知負荷です。この絶対量は人やチームによって決まっているので、そのワーキングメモリの使い方をきちんと考えたほうがいいよねという話です。
（スライドを示して）そのCognitive Loadの要素は3種類ぐらいあって、まず「Intrinsic」という内在的な認知負荷みたいなものがあります。技術的な話でいうと、例えば「GraphQLのスキーマってどうやって定義するんだろう？」とか「Javaでなにかものを作る時はどういうクラスを作ればいいんだろうか？」という、わりとファンダメンタルな知識に負荷がかかるケースです。
あとは「Extraneous」という、余分な負荷というんですかね。本来いらない負荷というか、余計な負荷みたいな感じです。例えば、アプリを開発して作ってそれをデプロイする時に、「前に1回デプロイしたけれど次にやろうとしたらちょっとわからないな」みたいな、リピートするタスクに対して余計な負荷がかかるとか、「あれってどうやったんだっけ？」と負荷がかかるとか、そういうなにかをしようとした時に、仕組みはあるんだけどどう使っていいかわからないという余計な負荷みたいな認知負荷で、これが多いとやはり良くないですねという話です。
そういう負荷がもう1個あって、それは「Germane」という、いわゆる銀行送金するにはどういう機能が必要なんだろうかという知識みたいな、物事を考える時に必要な負荷みたいなものがあります。
この3つの負荷みたいなもののバランスをうまく取っていかないといけません。いろいろな組織を作っていって、一つ一つのチームを作っている時に、このチームにどういう認知負荷がかかっているのか、どれぐらいの脳みその割合をどの負荷に使っているのかを、きちんと見たほうがいいよねというのがありました。
Cognitive Loadに3種類ある要素「Intrinsic」「Extraneous」「Germane」
（スライドを示して）例えば今回で言うと、プロダクト組織のエンジニアチームだと、Intrinsicみたいな、いわゆるスキルと言われているもので負荷を下げていくという話です。要は能力的にスキルが身に付くと、自然とこの部分のスキルの負担は下がっていきます。例えばJavaをマスターすれば、Javaに関する認知負荷がどんどん下がっていくので、ここは能力を磨くしかありません。
だけど、真ん中の余分な負荷は、仕組みを作って負荷を下げていこうというところなので、例えばアプリケーションをデプロイする時に、タグを打ってそれをプッシュすれば比較的負荷が低いかもしれないとか。そういう仕組みを持って、そこの認知負荷を下げるみたいな話です。
アプリをデプロイしたり、開発するコードをローカルで実行したりするために必要な認知負荷をどう下げていこうか？ というのが、もう1つあるのかなと思っています。
Germaneはドメインフォーカスにする力なので、言ってみると「プロダクトチームはここにフォーカスしてほしい」みたいなものです。余分なところはどんどん仕組みで解決していって、内在的なものに関してはどんどんスキルで解決をして、最終的にはドメインフォーカスに脳のキャパシティを全力で注いでいくというものを作っていくことで、速度が上がっていきますよねと書いてあって、すごくしっくりきました。
なので、プロダクトを作っている中での技術や仕組みや言語は何を使うとか、という技術的な判断ではなく、今ある「こうしたいビジネスロジック」を実現するにはどうするべきなのか、どうコードを書けばいいのか、どういうコンポーネントを作ればいいのかというドメインフォーカスしたところに、より脳みそのキャパシティを使っていくのが大事ですよという話です。
ここにすごくフォーカスさせるのが、プロダクトチームに対する最適化なんだろうなとは思っています。
（次回へつづく）
