https://tech.speee.jp/entry/internship-of-engineer

この記事は2025 Speee Advent Calendarの1日目の記事です！

こんにちは、Speeeでエンジニア新卒採用を担当している田中（@sei_ryo10）です。
本日から2025 Speee Advent Calendarが始まりました。

昨年度もAdvent Calendarを開催し、社内外ともに非常に大きな反響をいただきました！
2024年のAdvent Calendarも、よければあわせてチェックしてみてください。

レガシー産業の構造そのものを変えにいく事業づくりの現場で、
エンジニアが事業のど真ん中にどのように関わっているのかを25日間でお届けしていきます。

Speeeを最近知ったよ、どんな会社なんだろうという方は
是非、下記記事をまずはご覧ください！
https://tech.speee.jp/entry/ai-strategy-ax
https://tech.speee.jp/entry/reformdx-ai-dev-overview
https://tech.speee.jp/entry/reformdx-dev-mission

この記事では、その入口として
エンジニアインターンシップを企画・運営する中で、
エンジニアとしてコードを書いたことのない私が感じたSpeeeのエンジニアのあり方をお話しします。

「エンジニア＝仕様を実装する人」だった私の前提
インターンシップで見えた「自分の手で事業を創る」エンジニア像
おわりに：この景色が自分にフィットするかどうか

1.「エンジニア＝仕様を実装する人」だった私の前提

少しだけ私の話をさせてください。
これまでのキャリアはずっとビジネスサイドを歩んできました。
スタートアップ（採用支援SaaS）、大手（人材系企業の新規事業開発室）と、エンジニアと一緒に仕事はしてきましたが、
どちらの現場でも、基本的な構造は同じでした。

ビジネス側が顧客ヒアリングや市場分析をして、価値や仮説を立てる
要件定義や仕様書も、基本はビジネス側が握る
エンジニアは、それを「どう作るか」に集中する

会議では、ビジネス側が「こんな画面にしたいです」と Figma や資料を出し、
エンジニアが「この期間ならできますね」と工数を返す。
要望をまとめて持っていっても、運用・保守やシステムの制約が優先されて、
「今は難しいですね」と跳ね返ってくることも少なくありませんでした。

そういう環境で働いてきた結果、
「エンジニアは、ビジネス側が決めた要件を形にしてくれる専門職」、
そして関係性もいわば「社内の業務委託」的イメージが、自分の中ではすっかり前提になっていました。

そんな前提を持ったまま私はSpeeeに転職し、
エンジニア採用に携わるようになって驚いたのは、その当たり前が全く当てはまらないということでした。

2.インターンシップで見えた「自分の手で事業を創る」エンジニア像

Speeeのエンジニアインターンシップは
今年の7月から9月にわたって計3回開催され、4月頃から企画準備が進められていきます。

私が初めて企画概要を知った時は、本当に衝撃を受けたのを今でも覚えています。
前職の印象が色濃く残っていたことに加えて、他社のインターンシップにも目を通していた私は、よくある「決められた仕様を実装する」形式に近いのかな、と考えていました。

そしてそこで目にしたのは
「あえてコードを書かないエンジニアインターンシップ」というテーマ設定。
「Speeeのエンジニアとして事業に貢献するために、Why-Whatにフォーカスして意思決定を積み重ねさせたい」
「価値ある事業を創れる、これからの時代のエンジニアに自信を持って進んでもらいたい」
といった想いや背景をベースとした、事業開発とエンジニアリングを行ったり来たりする3日間のインターンシップでした。

なぜそういったテーマが成立するのか、Speeeのエンジニアに対する”なぜ”が問いとして浮かび会議を覗いてみると
最初から営業・カスタマーサクセス・PdM・エンジニアなどが同じテーブルに座り、

「この業界におけるどういった現場課題を変えることができたら、最終的なエンドユーザーの体験が良くなるか」
「このKPIを動かすなら、どの現場オペレーションを変えるのが筋が良さそうか」
「その変化をプロダクトで支えるとしたら、どんな打ち手がありそうか」

といった話を、同じ目線で議論していました。
一緒にホワイトボードの前に立って、産業や顧客に対して向き合い続ける姿勢がまず全く違っており、
さらに驚いたのは、1年目のエンジニアも、当たり前のようにKPIや業務構造の話に入っていくことです。

「この数値の上下って、現場だとどの作業時間に跳ねてますか？」
「この業務フローだと、ここの待ち時間がボトルネックになっていそう
です」

