【1社目】“できそうなこと”から始まった

まず大学卒業後に新卒で入社したのは経理システム開発会社で、そこでは営業職としてキャリアをスタートし、そこでテレアポ営業や飛び込みの訪問営業などの新規開拓の営業に従事していました。

なぜ「営業職」×「経理システム」という一見ピンポイントな選択をしたのか。
正直なところ、“やりたいこと”が明確にあったわけではなく、「文系の自分にできそうなこと」「今持っている資格（簿記）を活かせる分野」という消去法で選んだ結果でした。

今振り返れば、当時の自分の心の奥には「プログラマー」や「デザイナー」などのクリエイティブな仕事に対する憧れが確かにあったと思います。
でも、「文系だから無理だろう」「専門的な資格がないと難しい」といった先入観に縛られて、諦めてしまっていました。

ただ、その営業としての経験は、社会人としての土台を築いてくれた大切な時間だったとも感じています。将来的には自分の中にあった価値観や可能性、方向性に気づくきっかけにもなりました。
 

【2社目】売るだけじゃなく、“作る”ことにも関わりたいと思った

1社目に続き、2社目でも営業職を選びました。
理由はシンプルで、「自分にできそうなこと」に引き続きフォーカスしていたからです。

入社したのは名古屋のWeb制作会社。ここでは、地域の中小企業や個人事業主に対して、ホームページ制作の提案営業を担当していました。飲食店や美容室、整骨院など、さまざまな業種のお客様と関わる中で、単なる“売る”営業ではなく、課題をヒアリングし、価値を一緒に考え、提案する――そんな奥深さのある仕事でした。

ただ、営業としてものづくりに少しずつ関われるようになった中で、次第に「もっと“作る側”に近づきたい」という思いが徐々に強くなっていきました。
そんな時、社内にはエンジニアやデザイナーが多く在籍していて、ふとした雑談で「文系でもエンジニアになれるんですか？」と尋ねたところ、彼らの多くが自分と同じ文系出身だったことに驚きました。
自分の中にあった「文系だから無理」という思い込みや先入観がその瞬間に壊れ、道が開けたような感覚になったのを覚えています。

そこからは、業務の合間や休憩時間、休日などを使って、独学でPHPやJavaScript、ネットワーク基礎などを学習しました。
営業の現場で感じていた「顧客管理の煩雑さ」を解決するためのシステムを自作し、それを成果物として部署異動を打診したところ、無事Webエンジニアとしてのキャリアをスタートさせることができました。

今でこそ自分はなりたかったエンジニアとして働けていますが、この選択を行なっていなかったら今の自分はいなかったと思うとあの時、一歩踏み出してよかったと、今でも心から思っています。

初めての”実務”としての開発

前述の通り、2社目で営業から無事にWebエンジニアに転向できたのですが、開発部に配属された当初はかなり大変だったなと今振り返っても思います。

実務に入って最初に感じたのは、「独学とはまったく違う」という強烈なギャップでした。動くだけでは通用せず、品質・スピード・安定性すべてが求められます。そして何より、自分の開発した機能が本番環境に反映され、それによって実際にお金が動くという責任の重さに圧倒されました。ちょっとした不具合で顧客に迷惑がかかるかもしれない、というプレッシャーは想像以上で、毎回のリリースが緊張の連続でした。

それでも、できなかったことができるようになる過程は本当に面白く、実務経験を積むことでしか得られないトライ＆エラーを繰り返す中で少しずつできることが増えていく実感は、確かな手応えになりました。課題を1つずつ潰していくたびに、自分の中の「エンジニアとしての芯」が育っていくような感覚がありました。

新しいプロダクト開発へのアサインと、その“もどかしさ”

前職には当時、絶対の収益の柱となるサービスが1つありました。確かにそのプロダクトは安定した収益を生み、会社の大きな支えになっていたのですが、それ以外にはそのサービスと肩を並べるような明確な軸となるプロダクトが存在していませんでした。

エンジニアに転向して数ヶ月ほど経過した折、私は“新規プロダクト開発”を行うチームにアサインされるようになりました。エンジニアになってまだ日が浅かった自分からすると「ゼロから何かを作る」というフェーズは純粋にワクワクする経験でした。要件定義から設計、実装に関わり、プロダクトのコアに関与できるのは、経験が浅い自分としてはとても貴重なチャンスだったと思います。

しかし、その一方で、開発したプロダクトが適切に運用されることはほとんどなく、リリース後は徐々に社内でも存在感が薄れていくものも多くありました。まるで「作ること自体がゴール」になってしまっているような状況で、「誰のために」「何のために」作ったのかが曖昧なまま終わってしまうプロジェクトも珍しくありませんでした。

「育てる」経験をしたいと思った理由

 

そうした状況の中で、自分の中に芽生えてきたのが「プロダクトをしっかりと“育てていく”経験をしてみたい」という想いでした。作って終わりではなく、ユーザーに届け、フィードバックを受けながら改善を重ね、より良いものにしていく——そんなプロダクトライフサイクル全体に責任を持ちたいと思うようになりました。

