ID:85221さん

## 概要 ASPに計上される成果データを、Google広告・Yahoo!広告・Meta広告・Microsoft広告などへ オフラインコンバージョンとして自動連携するSaaSです（利用者800名超）。 立ち上げ時からシステム担当として参画し、5年半以上継続しています。 ## 体制と役割 - 事業側1名・技術側1名の2名体制で、技術側を単独で担当 - 事業側とプロダクト構想・開発の優先度をすり合わせ、仕様・工数・技術的な制約を説明したうえで合意する進め方を継続 - 要件定義から設計・実装・テスト・リリース・運用保守までの全工程を担当 - リポジトリ全5,788コミットのうち5,358コミット（92.6%）を担当 ## 主な機能 - 100社超のASPとの成果データ連携（CSV取込・ポイントバック） - Google Ads API v17.0／Yahoo!広告／Meta広告／Microsoft広告／TikTok広告 へのオフラインコンバージョン送信 - GMOペイメントゲートウェイと連携したポイント制課金（従量課金・繰越・有効期限管理・自動更新） - A/Bテスト基盤（配信パターンの比較検証、表示数・クリック数・CTRのレポート） - AWS（Lightsail／RDS／S3）による本番環境の構築・運用、本番サーバーの移行（PHP 7.4→8.3、Ubuntu＋Nginx＋PHP-FPM） ## 取り組んだ課題と判断 ### ASPごとに異なるデータ仕様 ASPごとに、CSVの列の位置や列名、文字コード、税込・税抜の扱い、読み飛ばす行、 ポイントバックで受け取るパラメータ名などがすべて異なります。 ASPごとに個別のコードを書くと、連携先が増えるたびに改修が必要になるため、 これらの差分をコードではなく、設定テーブルのデータとして持たせる設計にしました。 ASP1社ごとに30項目を超える設定で取込・ポイントバックの挙動を切り替えられるため、 新しいASPの追加や仕様変更の多くを、コードを変えずに設定の変更で吸収できます。 一方、広告媒体ごとに異なるAPIの仕様そのものは、データでは吸収できないため、媒体ごとのサービスクラスに分け、パラメータの受け渡し方式が同じ媒体は共通のインターフェースでまとめています。1媒体の仕様変更が、他の連携先に波及しない構成です。 ### レガシーPHPからLaravelへの移行 既存システムは自分の開発経験が浅い時期に書いたコードで、構造が整理されておらず、 自動テストもありませんでした。保守性と安全性を高めるため、Laravelへの移行を決めました。 一括で作り直す案は、移行に膨大な時間がかかるうえ、不具合が出た際に原因箇所を 特定しづらくなるため採用せず、モジュール単位の段階移行を選択しました。 移行済みのモジュールはアーカイブとして管理し、新旧を並行稼働させながら、 サービスを止めずに置き換えています。 移行後は2022年6月からPHPUnitでテストを整備し、Featureテスト167件・ユニットテスト17件（媒体ごとの連携処理など）を書いています。テストファイルの約9割は自分で作成しました。 ### ジャンルの異なるサービスへのピボット 事業の主軸が、ポップアップ配信ツールから広告成果連携ツールへと大きく変わりました。 ジャンルがまったく異なるため、旧サービスと新サービスは、フロントエンド・バックエンドともに 別系統（Tools01／Tools02）として分離して運用し、両者に共通する部分だけを 上位の階層に切り出して共通化しました。決済の仕組みは大部分をそのまま流用し、 新サービスの立ち上げにかかる工数を抑えています。 ### ポイント制課金の設計 ポイントの増減と残高（ストック）をDB上でどう持つかを設計の中心に置き、 繰越・有効期限・自動更新まで含めて整合が取れるテーブル構造を設計しました。 ### 本番サーバーの移行（PHP 7.4 → PHP 8.3） 本番サーバーはセキュリティ更新が終了したPHP 7.4で動いており、さらにBitnamiのLAMP環境だったため、その上でPHPだけを上げるのは難しい状況でした。 そこで、稼働中のサーバーを直接更新する案は採らず、Ubuntu＋Nginx＋PHP-FPMの新しい環境を別に構築し、静的IPの付け替えで切り替えるBlue/Green方式を選びました。 問題が起きても静的IPを戻すだけで元に戻せ、サービスが止まる時間も付け替えの数十秒で済むためです。 - スペックは、2週間の負荷を実測したうえで、旧環境の半分に見直しました - PHPStanで全コードを検査し、PHP 8での非互換が0件であることを確認しました（見つかった既存のバグは別タスクに分離） - 静的解析では見つからない問題として、PHP 8でDBの数値の返し方が変わり、画面側の比較処理が一致しなくなる不具合を実機で発見・修正しました - 本番と同じ手順で本番機を作る予行演習を行い、当夜の作業を差分の同期と設定の差し替えだけにしました - ロールバックの手順も用意したうえで深夜に切り替え、ユーザーのログイン状態も引き継ぎました ## 実績 - ASPからの成果データ取込：180日間で802,540件 - Google広告へのオフラインコンバージョンAPI送信：約4か月間で15,625,595件 - 本番サーバーの移行（2026年9月）：停止は静的IPの付け替えの数十秒のみ。ロールバックすることなく切替に成功

