そのコードはユーザーに価値を届けているか？少数精鋭で生産性の高い開発組織を目指す10Xの挑戦

小売業向けECプラットフォーム「Stailer」を開発するスタートアップ10Xは、創業から6年経ち、社員10名程度から現在は約120名へと急成長を遂げました。組織やプロダクトの規模が急速に拡大する中でも、開発体制やアーキテクチャの見直しを行うなど、開発環境向上のための取り組みを重ねた結果、一般社団法人日本CTO協会主催の「開発者体験が良いイメージのある企業ランキング」に、2022年から2年連続でランクインしています。

組織やプロダクトの急拡大の中で、スタートアップゆえの度重なる機能追加への要望に応えながら、どのようにして良い開発者体験を実現しているのでしょうか。事前に実施した同社のエンジニアへのアンケート結果を見ながら、エンジニアリング本部長を務める小迫明弘さんにお話を聞きました。

• keyboard_arrow_down 35名のエンジニアが、ドメインごとのチームに分かれて開発を進める
• keyboard_arrow_down 悩みの種の「技術的負債」解消への決定打は
• keyboard_arrow_down 心理的安全性の高いカルチャーは、意図的ではなく自然発生
• keyboard_arrow_down アーキテクチャの刷新に向けた体制変更とコード分割
• keyboard_arrow_down 「開発者体験がよい」とは、価値提供のサイクルを回せていると実感できること

――まず、10Xの開発組織について教えてください。

小迫：エンジニアは35名程度で、マトリクス組織を採用しています。メインプロダクトの「Stailer」は、今年の6月でリリースから3周年。今年の4月には開発体制の再編も行いました。以前はパートナー企業ごとに開発チームを編成し、各チームがプロダクト全体に対して機能追加や改修を行っていましたが、ドメインごとにチームを分ける体制に変更しました。

今回のテーマの「開発者体験」を強く意識して組織づくりをしてきたわけではないので、アンケート結果を見るまでは内心ドキドキしていました。おおむね良好といえる結果が出て一安心しています。

――エンジニアへのアンケートでは「技術的負債の解消」についての評価が高く、理由として「技術的意志決定会があること」が挙げられていました。これはどんな取り組みなんですか？

小迫：「技術的意思決定会」は、影響範囲が大きいなどの理由によって、チーム内だけでは意思決定しづらくなっている技術的負債について、チーム問わずエンジニアが集まって議論したり意思決定したりする場として設けています。2023年7月から開始し、週に1回、45分程度時間をとっています。

エンジニアが10名程度だった頃は、エンジニア1人ひとりが各々で開発していても、阿吽の呼吸のように自然と調整ができていました。しかし、エンジニアが35名程度まで増え、プロダクトの規模も大きくなってきた今は、見つけた負債を解消したくても、影響範囲が大きければ勝手に動くわけにはいきません。かと言って、いつ・どこで・誰に相談したらよいのかも分からず、負債を見つけたものの次のアクションに移れないというメンバーが出てきてしまっていたんです。

そこで、今ある技術的負債について相談し、どう動いていくか決めるための場所として、技術的意思決定会を始めました。全社的なシステムの根幹にかかわるような影響範囲が大きい負債や、解消のために工数がかかる負債について、チーム問わず集まったエンジニアがディスカッションし、ネクストアクションを決めるようにしています。

――技術的意志決定会を設けたことで、メンバーの様子に変化はありましたか？

小迫：この会があるおかげで、負債を放置することなく、必要な知見を持つメンバーと、これからどうするべきかを前向きに話し合い、解消に向けて動き出すことができるようになりました。

さらに、誰に相談すべきかわからなかった技術的負債について「相談できる場」があることは、メンバーにとって組織に属するうえでの安心感につながっています。「10Xの開発組織は、技術的負債を解消することの価値を認めていて、前向きに動き出せる」と。

ちなみに、この会は参加自由として開催しています。全体的な技術に関することに興味がある人は参加して発言すればいいし、それほど強い興味がない人は参加しなくてもよい。相談したり発言する機会が誰にでも開かれていることが大切だと考えているので、この方式をとっています。

――心理的安全性については、全項目のなかでもっとも高い評価が出ていますね。

小迫：たしかに、私もマネージャーとして心理的安全性が高い組織だと感じていますし、その通りの結果が出てよかったです。普段働いている中でも、メンバーが感情的になるシーンを見かけることはほとんどないですね。

10Xには割と成熟したメンバーが多いことがひとつの要因だと思います。事業を伸ばすことに責任感を持ち、真面目で真摯に業務に取り組む、社会人として自立したメンバーが集まっていることが、心理的安全性のベースになっています。

意識的に心理的安全性を高めようとすると、「否定的な意見は言うべきじゃない」という雰囲気を無意識につくってしまう場合もあると思います。その点において10Xでは、事業のために言うべきことはズバッと言うメンバーばかり。そして、言われたことを他意なく素直に受け取ります。見えないところでわだかまりが溜まることも少ないと感じますね。

――言うべきことはズバッと言い、素直に受け取るというカルチャーは、どのようにつくったのでしょうか？

小迫：最初からこうしたカルチャーを目指したわけではなくて、創業メンバーがそもそもこのような気質が強かったことで、事業を進めるうちに自然とこうなったような気がします。

これは個人的な意見ですが、カルチャーを意図的につくることはある程度はできても、そこにいる人が持つものと真逆のカルチャーをつくることはできないと思うんです。そこにいる人がそもそも持っている気質があって、その一部をカルチャーとして意図的に組織に伝播させることはできるでしょう。でも、そこにいる人の気質と反対のものを無理やりつくろうとしたら、どこかに歪みが生じると思います。