その想いが、現状を変えるという意味で転職を意識する大きなきっかけになりました。
よりユーザーに向き合い、プロダクトとともに成長していける環境に身を置きたい。ちゃんと使われるシステムの開発をしたい。その気持ちが、次のキャリアの選択に自然と繋がっていきました。

sumarchに入社を決めた理由

プロダクトを“育てる”経験をしたい——そんな思いから転職活動を始めた私は、「リリース後もプロダクトと向き合い続けられる企業」を探していました。単なる受託開発や機能実装ではなく、ユーザーの声をもとに改善を繰り返し、プロダクトを中長期で育てていく姿勢を持つ企業に身を置きたいと考えていました。

具体的には、自社で基盤となるプロダクトを運営しており、ユーザー、現場などの利用者と直接向き合える体制があること。さらに、プロダクトに対して強いオーナーシップを持つチーム文化があり、開発者自身が意思決定や改善のプロセスに関われること。この2つを特に重視して企業を探していました。

転職エージェントを使用して転職活動を行っており、その中で何社か内定をいただいていて、自分が100%納得のいく結果ではなかったが次の環境が充分に自分のやりたいことができる環境に身を置けるなと実感はしていたので、転職活動をそろそろ終わりにしようと思っていた矢先で転職エージェントに提案されていたスケジュールの残り日程にあったsumarchのカジュアル面談を受けました。

そこではプロダクト運営の進め方や使用されている技術スタック、メンバーの特色、チーム開発についてなど様々な話を聞かせていただき、次第に興味を惹かれるようになりました。

技術スタックやチームの雰囲気も自分にフィットしていると感じた一方で、sumarchの皆さんが「プロダクトを通じて世の中の構造を変えていきたい」と真剣に語っていた姿勢にも強く心を動かされました。単なるツールの提供やサイトの管理ではなく、プロダクトの進化によってユーザーの行動や習慣、ひいては業界全体のあり方に影響を与えていこうという視座の高さに、大きな魅力を感じました。

すでに他社の内定を受けていた私にとって、sumarchとの出会いは“想定外”ではありましたが、話を重ねるごとに「ここでなら自分の望むプロダクト開発が実現できる」という感覚が強まり、最終的には100％納得いく決断と共に迷いなく入社を決めました。

 

チームメンバーのプロダクト意識の高さ

sumarchに入って驚いたことのひとつが、エンジニア・デザイナー・ビジネスサイドを問わず、誰もが「プロダクトを良くする」ことに強い当事者意識を持っているということでした。

たとえば、1つの機能を実装するにしても、sumarchの制作チームでは単に「要件を満たすかどうか」だけでは議論は終わりません。
「この機能は本当にユーザーにとって必要か？」「別のユースケースではどう振る舞うべきか？」「この設計で将来的な拡張性に問題はないか？」といった問いが、日常的に行き交っています。

誰かがリードするのではなく、それぞれが自分の立場を越えて、ユーザー視点やプロダクト全体の文脈から意見を出し合う。
それによって、一見シンプルな仕様も、プロダクトとしての意義を持った実装に磨き上げられていっていると一緒に働いていて感じました。

 

「育てる」という開発スタイル：終わりのないプロダクトとの向き合い方

sumarchではプロダクトは「一度作って終わり」ではなく、継続的に手をかけて育てていく対象として捉えられています。リリースはゴールではなく、むしろスタートライン。運用フェーズに入ってから見えてくる現場の課題や、技術的負債への対応、さらには中長期的な保守性・拡張性まで視野に入れて、プロダクトと向き合い続ける姿勢が当たり前となっています。

たとえば、ある機能の設計においても、開発チーム内では「将来的に似たような機能が追加された場合にも横展開対応がスムーズにできるか」「運用チームが無理なく管理できる設計になっているか」「システムとしての安定性をどのように担保するか」といった観点からの相談や議論が活発に行われています。時には、実際の業務を担う現場サイドの声を聞きながら、プロダクトの“使われ方”を理解したうえで判断していくプロセスも組み入れて進めていくことも珍しくないと思います。

また、開発効率やスピードだけに偏らず、「作ったものを将来にわたって責任を持てるかどうか」を重要な判断基準として、仕様や実装を丁寧に積み上げていったり、コードレビューの文化も根付いています。単なる“動くもの”ではなく、“安心して使い続けられるもの”を提供するための技術的な設計やコード品質への配慮が、開発の随所に見られるなと個人的には感じています。

こうした姿勢は、単なるバグ修正や改善対応にとどまらず、プロダクト全体の持続可能性と進化の可能性を高める土台となっています。sumarchの開発スタイルは、まさに“プロダクトと長く向き合い、共に育てていく”という言葉がふさわしいと日々実感しています。

生きているシステムを壊さずに育てていくという責任

0→1でプロダクトを立ち上げるフェーズでは、「まず作ってみてダメなら壊す」といういわゆるプロトタイプ的な進め方が許されることもあります。でも、すでに多くのユーザーが使っている“生きているプロダクト”では、そうはいきません。
ちょっとした改修が、システムの思いもよらない部分に影響を与えることもあります。システム全体の整合性や保守性、そして安定稼働をいかに守るか。自分が触れるコードが、裏側で多くの人の業務を支えていたり、ユーザーが使っているんだと考えると、自然と身が引き締まります。

 

