プロローグ

-- まずは簡単に自己紹介をお願いします。

井上慧汰です。株式会社ソワレ東京でCTOをしています。

ソワレ東京では、主にWebアプリケーションの設計・開発をしていますが、
単に「作るだけ」ではなく、
「エンジニアがどれだけ“ユーザーにとっての価値だけ”に集中できるか」
みたいなところを、日々考えています。

今日は、ソワレ東京がどんな技術スタックで、どんな思想で開発をしていて、
そこで働くエンジニアにはどんな環境があるのか、お話しできればと思います。

1. 技術スタックの選定理由

-- 現在のメインスタック（Next.js / TypeScript / Supabase / Vercel など）を選定した一番の理由は何でしょう？

一言で言うと、知る限り一番イケてるからです。

前提として、Webアプリでは、バックエンドロジックの複雑性よりも、

• イケてるUI
• イケてるUX

の方がユーザー価値であると考えています。
だからこそ、まずフロントエンドが書きやすいか？を重要視しています。
そのうえで、

• バックエンド含めフルスタックで開発できる
• チームの経験とも相性がいい

という条件で考えると、候補は Next.js や Nuxt.js などが候補に上がり、
今のメンバー構成や情勢も含めて、Next.js が一番しっくりきたという判断です。

インフラ側では、

• Supabase：RDBが使えて、認証認可機能やストレージも揃ったオールインワンでイケてるやつ
• Vercel：Next.js との相性が非常に良く、デプロイも含めて開発体験が抜群

という理由で採用しています。
まとめると、

「本質的なことだけに頭を使える構成であり続けること」

これが、技術選定のいちばん大きな軸です。

-- 「どこでも通用する人材にしたい」と仰っていましたが、古い技術ではなくモダン技術を選ぶ意図は？

この質問って、要するに

古い技術のほうが案件多いし、そっちをやってた方が『どこでも通用する』んじゃないの？

という指摘だと思います。僕の回答は下記です。

新しい技術には新しい思想や哲学、そして古い技術での痛みを踏まえたベストプラクティスが宿っており、モダンなものから学んだ方が結果的にどこでも通用する。

もし、古い技術がイケているならば、新しい技術は生まれません。
新しい技術には、

• 古い技術で解決できなかった課題を解決している
• 「ここイケてないよね」という反省が反映されている
• 現場感のあるベストプラクティスが設計に織り込まれている

という背景があります。
つまり、技術には思想が宿っているという話です。
モダンな技術を習得すると、

• 古い技術を触ったときに「どこがイケていないのか」がわかる
• 「Next.js だとこう書けるけど、この技術スタックではどう実現する？」という発想ができる

という、環境非依存なスキルが身についていきます。
これはまさに「どこでも通用する人材」の土台だと思っています。

もう一つ大事だと思っているのは、

「その技術イケてないのでやめませんか？」と言えること

です。
古い技術を引きずると、

• 技術的な制約でやりたいことがどんどんできなくなる
• 開発コストだけ増えて、ユーザー価値が増えない

というのは良くある話です。

今の時代、技術的に「できないこと」などほとんどありません。
そのため、

• モダンな技術で思想やベストプラクティスを学ぶ
• そのうえで古い技術にも対応できる
• 必要に応じて「やめよう」と提案できる

こういうエンジニアが、本当に「どこでも通用するプロ」だと考えています。

-- インフラ周りの技術（AWS / Docker / Firebase など）はどのように使い分けていますか？こだわりがあれば教えてください。

正直に言うと、インフラは「何でもいい」と思っています。
理由は、

インフラ構築でどれだけ複雑なことができるかより、エンジニアがインフラのことを考えずにどれだけユーザーにとっての価値だけ考えられるかの方が重要

だと考えているからです。

ユーザーにとっての価値以外に、エンジニアの脳のリソースを使うのは基本的に無駄であると考えています。
そういう意味で、

• Vercel
• Supabase

をよく使っています。
理由は「ほとんど考えなくていいから」です。

• Vercel：インフラCI/CD系、クリック1回でいい感じに構成してくれる
• Supabase：RDB 、認証認可、ストレージ系、クリック1回でいい感じに構成してくれる

