400万人が利用するビジネスSNS
2025年11月にパナソニックを退職し独立。 現在は Homii World(ホスト中心のコミュニティで深くつながるソーシャルアプリ)のフルスタック開発(Flutter / Firebase / Supabase / Next.js)を担当し、AI を開発組織の一員として運用する体制で、PMF 検証フェーズでも週1リリースを11ヶ月継続中。 仕様が固まっていない段階から具体物を出し、関係者とサービスが成立する形まで持っていくことに強みがあります。
PMF検証フェーズのスタートアップで、技術面から市場検証のサイクルを速く回すことに貢献したいと考えています。これまで培った3つの軸を活かしていきたいです。
<担当業務など> フルスタックエンジニアとして、モバイルアプリ・バックエンド・管理画面を横断し、要件定義からリリース運用まで一人称で担当。
Homii World は、ホスト中心のコミュニティを通じて、価値観の合う人と現実世界で深くつながるためのソーシャルアプリ。 AIの普及・リモートワーク定着で、引っ越しや転職などライフステージが変わっても深い人間関係を作れない人がいる——自分に合った人が集まるコミュニティ(場)を見つけにくいことが背景にある。 Homiiはその場を提供し、深いつながりをお手伝いするサービスで、場の質を担保するのが「ホスピタリティを持った人(ホスト)が場を作る」という設計。 ホストのパーソナリティが集まる人の質と空気を決め、「この人に会いに行く」という動機からコミュニティが育つ。 「たくさんの人に会う」より「自分に合う人と深くつながる」を実現するため、Homiiは質の高いゲストマッチングとホスピタリティある案内で出会いをキュレーションする。 現在はニューヨークを中心に、ホスト主催グループイベントを軸としたホスト獲得・ユーザー流入といった「人と繋がるための土台づくり」に注力している段階。 だからこそ、単機能を作るのではなく、人・場・運営・決済・案内がどう連動すれば現実の出会いが成立するかを見ながら設計しています。
<置かれた状況> マッチング型グループディナー・ホスト主催ディナーイベントは、ユーザー・ホスト・運営が連動して初めて成立するサービスだった。レストランをいつ押さえるか、確定連絡はいつまでか、といった運営の動きまで把握せずにシステムを作っても機能しない。 <打ち手> 「開発者であり、サービス運営の責任者でもある」という思考で臨み、FigJamでサービスブループリントを作成して全登場人物とシステムの時系列の動きを可視化した。これによりアプリ・バックエンド・管理画面それぞれの役割と連携ポイントが整理され、必要要件の洗い出しにも繋がり、サービスとして成立する機能実現ができた。 <結果> このブループリントは運営手順書としても機能し、管理画面ハンズオンを踏まえたオペレーションレクチャーにも活用した。リリース後も監査・運営サポート・CRM対応まで一体として担い、自分が設計したサービスの成立に責任を持ち続けている。 <現在への接続> パナソニック時代の見守りサービス開発で培った「システム+全登場人物の時系列把握」という知見が、迷いなく即行動に繋げられた素地になっている。
<置かれた状況> PMF検証フェーズで仕様が毎週変わる中、少人数でいかに速度と品質を両立するかが課題だった。 実装速度だけでなく、意思決定・仕様の整合性・品質担保も追従させる必要があると考えた。 <打ち手> パナソニック時代に経験した「要件→設計→実装」とフェーズで切る進め方を高速回転させる形が、自分に馴染みがあってシームレスに回せると判断。スクラム的な体制を、AIを組織の一員として組み込む形で運用することにした。 自分ひとりで全てを抱えるのではなく、AIを擬似的な開発チームとして扱い、開発リーダー・エンジニア・QA・レビュアーといった役割を分けて運用。 職能ごとの役割定義書に相当するものをAIルール・skillsに落とし込み、タスクごとの職能を明確にした。 たとえば新機能開発では、要件整理 → 設計 → 実装 → テスト観点整理 → リリース前レビューと段階で切り、各段階で自分が判断するチェックポイントを置いている。意思決定レベルも定義し、高レベルは自分に確認を求め、それ以下はAIが判断しレビューでカバーする運用にした。 要件・設計・計画の完了時と実装完了後にチェックポイントを設け、AIが自律的に動きながらも要所で人間の判断を挟む体制を構築。 <結果> この体制により、仕様が常に動くPMF検証フェーズでも週1リリースサイクルを11ヶ月継続。少人数でも速度と品質を両立できる形を確立した。 <現在への接続> この「AIを組織として扱う」アプローチは、PMF検証フェーズに限らず、少人数で広範囲を回す必要がある他のスタートアップ案件にも応用できる体制設計だと考えている。
<置かれた状況> PMF検証フェーズではスピーディに開発からリリースまで持っていきたい一方、モバイルアプリにはストア審査というボトルネックがある。アプリ内容を変更するたびにストア審査を挟む構成だと、容易な変更も実現しにくい。 <打ち手> 機能追加・変更のたびに、変更箇所・頻度を見越して、後からバックエンドからの変更で成立するような形にできるよう、設計・実装・運用を心がけている。 具体的には、いつ・何を出すかといった境界値判断をバックエンド側に寄せ、アプリは状態ベースでUIを出し分ける形にしている。また、公開コンテンツ(写真・動画・説明文など)はデータベースや管理画面から変えられる構成にすることで、アプリ側への依存度を意識的に減らしている。たとえば、イベントの公開状態・受付締切・タイトルや説明文の修正、ホスト掲載の追加/削除など、運用で頻繁に変わる項目は、アプリ側のリリースなしに反映できるようになっている。 <結果> 以前はちょっとした変更でもアプリ審査含めて1〜2日かかっていたものが、即時反映やバックエンドデプロイで数十分後の本番反映で済むようになった。 アプリリリースを挟まずに動かせる範囲も文言・画像・公開状態・表示条件まで広がり、PMF検証フェーズの速いサイクルを技術設計で支えている。 <現在への接続> 「アプリリリースをボトルネックにしない」という設計思想は、Homiiの新機能を作る際の判断軸にもなっており、検証速度を継続的に上げる土台になっている。
◯企画要件が未確定な状況下での Figma 活用による仕様主導(2021〜2022) <置かれた状況> 事業部初の Wi-Fi 対応シーリングライト開発は、発売時期が決まっているにもかかわらず企画要件がまだ固まっていない状態でスタートした。 加えてコロナ禍2年目(2021年3月〜)の原則リモート稼働という制約もあり、Teams での会議を通じてオンラインで仕様を詰めていく必要があった。 <打ち手> 対面なら資料を指差しながら話せるが、オンライン会議では画面や操作のイメージが伝わりにくく認識齟齬が起きやすい。そこで Figma を使い、50〜60点の完成度でも構わないという前提で画面仕様を先に具現化するアプローチをとった。 Figma であれば操作フローや画面遷移をビジュアルとして共有できるため、オンライン会議でも「ここはこう動くべきではないか」「この状態は想定していたか」という具体的な議論が生まれやすかった。 <道中の苦労> もちろん全てが順調だったわけではない。一番苦しかったのは、企画仕様が固まっていないのに、開発側としては前に進めなければならない板挟みだった。 各方面から「仕様はまだか」「これ以上遅れたら困る」と声が上がる中、未確定なものを画面として出す怖さもあった。それでも、何も出さないまま議論を続ける方がプロジェクト全体のリスクが大きいと判断し、小出しでも構わないから画面仕様を出し続け、少しずつでも前に進める形を取り続けた。 <結果> 画面仕様を起点に企画・デザイナー・品質・ファームウェア・CS の各部門と折衝を重ね、曖昧だった仕様が順次確定。 アプリ画面仕様が全体仕様のアンカーになる形で、他コンポーネントの仕様決定も連鎖的に進み、タイトなスケジュールの中で予定通りの商品・アプリ同時リリースを実現。その後もストアレビュー評価を2.0→4.3に改善・維持し、2024年にはPLとして新機能開発を任され、要件が複数回変わる状況でも最終的にリリースまで結びつけた。 <現在への接続> 「具体物を先に出して、それに対するコメントで議論を動かす」というアプローチは、現在の Homii World でのデザイナー協業や、AI への指示出し設計にも通じる原点となっている。
入社1年目から保守リーダーを任され、年間保守計画の策定からリリース実施まで一貫して担当。通信性能の改善やOSバージョン対応など、安定稼働に向けた継続的な品質向上を推進。
・ハードウェア設計・実装 - デリングソフト「Fusion360」を使用した外装・内装試作、3Dプリンター出力 - 基盤回路設計ツール「KiCAD」を用いた基板設計(実用を意識した小型化、省電力化まで検討)
スタッフ稼働状況可視化による人員配置最適化を目的としたIoTデバイスを設計・開発。Fusion360での筐体設計、KiCADでの基板設計、Arduino・Raspberry Piを用いたソフトウェア実装まで一貫して担当。 社員フィードバックを元に携帯性・省電力性を追求し、連続稼働期間を約20日から推定500日へ大幅向上。 大分県のサッカースタジアムでの実証実験では現場スタッフから「従来より的確な指示が出せる」との評価を獲得。 この経験を通じて、ユーザーの声を早期に取り入れる重要性と、自らの手でプロダクトを磨き上げる開発の面白さを実感しました。
製品の構想、企画から設計、開発におけるデザインを主に学ぶ
シンガポールにて寮生活をしながら通う
小学3年生から編入して中学卒業まで在籍
<サービス内容> 遠距離の相手と「お互いが何をしているか見えない」情報の非対称が、距離感・孤独感に直結する——という自身の原体験から開発を始めた位置情報ライフログアプリ。LINEなどの非同期チャットは、忙しくなるほど往復が減り、関係の疎遠化を構造的に加速させる問題がある。「今日何した」が能動的に伝えなくても自然に伝わる仕組みがあれば、チャットの頻度に関係なく繋がっている感覚が維持できるのではないか——という仮説のもと、自らターゲットユーザーとして設計・開発を進めている。 GPS 軌跡を滞在スポットとして自動記録し、プライバシーを担保した形で大切な人と共有できるアプリ。現在 Beta テスト段階、2026年中の App Store 公開予定。 <担当業務など> Flutter を軸に、iOS/Android ネイティブ・Firebase バックエンド・データベースのフルスタック開発の全工程を一人称で担当。デザイナーと協力してアイデア企画とユーザーテストを実施。 <実装内容> iOS / Android それぞれのネイティブ API を用いたバックグラウンド位置情報取得・ジオフェンシングの実装。(iOS: BGTaskScheduler / Swift、Android: Kotlin) Dart ⇔ Swift 双方向通信・Isolate・アプリライフサイクルを考慮した Flutter × Native 統合設計・実装。 認証・プッシュ通知・フレンド申請フローの実装。 Fastlane / GitHub Actions / Xcode Cloud を用いた CI/CD・配信基盤の構築。 <取り組み> ◯技術的注力点 ── Flutter × Native ハイブリッド構成の選択と、その先の難しさ デザイナーが設計したUIをOS差分なく忠実に再現したいという思いから、Flutterを採用した。 UIの共通化はできる一方、バックグラウンド位置情報処理はネイティブの制約から逃れられない。前職のIoTアプリ開発でネイティブ実装の素地があったことも後押しになり、Flutter × Native のハイブリッド構成でこの両立を目指した。OSがいつアプリを止め・再開するかを前提に、取得の開始・停止・復帰処理をすべて洗い出してから設計するアプローチをとった。 ◯プロダクト設計への考え方 ── 「GPS 軌跡」ではなく「体験」を設計する 「GPS の軌跡をそのまま共有しても、相手には伝わらない」という判断から、軌跡を滞在スポットとして変換・記録する体験設計を軸に据えた。 プライバシーへの配慮と「今日何をしていたか自然に伝わる」UX の両立を基準に、データモデル・通知・フレンドとの共有フローを一貫して設計している。その分、バックグラウンドでの位置情報取得の精度と確実性がプロダクト品質を直接左右するため、自ら日々使いながらバックグラウンドロジックの改善を継続している。 ◯Homii への接続 ── 個人開発の追求が本番プロジェクトに活きる LifePathで追求した Flutter 開発の経験は、Homii で2つの形で活きている。 ひとつはデザイン忠実度。 Flutterでデザインを忠実に再現する経験と、パナソニックで培ったFigmaへの感度・UI美意識が合わさり、デザイナーが設計した画面を高い忠実度で実装。「アプリのデザインが良い」という評価を継続的に受けられる要因になっている。 もうひとつはFlutter × Native の連携実装。 LifePathで位置情報処理のために Method Channel を用いた Dart ⇔ Native 双方向通信を構築した知見が、Homii で CRM ツール「Channel Talk」を組み込む際に活きた。当時 Channel Talk は Flutter SDK を提供しておらず、ネイティブ SDK を自前でラップする必要があったが、Method Channel の設計・実装に迷うことなく対応できた。ネイティブ専用機能を Flutter アプリに組み込む際のテンプレートが手元にある状態となり、以降の同種の連携にも展開できる素地となった。
学習欲
山田 菜緒、鈴鹿 優太が+1
3Dプリンター
鈴鹿 優太が+1
はんだ付け
鈴鹿 優太が+1
カメラ
鈴鹿 優太が+1
python(少し)
鈴鹿 優太が+1
企業からスカウトをもらいましょう