ID:82834さん

## ■プロジェクト概要 知人の社長から依頼を受けて、双眼鏡ECサイトの新規立ち上げをエンジニア1名体制で担当しました。 技術選定・要件定義・UI/UX設計・実装・インフラ・SEO・広告運用・分析基盤の構築まで、一気通貫でスコープに含めています。 1週間スプリントのアジャイル開発で継続的に改善を回しました。 意識したのは、作って納品で終わらせず、売上に効く施策をエンジニアリングで解くことです。 初期売上0円から、第二期で売上160万円まで伸ばしています。 ## ■チーム構成 エンジニア1名、ビジネス側1名（社長）の2名体制です。 担当ロールはPM、要件定義、UI/UXデザイン、フロントエンド、バックエンド、インフラ、SEO、広告運用までカバーしています。 小さな体制だからこそ、意思決定から実装までのリードタイムを短く保つことを重視しました。 ## ■使用技術 フロントエンドはNext.js（App Router / SSG）、TypeScript、Tailwind CSS。ヘッドレスCMSにmicroCMS。 配信・インフラはCloudflare PagesとCloudflare R2。 データ基盤にBigQueryとCloud Scheduler。 分析基盤のバックエンドはGo + Cloud Run Jobs。 計測・API連携はGA4、Google Ads API、Google Search Console API。CI/CDはGitHub Actionsです。 ## ■SEO集客基盤の構築（Next.js SSG × microCMS） **【課題】** 立ち上げ直後は売上0円で、広告費も潤沢には使えません。 広告依存を早めに脱するにはSEO流入を育てる必要があり、そのためには非エンジニアである社長が 自分のタイミングで記事を公開できる環境が不可欠でした。 ただし、CMSを普通に繋ぐだけでは記事公開のたびにエンジニアのビルド作業が発生し 量産ペースに追いつきません。 画像の多いECではCore Web Vitalsが劣化しやすくSEO順位にも直結する一方 立ち上げ期にSSRサーバーを常時稼働させるとインフラコストが重くのしかかります。 これらの制約を同時に満たす構成が必要でした。 **【解決策】** Next.jsをSSGで構築し、商品ページ・記事ページともにビルド時に静的化してCloudflareのエッジから配信。 microCMSのWebhookをGitHub Actionsに繋ぎ、社長が記事を公開した瞬間にCIが走って自動デプロイされる仕組みを組みました。画像はCloudflare R2とnext/imageで最適化し、LCP 2.5秒以内を維持。 microCMSのスキーマはTypeScriptの型として自動生成する仕組みを入れ、コンテンツモデル変更時の修正漏れを防いでいます。 **【結果】** 記事公開のリードタイムが「エンジニア待ち数日」から投稿即日に短縮されました。SEO流入が安定したことで広告依存度も下がり、第二期売上160万円の到達に寄与しています。 ## ■広告・分析データパイプラインと内製ダッシュボード（Go × BigQuery × Cloud Run） **【課題】** 売上が立ち始めると、運用側がボトルネックになりました。 各広告媒体の管理画面を毎朝巡回して手でレポートを作っており、広告投資の判断が1日以上遅れていたためです。 Looker Studioなどの既製BIも検討しましたが、SKU別ROASや広告費/粗利、 在庫回転率といったEC固有のKPIを柔軟に扱うには不向きでした。 かといって、定期実行のためだけに常時稼働のサーバーを立てるのはコスト的に割に合いません。 **【解決策】** ETLはGoで書き、Cloud Run Jobs上で動かしてCloud Schedulerから日次で叩く構成にしました。 Cloud Run Jobsを選んだ理由は、実行時以外は課金がほぼ発生しないこと、起動が速いこと、 広告APIを複数並列で叩く用途にGoの並列処理性能が噛み合うことです。 集約先はBigQueryで、SKU×日付×媒体の粒度でスター型のデータマートを構築し、 事前集計テーブルを挟んでダッシュボード側のクエリ費用を抑えています。 ダッシュボード本体はNext.js（App Router）とRechartsで内製。 BigQueryに直接繋がず、事前集計テーブルをAPI経由で返す設計にして 表示速度とクエリコストのバランスを取りました。 広告費の異常消化やCVRの急落はSlack通知で検知し、閾値はコード側でバージョン管理しています。 **【結果】** 毎朝1時間ほどかかっていた広告レポート業務がゼロになりました。 ROASが悪化したSKUを即日で検知し、同日中に入札調整まで回せる運用を確立。 データに基づく予算配分が可能になり、広告効率も改善しています。 ## ■補足 守秘義務の都合上、具体的な広告費のレンジやSKU数などは記載していません。面談時に可能な範囲で共有しますので、気になる点があればご質問ください。