みたいな感じで、面倒なことをサービス側に押し付けられるのが大きいです。

ちなみにローカル開発でも、Dockerはあまり使いません。
ツールが増えれば増えるほど、「考えること」が増えて開発体験が落ちるからです。

• Next.js は `pnpm dev` でフロントもバックも立ち上がる
• Supabase も `supabase start` で必要なものが全部立ち上がる

それで十分、という考えです。
それでもどうしても対応しきれない、本当に複雑な要件が出てきたときに初めて、
AWS など、より複雑な選択肢を選べばいい。
「基本は開発体験の高いサービスでやる。それでもダメならAWS」
この優先順位で考えています。

2. 品質へのこだわり

-- CTOとして、どのようなコードを「美しい」と感じますか？

一言で言うと、「エンジニアの脳リソースを奪わないコード」です。
細かい実装に引っ張られず、高い抽象度でシンプルに「何をしているか」が追える。
そういうコードが、美しいと思っています。
そのためにはまず、

• 車輪の再発明をしない
• DRY原則に従う
• すでにあるベストプラクティスをちゃんと取り入れる

といった、基本に忠実であることが前提になります。

ここまで思想ばっかり書いてきたので、具体的な例を出しましょう。
よくある「アンチパターン」が、

• useEffect でレンダリング時に API からデータ取得
• useState に詰めて
• その State 変数で画面を表示して
• 何かあったら同じ API をまた叩く制御を自前で書く

みたいな実装です。

これをカスタムフックにまとめて

export function useUser() {
  const [user, setUser] = useState<any>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<unknown>(null);

  const fetchUser = useCallback(async () => {
    try {
      setLoading(true);

      const res = await fetch("/api/user");
      if (!res.ok) throw new Error("Failed to fetch user");

      const data = await res.json();
      setUser(data.user);
      setError(null);
    } catch (err) {
      setError(err);
    } finally {
      setLoading(false);
    }
  }, []);

  // 初回レンダリング時に一度フェッチ
  useEffect(() => {
    fetchUser();
  }, [fetchUser]);

  return {
    user,
    loading,
    error,
  };
}

// 画面側
const { user, loading, error } = useUser();

のようにする感じ、あるあるですよね。
この実装、全部自前でやってる時点でイケてないと考えています。
リソースの数だけこんなのを量産するのは本質的にイケていません。

代わりに、SWR のようなライブラリを使えば、

• フェッチタイミングの制御
• キャッシュ
• 通信の最適化

などを、いい感じに丸ごと任せられます。

const fetcher = async (url: string) => {
  const res = await fetch(url);

  if (!res.ok) {
    throw new Error(`Failed to fetch: ${res.status}`);
  }

  return res.json();
};


// 画面側
const { data, error, isLoading, mutate } = useSWR("/api/user", fetcher);

これで終わりです。

どれだけ業界標準であろうとイケてないものはイケてないです。 State 管理や Effect でコード量を増やすと、そこに脳リソースを持っていかれます。
すでに SWR という良い車輪があるなら使いましょう。

「このアプリ、購読できるのに解約できなくね？」
「プロフィール画面への動線わかりづらくね」

みたいな致命的なUXの問題って意外と気付けないものだったりするのですが、それは余計なことに脳を取られていることにも起因するでしょう。

なので、

「考えないで済むコード」にして、「UXの方に頭を使おう」

というのが、僕のいう「美しいコード」のイメージです。

-- コードレビューでは、具体的にどのような点を見ていますか？

実は、ソワレ東京には「いわゆるコードレビュー文化」がありません。
PRを出して、レビュワーが1行ずつコメント、ということは基本していません。

理由はいくつかあります。

まず前提として、今の時代、コードは基本AIに書かせます。
AIが生成するコードは、よほどのことがない限りやばい実装にはなりません。
ある程度きれいで、ベストプラクティスも踏まえてくれます。
そこに対して人間が目で追って、
インデントやカンマの位置をチェックするのは、あまり本質的ではないと思っています。