そういった問いをきっかけに、議論の矛先が変わったり、KPIの持ち方が見直されたりしていく。
その場を見て「あ、ここではエンジニアの仕事の範囲が、最初から事業の根幹を支える部分まで、仕事のオーナーシップを期待されているんだな」
「普段の業務からコードを書く（手段）ではなく価値（目的）に常に視座を置いているんだな」と感激したのを覚えています。

そして実際のインターンシップは、3日間という短い期間で、
こんなサイクルを何度も回しながら、事業創造に挑み続けます。

業界全体の構造や現場オペレーションを調べながら「誰が・どの瞬間に・何に困っているのか」を言語化する
事業のKPIやP/Lを考えながら、「どこを変えるとインパクトが大きいか」をチームで考える
その上で、「プロダクト/仕組みとしてどこをどう変えていくべきか」の方針を決める
選んだ打ち手を実現するための技術的な構成を考える
メンターと相談しながら、検証のスコープや優先順位を整理する
限られた時間の中でプロトタイプを作り、事業の文脈とあわせて事業責任者とエンジニアリングマネージャーへ発表する

※インターン時の風景

今まで考える機会が少なかった、ビジネスとして成立するのか？や本当に顧客に価値があるのか？という問いをひたすらメンターからフィードバックされながら、
分からないなりになぜ必要なのかを考え抜き、単にエンジニア視点で作りやすい、使いやすそうな機能を開発するのではなく、それがどういう風に顧客に価値として届き、産業課題の解決に繋がっていくのかという問いに向き合ってもらいたい。

そんな想いの先のインターンシップ後アンケートでは

「なぜ作るのか？作った先にどれほどのビジネスインパクトがあるかという、ここまで上流の視点を持って開発に携わることは初めてだった」
「機能開発というより、事業づくりそのものにエンジニアが関わる感覚があった」
「その事業が誰のどんな課題をどのように解決するのかや利益の出し方、実装方法まで幅広い側面から、0からの事業案を組み立てる経験が得られた。また、ビジネス側、エンジニア双方の社員さんと一緒に事業案を組み立て、フィードバックをいただけるので、実際に現場で求められるレベル感を肌で感じることができた」
「参加したエンジニアインターンの中で、最もビジネス側の事業価値をエンジニアが考えていた」

といったコメントが複数見られました。
これは、私達が日常として見ている、届けたい「Speeeエンジニアの仕事」がそのまま学生にも届いた瞬間でした。
私自身、当日の参加学生や社員が本気で熱量高く没頭している様を受けて、めちゃくちゃアツい想いが湧いてきて、何かできることはないかと最後まで奔走していました。
（ちなみに）実際に参加者の7割以上は、自分の手で事業をつくり、ユーザーに届けられるエンジニアになりたいと思って本選考に進んでくれています。

おわりに：この景色が自分にフィットするかどうか

エンジニアとしてコードを書いたことのない私がSpeeeに入り、
「事業を創るエンジニア」と「そのエンジニアが力を発揮できる組織づくり」の両方を、そばで見てきました。

その中で、自分の中に残っているのは

産業や事業構造の根本からエンジニアが深く考えること
どこにAIを活用させながらプロダクト設計するかチームで踏み込んでいくこと
その結果が、Speeの現場だけでなくその先の顧客体験としても大きく跳ね返ってくること

こういったプロセスが「特別な場」ではなく「日常」として回っていると、
エンジニアの仕事の役割はかなり立体的になっていきます。

以前は「ビジネス側が決めた要件を、できるだけきれいに実装してくれる人」という印象が正直なところでした。
今はむしろ、「誰の・どんな前提を変えると、一番インパクトが出るのか」を一緒に考えるチームであり「事業の意思決定と、プロダクト技術選択を同じ目線で”つなぐ”」関係性だと感じています。
コードを書くこと自体よりも、「どんな事業をどう動かすために、その技術を選ぶのか」というところまで踏み込むエンジニアが、Speeeでは当たり前にいます。

ものすごくレベルの高い経験や、完璧な答えを持っていてほしいわけではありません。
むしろ、「まだうまく言葉にできないけれど、事業づくりにもちゃんと関わりたい」「ユーザーや産業のことをもっと深く理解した上で、技術を選べるようになりたい」と思っている人にこそ、Speeeの環境はフィットするんじゃないかと感じています。

この記事は、「Speeeはこういう会社です」と結論を出すためのものではありません。
私が入社後に見えた景色のいくつかの断片が、Speee理解のヒントになれば嬉しいです。

もし読み終わって、