## 概要 個人向けWebサービスの会員システムと、継続課金基盤を設計・構築しました（ユーザー6,000名超）。 Laravel + Vue のSPA構成で、同じ会員・課金基盤を、法人向けを含む別事業へ横展開しています。 ## 体制と役割 - 本体の会員システムは、要件定義から実装・インフラ・運用までを単独で担当 - 事業の担当者と直接やりとりしながら要件を整理し、DB設計から実装・リリース後の運用まで一気通貫で対応 - 本体システムの全567コミットのうち541コミットを担当 - 横展開先では、別の開発者が開発した本体システムと、自分が構築した会員・決済システムを連携させる部分を担当 ## 主な機能 - 会員管理（企業／従業員／店舗／商品／注文／サブスクリプションのドメインモデル） - GMOペイメントゲートウェイと連携した継続課金（決済登録・カード情報管理・定期課金・コールバック処理・課税履歴管理） - SMS配信・メール配信・Chatwork通知などの外部サービス連携 - AWS（EC2／RDS）上での本番環境の構築・運用 - Apache、cron／Laravel Schedule、Let's Encrypt 証明書の自動更新、ストレージの権限・ログローテーションの設計 ## 取り組んだ課題と判断 ### 業務の理解を写した、無駄のないDB設計 設計で最も重要なのは、要件定義（ビジネスの理解）とDB設計だと考えています。 テーブルは業務の理解を写したものであり、データの構造は後から変えるのが最も難しいため、 この2つには最も時間をかけ、詰められるところまで詰めたうえで、無駄を徹底的に省いています。 この案件でも、事業の担当者と直接やりとりしながら業務を確認したうえでテーブルを設計しました。 導き出せる値は持たず、税率改定や商品価格の変更、解約のタイミングなど、後から変わる条件は構造に織り込んでいます。 - 税率は履歴テーブル（税率・適用開始日時）で管理し、税率改定はレコードの追加だけで対応できるようにしています - 注文には税率・税抜金額・税額・税込金額を、明細には税込単価を保存し、商品価格や税率が変わっても過去の注文金額が変わらない構造にしています - 契約状態はカラムで持たず、契約の開始日・終了日から算出しています（未契約／登録中／課金中／解約済み）。状態と日付の食い違いが起きません - 決済完了前の仮登録（トークン・有効期限付き）と本会員を別テーブルに分け、未完了の申込が会員データに混ざらないようにしています - 都道府県・支払方法・解約理由・商品はマスタ化し、選択肢の追加や変更をデータの操作で済ませられるようにしています 14テーブル・28本のマイグレーションのうち27本を自分で作成しました。 運用中の仕様追加は列や制約の追加で吸収し、2024年9月以降はテーブル構造を変えないまま、約2年間運用を続けています。 ### 設計の軸：結合度と凝集度 設計では結合度と凝集度を判断の軸に置き、Contracts / Repositories / Services / Enums / Facades による 階層化で、各層をインターフェース越しに依存させ、実装の差し替えとテストがしやすい構成をとりました。 その結果、同じ会員・課金基盤を別事業へ展開した際は、34コミットで立ち上げることができました。 ### 別の開発者が作ったシステムとの連携 横展開先では、別の開発者が開発した本体システムと、この基盤を流用して構築した会員・決済システムを、 APIで連携させる構成をとりました。会員登録と決済登録が完了すると、 もう一方のシステムへAPIで会員情報を送信し、会員登録が行われる仕組みです。 自分だけでは完結しないため、連携するデータ項目・APIの仕様・エラー時の扱いを 相手の開発者とすり合わせたうえで実装しました。 ### レビュー担当がいない中での品質の維持 レビュー担当が常時いる体制ではないため、命名規則・DB設計規約・レイヤー構成・ テスト規約・レビュー観点を文書化し、同じ基準で実装できる状態を整備しています。 ## 実績 - 会員数：6,000名超 - 2024年9月以降、テーブル構造を変更せずに約2年間運用 - 同一基盤による別事業の立ち上げ：34コミット