子ども支援領域のスマホアプリ開発に、5名体制のチームでアジャイル開発を実施。 週1稼働で1年5ヶ月にわたりプロジェクトを支援した。 **・2023年8月〜12月(AD / PG)：技術相談と実装** Flutter + Firebaseを基盤としたアプリの要件定義・基本設計・詳細設計・実装を担当。 子ども支援領域特有のユーザー要件を踏まえた機能要件を整理した。 **・2024年1月〜12月(TAD / PG)：技術顧問にポジションシフト** チーム全体の技術選定・アーキテクチャ方針のリードに加えて、実装も継続担当。 週1稼働の制約の中で、非同期でのコードレビューと同期MTGでの設計レビューを組み合わせ、開発生産性と品質を担保した。 **主な担当業務：** ・Firestoreデータモデル設計、Cloud Functionsによる処理設計、Cloud Storageでのファイル管理設計 ・Flutter/Dartでの画面・ロジック実装、Firebase各サービスを活用したバックエンド構築 ・チームメンバーからの技術相談対応、設計レビュー、コードレビュー ・アーキテクチャ方針の提案と関係者への合意形成 **特に取り組んだこと：** **1．元エンジニアのクライアントとの技術協議** クライアント様自身がエンジニア経験者であったため「こんな機能を作りたい」という要望に対して 単なるヒアリングにとどまらず、実装方法を技術レベルで具体的に協議。 データ構造・ライブラリ選定・実装アプローチを一緒に検討することで 認識齟齬を生まずに最短ルートで要件を固めることができた。 **2．週1稼働でのセルフマネジメント** 週1回のMTGで細かいタスクの進捗を確認・分解し、次の1週間で進める作業を自己管理で遂行。 リリースというゴールから逆算して、限られた稼働時間内で優先順位を判断しながら開発を進めた。 **3．アーキテクチャの提案とリード** Flutter + Firebaseの構成でFirestoreのデータ設計・Cloud Functionsでの処理設計・認証設計を主導し チームメンバーへの設計レビュー/コードレビューを通じて方針を共有した。

## BLE通信の安定化とバックグラウンド制御 **【課題】** 歩行解析アプリでは、BLEセンサーからのデータを測定中に途切れなく受信し続ける必要があります。 ただしiOS/iPadOS/watchOS/Androidそれぞれでバックグラウンド実行の制約が異なり 標準的な実装のままではアプリが非アクティブになった瞬間に通信が途切れ、歩行データが欠損するリスクがありました。 医療・スポーツ現場で使われるプロダクトである以上、測定中のデータ欠損は許されませんでした。 **【解決策】** OSごとのバックグラウンド制御要件を個別に調査し、Android側はflutter_background_serviceによる前景サービス化 iOS側はCore Bluetoothのバックグラウンドモードを活用する形で、OSごとに最適な制御を実装しました。 加えて、通信断が発生した際のリトライ機構を独自に設計し、セッション単位でのデータ整合性を担保。 Flutter Pluginとしてネイティブ実装（Swift / Kotlin）をラップし、アプリ側からは統一APIで扱える構造にしています。 **【結果】** 医療・スポーツ現場の実運用に耐えうる安定したBLE通信基盤を構築できました。 歩行データ欠損に起因する測定やり直しが大幅に減り、プロダクトの信頼性向上に寄与しています。 ## チーム未経験領域のR&Dと開発推進 **【課題】** プロダクトの拡張に伴い、チームとして経験のない技術領域（独自SDKの開発、OIDCによる認証基盤の刷新など）への対応が 複数発生しました。 こうした領域は事前知識がないままタスク化すると見積りが崩れやすく、着手段階で詰まってチーム全体の進捗を止めるリスクがありました。 **【解決策】** 未経験領域のタスクは率先して引き取り、設計とPoCを先行して進めました。 調査過程で得た知見や踏んだ地雷はNotion上で検証プロセスとして型化し 後続メンバーが同じ領域に入る際に再利用できる形でチームに還元しています。 加えて、AIコーディング（Cursor、Claude Code、Figma MCP）を検証フェーズから積極的に活用し PoCのサイクルを高速化しました。 **【結果】** 未経験領域が原因で開発が止まることがなくなり、チーム全体の開発速度が上がりました。 自走力の高さはリードエンジニアからも「タスク消化の速さと的確さ」として評価いただき 継続的に信頼を得られる関係を築けています。

