事業成長・事業拡大による技術負債と解消。それからの事業成長。[CTO meetup]

事業成長・事業拡大による技術負債と解消。それからの事業成長。

株式会社TENTIALは、2018年に創業したウェルネス領域のスタートアップ企業です。主にD2C事業を手掛け、現在に至るまで新規サービスも含めて事業領域を急拡大してきました。
エンジニア数10数名と小規模なチームで、TENTIALは急成長・急拡大で生じる技術的・組織的な課題をどのように解決してきたのでしょうか。同社の執行役員CTOである市來 晟弥氏に課題内容の詳細と、具体的な解決策を3つご紹介していただきました。

2月10日に開催したCTO meetup「関西CTO/技術責任者10名が語るDX時代のエンジニアリング組織戦略」

関西CTO/技術責任者10名が語るDX時代のエンジニアリング組織戦略

CTO meetup初の試みとして2023年2月10日に大阪なんばのイベントスペースFun Space Dinerを貸し切り、関西のCTO/技術責任者10名をお呼びしカンファレンス形式でオフラインイベント「関西CTO/技術責任者10名が語るDX時代のエンジニアリング組織戦略」を開催しました。
採用/育成/技術戦略をはじめとしたエンジニアリング組織戦略を軸に、各社での取り組みをお話しいただきました。

「事業成長・事業拡大による技術負債と解消。それからの事業成長。」をテーマにTENTIALの執行役員CTO 市來 晟弥氏にセッションいただいた内容をご紹介します。

TENTIALの紹介

事業内容とエンジニア組織の概要

事業内容とエンジニア組織の概要

TENTIALの市來です。今日は事業成長・拡大による技術負債の解消と、そこからの事業成長について発表させていただきます。
私は19歳のときに起業をして、自ら資金調達をしていろいろやってきました。その後はロボット事業や、動画ファッションメディア、アプリ開発などにも従事してきて、TENTIALに至ります。

TENTIALの事業は、ウェルネス領域のD2Cブランドです。直営店としては新丸ビルや渋谷パルコにあったりしますが、ロフトさんや東急ハンズさんなどにも卸されていたりするので、実際の商品は全国どこでも見かけられるかと思います。あとは、健康系メディアの運営も行っています。

組織には、例えば特許の取得や商品開発といったリアルプロダクトならではの事業部がある中、全社の課題をテクノロジーで解決するために、テクノロジー本部が存在しています。
従業員数は60名で、このうちエンジニアは14名です。ECサイトやメディア運営のほか、ノーコードでECサイトが構築できるようなシステムによるオペレーションの高速化、VOC基盤でのシームレスなデータ収集などを実現しています。分析結果は商品開発やCSに活用中です。

TENTIALの時系列

TENTIALの時系列

TENTIALはスポーツメディア立ち上げ後、2019年にD2Cブランドを展開し、同年に私が入社。エンジニア組織をゼロから築きました。そこからフルスクラッチでECをリプレイスし、さらにECモールとメディアを新規で立ち上げましたが、事業拡大に伴い組織は悲鳴を上げることになりました。
現在は回復の狭間まで来た感じですね。ECサイトをプラットフォームとして再構築して負債も解消しつつ、分析を含めた新しい活動に取り組めています。

現在は売上も伸び、堅実に事業成長を遂げているところです。今回の話では、これまでの課題をエンジニアの増員なしに解決してきたところが面白いポイントだと考えています。

ECフルスクラッチ

ECフルスクラッチ-当初

ECフルスクラッチ-当初

ECのフルスクラッチについては当初、「EC×メディア×診断の世界観を実現するなら、フルスクラッチにしたい」という要望がありました。
ただ、当時は商品数が2商品ほど。そこで商品ページデザインにかなりこだわって、一つひとつコーディングを行うようにしました。「定期購入はまだ必要ない」「クーポンはこれぐらいだよね」ぐらいの感覚で、あとはECの機能を一通り揃えたような感じです。

ECフルスクラッチ-事業成長

ECフルスクラッチ-事業成長

ところが、事業成長に伴い経営戦略が変わり商品数を増やすことになり、そうなると、ページの実装がエンジニア待ちに。商品をリリースしたいのにデザインが1日前に来て、1ページずつコーディングするような状態が起きました。そのため、商品数が多くなっても管理しやすいようにしないといけなくなりました。
さらにユーザーが増えて問い合わせ対応が増える、インフルエンサーマーケティングの影響で新しいクーポンが出てくるといった中、エンジニアサイドではエラーが増加。TypeScriptに移行したいけれどそんな時間もなく、やっつけで実装していきました。テレビ露出が増えたので、パフォーマンスも良くしたかったです。
こういった状況が積み重なって、疲れたメンバーが辞めていくこともありました。

ウェルネスECモール/メディア立ち上げ

ウェルネスECモール/メディア立ち上げ-当初

ウェルネスECモール/メディア立ち上げ当初