その代わりに頻繁に行っているのが、ペアプロです。
ペアプロでよく指摘するのは例えば：

• 操作が遅い（無駄なクリックが多い／ショートカットを使っていない）
• そのタスクはAIに聞くより公式ドキュメントを読んだ方がいい
• AIへのプロンプトの書き方が、意図を正しく伝えられていない

といった「コードの中身」よりもっと上位レイヤーです。

つまり、

人間に対するレビュー

がメインです。
コードの品質自体は、

• Linter
• Formatter
• 型チェック
• Git hooks
• 結合テスト等

で守っています。
規約に従わないコードは、そもそもコミットできないようにしています。
なので、テストがすべて通っていれば「もうリリースしていいよね」という運用です。

また、コードレビューのデメリットとして大きいのがコンフリクトです。
人力レビューを前提にするとPRが大きくなりがちで、コンフリクトも巨大化します。
ソワレ東京ではそもそもコンフリクトが起きない、起きても極小という設計にしているので、そういう意味でも「毎回がっつりコードレビュー」は不要だと考えています。

3. AIとツールの活用術

-- FigmaとAIを連携した「デザインからコードへの変換フロー」によって、開発工数はどれくらい削減されましたか？

• デザイナーがFigmaで作った画面を
• ほぼそのままのクオリティで
• すぐにブラウザで触れる状態にする

という形で、UIを「触れる状態」にするという意味で言えば、95％ほど削減できました。
今まで1週間かかっていたような作業が、30分以内で終わるようになりました。

-- 以前はどんなところに時間がかかっていたのでしょう？

これは結構共感してもらえると思うのですが、まずAIが出てくる前は「見た目の微調整」にめちゃくちゃ時間がかかっていたんですよね。

• 角丸の半径が1px違う
• 余白がちょっとだけズレている
• 共通コンポーネントにしたいけど、画面ごとに微妙にサイズが違う

こういうのを1個ずつ直していく時間は何の生産もしない不毛な時間です。
なぜなら、デザイナーが作ったものをただ再現しているだけの時間だからです。
新しい価値を生んでいるわけでもないし、頭もそこまで使っていません。

また、AIが出てきてからも、たとえばスクショを渡しても、

• 少し違うデザインになってしまう
• ボタンが真っ黒になっちゃう
• 細かいところは人間が手で調整する

といった形で、結局微調整に時間を取られたりしていました。
今は、MCPサーバーを導入したことで、

• ほぼそのままの見た目で再現できる
• 微調整にかかっていた時間がほぼゼロになった

ので、「脳を使わない作業」を大幅に削減できました。
浮いた時間を、

• ロジック設計
• UXの細部
• ビジネス的な打ち手

に使えるようになったのが、いちばん大きなメリットです。

-- 社内で流行っている、Cursor（AIエディタ）の便利な使い方はありますか？

エンジニアはもう誰しもAIツールを活用しているような気がしますが、他社であまり使っていない方法で僕たちがやっている例を考えてみます。

ソワレ東京の受託案件はリプレイス案件が多いです。
オフショアで作ったアプリがあるが、イケていないのでリプレイスしたい、といういわゆる Phase1 から Phase2 への移管という案件が多いです。

この時、

1. 既存システムのリポジトリ
2. 新システムのリポジトリ

この2つを1つの親フォルダの中にまとめて、丸ごと Cursor で開くやり方です。

その状態でAIに対して、

この既存実装の中にある◯◯機能を、新しい Next.js プロジェクトに移植してほしい

とお願いすると、かなり高い精度で移植してくれます。

特に、

• Googleスプレッドシート連携
• Googleドライブの権限周り
• 組織ポリシーやサービスアカウント周り

のような、1から構築し直すと煩雑なロジックでも、元の実装がちゃんと動いているなら、それを理解したうえで Next.js 用に書き換えてくれるので、リプレイスが一気に楽になります。

-- 「AI使い放題」の環境によって、チームの開発スピードや学習速度はどう変わりましたか？

これはつまり生産性の変化を問われていると思いますが、ぶっちゃけソワレでAI使い放題ではなかった時期というのがなくてですね、最初からAI使い放題でした。