マッチング機能を核としたスマホアプリの開発に、アドバイザー兼エンジニアとして参画。 Flutter + TypeScript(Cloud Functions)+ Firebaseの構成で新規開発し、4名体制のチームでアジャイル開発を実施。 月40時間稼働で支援した。 **担当した役割：** **・ADとして** 技術選定・検証の実施、アーキテクチャ設計 クライアントとの技術協議、実装方針のリード 課題と目的の整理、発散した議論のとりまとめ 技術観点での今後のアーキテクチャ計画の立案 顧客・ステークホルダーとの交渉 **・PGとして** Flutter/DartでのUI・ロジック実装 Firestoreを活用したデータモデル設計 TypeScript + Cloud Functionsによるサーバーサイド処理の実装 Firebase Authenticationによる認証設計 **特に取り組んだこと：** **1．マッチングロジックのサーバーサイド設計** マッチング処理はクライアント側ではなくCloud Functions側で行うアーキテクチャを採用し データの一貫性とセキュリティを担保。 TypeScriptで型安全に実装することで、ロジックの堅牢性を確保した。 **2．自社エンジニアを活用したチーム組成** BestRise LLCとしてエンジニア2名を雇用・育成し、プロジェクトに配置。 採用・教育・予算管理まで担当し、クライアントへ安定した開発体制を提供した。 **3．月40時間稼働でのリード役** 限られた稼働時間の中で、自社エンジニアとの役割分担とコードレビューを通じて、開発の品質と速度を両立させた。

介護領域に特化した歩行解析スマホアプリの開発に、アドバイザー / プロジェクトマネージャー / エンジニアの3役を兼任して参画。 Bluetoothセンサーと連携して歩行データを取得・解析するアプリを、Flutter + Kotlin + Firebaseの構成で新規開発した。 月80時間稼働、4名体制のチームでアジャイル開発を実施。 **担当した役割：** **・ADとして** BLEセンサー連携の技術選定・検証の実施 アーキテクチャ設計およびクライアントへの方針提案 課題と目的の整理、発散した議論のとりまとめ 介護特化という業界特性を踏まえた機能要件の整理 **・PjMとして** WBS・機能一覧の作成、工数見積り、マイルストーン決定 進捗管理・工数管理・スケジュール調整 チーム内外のファシリテーション、ステークホルダー交渉 自社で雇用した2名のエンジニアの教育・進捗フォロー・予算管理 **・PGとして** FlutterでのUI/ロジック実装、Firestore設計、Cloud Functions処理設計 KotlinによるAndroid側のBLE通信モジュール実装 BLEセンサーとの結合テスト設計・実施 **特に取り組んだこと：** **1．BLEセンサー連携の技術実現** Flutter単体では対応しきれないBLE通信処理をKotlinでネイティブ実装し プラットフォームチャネル経由でアプリに組み込み。通信の安定性・バッテリー消費・センサー切断時のリカバリまで含めて設計・実装した。 **2．介護特化プロダクトとしての価値設計** 歩行解析データを介護現場で実用的に使えるよう、利用者(高齢者)および介護職員双方の 利用シーンを踏まえた画面設計・通知設計を行った。 **3．自社エンジニアを活用したチーム組成** BestRise LLCとしてエンジニア2名を雇用し、プロジェクトに配置。 採用・教育・予算管理まで一気通貫で担当し、クライアントへ安定した開発体制を提供した。