ここまでが既存事業の話で、次は新規事業も出てきました。組織にECを軸に物を届けるノウハウがあるため、この仕組みを他社様にも活かす形で事業展開する考えが生まれたのです。
エンジニアサイドとしては、まだ仮説検証の段階なのでとりあえずFirestoreで始めて、EC・メディアの制御もやれるだろうという見込みで、既存ECと同じような機能を新規のモールでも作っていきました。

ウェルネスECモール/メディア立ち上げ-事業成長後

ウェルネスECモール/メディア立ち上げ-事業成長後

事業成長していくと、「カテゴリの概念をやっぱり変えます」といった要望が出てきて、商品数も一気に増えました。D2Cのほうが20~30SKUだったのに対して、営業が上手くいったためモールは1000~2000SKUをすぐに想定しないといけなくなりました。
メディアも改修量が増えましたし、企業側のPMFがおもったよりも早かったためFirestoreだとスケールしづらくなり、DB移行しなければならなくなりました。

D2Cとモールで得た知見を掛け合わせればシナジーが生まれる見込みもあったのですが、上記のような状態では両チームがいっぱいいっぱいで、情報を取りに行く気力がありませんでした。それどころか、重複した実装が発生する辛さがありましたね。
例えばAmazon PayをD2CとECモールに実装することになったのですが、v2に上げようと思うと両方アップしなければならなかったんです。何をやっても2倍工数がかかり、人件費のROIが合わなくなってきてしまいました。

課題のまとめ

課題をまとめると、ビジネス側の要望で短期的に解決したいことが多くなり小手先修正に追われる、一つの負債解決が永遠に後回しになって負債が積もっていくといった無限ループに陥っていきました。中途半端な開発しかしていないので、エンジニアスキルも伸びません。
顧客からの問い合わせは仕組みで解決するのではなく、CS人員の増員で対処していたので、顧客が増える分問い合わせ量がどんどん増え続けてしまいました。メンバーが入社しても、離職していくスパイラルです。
テレビや急な著名人のバイラル露出によるサーバーダウンも発生。Perfumeさんが深夜のラジオで言及して頂いていたことで予期せぬサーバー負荷がかかったこともあります。自動復旧はするのですが、一秒でも速めたかったです。

事業拡大の観点では、ユーザーが流入しだすと仮説検証でさえ改修が重く、1プロダクト分あった感じですね。EC機能を重複して作らなければならない部分も含め、プロダクト増加に伴い横断業務やコミュニケーション量が増えて、人材が足りなくなっていました。

1プロダクトが事業成長するたびに組織は悲鳴を上げていて、プロダクト数を増やす前に改善しないといけないことだらけな状態だったんです。

解決フローと具体策

解決フローと具体策

健全な状態で事業成長し続けるための解決フロー

ただ無闇に人を増やすだけではなく、今のメンバーでもっとやれることはないかと模索した結果、解決フローを生み出しました。目的は、健全な状態で事業成長して、事業拡大しても健全な状態を保つことです。

1つ目は、イシューに対する解決策から考え直すこと。お客さんにとってのベストを追求し、エンジニアがいなくても事業が回る仕組みにしていこうとしました。
2つ目が、実装しやすい仕組み、そして遂行しやすい組織に根本からリアーキテクチャすること。同じ実装、同じコミュニケーションを取らずに済むようにしたかったです。
3つ目が、全エンジニアが爆速成長すること。働き方やスタンスの目線を合わせ、熱量高くプロダクト開発をする組織になることで、自然とお互いが高め合って求め合うような仕組みを作りたいと思いました。

具体1.イシューに対する解決策から考え直す

イシューに対する解決策から考え直すという点については、「カスタマーオブセッション×クリティカル・シンキング」を全メンバーに浸透させていきました。
カスタマーオブセッションは、「いかなるときもカスタマーを起点として考え、行動する」という姿勢です。施策や依頼が顧客起点で考えられているかどうかの視点で、開発の考え方から変えていきました。

クリティカル・シンキングが示すのは「前提を疑う」「思考の偏りに気付く」といったもので、依頼されたのがそもそもやるべき内容なのかを検討するということですね。イシューに対して依頼された内容以外にも別のアプローチがあるのではないか、前提を疑うようにしました。

具体2.根本からリアーキテクチャする

具体2.根本からリアーキテクチャする

根本からリアーキテクチャするという点では、逆コンウェイとモノレポを用いました。

コンウェイの法則によればアーキテクチャは組織構造を反映させたものになりますが、逆に言えばアーキテクチャのための組織を作ることもできます。私たちはシンプルなアーキテクチャにこだわれば、組織もシンプルなものになるだろうと考えました。
その結果、コミュニケーションと実装速度が上がり、開発がスムーズに。結果的に顧客への提供速度が上がり、売上も上がっていくという考え方です。

シンプルなアーキテクチャにこだわる意味で、モノレポも導入しました。一つのリポジトリで複数のプロジェクトを管理する方法ですね。
これに基づき、D2Cとモールを「ECプラットフォーム」として再定義しました。私たちはフロントエンドもバックエンドも全てTypeScriptだったからこそ、実現できたのだと思います。決済やクーポン、商品、SKU管理も、全部共通して使える基盤にしています。
統合前はD2Cとモールにそれぞれのデータベースもあり、分析基盤が異なりました。統合後は一つのリポジトリでデータベースまで一貫して共通化できるようになっています。

