株式会社Squadは、「この世で最も人を生かす企業であり続ける」という理念を掲げ、デジタル広告運用プラットフォーム「Squad beyond」を開発・提供しています。

今回は、2025年2月に中途入社した開発リーダー、岩倉誠徳さんにインタビュー。

SIer、受託開発、自社サービスなど複数の開発現場を経験してきた岩倉さんが、なぜ6社目としてSquadを選んだのか。入社後に任されたClickHouseへの大規模移行プロジェクト、現場の声を拾いながらプロダクトを磨く開発スタイル、そしてSquadで感じる「プロダクトの当事者」としての手応えについて話を聞きました。

岩倉 誠徳 / 開発

岩手県の商業高校情報科を卒業後、情報系の短期大学校にてITエンジニアの基礎を習得。新卒でSIerに入社し、受託開発会社を経て、「プロダクトの仕組みから考える開発がしたい」という想いから、自社サービスを展開する企業を数社経験。前職時代の先輩との縁をきっかけに、2025年2月、株式会社Squadに入社。

「もっと良い方法があるのに」。作業者としてコードを書くことへの違和感

──まずは、これまでのキャリアについて教えてください。

エンジニアとしてのキャリアは、SIerからスタートしました。その後、受託開発会社や自社サービスを展開する企業など、複数の開発現場を経験してきました。

Squadは6社目の会社になります。

これまでいろいろな現場を見てきましたが、どの環境にいても、心のどこかで小さな違和感を抱えていました。

それは、「最適ではないと分かっていながら、言われた通りに作る」ことへの抵抗感です。

受託の現場では、派遣先やお客様から指定された仕様書が絶対になることがあります。エンジニアの視点では「もっと良い方法がある」「この設計は後で問題になりそうだ」と思っていても、議論の余地がなく、ただ過不足なくコードを書くことだけが求められる。

もちろん、決められたものを正しく作ることも大切です。ただ、自分の知見を活かしてプロダクトをより良くするというより、「作業者」として手を動かしている感覚が強く、そこにどうしても納得しきれない部分がありました。

──その違和感が、転職を考えるきっかけになったのでしょうか。

そうですね。

自分は、ただ仕様通りに作るだけではなく、「なぜそれを作るのか」「本当にその設計が最適なのか」まで考えながら開発したいという想いがありました。

特に自社サービスの開発を経験する中で、プロダクトの仕組みや事業の構造から考えて開発する面白さを感じるようになりました。

だからこそ、次の環境では、エンジニアとしての技術だけでなく、プロダクトやビジネスに対しても当事者意識を持てる場所を選びたいと思っていました。

ホワイトボードの前で感じた、Squadならではの「納得感」

──Squadを知ったきっかけは何だったのでしょうか。

以前お世話になっていた先輩から紹介いただいたことがきっかけです。

正直に言うと、これまで複数の会社を経験してきた分、新しい環境に対しても、どこか冷静に見ている自分がいました。

ただ、代表の杉浦さんと話したときに、その感覚が大きく変わりました。

最終面接の場で、杉浦さんがホワイトボードを使いながら、業界構造やSquadのプロダクトの特徴、そして「なぜこのプロダクトが必要なのか」を非常にロジカルに説明してくれたんです。

単なる機能の話ではなく、ビジネスとしてどこに勝ち筋があり、そのためにシステムがどう機能すべきなのか。その説明にとても納得感がありました。

「ここなら、言われたものをただ作るのではなく、なぜ作るのかを理解した上で開発に向き合えそうだ」と感じたことが、入社の大きな決め手です。

──入社後、その印象に変化はありましたか。

むしろ、入社後にその感覚は強まりました。

印象的だったのは、入社後に飲みの席で「実は一度も出張に行ったことがない」と何気なく話したことがあったんです。すると翌週には、大阪にあるグループ会社、株式会社ビジネスブレーンの現場に行くことになっていました。

そこで、営業メンバーの隣に座り、実際にシステムを使うお客様の困りごとを直接ヒアリングしました。

エンジニアが仕様書だけを見て開発するのではなく、現場に足を運び、ユーザーが何に困っているのかを自分の目で見る。そうやって得られる情報には、仕様書だけでは分からない「手触り感」があります。

この働き方は、自分にとても合っていると感じました。

ClickHouseへの大規模移行。プロダクトの骨格に触れた3ヶ月

──入社後、最初に大きく任された仕事について教えてください。

入社後まもなく任されたのが、広告運用最適化プラットフォーム「Squad beyond」のレポートデータを、新基盤であるClickHouseへ移行するプロジェクトでした。

対象となるのは、複雑なロジックが絡み合う10数個のレポートです。それを一人で新しいシステムに載せ替える必要がありました。

お客様が日々の広告運用で参照する重要な画面なので、万が一ミスがあれば、日々の意思決定にも影響してしまいます。プレッシャーは大きかったです。

約3ヶ月間、レポートの裏側にあるデータの流れや、システムの核となるヒートマップのロジックを一つひとつ紐解きながら、地道に移行を進めていきました。