プレッシャーの先にある、プロダクト育成の楽しさ

正直に言えば、入社してまだ3ヶ月の自分にとって、この「育てる開発」の責任の重さは前述のように大きなもののように感じています。

しかし、それと同時に自分の手でプロダクトをより良くできる余地があること、それが誰かの仕事や体験を確実に変えていくことに、エンジニアとしての面白さを強く感じています。

この環境で成長していくには、技術的なスキルを伸ばすだけでなく、プロダクトの構造やユーザーの視点、チームの動きなど、もっと広い視野で物事を捉える力が必要だと感じています。
だからこそ、いまは目の前の一つひとつの課題と真摯に向き合いながら、少しずつ「自分にできること」を増やしていくフェーズだと思いますし、その過程をすごく楽しめているので入社して良かったなと感じる点の1つでもあります。

これからもっと経験を積んで、技術的なスキルはもちろん、プロダクト全体を見渡して判断できる力もつけていき、安心して使い続けられるプロダクトを、チームメンバーと一緒に“育てていける”存在になれたらいいなと思っています。

sumarchに入社してまだ3ヶ月程度と日は浅いですが、その3ヶ月の間にも様々な分野の実装に携わらせていただきました。
その中でも印象的な実装をご紹介できればと思います。

類似物件表示機能

sumarchではハウスボカンという愛知県に根ざした不動産売買サイトを運営しております。

私が入社して初めてアサインされた機能追加案件としては
物件詳細ページの中に今見ている物件と近い性質を持つ物件を類似と判断される条件に基づいて、
取得し、表示するというものでした。

初めて不動産業界のサイトのソースコードに触れたこともあり、初めは物件種別や駅近、価格、築年数など多岐にわたる条件の組み合わせに苦戦しましたが、エンジニアチームの先輩方のお力添えなどもあり無事に実装できたことを嬉しく思ったことを覚えています。

マイページ拡充

ハウスボカンには会員登録機能があり、会員ユーザーに最適なおすすめ物件の表示や物件のお気に入り機能などがありました。

もっと会員登録者数を増やすにはどうすればいいか、会員登録後により多くのメリットをユーザーに届けるにはどうすればいいかが社内でも議題で上がっており、そのための施策の一歩としてマイページの機能拡充に私がアサインされることになりました。

主に今回の実装で行ったことは、デザイナーさんの協力によるUIの大幅改善やバックオフィスツールとの連携強化など様々でしたが、特に自分が力を入れた機能はユーザーがお気に入りしてくださった物件に対するアプローチの追加でした。

従来のお気に入り物件確認機能は単純にお気に入りされた物件を表示し、確認や個人メモを残せるようなものでしたが、ここにプラスでマップ上からお気に入り物件を確認できるようにし、地理的表示確認を可能にしました。加えてマップ上にお気に入り物件に紐づく学校の位置を出力することで物件購入後の生活のイメージがしやすいようにもなっております。

 

S3バケットの移管と画像のCDN配信対応

sumarchではサイトのインフラにAWSのサービスを多く採用しており、その管理をTerraformというIaC（Infrastructure as Code）ツールで管理しています。

ある日、サイトパフォーマンスの改善が議題に上がりそのための施策の一環として、
画像のCDN配信がエンジニアチーム内で提案され、その実装担当者として私がアサインされました。

前職ではオンプレミスのサーバーの監視と簡単なサーバー操作くらいの経験しか積んでおらず、自分にとって初めてパブリッククラウド型のインフラ領域とIaCという管理手法を触る機会になりました。

今回の対応で行ったことは3つあり、1つは運用上の都合によるS3のアカウント移行、もう1つはCloudfrontの実装、最後にキャッシュ削除用lambdaの設置になります。

いずれの作業も自分からすると未知の領域で不安もありましたが、チームの先輩方がしっかりフォローしてくださり、緊張はしながらも落ち着いて作業に挑むことができました。

インフラというプロダクトのコアの部分を触るという緊張感もありましたが、なにより自分が書いたソースコードでインフラが実装されていくというのは非常に面白かったですし、これからも機会があればもっと挑戦していきたいと思いました！

ここまで読んでいただき、ありがとうございました！

この記事は、入社して3ヶ月のタイミングで書いた、自分にとって初めてのストーリー記事になります。
前職までの経験と比べながら、sumarchで感じたことや、日々の中で見えてきたギャップや発見を、できるだけ等身大の言葉で書いてみました。

sumarchのプロダクトとチームは、まさに“これからもっと成長していく”というフェーズにいます。まだ完成された仕組みではないからこそ、意見を出し合いながら一緒に作り上げていく余白があり、フラットに議論できるメンバーがそろっているのも、大きな魅力だと感じています。

「プロダクトを育てる」ことに向き合いたい方、自分の手で“誰かに届く”開発をしてみたい方、そんな方と一緒に働けたら嬉しいです。

少しでも興味を持っていただけたら、ぜひカジュアルにお話ししましょう！