具体3.全エンジニアが爆速成長する

具体3.全エンジニアが爆速成長する

最後は全エンジニアが爆速成長するということで、フロー理論の導入と世界観の徹底をしました。

フロー理論とは、個人が完全に今行っていることに夢中になれている状態――山登りをするときに流れるように頂上へ登っていく流れ、フローを意味します。
これによって、ミッション・ビジョンに対して自走し、ボトムアップのスタンスを生み出したい思いがありました。もともとタスクに対してはある程度自走していましたが、タスクをこなした後は待ちの状態に陥っていたんです。ビジョンに対して自走していれば、次のタスクも考えながら動きだせるはずだと考えました。
その結果、コミュニケーションがシンプルに。以前まではやっていることや実現方法に対するティーチングになっていましたが、それではタスクしか解決できません。そこから、「そもそもミッション・ビジョンに夢中になっているか」にフォーカスしたコミュニケーションをするようにしています。1on1などでもヒアリングし、夢中になれていなければマネージャー・経営陣の責任です。一メンバーがミッション定義に対して責任を持つのはおかしいですから、そこもしっかり分担をした形ですね。

最後に行ったのが世界観の徹底です。イシュー起点で、プロダクトの達成状態と世界観を定義しました。顧客だけではなく、ビジョンに沿っているかももちろん重視しなければいけないので、顧客とビジョンのバランスを保とうと考えたのです。
世界観は徹底しつつも、アプローチ方法にこだわらない形でOKRを導入しました。Oは徹底するけれども、KRは柔軟に調整する形ですね。
例えば「物流起因のマイナスをなくす」という課題の解決法としてスプシ運用からの脱却があった場合、どういう機能が必要なのかはメンバーがボトムアップで提案します。マネージャー・経営陣が与えるのはミッションのみです。ミッションに沿って日々行動できているかが、確認指標になります。

結果とまとめ

結果とまとめ

取り組みの結果、VOC(顧客の声)アンケートのスコアが爆伸びしました。売上はもちろん重要ですが、我々は顧客をどれだけハッピーにできたかを重視しているので、一番良い結果が得られたと考えています。統合前は10段階中6程度だったのが、統合後は7~8になりました。
また、顧客のポジティブな声に伴って実際に売上もアップしていることを実証できたのも大きいです。

今回はカスタマーオブセッションや逆コンウェイ、モノレポ、フロー理論などを用いましたが、フロー理論なんかは論文にもなっている内容で、私が独自の解決策を編み出したわけではありません。過去の手法を用いる大切さを実感しました。過去に成功例や歴史があるものだと信頼性が高い手法なので、メンバーにも浸透させやすかったです。

質疑応答

TENTIAL 市來 晟弥氏 質問者:当社でもエンジニアメンバーがどこまで考えるのかはすごく難しいと思っています。実際にミッションをベースに動いてもらっても、「ちょっと違うよね」ということもあります。そうなると「もう上が決めてくれ」という感じになってしまい苦労するのですが、TENTIALはコミュニケーションの過程でだんだんと変わってきたのか、それともすぐにボトムアップを実現できたのか、どちらでしょうか。

組織の課題が異なるとは思いますが、当社の場合はしっかりボトムアップしないと、マネージャーがどれだけ言っても伝わらないだろうという判断でした。
そこでマネージャー陣も経営の定例会議に入ってもらうようになり、少しずつ私が直接指示を出さない形へと変わっていきました。マネージャーに全ての権限を渡して、マネージャーがCTOのように振る舞うことでボトムアップするイメージですね。そうすることで、メンバー、マネージャー、CTO、経営陣が意思疎通をして共通認識を取り、限りなく認識の差分をゼロにしていきました。

質問者:権限委譲の際に、現場からのハレーションは起きませんでしたか?

ハレーションが起きないように、「彼が部長候補だよ」などといった情報は、メンバーに細かに周知していきました。メンバーに対しても、その人に部長になってもらいたいかどうかヒアリングをしています。
あとは各事業部からの評価も出しています。半期ごとに特定のメンバーがいることで何が変わったのか評価をヒアリングし、総合的に誰がマネージャーになるべきなのかを判断する形です。誰かが突然ポンとマネージャーになることはないですね。きちんと当社の歴史を知っているメンバーがマネージャーへと昇格していくのは、王道ルートだと思っています。

まとめ

エンジニア数10数名と小規模なチームで急成長・急拡大で生じる技術的・組織的な課題をどのように解決してきたのか、TENTIALの市來氏に伺いました。
3つの具体的な解決策や過去の手法を用いることでメンバー浸透させやすかったお話は参考になりそうですね。

他のセッションのレポートもご覧ください。

FLEXYとはABOUT FLEXY

『FLEXY』はエンジニア・デザイナー・CTO・技術顧問を中心に
週1~5日のさまざまな案件を紹介するサービスです