【テクニカルサポート】大手SEからテクニカルサポートへ。技術力で「プロダクトの信頼」を資産化する挑戦

株式会社Squadは、「この世で最も人を生かす企業であり続ける」という理念を掲げ、デジタル広告運用プラットフォーム「Squad beyond」を開発・提供しています。リリースから約4年でARR12億円を突破し、現在は「10→100」の非連続な成長を目指す第2創業期の真っ只中にあります。

今回は、2024年10月に中途入社したテクニカルサポート、飯田瑞穂さんにインタビュー。大手証券系のシステム会社でSEとして大規模システムの根幹を担ってきた彼女が、なぜスピード感溢れるスタートアップへの転身を決めたのか。その背景にある仕事への哲学と、SquadのVALUEである「MECHANISM FIRST」を体現する、自動化と品質向上への並々ならぬこだわりを深掘りします。

飯田 瑞穂 / テクニカルサポート

2021年、大手証券系のシステム会社に新卒入社。SEとして新NISA制度対応の大規模プロジェクトや国内・米国株の保守運用に3年半従事。2024年10月に株式会社Squadへ参画。現在はテクニカルサポートとして、SQLを用いたログ調査、不具合の切り分け、リリース前の最終検証、業務自動化の仕組み構築を担う。

若い世代の資産形成を支えたい。コロナ禍で決意したエンジニアへの道

──飯田さんは新卒で証券系のシステム会社を選ばれたとのことですが、まずは当時の入社理由から教えてください。

就職活動を行っていた時期は、ちょうど新型コロナウイルスの流行と重なっていました。将来に対する不透明感が強まる中で、場所を選ばずに働ける在宅勤務の可能性と、どこに行っても通用する一生モノのスキルを身につけたいと考え、IT業界を志望しました。

数ある中で証券系を選んだのは、当時話題になり始めていた「年金問題」や「将来の資産形成」に対する不安がきっかけです。自分たちのような若い世代が将来困らないよう、複雑で分かりにくい証券システムをより身近で使いやすいものにしたい。そんな想いから、社会インフラとしての責任が重い大手証券系のSEとしてキャリアをスタートさせました。

──実際に3年半、どのような経験を積まれたのでしょうか。

入社2年目という早い段階から、金融業界のビッグプロジェクトであった「新NISA制度」への対応チームでリーダーを任せていただきました。要件定義から設計、テスト、リリース後の運用まで、約2年の歳月をかけて一貫してプロジェクトを牽引しました。

ですが、大手ならではの「責任の重さ」は相当なものでした。特に月に2回ほどあった夜間待機業務は過酷でしたね。夜中の2時や3時に不具合が発生すれば、自分一人で調査し、寝ている上司に電話をして指示を仰がなければなりません。1分1秒の遅れが大きな障害に繋がるプレッシャーの中で、周囲に相談できる相手もいない状況を何度も乗り越えてきました。この経験が、どんな不測の事態でも「まずは自分で手を動かして解決策を探る」という現在の私のメンタルの強さに繋がっています。

「リリースして終わり」のジレンマ。技術を武器に、ユーザーの声を拾う場所へ

──着実に実績を積まれていた中で、なぜ転職を考えたのですか。

SEとしての仕事に誇りは持っていましたが、次第に「自分の作ったシステムが、本当にユーザーのためになっているのか」が見えにくいことに寂しさを感じるようになったんです。大規模開発では、決められた仕様通りにリリースすることが正解とされ、リリースした瞬間にそのシステムは自分の手を離れてしまいます。

2年もかけて構築した新NISAのシステムでさえ、リリース後にお客様からどのような反響があったのかを直接知る機会はありませんでした。次第に、ただ作るだけではなく、ユーザーの隣でプロダクトの価値を直接高められる場所へ行きたいという想いが抑えきれなくなりました。

──Squadへの入社の決め手は何だったのでしょうか。

実は、最初は全く別のマーケティング職への挑戦も考えていたんです。ですが、Squadの面接で明石さんとお話しした際、「未経験の職種に飛び込むよりも、今持っているエンジニアとしての技術力を武器に、マーケティング業界を支えるテクニカルサポートとして関わる方が、飯田さんにしか出せない価値が最大化されるはず」とアドバイスをいただきました。

