※この記事は、2025 Speee Advent Calendar最終日の記事です。昨日の記事はこちら
デジタルトランスフォーメーション事業本部（以下、DX事業本部）の石井です。 エンジニアリングマネージャー（以下、EM）として、4つの不動産DX事業の開発部署と、DX事業本部横断の開発基盤チームを管掌しています。
2020年9月にSpeeeへ入社し、気づけば5年が経ちました。節目なので、振り返りを交えた在籍エントリを書いてみます。
入社当時、私は30代半ば。「事業と開発を行き来しながら事業成長に貢献できる人になりたい」という想いでSpeeeを選びました。
5年経った今、自分なりに変化できたと感じています。その原動力となったのは「問われる環境」と「挑戦の機会」でした。そして振り返ってみると、ここで培った力は、AI時代に活きる土台にもなっていると思います。
「問われる環境」がくれた成長の圧力
問われ続けるから、応えられるようになる
以前、プロダクトチームのエンジニアとして働いていた頃、「その施策でどんな価値を提供したいのか」「どんな学びを得たいのか」にこだわり、意思決定することの重要性について記事を書きました。
エンジニアとして事業に貢献するとは「Why-What-Howの一貫性を保ちながら、技術意思決定を積み重ねること」である - Speee DEVELOPER BLOG
EMになった今、問われる範囲はさらに広がっています。
現在、管轄部署の各エンジニアメンバーと目標設定・振り返り・評価を行っています。メンバーには期待役割に紐づく成果を追ってもらいますが、同時に個々人のキャリアを豊かにすることも大切です。
「なぜその成果を追うのか」「何を成果として追うのか」「それがメンバーのキャリアにどうつながるのか」「どうやって成果を出してもらうのか」。事業成果と個人成果の一貫性を設計し続ける必要があります。
事業責任者からは「事業を伸ばすためにどんな開発投資が必要か」「どんな人材をいつまでに採用すべきか」といった投資判断を求められます。採用プロセスでは「なぜ今、あなたにとってSpeeeが最適な環境と言えるのか」を候補者に伝える責任もあります。
もちろん、すべての問いにスムーズに応えられたわけではありません。むしろ「問いに十分応えられず反省し、がむしゃらにインプット・アウトプットを繰り返して何とかしてきた」というのが実態です。
開発組織戦略の質を高めるために、隣で見てきたマーケメンバーのデータ分析手法を真似てみたり、社内に知見のない技術課題の壁打ちのために社外の方にカジュアル面談を申し込んだり。泥臭く手を動かし、学ぶことが多かったですね。
Why-What-Howの一貫性や事業合理性を、より広いスコープで、多様なステークホルダーから問われ続ける。必要に応じて新たなスキルを獲得し、問いに応え続ける。これが、この5年間の仕事の核心でした。
「丸投げ」の失敗が教えてくれた、問いの立て方
もう一つの大きな学びは「権限委譲と責任」の関係についてです。
私は複数事業を兼務しながらEMをしています。同時に扱えるコンテキストの限界を超えることも多々ありました。そこで現場のエンジニアに問題解決を任せ、自分は報告を受けるだけ、というオペレーションを組んでしまったことがあります。
その結果、事業責任者から「開発計画遅延の要因、課題は何か」と問われても、「自分は関与していないのでよくわからない」という状況に陥りました。これでは説明責任を果たせていません。
仕事をしている風に見せかけて、実態はメンバーに丸投げし、成果を追えていなかったのです。「兼務しているのだから仕方ない」と何度も言いたくなりましたが、それはただの言い訳でした。
ただ、この失敗の背景には、EMになってからずっと抱えていた葛藤もありました。
- 以前の自分なら、開発上の問題が起きても自らコードを書いて何とかできた
- EMになってからは日々自分の知らないところでコードベースが変わり、PRを見ても即座に「ここはこう直せばいい」と嗅覚が働かない
手触り感がなくなる焦りから、「だったらメンバーに任せるしかない」という丸投げにつながってしまったのだと思います。
この失敗から学び、私は以下の構造を常に頭に描きながら関係者と対話するようになりました。
- 理想状態は何か
- 現状はどうなっているか
- ギャップとその要因は何か
- 解くべき課題は何か
この構造を頭に置いて対話すると、報告を受け身で聞くのではなく、「なぜその判断をしたのか」「何が現状のボトルネックか」と能動的に問いを立てられます。
直接手を動かしていなくても、適切な問いを立てることで問題の本質を把握し、解決に導く。 この血の通った問題解決こそがEMとしての自分の役割だと腹落ちしました。
そして中身を自分なりに評価できるようになると、「この問題はメンバーに任せるには荷が重い。ここはキャッチアップ込みで自分も手を動かすべきだ」といった柔軟な判断も可能になります。
とはいえ、今でも完璧にできているとは思いません。キャパを超えて丸投げしそうになる瞬間は定期的に訪れます。その度にこの失敗に立ち返り、自分を戒めています。
「挑戦の機会」が広げた問題解決の幅
2ヶ月でインフラ基盤を引き継いだ話
昨年、体制変更に伴い、DX開発基盤チームの責任者を担うことになりました。組織が拡大する中で「これまで以上に事業理解と技術理解の両観点を持って、基盤領域の開発投資を推進できるようにすべきだ」という判断があり、私に白羽の矢が立ったのです。
弊社の基盤はAWS EKSやArgoCD、Terraformを中心に構成されており、コードベースも数十万行を超える規模感です。当時の私は、マネジメントコンソールでAWSリソースのCRUDができる / TerraformやKubernetesをちょっと触ったことがある程度のインフラ経験しかありませんでした。立ち上がり期間は2ヶ月。私自身は4つの事業の開発責任者を兼務しながら、という状況です。
「体制含めてすべて自分が何とかします」と宣言し、以下のアプローチを進めました。
- 開発時間の確保：事業側の開発責任はメンバーと事業責任者に協力してもらい、定例MTGを削るなど一時的に自分の関与度を下げる
- 継続的な学習：各事業部からの開発依頼のうち、特に自分がイメージできていないものから率先して担当する。アーキテクチャの全体像を捉えるため、「毎日1時間程度インフラのコードリーディングを行う」という習慣を2ヶ月間継続する
- 新体制の構築：並行して社内外のスカウティングも行う。新メンバーのオンボーディングコストを下げられるよう、自身がキャッチアップした内容や担当した機能開発の手順はすべてドキュメントに残しながら進める
事業本部全体の基盤を守るということで、正直プレッシャーも感じていました。しかし、「あ、この設計はこういう意図だったのか」「このモジュールとあのモジュールはこう繋がっていたのか」と、苦手意識のあったインフラ領域でわかることが増えていく楽しさのほうが勝っていました。
また、基盤チームの歴代メンバーたちがドキュメント文化を大切にしており、情報が豊富に残っていたことでかなり助けられました。ドキュメント文化、大事ですね。エンジニアになりたての初心を思い出す、良い経験でした。
結果として、新たな開発投資やコストカット施策も進められる新体制を構築でき、周囲に支えられながら良い方向に進んでいます。
事業と技術の掛け算で成果を出す
新体制の狙いでもありましたが、基盤チームを引き継いで最も価値があったと感じるのは、「事業理解×技術理解の掛け算」で成果を追えるようになったことです。
これまで基盤チームは専任メンバーで構成されていたため、構造的な問題がありました。各事業の最新状況やリアルな課題をキャッチアップするコストが高く、事業成果と整合する成果定義や、全体最適な基盤投資の意思決定が難しかったのです。
例えば、基盤チームには「本番環境の個人情報をマスクしてdumpし、STG環境に定期インポートする機能」がありました。しかし元々特定の部署向けに作られたこともあり、他の部署ではあまり活用が進んでいませんでした。
ある時、私の管掌するプロダクトチームで本番環境のみで発生するパフォーマンス問題が起きました。調査の結果、データ量に起因するクエリの問題だと判明。そこで本番マスクdumpを導入したところ、STG環境でのデバッグやリリース前の検知が可能になりました。
この活用事例を他のプロダクトチームにも広めていき、最終的にすべてのプロダクトチームで導入されました。
私は複数事業部のEMを兼務しており、各事業の状況をある程度理解しています。自分がメインで関わっていない部署についても関係者とつながりがあります。兼務の特性を活かして横断機能の導入・展開を推進できるのは、基盤責任者とEMを兼ねているからこその強みです。
基盤責任者として「なぜこの投資をするのか」「何を作るのか」「どう進めるのか」を事業側に説明し、合意を取り、実行する。EMとして培ってきたWhy-What-Howへの向き合い方が、ここでも活きています。
この5年間で培った力は、AI時代の土台になる
振り返ると、この5年間で培ってきたのは「Why-What-Howの一貫性を設計し、ヒト・モノ・カネを動かして統合成果を追う」という仕事の進め方でした。結果論ではありますが、これはAI時代にも通用するアプローチだと考えています。
AIコーディングが主流になりつつある今、プロダクト開発における上流の重要性が増しています。ドメイン理解、要件定義、アーキテクチャ設計、プロジェクトマネジメント。顧客に届けたい価値から顧客体験、エンジニアリングまでの一貫性をデザインする力が求められています。
コーディングの生産性がAIで底上げされる分、上流から統合成果を追える人の希少性が増す。そんな時代が来ると思っています。
「問われる環境」で向き合い方を培い、「挑戦の機会」で問題解決の幅を広げる。この5年間の経験は、まさに統合成果を追うための土台になりました。
一緒に「問われる環境」で挑戦しませんか
ゲームルールが変わりつつあるAI時代。Speeeには各事業でやりたいことが山ほどあります。「問われる環境」と「挑戦の機会」がたくさんあります。私自身もまだまだ満足していません。
骨太なテーマに、優秀で誠実な仲間たちと挑みたい。巨大産業にバーティカルに切り込み、大きな社会課題を解決していきたい。
そう思っている方がいれば、ぜひ一緒に働きましょう。
Speeeでは一緒にサービス開発を推進してくれる仲間を募集しています！
新卒の方はこちらより本選考に申し込みが可能です！キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれた方は、こちらをチェックしてみてください！