## 概要 自社ECシステムに、外部SaaSを使わず物流EDI（企業間データ交換）機能を内製で組み込むプロジェクトです。 ECサイト側は別の開発者が担当し、物流EDI側を自分が単独で担当しました。 ## 体制と役割 - 通算3名が関わるプロジェクトで、機能領域ごとに分担 - 物流EDI領域の設計から実装・テストまでを単独で担当（DB設計・マイグレーション作成を含む） - 物流業務の担当者と直接やりとりしながら、実際の業務フローと運用上の制約をヒアリングし、要件定義から設計に落とし込み - 全267コミットのうち179コミットを担当 - 2年以上にわたり保守・機能追加を継続 ## 主な機能 - 取引先とのデータ授受を担うファイル連携（アップロード／一覧／ステータス管理／複数ファイルの結合ダウンロード） - ファイルのステータス変更履歴を保持する仕組み - 在庫切れアラート - 出荷レポート／アップロード通知のメール配信 - Artisanコマンドによる連携ファイルの自動生成バッチ - PHPUnit による Feature テスト ## 取り組んだ課題と判断 ### 他の開発者が作ったコードベースへ、新しい機能領域を追加する ECサイト側は別の開発者が構築しており、物流EDIはそこに後から加わる機能領域でした。 一つのコードベースに二人の書き方が混ざると、後から読む人の負担が大きくなるため、 既存のサービス層・リポジトリ層の設計方針とコーディング規約を踏襲したうえで、 物流EDI領域を追加しました。カート・注文・ルーティングなど双方が触る箇所は、 既存実装の書き方に合わせる形で変更しています。 物流EDI領域そのものは、Controller／Service／Repository／Model／マイグレーション／ Vueコンポーネントまで一貫して自分が実装しました。 ### 業務の実態を仕様に落とす EDIは取引先とのデータ授受が前提になるため、物流業務の担当者から実際の運用をヒアリングし、 ファイルの状態管理と変更履歴、在庫切れの通知など、現場で必要になる機能を設計に反映しました。 ## 成果 - 2025年1月の本番稼働から約1年8か月で、8種類・722件の物流ファイルを授受 - うち401件（約55%）を、システムが自動で生成（出荷指示257件・商品マスタ136件など） - 直近6か月の取扱いは月平均約43件。3社分のファイルを一つの仕組みで運用 - ステータスの変更を483件記録し、どのファイルがいつ完了したかを追跡できる状態に - 外部SaaSの利用料を発生させず、自社ECシステムの中で完結 - 2024年の開発開始から2年以上、Feature テストで既存機能への影響を確認しながら機能追加と保守を継続

