S2 では、入社から比較的早い段階で実案件に関わるケースも多く、それぞれの開発を通じて、様々な経験を積んでいきます。
今回は、そんな“最初の案件”にフォーカスし、新しくチームに加わったメンバーがどのように開発に取り組んでいたのかを掘り下げてみました。

話を聞いたのは、バックエンドチームの maya さん。
入社してしばらく経った今、あらためて最初の案件を振り返ってもらいました。

前職との違いや、技術的に苦労したこと、社内での進め方の学びなど、今につながる経験について話を聞いています。

※アイキャッチの写真は、maya さんが普段から愛用している自作キーボード。
こちらの記事もぜひ合わせてご覧になってみてください。

01 S2 に入るまで、そして入社初期のこと

ーーまず、これまでのご経歴を簡単に教えてください。

前職では、受託開発や SES として PHP や Java を使ったプロジェクトに取り組んでいました。
いわゆるレガシーなシステムを少しずつモダンな構成に置き換えていくような案件にも関わっていて、技術的な整理をするような場面もありました。
フロントとバックエンドがはっきり分かれていない現場だったので、どちらも担当していましたね。


ーーS2にはどういった形で入社されたんですか？

バックエンドエンジニアとして入社しました。
最初は社内向けのサービスの修正や、比較的小さな開発業務を通じて、S2 での開発体制や進め方に慣れていきました。
そうした期間を経て、今回の案件がはじめて本格的に関わる外部向けのプロジェクトでした。

02 最初の案件で得た「関わった実感」

ーー初めての案件では、どのような開発に携わりましたか？

詳細は伏せますが、複数のデータを結びつけ、最適な結果を導く仕組みを持つサービスに関わっていました。
対象となるのは何十万件という大規模なデータで、検索や表示速度への配慮も求められるプロジェクトです。

担当したのは、バックエンドの実装全般。
外部のフロントエンド担当者と連携しながら、リリースに遅れが出ないよう調整を進めていました。
自分の作業範囲だけで完結しないからこそ、前倒しで動く意識が必要だったと感じています。


ーーこの案件を通して、特に印象に残っていることはありますか？

一番大きかったのは、「自分の関わったものが世の中に出ていく」という実感を得られたことです。
前職では、自分の書いたコードが最終的にどう使われているかを見る機会がほとんどありませんでした。
“納品して終わり”という感覚が強かったと思います。

今回は、完成した成果物を実際に目にすることができて、ちゃんと「関わった」と思える手応えがありました。
手を動かしたことが形になって残る――それが素直にうれしかったですね。

03 技術選定で直面した壁と判断

ーー開発の中で、特に技術的に難しさを感じた場面について聞かせてください。

当初は TypeScript で開発を進めていましたが、扱うデータが増えるにつれてビルド時間が延び、やがて TypeScript のコンパイルツール tsc の実行時にメモリ不足でコンパイルが通らなくなる状況が発生しました。

今回の構成では、コスト削減のために DB を使わず、コード内にデータを保持する形を選択していたため、ファイル全体が大きくなってしまったことが原因です。
DB に分離すれば解消できる問題ではありましたが、JavaScript であれば問題なく動作することもあり、TypeScript からの切り替えを決断しました。

TypeScript を使い続けたい気持ちもありましたが、限られたスケジュールの中では、まず「確実に動くものを用意する」ことを優先すべきだと判断しました。

あわせて、ビルド環境には esbuild を導入。
当時は初めての利用でしたが、コードの最適化や処理速度の面で大きな効果がありました。
この経験は、S2 のバリューである「チャレンジを楽しむ」を体現できた場面のひとつだと感じています。

04 数字で見る改善と工夫の積み重ね

ーーパフォーマンス改善にも取り組まれていたとのことですが、具体的にはどのような対応をされたのでしょうか？

ファイル処理の中に繰り返しが多く、重たくなっている箇所がありました。
まずは処理時間を計測し、どこに負荷が集中しているのかを可視化するところからスタート。
最初は10秒以上かかっていた処理が、最終的には 3 秒以下に。メモリ使用量も320MBから220MBほどまで削減できました。

改善は、一気に進むというより、少しずつ調整を重ねていくような地道な作業です。自分の担当範囲を明確にしながら、今できる範囲でどこまで最適化できるかを考え、取り組んでいました。数字が目に見えて変化すると、やはり手応えを感じます。

05 チームの中でどう動くかを考える

ーープロジェクトを進める中で、スケジュールやチームとの連携面で意識していたことはありますか？

進行上のやりとりでは、フロントエンド側のタスクやリリーススケジュールを確認しながら、自分の作業を前倒しで組み立てるようにしていました。
特に初期段階では、仕様の変更や微調整も多く発生したので、タスクの優先順位を見直しながら対応する必要がありました。

自分の担当だけを見て動くのではなく、相手の作業状況も踏まえたうえで進め方を調整する。以前はあまりできていなかったことですが、今回は自然とそれが意識できていた気がします。
相談のタイミングや情報共有の仕方なども含めて、少しずつ余裕を持って動けるようになってきたと感じました。

また、開発環境や実行手順などは Readme にまとめるようにしていました。最初に記録しておくことで、あとから焦る場面が減りますし、自分自身も助かる。小さなことかもしれませんが、結果的にプロジェクト全体の動きやすさにつながると思っています。

06 次のステップにつながる経験として

ーー今回の案件を通じて得たものや、今後につなげていきたいことを教えてください。

実装量としてはそこまで多くはなかったのですが、S2 での案件がどう進んでいくのか、その全体像を初めて体験できたという点で大きな学びがありました。設計や実装だけでなく、スケジュールの管理や進行上の調整といった部分も含めて、実案件の流れにしっかり向き合えた感覚があります。

前職では、進め方がやや曖昧なプロジェクトが多くて、優先順位を意識すること自体が少なかったんです。
今回、限られた時間の中で「何をどの順で進めるべきか」を自分なりに整理しながら動けたことは、大きな収穫でした。

初めての案件だからこそ、ひとつひとつの判断や対応が今も印象に残っています。
今後もこの経験を土台にしながら、より広い視点で開発やチームの動きに関われるようになっていきたいと思います。