――組織の拡大につれて、今のカルチャーの維持は難しくなるのではないでしょうか。

小迫：たしかにそうかもしれません。ただ、10Xは将来的に、エンジニアが数千人いる会社を目指しているわけではありません。事業成長のために必要な人数は増やしますが、できれば今のような、少人数で生産性の高いエンジニア組織を維持していきたいと考えています。

幸いなことに、今のメンバーは育成経験も豊富です。エンジニアの人数が今の2倍、3倍必要だとなったとしても、ジュニアのメンバーの育成にコストを割いた上で開発生産性も下がらないような体制づくりに、今後数年をかけて取り組んでいこうと考えています。

――アンケートでは「開発に最適なアーキテクチャ」の項目の評価が目立って低いですが、要因はなんでしょうか？

小迫：開発当初のアーキテクチャと今の要件が合わずに開発しづらくなっていることが、アーキテクチャへの低評価につながっているのではないかと思います。

「Stailer」の開発当初は、少人数のチームでも開発しやすいように、モノリシックなアーキテクチャを採用しました。ところがリリースから3年を経て、事業規模の拡大に伴ってアーキテクチャも限界を迎えつつあります。3年前の時点でここまでの拡大や変化を見通せるわけがありませんから、こうした状況に陥ってしまうのも必然だったと思います。

今は古いアーキテクチャが開発を進める妨げとなり、新機能の開発や既存機能の改善を進めたくても、思うように進まなくなってしまっている部分もあります。これに目をつむったまま開発を進めれば、本来書く必要のない無駄なコードを書かなくてはいけなくなり、開発生産性やメンバーのモチベーションが低下し、開発組織に致命的なダメージを及ぼしかねません。この悪循環を防ぎ、抜本的に改善するために、目下動き出しているところです。

――現状のアーキテクチャはいわば10Xにとっての最大の技術的負債ということですね。今はこの問題に対して、どんな取り組みをしているんですか？

小迫：前述の通り、今年の4月に10Xは「Stailer」の開発体制を変更し、ドメインに基づいてチームを分割する形にしました。今は、チームの単位に合わせてコードも分割するために「Stailer」のアーキテクチャをどう変更すべきか、検討を進めています。

開発体制変更の目的は、負債の解消はもちろん、根本的に負債を溜めていかない仕組みをつくるためです。

以前のパートナー企業ごとのチーム分割では、それぞれのビジネスサイドからの要求に優先度高く応えていくので、顧客にとっての価値は生み出しやすいものの、負債解消にはコストを割きづらくなってしまっていました。また、異なるパートナーから似たような機能の要望があるとき、それぞれのパートナーの要望が少しずつ異なるため「似ているけどちょっと違うもの」が複数できて、それぞれを保守しなければいけない、といった問題も起こっていました。

ドメインベースでチームを分割することで、コードに対するオーナーシップが生まれ、以前よりも負債解消に前向きに工数を割けるようになりました。似た要望を取りまとめて統一の機能としてつくり、保守コストを抑えられるようにもなりましたね。

このように、まずは開発体制を変更して負債を溜めにくい仕組みをつくり、その上で、具体的にどんなアーキテクチャが開発しやすいのか、それをどう実現していくかを考えています。

――小迫さんは、前職のRettyで8年間EMを務め、10Xでも開発組織のマネージャーを務めていますが、「良い開発者体験」とはどのようなものだと考えていますか？

小迫：良いPC、良いディスプレイ、良い椅子も、開発時の言語や開発環境がモダンだというのも「開発者体験」を良くする重要な要素だと思います。

ただ、ソフトウェアエンジニアは「ユーザーの課題を解決するためにソフトウェアをつくる人」です。「自分のつくったものが誰かの課題を解決した」と実感できたときは、エンジニアなら誰でも嬉しいはず。つまり、誰かの課題を解決できるものをつくれたり、そのために改善のサイクルを回せたりする環境こそが、「開発者体験が良い」ということなのではないかと思います。

Rettyに入る前のフリーランスだった頃、1人でアプリを開発・運用していたことがあるんですが、それがすごく楽しかったんですよね。企画、開発、デザイン、マーケティングなど、プロダクトに関わることを全て1人でやるのは大変ですが、1人だからこそ自分が考えたことをそのままアウトプットできて、仮説検証のサイクルがものすごく高速に回るんです。「これをつくったら、このように役に立つんじゃないか」と新しいアイデアを実装したら、2〜3日後にはその実装によってユーザーの行動が変わって利益が生まれたり、そうでなかったりする。じゃあ次はこうしたらもっといいんじゃないか、と仮説を立てて実装し、その効果を検証する。こうして価値提供のサイクルを自分の手で回していけるのがすごく楽しかったし、これこそがエンジニアという仕事のおもしろさなんだと実感しました。そもそも、自分がつくったものを使ってもらえること自体、単純にすごく嬉しいですしね。

10Xには、事業による価値提供に強い興味を持つエンジニアが数多く集まっています。私も、個人開発時代に価値提供のおもしろさや嬉しさを知ったからこそ「プロダクトがユーザーに提供する価値に強い興味がある」という、ある意味10Xらしいエンジニアになったんだと思います。そんなメンバーが集まっているからこそ、「開発者体験」を強く意識しなくても1人ひとりが自然と価値提供のために動けていて、それが今回の良い結果につながったんじゃないかと思いますね。

取材・執筆：青山 祐輔