## 概要 自社SaaSを3プロダクト並行で立ち上げ、企画から運用まで単独で行っています。 - 古物台帳SaaS（BtoB） - 美術鑑賞ログ（BtoC） - 所有物の価値可視化（BtoC） ## 体制と役割 - 1名体制で、市場調査・プロダクト企画・要件定義から、DB設計・アーキテクチャ設計・実装・CI/CD構築・運用までを担当 - 実装は生成AI（Claude Code）に任せる比重が高く、自分はAIに渡す基準の設計と、その出力の検証を担当 ## 主な機能・取り組み - 古物営業法という法規制のあるドメインで、法令上の要件をプロダクト仕様へ反映 - GitHub Actions によるCI/CD（デプロイとセキュリティスキャンの自動化。アプリ用とLP用でワークフローを分離） - Playwright による E2E テスト - LP／ブログ／アプリをドメイン設計で分離し、SEO資産を本体に集約 - Python による市場調査データの収集基盤（App Store／Flippa／Stack Exchange／公的統計など8本） ## 取り組んだ課題と判断 ### AIが書くコードの品質をそろえる AIが書く量が増えるほど、規約から外れたコードが混ざり、後から読み解くコストが上がります。 そこで、AIに参照させる開発規約を10文書に体系化しました （プロジェクト概要／命名規約／コーディングスタイル／ディレクトリ構成／DB設計規約／ ルーティング／アーキテクチャ／テスト規約／フロントエンド規約／レビュー観点）。 条件文・ループ・return文の書き方まで基準を定め、 レビュー観点は『Code Complete』を下敷きに7カテゴリで整理しています。 ### 文書だけでは守られない 規約を文書に置くだけでは守られないと判断し、命名規約をESLintルールとして実装して、 違反があればCIで停止させる仕組みにしました。 人の目によるレビューだけに頼らず、機械的に検出できる状態にしています。 ### 企画を感覚に頼らない 企画の段階では、市場のデータを定量的に集めるため、 App Store・Flippa・Stack Exchange・公的統計などから収集する仕組みをPythonで自作しました。 ## 成果 - 3プロダクトを1名で並行して立ち上げ、運用 - ESLint と CI による検証の導入後、目視のレビューで見落としていた規約違反を4件検出 - AIに渡す開発規約を10文書、レビュー観点を7カテゴリに体系化 - 市場調査用のデータ収集スクリプトを8本整備

## 概要 個人事業主として、士業事務所、人材・求人サイト、EC、NPO、不動産、サービス業など、 幅広い業種のWebシステム・Webサイトを受託開発しています。 クライアントは15社以上、並行して管理しているリポジトリは50を超えます。 ## 体制と役割 - 1名体制で、クライアントとの直接折衝から、要件定義・見積もり・納期管理・仕様調整、設計・実装・テスト・保守までを担当 - 非エンジニアのクライアントに対して仕様と工数を説明し、優先度を合意したうえで進める進め方を、通算6年続けている ## 使った技術と用途 - Laravel 10 ＋ Vite ＋ jQuery で、投稿・カテゴリ・タグ・カスタム投稿タイプ・店舗情報を管理する独自CMSを実装しました（2案件）。 - Laravel 6 で、商品・買取実績・コラム・問い合わせを扱う買取サイトを開発・保守しています。 - Vue ＋ PHP（API）で、士業事務所向け簡易CMSのログイン・投稿・カテゴリ・画像アップロード・並び替えを実装しました。 - WordPress で、求人サイトを含む複数サイトのオリジナルテーマと、問い合わせフォーム（確認・完了画面）を構築しました。 - Docker で、案件ごとの開発環境を構築しています。 ## 主な機能と目的 - お知らせ・ブログ・店舗情報を更新できる独自CMSを構築し、クライアントが更新のたびに開発を依頼しなくても、自分で情報を発信できるようにしました。 - 士業事務所向けには、ログインして投稿と画像を管理できる簡易CMSを用意し、事務所の担当者が自分で情報を更新できるようにしました。 - 求人サイトでは、求人情報を掲載し、問い合わせフォームから連絡を受け付けられるようにしました。 - 買取サイトでは、商品と買取実績を掲載し、実績を見たうえで問い合わせにつなげられる構成にしました。 - 決済機能を含む会員システムも担当しています（詳細はプロジェクト2）。 - 複数の案件で長期保守を担当しており、うち1件は2020年4月から現在まで継続しています。 ## 取り組んだ課題と判断 ### 技術以外の部分も自分で担う 個人事業主として直接契約しているため、開発だけでなく、要件のヒアリング・見積もり・ 納期の調整まで自分で行う必要があります。 クライアントの多くはエンジニアではないため、仕様と工数を説明し、 優先度を合意してから着手する進め方をとっています。 ### バージョンの異なる案件を並行して扱う Laravel 6系と10系の案件が混在しています。開発環境を1つにまとめる方法もありますが、 PHPやライブラリのバージョン差が他の案件に影響するため、案件ごとにDockerで環境を分けています。 ### 同じ要件は同じ構造で作る 投稿管理が必要な2つの案件では、案件ごとに設計し直すのではなく、 投稿・カテゴリ・タグ・カスタム投稿タイプという共通の構造で設計し、仕組みを流用しています。 ## 成果 - クライアント15社以上、リポジトリ50超の受託開発を一人で並行して担当 - 求人サイトを4サイト以上構築 - 2020年4月から現在まで保守を継続している案件あり