なので、

AIがなかった頃と比べて何倍になりました

みたいな比較はできないんですよね。
ただ、具体例としては、

開発に2年かけていたと聞いていたプロジェクトを、Next.jsで丸ごとリプレイスするのに2ヶ月で完了できた

という事例があります。
もちろん、これはAIだけの力ではなく、

• モダンな技術スタック
• チームの習熟度

なども寄与していますが、それでも AI 駆動じゃなかったらこのスピードは絶対に出せなかったと思います。

4. 元請け × アジャイルの魅力

-- 100％元請けだからこそできた「技術的な提案」や「仕様変更への対応」のエピソードはありますか？

大前提として、ソワレのクライアントワークは

• 開発スタイル：アジャイル
• 契約形態：準委任

が基本です。

クライアントは、エンジニアではありません。
一方で、僕らはエンジニアです。
つまり、クライアントにとって僕らは「開発のプロ」です。

なので、コミュニケーションとしては、

「要件を一方的に受け取る」のではなく、「相談ベースで一緒に考える」

というスタイルになります。コンサルっぽい立ち回りになります。
クライアントから、

こういう機能が欲しい

と相談を受けたとき、僕らはプロとして

• 「その機能が欲しいのって、目的はなんでしょう？」
• 「うーん、多分こういう運用や代替案の方がいいような気がします」
• 「理由は◯◯で、ユーザーにとって価値が低いからです」

という提案ができます。
この手の話は、「はい、やります」と言って作ったほうが、会話も楽だしお金ももらえます。しかし、それをやると、

• 画面がごちゃつき、UXが悪くなる
• 誰も使わない機能が生まれる

という話になります（そしてウォーターフォールの現場で幾度となく見てきました）。
要するに考え方として、

• 99％のユーザーには不要
• 1％の特殊ケースだけで必要

みたいなものまでUIに載せてしまうと、

• 開発工数は膨らむ
• ほとんど誰も触らないボタンが画面に残る
• そのせいでメイン導線のUXが落ちる

ということが起きます。
この手の話では、僕らは、

それはシステム化するより、運用でカバーしたほうが全体最適では？

と、素直に提案します。
これが、元請け × 準委任 × プロとして並走するスタイルのいちばんの強みだと思っています。

結果として、

• クライアント → 無駄な開発工数が減ってうれしい
• エンジニアやPM → 本当に価値のある機能に集中できてモチベが上がる
• エンドユーザー → シンプルで使いやすいUIになってうれしい

という、三方よしの状態をつくりやすいです。

やっぱお客さんがテンション上がって喜んでくれると、やる気出ますね。
仕事が楽しくなります。

5. 未来の仲間へ

-- 「技術が好きだけど、今の環境ではモダンな技術が試せない」というエンジニアに、ソワレ東京なら何を提供できますか？

ソワレ東京は、

新しくて優れた技術はどんどん試してベストプラクティスを更新していく

というのをカルチャーとして大事にしています。
直近でいうと、

• ずっと Prisma を使ってきたけど、Partial Index 使いたいから、Drizzle を試してみる
• ESLint + Prettier を滅ぼして Biome に切り替えてみる
• SendGrid から Resend を導入して比較してみる

みたいなことをやっています。
これらは導入したばっかりなので、今後レギュラー入りかクビか判断していきます。

プロジェクトもどんどん立ち上がるので、
「新しい技術を本番環境で試すチャンス」が継続的にある状態です。

• 今慣れてるものより優れたものがあるなら試したい
• ベストプラクティスをアップデートし続けたい

という人で組織が構成されています。

-- 最後に、この記事を読んでいる方にメッセージをお願いします。

• ちゃんとユーザー価値も見たい
• がっつりAI使いたい
• ベスプラを更新したい

こういう人とは、きっと相性が良いと思います。
ソワレ東京は、

• 100％元請け × アジャイル
• モダンな技術スタック
• AI前提の開発スタイル
• ベストプラクティスを更新し続ける文化

という環境です。

少しでも気になった方は、ぜひカジュアルにお話ししましょう。
ご応募、お待ちしています。