fuga について
fuga.
ソフトウェアエンジニアとして 8 年。企業向けサービスと大規模 EC の開発を本業にしながら、個人で iOS アプリを作っています。App Store で 3 本を配信中です。受託・業務委託のご相談も受け付けています。
8 年ほど、企業向けのサービスと大規模な EC サイトの開発を本業にしています。 2026 年に入ってからは、そのかたわらで自分のアプリを作り始めました。 企画から実装、審査の対応、リリース後の運用までを通しでやっています。
受託でお手伝いするときも、同じ進め方をします。仕様を待つのではなく、 何を作るべきかというところから一緒に考えます。できないこと・やらない方がいいと思うことは、 引き受ける前にお伝えします。
本業での経験
会社での仕事.
守秘の都合で社名は伏せますが、どういう性質の仕事をしてきたかを書いています。
AI エージェントの開発
フルスタックエンジニア
EC サービスの内部から呼び出される AI エージェントを作っています。エージェントが使う各種ツールの実装、フロントエンド、そしてプロンプトの設計とチューニングまでを担当しています。
要件が動きやすい領域なので、決まったものを作るより、何を作るべきかを提案しながら進める比重が大きい。担当範囲も縦割りではなく、バックエンドが必要ならそこも書き、他部署との調整も自分で行っています。
- LLM を組み込んだ機能の設計と評価
- プロンプトの設計・チューニング
- 部署をまたぐ調整
Java · Python · iOS · Langfuse · Splunk
EC サイトのフロントエンド開発
フロントエンドエンジニア
国内でも有数の規模を持つ EC サイトで、最も可用性が求められるカートページを担当していました。止まると売上が直接止まる場所で、毎週の負荷試験でパフォーマンスを確認しながら開発する環境です。
カートはサイト全体のほとんどの機能改修に関わるため、常に複数の案件を並行して持っていました。進捗は自分で管理し、企画や PdM と直接やり取りしながら、見積もりの作成・設計・開発・テスト・リリース日の調整までを一貫して担当しています。
- 高トラフィック環境での可用性とパフォーマンス
- 見積もりからリリースまでの一貫した担当
- 複数案件を並行して回す工程管理
TypeScript · React · Java · GraphQL · DDD
受発注電子化・Fintech サービスの開発
バックエンドエンジニア
企業間の受発注を電子化するサービスの開発と保守から始めました。要件を受けて設計・製造・テストまでを行い、不具合の調査と修正も担当しています。システムの一部が古い言語で書かれており、複数の言語をまたいで作業することが多い環境でした。
その後、ファクタリングサービスの新規立ち上げに参加し、リリースまでを経験しました。複数サービスを横断して使える ID の招待機能の開発・保守も担当しています。
- 企業間取引を扱う業務システムの開発と保守
- 既存システムに合流しての機能追加
- 新規サービスの立ち上げからリリースまで
Java · JavaScript · ASP.NET · VB.NET · JSF
社内ハッカソンで 2 年連続の受賞
5 年続けて参加し、直近 2 年でデザイン賞とコーポレート IT 賞をいただきました。チームで実装したアイデアは自分が発端のものが多く、技術的な面白さと同じくらい、触った人がどう感じるかを考えて作っています。
自分の提案を、リリースまで持っていった
ボトムアップで出した施策の提案が通り、実現に必要な人を自分で集めて回すことになりました。実装するエンジニア、LP を作るデザイナー、広報や法務まで、普段は関わりのない相手にひとりずつ話をしに行き、力を借りながら公開まで漕ぎ着けています。個人でできる範囲には限りがあるが、人を巻き込めば越えられる、という手応えを得た経験でした。
使っている技術
道具.
iOS
- Swift
- SwiftUI
- MusicKit
- AVFoundation
- WidgetKit
- CloudKit
Web
- TypeScript
- React
- Next.js (App Router)
- CSS
サーバ・基盤
- Supabase
- Vercel
- PartyKit
- Cloudflare
その他
- App Store 申請・審査対応
- SEO・構造化データ
- アクセシビリティ対応
道具は目的ではないので、必要であれば知らないものも使います。 すでに動いているものに合流する場合は、そこで使われている技術に合わせます。
大事にしていること
AI が書く時代に、残ること.
実装そのものは AI がやります。そのぶん、人の側に残る仕事は この 2 つに絞られてきたと思っています。
出てきたものが妥当かを判断する
AI は実装させる道具ではなく、要件を詰める段階から組む相手として使っています。先に仕様を固めておくほど、一度に任せられる範囲も、返ってくるものの精度も上がるためです。そのうえで、速く書けること自体はもう差になりません。差が出るのは、出てきたものが妥当かどうかを見極められるかどうかです。動いているように見えて、負荷がかかると壊れる。審査で弾かれる。データが壊れたときに戻せない。この手の穴は、実際に運用したことがないと見抜けません。止まると売上が止まる画面を担当し、自分のアプリを出して直してきた経験が、そのまま判断の精度になっています。
ユーザー目線に立って考える
作る側は、どうしても機能の側から物を見ます。この機能があるのだから使えるはずだ、と。ですが使う人はそう考えません。触った瞬間に何をすればいいか分からなければ、機能はあっても無いのと同じです。イントロクイズをサブスク未加入でも遊べるようにしたのも、単語アプリをアプリを開かせない方向に振ったのも、そこからの判断でした。社内のハッカソンでデザイン賞をいただいたのも、技術的な面白さと同じだけ、触った人がどう感じるかを考えていたからだと思っています。