販売管理業務を扱うWebシステムの開発に、アドバイザー兼エンジニアとして参画。 2名体制のチームでアジャイル開発を実施し、月40時間の稼働で支援した。 **・ADとして** 技術選定・アーキテクチャの方針提案 クライアントとの技術協議、実装方針のリード 課題と目的の整理、議論のとりまとめ 技術観点での今後のアーキテクチャ計画の立案 **・PGとして** FlutterWebでのフロントエンド画面・業務ロジック実装 Firestoreのデータモデル設計、Cloud Functionsでの処理設計 動作検証とバグ修正 **特に取り組んだこと：** FlutterWebを活用した業務システム開発:Flutterで培った開発資産を活かしつつ PCブラウザでの業務操作に最適化した画面を構築。 月40時間の制約下でのセルフマネジメント:限られた稼働時間内で優先順位を判断し 2名という少人数体制でも開発が停滞しないよう、タスク分解・自己進捗管理を徹底した。

## 担当業務 Flutter黎明期に医療系スタートアップのアプリ開発に未経験から参画し Firebaseを活用したアーキテクチャの構築と実装を担当しました。 ## 新技術への適応と実装水準の確立 **【課題】** 参画時点ではFlutterが登場して間もない時期で 日本語はもちろん英語の技術情報も乏しい状況でした。 書籍や体系化されたノウハウがほぼ存在せず、Qiitaや個人ブログの断片的な情報を拾い集めても、実プロダクトに耐える設計判断までは落とし込めません。 未経験での参画だったこともあり、短期間で戦力化するための学習経路を自分で設計する必要がありました。 **【解決策】** 公式ドキュメントの解読を軸に据え、一次情報からアーキテクチャの意図を読み解くことを習慣化しました。 並行して、社外のFlutterコミュニティでの共同開発リーダー、受託開発、個人開発を複数走らせ、異なる要件のプロダクトを同時に触ることでベストプラクティスを実践ベースで開拓。 業務外の時間も投下して、公式の設計思想と現場で通用する実装パターンを突き合わせながら検証しました。 **【結果】** 参画から半年で、アジャイル開発（1週間スプリント）の主戦力としてタスクを完遂できる水準に到達しました。 ## Firebaseアーキテクチャの設計と安定稼働への貢献 **【課題】** プロダクトはFirebase（Authentication、Firestore、Functions）をフル活用する構成で Dartもチームとしては新規導入の言語でした。 医療系ということで稼働の安定性が強く求められる一方、参照できる先行事例が少なく 設計判断の妥当性をその場で検証しながら進める必要がありました。 **【解決策】** 既存のJava経験を活かしてDartの型システムと設計思想を早期に吸収し Firestoreのデータモデリング・Functionsの責務分離・クライアント側の状態管理の切り分けを設計に落とし込みました。 情報が揃っていない中でも、公式ドキュメントから仕様を紐解き、実装と検証を回しながら判断を固めていくスタイルを確立しています。 **【結果】** プロダクトの実装と安定稼働に貢献できました。 このプロジェクトで身に付けた「情報がない中で仕様を紐解き 実装に落とし込む力」が、その後のBLE連携やネイティブ領域における高いキャッチアップ力の原点となっています。

