専任のEngineering Managerはいないけど、みんなで最高の組織を作ってるよ、という話

※この記事は、Engineering Manager Advent Calendar 10 日目の記事です。

こんにちは、DX 事業本部のエンジニアのさとーる（@satotoru2000）です。

株式会社SpeeeのDX事業本部には専任のCTOやEngineering Managerがいません。その代わり現場のエンジニアたちと事業本部長が力を合わせて、みんなで開発組織づくりに取り組んでいます。

第二創業フェーズでもあるこの2年間は「どんどん新規事業を立ち上げていく必要があるが、その道筋は整備されておらず、走りながら考えるしかない」という状況の中で、何とかそれに耐えられる技術的、組織的な体制を整えてきました。

この記事では自身の振り返りも兼ねて、どのようにこの課題を乗り越えてきたかをご紹介できればと思います。同じような課題を抱えているエンジニアの皆さんのお役に立てたら幸いです。

DX事業本部ってどんな組織？

組織の概要

戦略についてお話する前に、まずSpeee事業概要とDX事業本部について軽くお話しておこうと思います。

Speeeは大きく3つのセグメントに分かれています。DX事業本部は以下資料の 不動産DX事業 にあたります。

DX事業本部の開発組織体制

冒頭でもお話したとおり、DX事業本部はエンジニアのトップとなる人間はおりません。エンジニアの1on1や評価など開発組織のピープルマネジメントは事業本部長が担っていますが、技術的な部分は現場のエンジニアに任されていて、それぞれが走りながら意思決定する体制です。

全社横断としてはVPoEの大場がいるのですが、事業ドメインに飛び地で参入しているSpeeeの特性上、ほとんどの役割を事業本部で担う構造になっています。

当時のDX事業本部の状況

2年前のDX事業本部は第二創業フェーズといった雰囲気で、新しいサービスをドンドン立ち上げていく入り口でした。同時に複数の新規立ち上げが走っていて、新しいエンジニアも一気に増えてくるようなフェーズです。

当時の状況はこんな感じでした。

イエウールをモデルにしたサービスを立ち上げてるけどイエウールに詳しい人はいない状態
CTOもEMもいない。自分たちで技術戦略や組織戦略を考えないといけない
サービスも立ち上げフェーズだし、事業が今後どうなるか分からない
そもそも入社したばかりの人も多くてコンテキストに十分追いつけてない
とはいえ今の新規事業を軌道に乗せることが何よりも大事

つまり、新規事業を並列で走らせながら、同時並行でスケールに耐えられる技術戦略や組織体制も作っていく必要がある状況でした。

どうやって乗り越えてきたのか？

最初の事業立ち上げ

まず、最初に新規立ち上げをするにあたって、「既存の資産を流用してスピードを出すのか？フルスクラッチでやるのか？」という問題に直面しました。

これは双方メリデメあると思いますが、今回は「イエウールのコード資産を使わない」と決めました。当時のメンバーが決めたので実際の経緯は分からないですが、

イエウールは年数も経っておりコードが複雑化していた
技術スタックもモダンとは言えず、ベストプラクティスを取り入れられない

等があり、資産を流用してもスピードが出ない見込みがあったのと、これをパイロットプロジェクトとして成功させて、他のプロダクトに横展開することを考えていたことが理由だったと記憶しています。

そのため、Kubernetesでインフラを完全新規で作り直し、アプリケーションの設計も完全新規でベストなものを作ることを目指しました。当時のベストメンバーがこのプロジェクトに当たりました。

結果、これは大成功を収めることができ、第一関門を突破することが出来ました。

シングルテナント戦略

この時期には2,3ヶ月に1度ペースで新しいサービスを立ち上げなければいけませんでした。まだ新しい事業がどうなるか分からないなかで、インフラの技術戦略を決めていく必要がありました。

その中で、AWSアカウントもKubernetesクラスタもサービスごとに完全分割する「シングルテナント戦略」を意思決定しました。

この辺りは開発基盤チームの西田が対応したので、当時を振り返ってもらいました。

当時は「Kubernetes使おう」ということだけは決めていたが、自身もKuberenetesに詳しいわけではなかった。 AWSの思想とKubernetesの思想が異なるのは分かっていて、AWSに従うならアカウントを分けるべきだし、Kubernetesに従うなら同一クラスタ上に構築すべきだった。「分けたものをくっつけるのは簡単だが、くっつけたものを分けるのは難しいはず」と考え、先行きが不確実な今の段階では分ける側に振り切った方が良いと判断した。

結果的に、この時期に立ち上げるサービスは大小問わず全て別AWSアカウント、別クラスタで構築を行いました。