──そのプロジェクトを通じて、どのような手応えがありましたか。

もしこれが、誰かが決めた設計図をそのままなぞるだけの仕事だったら、プレッシャーに耐えるだけの時間だったかもしれません。

でも今回は、プロダクトの構造そのものを理解しながら進める必要がありました。なぜこのデータが必要なのか、どのように表示されているのか、どこに改善余地があるのかを、自分で考えながら進めていく感覚がありました。

移行が完了した後、社内から「岩倉さんのおかげで、これまでにできなかった分析が可能になった」という声をもらえたときは、とても嬉しかったです。

自分の仕事が、プロダクトの改善だけでなく、インフラコストの削減という経営数字にもつながっている。その実感を得られたことで、ようやくプロダクトの当事者になれたように感じました。

失敗を責めるより、次にどう良くするかを考える組織

──Squadの組織文化については、どのように感じていますか。

Squadには、「レスポンスは速く、悪い報告こそ直ちに行う」という考え方が根付いています。

以前の現場では、不具合を出すと責任を追及され、重い空気が流れることもありました。もちろん不具合を出さないことは大前提ですが、人が関わる以上、何かが起きる可能性はゼロではありません。

Squadで私が初めて障害を起こしてしまったとき、メンバーが最初に声をかけてくれたのは、「大丈夫？落ち込んでない？」というフォローでした。そのうえで、「次はどうリカバーしようか」と、すぐに前向きな話に切り替わりました。

失敗した人を責めることに時間を使うのではなく、次にどう良くするかを全員で考える。

これは単なる優しさではなく、組織としてとても合理的な姿勢だと思っています。隠さず、速く報告し、速く改善する。その規律があるからこそ、安心して挑戦できるのだと感じています。

──チームの雰囲気としては、どのような特徴がありますか。

フラットでありながら、決して自由すぎるわけではないところが特徴だと思います。

それぞれが自分の役割に責任を持ち、必要なことは率直に伝える。一方で、困ったときには自然にフォローし合う空気があります。

「ただ優しい」だけではなく、プロダクトを良くするために必要なことはきちんと話す。そこに、Squadらしい健全さがあると感じています。

完璧を待たず、今の最適解を出す。Squadのスピード感

──Squadの働き方で、特に印象的なことはありますか。

やはりスピード感です。

入社前から「スピード感のある会社だ」と聞いていましたし、自分自身もそれを求めて入社しました。ただ、実際に入ってみると、想像以上に徹底されていると感じました。

象徴的なのが、「まず出して、ブラッシュアップする」という考え方です。

完璧な100点を待つのではなく、まずは7割、8割の段階で世に出し、現場の反応を見ながら改善を重ねていく。

エンジニアとしては、どうしても完璧なものを作ってからリリースしたい気持ちがあります。私自身もそうでした。

ただ、今は「完璧なものを作る」よりも、「今の状況で最適なものを作る」ことに意識が向くようになりました。

現場のニーズは常に変わります。その変化に対応するには、時間をかけて完璧を目指すよりも、現時点でできる最適解を早く届け、そこから改善していく方が、結果的に正解へ近づけるのだと思います。

──そのスピード感に戸惑いはありませんでしたか。

最初は驚きました。

ただ、今はこのやり方にとても納得しています。

リリースして終わりではなく、出した後に改善を続けることが前提にあるので、プロダクトがどんどん強くなっていく感覚があります。

また、現場の声を拾いながら改善するため、自分たちの開発がユーザーや事業にどう影響しているのかを感じやすいです。

この手触り感は、これまで経験してきたどの現場とも違う面白さだと思います。

技術を、事業成果につなげられるエンジニアへ

──Squadに入社してから、自分自身に変化はありましたか。

エンジニアとしての視座が変わったと思います。

以前は、目の前の機能をどう実装するか、どう正しく動かすかに意識が向きがちでした。

もちろんそれは今も大切ですが、Squadではその先にある「この機能は誰のどんな課題を解決するのか」「事業にどう影響するのか」まで考える機会が多くあります。

ClickHouseへの移行プロジェクトもそうですが、自分の仕事がプロダクトの土台や経営数字に直結していると感じられる経験は、エンジニアとして大きな成長につながりました。

今後も、単なる実装者ではなく、プロダクトの当事者として、技術をビジネスの成果に結びつけられるエンジニアでありたいです。

──最後に、どのような方にSquadを知ってほしいですか。

かつての私のように、「自分の知見を活かし、納得しながらモノづくりをしたい」と感じているエンジニアには、ぜひ一度Squadを知ってほしいです。

Squadには、言われた通りに作るだけではなく、なぜ作るのか、どう作るべきかを考えながら開発できる環境があります。

もちろん、スピード感はあります。変化も多いです。完璧を待つのではなく、今できる最適解を出し、改善し続ける姿勢も求められます。

ただ、その分、自分の仕事がプロダクトや事業にどうつながっているのかを、ダイレクトに感じることができます。

技術をどうビジネスの成果に結びつけるか。その手応えを感じながら働ける毎日は、これまでのどの現場とも違う面白さがあります。