Lancers経由で個人受託した、自動車関連SNSアプリのプラットフォームリプレイス案件。 既存のSwift製iOSアプリをFlutterへ移行する工程を担当し、1人体制でウォーターフォール開発にて完遂した。 **使用技術：** 移行元:Swift(既存iOSアプリ) 移行先:Flutter バックエンド:Firebase(既存構成を踏襲) **担当業務：** 既存Swiftアプリの仕様読解と、Flutterでの同等機能の実装 既存Firebase構成を維持したまま、モバイル側のみを置き換える移植作業 製造および試験フェーズを担当 **特に取り組んだこと：** **1．システムリプレイス経験** 本格的リプレイス案件。既存機能と新実装の挙動を一致させるための仕様読解と、移行後の動作検証を徹底した。 **2．ウォーターフォール開発での遂行** アジャイル開発が主流のキャリアの中で、要件と納期が明確に固定されたウォーターフォール型の受託案件を経験。開発プロセスの幅を広げる機会となった。 **3． Lancers経由の直接受託** クライアントと直接やり取りする受託案件を1人で完遂。 要件の把握・見積もり・納品・検収まで一貫して対応した。

損害保険会社向け業務システムの新規開発プロジェクトに、SE(システムエンジニア)として上流工程を担当。 Java / Oracle / H2 の技術スタックで、20名体制のウォーターフォール開発に参画した。 **使用技術：** 言語:Java データベース:Oracle、H2 **担当業務：** 要件定義:ステークホルダーからの業務要件ヒアリング、課題・目的の整理 基本設計 / 詳細設計:設計書の作成、データベース設計、設計レビュー 試験設計:テスト仕様書作成、テスト設計 **特に取り組んだこと：** **1．映像AP(アプリケーション)の経験を活かした要件整理** 前職の映像AP開発で培った、仕様の複雑さと関係者の多さを整理する力を活かし 損保業務の複雑な要件を論理構造に落とし込んで設計書に反映した。 **2．金融系・大規模チームでの上流工程経験** 20名体制のエンタープライズ案件において 損保業界の業務知識のキャッチアップとウォーターフォール型開発プロセスでの成果物作成を実践。 設計書・テスト仕様書・Q&Aシートなど、金融系案件で求められる文書品質に対応した。

電力システムのデータ分析を目的としたツール開発プロジェクトに、SE(システムエンジニア)として参画。 7名体制のウォーターフォール開発で、VBAでのAPI連携ツール作成とJava/Spring/Hibernateでの WEB統計ツール実装の2種類の開発を担当した。 **使用技術：** 言語 / フレームワーク：Java、Spring、Hibernate、VBA データベース：Oracle、PostgreSQL **担当業務：** ・VBAによるAPI連携・DB連携ツールの設計・実装(単独担当) ・Java/Spring/HibernateによるWEB統計ツールの実装(詳細設計・製造・試験) ・PostgreSQL / Oracleを用いたデータ分析処理の実装 **特に取り組んだこと：** 1．業界参入から半年の時点で、未経験のVBAを独学でキャッチアップし、DB連携ツールを単独で完成させた。 前述のJava案件で身につけた「未知の技術を短期間で身につける力」を、VBAという新たな領域でも発揮した。 2．VBAでのデスクトップツールと、Java/Spring/HibernateでのWEBシステムという 性格の異なる2つの開発を並行担当。技術領域を横断する柔軟性を身につけた。

Java/Spring/Struts2/Oracle構成のWEBシステムの開発・保守・エンハンス対応を担当。 10名体制のウォーターフォール開発で、View層からDB層までの全レイヤーにわたる製造・試験フェーズを経験した。 IT業界参入時の案件であり、エンジニアとしてのキャリアの出発点となる。 **使用技術：** 言語 / フレームワーク：Java、Spring、Struts2 データベース：Oracle **担当業務：** 既存システムへの機能追加・改修対応(エンハンス開発) View(JSP)〜ビジネスロジック(Spring/Struts2)〜DB(Oracle)の全レイヤー実装 試験(ユニット / 結合 / 回帰)の実施 **特に取り組んだこと：** 未経験のSpring/Struts2/Oracle環境で、参画1ヶ月で戦力になるよう努めた。 IT業界参入時、実務未経験のSpring/Struts2/iBATIS/SQL環境に参画。 既存コードの読解と動作確認を徹底することで、1ヶ月で戦力として稼働できる水準に到達した。 この時に身につけた「既存コードから仕様と設計意図を読み解く力」は その後の損保案件での上流工程担当、および医療系アプリでのFlutter黎明期への飛び込みにも直結している。