当時としてはベストな判断だったと思います。完全に切り分けたことによって、デプロイや運用の仕組みを急速に洗練させることが出来ました。あるサービスの立ち上げで起きた失敗を次の立ち上げで改善するというサイクルを回すことが出来ました。アプリケーションエンジニアとして関わっていた私から見ても「どんどん変わっていくなー」と感じていたのを覚えています。(速すぎてキャッチアップが大変だった)

もしも最初からクラスタの統合をしていたら、このような急速な改善は無理だったと思います。当時の私たちには、既に動いているサービスを変えてまでリファクタリングする余裕はありませんでした。

もちろん全てを分割した揺り戻しもあって、今では集約したほうが良いサービスも分かってきているので、クラスタの統合を順次進めています。
(この辺り詳しく聞きたい方は、ぜひ西田と話してみてください)

フロント技術を統一する

複数の事業を立ち上げてまもなく、「プロジェクトごとバラバラのフロント技術を採用し始める」という自体に直面しました。具体的に言うとVue派とReact派がいて、それぞれのプロジェクトで別々に技術を採用し始めました。現場からも「ReactのチームとVueのチームあるけど大丈夫か？」という声が上がり始めていました。そこで「既に作ってしまったものを除き、Reactに統一する」という意思決定をしました。

Reactに決めた背景としては以下です。

ぶっちゃけどちらを選んでも出来ることに大差はない
ただし、どちらかに揃っていることは絶対大事
- 分かれていると学びの蓄積が半減してしまう
- 異動したときのキャッチアップのコストが掛かる
相対的に組織に有識者が多そうなReactを選択

結構思い切った意思決定でしたが、想像以上に各プロジェクトすんなり受け入れてくれました。

今振り返るとこのタイミングで決めてよかったと思っています。コードの再利用が進んだというわけではないのですが、「とにかくReactでチャレンジしていこう」というムーブメントを起こすことは出来たかなと思っています。Reactという共通言語を通して社内でフロントエンドに関する会話が活発になりました。ライブラリ選定などで失敗することもあったのですが、事業を立ち上げるたびに洗練されたものになっていきました。

カオスな環境を面白がってくれる仲間を集める

同時多発的に事業が立ち上がる環境下で、正直言って丁寧にオンボーディング出来る環境は提供できませんでした。その代わり「カオスな環境を面白がってくれるような強い仲間をとにかく採用すること」に全てのエネルギーを注ぎました。

「カジュアル面談60分で知識ゼロからSpeee好き度90%にすること」を目標に、ひたすらトークを磨き込んでPDCAを回していきました。(具体的にどうやったかは菅沢と話してみてください。)

そうして入ってくれた仲間が、新規事業のカオスの中に飛び込んで成果を出してくれました。長年勤めたスタートアップを辞めて来てくれる仲間もいました。

ちなみに、オンボーディングに関しては反省点も多いです。単純に手が回ってなかったし、当時の実力ではそこまで考えきれませんでした。雑にプロジェクトに放り込んでつらい思いをさせてしまったこともあったと思います。ホントに申し訳ない。。。

全力で走りながら組織を作るために必要なこと

無我夢中で走っているときには気づかないのですが、改めて当時を振り返ることで分かる気付きがたくさんあります。私なりに全力で走りながら組織を作るために重要だと思うことを、以下にいくつかまとめてみました。

「専門家はいない。私たちしかいないんだ。」

困難な状況に立ち向かうとき、エラスティックリーダーシップのこの言葉をいつも思い出します。足りないものなんて沢山あるし、配られたカードで戦うしかないのです。

前述した意思決定に共通しているのは、学びと挑戦を繰り返したという点です。インフラやフロントエンド、組織づくりなども、最初から見通せたことなんてほとんど無かったし、学びを繰り返すうちにやっと輪郭が見えてきたという感想です。

特に、「学ばないと乗り越えられないくらい高いハードルに挑んでいた」というのが最も大きかったと思います。 Reactに詳しかった訳でもないし、採用もほとんどやったことなかったのですが「やるしかない」という気持ちで必死で走っているうちに自然と学びに変わっていきました。

重要なのは「真実に向かおうとする意思」

もっとゆっくり考える時間があれば、事前に要素を洗い出して、もっと効率的な 技術戦略を決めることが出来たのかも知れません。しかし、組織の状況、ビジネスの状況は刻々と変化をしており、ゆっくり考える時間があることの方が稀です。少なくとも私たちの組織ではそうです。

たとえ回り道をしたとしても「真実に向かおうとする意思」を持ち続けている限りいつかは正解にたどり着きます。「正しい意思決定をする」のではなく「意思決定を自らの手で正解にする。正解にするまで諦めない」という強い心を持つことが最も大事なことだと思います。