「Squad beyond」というプロダクトは、非常に多機能で奥が深く、ユーザーであるマーケターの方々にとっても技術的な理解が成功の鍵となります。私の培ってきたスキルがあれば、複雑なログから本質的な課題を特定し、ユーザーが抱えるハードルを技術で取り除いていける。この「エンジニアリング×顧客接点×マーケティング」というテクニカルサポートの立ち位置こそが、私が求めていた「手触り感のある仕事」そのものだと確信し、入社を決めました。

「MECHANISM FIRST」の体現。不具合を「仕組み」で根絶する攻めのサポート

──現在の具体的な業務内容について教えてください。

テクニカルサポートとして、SQLを用いた高度なログ調査や不具合の切り分け、そしてリリース前の最終検証などを担当しています。Squadのテクニカルサポートは、単にお問い合わせに回答するだけの「受け身のサポート」ではありません。

例えば、以前は人手によるチェックに頼っていた検証工程を、前職の厳格な品質管理の知見を活かして網羅的なテストケースとして資産化しました。また、ユーザーから指摘されてから不具合に気づくのではなく、システム側で異常を事前に検知するツールの導入を開発チームに提案し、実装を進めています。実際に、私が検証フローを整備するようになってから、リリース後の大きな障害発生件数は減少しており、プロダクトの信頼性向上に直接寄与できていると実感しています。

──「業務の自動化」にも非常に力を入れているとお聞きしました。

私は「面倒なこと」が本当に嫌いなんです（笑）。同じ作業を繰り返すのは時間の浪費ですし、属人的な作業は必ずミスを生みます。だからこそ、一度起きた不具合や定型的な調査業務は、スクリプトを組んで徹底的に自動化することを心がけています。

これはSquadのVALUEの一つである「MECHANISM FIRST（仕組み化・資産化）」そのものです。自分が頑張って問題を解決するのではなく、次からは「誰がやっても、あるいはシステムが自動で」解決できる仕組みを創り上げる。この仕組み自体を会社の資産として残していくことに、テクニカルチームとしてのこだわりを持っています。

──他部署との連携において、意識していることはありますか。

テクニカルサポートは、開発チームとCS（カスタマーサクセス）チームの間に立つ「翻訳者」のような役割だと思っています。エンジニアの言葉をユーザーに分かりやすく伝え、逆にユーザーの切実な声を開発が優先すべき課題へとロジカルに整理して届ける。このハブとしての機能が、プロダクトの進化スピードを最大化させると信じています。

自律したプロが選ぶ「Work as Life」な生き方

──働き方の面で、大手企業との違いを感じる部分はどこですか。

時間の使い方の「密度」が圧倒的に違います。Squadには10時から18時までの実質7時間という規定がありますが、これは単に「短い」ということではなく、その時間内にどれだけのインパクトを出せるかという、非常に高いハードルが設定されていると感じます。無駄な会議や形式的な報告は削ぎ落とされ、VALUEの「IMPACT FIRST（成果への執着）」を徹底しているように感じます。

また、社内には本格的なコーヒーを楽しめる「Squad Base Cafe」が併設されており、福利厚生の社割を利用することで1杯100円で味わうことができます。加えて、パフォーマンスを最大化させるための柔軟な休暇制度が整っていたりと、社員が「成果を出すこと」に集中できる環境があります。仕事の質に一切妥協したくない私にとって、高い集中力を維持できるこの環境は非常に魅力的です。

──今後の展望について教えてください。

今後は、AIをさらに活用してテクニカルサポート業務の完全自動化領域を広げていきたいです。そして、ユーザーからの問い合わせを待つだけの立場を卒業し、収集したデータを基に「プロダクトをこう変えるべきだ」という提言を短いスパンで開発チームへ送り続ける存在になりたいです。

──最後に、どのようなエンジニアにSquadのテクニカルサポートを勧めたいですか？

「自分が何のためにコードを書いているのか」という目的意識を強く持ちたい方です。大手企業の整った環境では味わえない、自分の判断一つでプロダクトが劇的に良くなる手応え、そしてユーザーから届くダイレクトな「ありがとう」の声。技術を単なる作業ではなく、ビジネスを動かす強力なエンジンとして使いたいと考えている方なら、Squadはその力を存分に発揮できるフィールドだと思います！