ID:82724さん

#### 【概要】 - 会員数約6,500名規模の公認会計士向けサービス「会計士.job」で、案件・求人、キャリア相談、セミナーなどの継続開発を担当。2025年4月以降、会員獲得・収益化に向けた機能拡充と、外部サービス連携・運用基盤の改善に取り組んだ。 - 自身を含む4名の開発チームで、テックリードとして設計方針の決定、他メンバーのレビュー、リリース判断を担当。Next.js／Reactの会員画面、Nuxtの管理画面、DjangoのAPI・バッチ、Google Cloudの開発・運用基盤を横断して設計・実装した。 #### 【課題・問題点】 - 有料サービス提供に必要な決済・購読管理と、会員向け画面・管理業務を一貫して整える必要があった。 - LP・紹介プログラムなどの会員獲得施策に加え、仮登録から本登録への移行促進と、施策の効果を確認するための計測が必要だった。 - 複数の自社サービスに業務処理・通知が分散し、管理画面から確認・操作できない機能が残っていた。外部SaaSとの連携では、同期失敗や再送、同時更新を考慮した運用が必要だった。 - 案件・会員データの増加に備え、一覧APIの全件取得や不要な関連データの取得・集計を抑える必要があった。 - フレームワーク更新と機能開発を並行する中で、複数の画面・API・DBを整合させて検証・リリースする仕組みの強化が必要だった。 #### 【打ち手・使用した技術】 **決済・購読管理**： - Stripeを用い、認証済み会員と決済を紐づけるCheckout、契約状態の連携、退会時の解約処理、管理画面での購読状況確認を実装。既存契約の確認と冪等性キーにより、重複申し込みへの対策を追加した。 - 会員向け購読管理画面・サービス説明・特定商取引法ページはメンバーと分担し、バックエンドと画面の契約状態・表示条件を整理した。 **LP・会員獲得施策／登録フロー改善**： - チームで、お友達紹介プログラム、キャリア相談・転職LP、外部向けコンテンツ公開、CTA改善、仮登録者へのリマインド、外部アカウント仮登録者の自動退会、登録フォーム改善を実施。 - 自身は紹介コードの生成・検証方針の検討と技術レビュー、本登録期限の延長・リマインド処理の改善を担当し、画面・API・定期処理の整合を図った。 **外部SaaS連携／運用機能の集約**： - 旧サービスに依存していた業務申請・アカウント関連処理をDjangoのサービス層と管理画面へ移行。Google Workspace／Microsoft 365の状態確認、申請結果・通知状態の記録、Slack通知を整備した。 - Salesforce連携では、JWT認証部分の技術レビューに加え、差分同期を設計・実装。同期結果の記録、失敗データの再実行、実行の排他制御、API制限時の再試行、同期中の更新を取りこぼさない仕組みを追加した。 - SendGridのWebhookにイベントの一意制約とトランザクションを導入し、再送時の重複処理を抑制。Stripe／SendGridの異常通知とCloud Runのログ・ヘルスチェックも整備した。 **API・データ基盤改善**： - 公開案件サマリ・案件一覧に、公開状態の絞り込みと表示順に合わせた複合インデックスを追加。管理・配信用の一覧にはページネーションと用途別の取得処理を設け、不要な関連データ・件数集計を省いた。 - MySQL接続切断への対応では、読み取り処理に限定した再接続・再試行を実装し、回復できない場合のエラー応答を統一した。 **テスト・リリース基盤強化**： - Playwright E2EとDjango単体テストを整備し、登録・認証・応募などの主要フローに加え、外部API失敗、再送、同時更新、DB移行の回帰テストを追加した。 - Cloud Workflows・Cloud Build・Terraformで、ビルド済みイメージの固定、DB移行の互換性検査、リリース候補へのE2E、APIから各画面への段階的な切り替えを制御する基盤を実装した。 - PR単位でアプリケーションとDBを分離した検証環境を構築。IAPによるアクセス制御、外部連携の制限、終了・期限経過時の削除を組み込み、チームで変更を確認するための環境を整備した。 **セキュリティ・技術更新**： - Django 4.2から5.2、React 18から19への更新を担当。Next.js 15から16への移行では、依存更新と合わせてビルド・lintの互換対応を実施し、Python 3.12・Node.js 22への更新、依存関係の固定、回帰テストを継続した。 - 公開画像と非公開ファイルのストレージを分離し、非公開ファイルには署名付きURLを使用。利用規約・プライバシーポリシーの文書バージョンと会員の同意履歴を管理する機能も実装した。 **効果検証の可視化**： - 登録導線の施策前後における本登録数の推移をSQLで可視化。さらに流入元・フォームの施策パターンを保持し、本登録のコンバージョン連携をキュー経由で実装して、施策評価に必要なデータを拡充した。 #### 【工夫した点】 - **設計とレビューによるチーム開発の支援**：紹介プログラムでは、自身がコード生成の方針検討を担い、メンバーの実装に対して固定値の解消と共通検証ロジックの利用を提案。ほかのPRでも、N+1クエリ、例外処理によるロールバック漏れ、認証情報のログ出力を具体的に指摘し、性能・整合性・安全性の観点を共有した。 - **障害時に復旧できる外部連携**：Salesforce同期は成功時だけ次の同期起点を進め、処理中に再更新されたデータは未同期として残す設計とした。本登録と外部へのコンバージョン送信も分離し、外部サービスの障害が会員登録を妨げない構成にした。 - **鮮度と負荷の両立**：公開案件APIで一時的に実装したレスポンスキャッシュは、公開・更新情報の鮮度を優先して撤去。インデックスと取得処理を改善するとともに、フロントエンドの定期再取得頻度を見直した。 - **段階的移行と検証対象の一致**：DB変更は旧コードとの互換性を確認し、移行後の障害は修正版の適用で回復する方針を採用。E2Eが実際のリリース候補を検証するよう接続先を揃え、開発環境で古い待機リリースが新しい変更を上書きする問題にも対処した。 - **既存仕様を守る技術更新**：依存ライブラリ更新だけで終わらせず、認証・ビルド・主要操作の互換性を確認。Claude／Codex／GitHub Copilot／Geminiは設計整理・テスト観点・レビュー補助などに活用し、採用判断と仕様・セキュリティ・運用影響の確認は自身で行った。 #### 【成果】 - 会員向けの申し込みから購読管理・退会、運用側の契約確認までを整え、有料サービス提供に必要な課金基盤を構築した。 - 分散していた運用機能を管理画面へ集約し、担当者が状態確認・操作できる範囲を拡大。複数の旧サービスの終了に貢献し、運用コストと保守対象の縮小につなげた。 - 外部連携の失敗箇所・処理状況を追跡し、再実行できるようにするとともに、再送や同時更新に備えた処理へ改善した。 - 会員獲得施策をチームで継続開発し、登録導線から本登録までの計測情報を拡充。施策の実装と効果検証をつなぐ基盤を整えた。 - APIの不要な取得・集計を削減し、技術更新に伴う互換対応と、候補環境での検証・段階的リリースを仕組み化。既存サービスを保守しながら改善を続けるための開発基盤を強化した。

#### 【概要】 公開画面リニューアルと並行して、会員管理・応募管理・メール配信・管理画面・開発基盤の継続的な改善が必要だった。協力会社エンジニア3名の新規参画により開発体制が複数名へ拡大し、実装だけでなく、タスク整理、優先度調整、進捗管理、レビュー、QA対応を含めた開発推進が求められた。 #### 【課題・問題点】 - 協力会社エンジニア3名の参画により、属人的なタスク管理やレビュー体制では開発が回らない - E2Eテストが未整備で、機能追加時のリグレッション検出が手動QA頼り - API仕様書が断片的で、フロント・バック間の認識齟齬が発生しやすい - メール配信状況（SendGrid）の可視化が運用側で困難 - ESLint・Node.jsバージョンの古さによる開発体験の劣化、Container Registry廃止予定への対応必要 #### 【打ち手・使用した技術】 **開発推進・チーム運営**： - 週次スプリント会議運営、タスク整理、優先度調整、進捗管理、コードレビュー、QA指摘整理 - 協力会社PRに対する継続的なレビュー・マージ（後述「成果」参照） **業務機能拡張**： - 会員退会機能、要注意会員フラグ、応募管理改善、ページネーション改善、CSV / XLSX出力改善 **メール基盤整備**： - SendGrid（v6.12.5）webhook連携、メール配信ログ収集、配信レポート管理画面 **開発基盤整備**： - **Playwright E2Eテスト導入**：会員登録・マイページ編集・案件応募・セミナー申込・退会など主要ユーザーフロー7シナリオをカバー - **Djangoユニットテスト整備**：リポジトリ全体で243テストメソッド・49テストクラスをカバー。API・Affairs・Gateway（Salesforce連携）・Memberの主要ドメインに限定すると177テストメソッド・30テストクラスを段階的に整備 - **APIドキュメント**：drf-spectacular でSwagger / Redoc を自動生成 - **ランタイム最新化**：ESLint 7→9、Node.js 14→22.14、Container Registry → Artifact Registry へ移行 #### 【工夫した点】 - **レビュー観点の標準化**：協力会社エンジニアからのPRに対し、セキュリティ・パフォーマンス・テスト観点を含むレビューチェックリストを整備し、属人性を抑えたレビュープロセスを構築 - **E2Eシナリオ設計**：機能網羅ではなく主要ユーザーフロー（登録〜応募〜退会）に絞ることで、メンテナンスコストを抑えつつ事業価値の高いリグレッション検出を実現 - **段階的なPlaywright導入**：1スプリントに1シナリオ追加するペースで進め、開発速度を落とさずE2E基盤を構築 #### 【成果】 - 複数名体制（自社+協力会社4〜5名）での開発推進に必要なタスク管理・レビュー・QA対応の流れを整え、機能開発と品質改善を継続的に進められる体制を構築 - **管理画面規模**：Nuxt.jsベースの約31画面、Vuex actions 222件規模の機能群を保守・拡張。Django adminでは57モデルを扱う管理機能を整備 - **PR・コードレビュー実績**（2023/7〜2026/5、GitHub PRメタデータより集計）： - リポジトリ全体のPR作成総数：609件 - 自身作成PR：266件 - 自身がマージしたPR：476件（うち他メンバー作成のPRを224件レビュー・マージ） - Playwright E2Eにより主要ユーザーフローを自動検証し、リグレッション検出を仕組み化 - Django ユニットテストを段階的に整備（リポジトリ全体243メソッド／API・Affairs・Gateway・Member等の主要ドメインに限定すると177メソッド）し、Salesforce連携・API・通知基盤の挙動を継続的に検証 - ランタイム最新化により、開発体験と将来的な保守性を改善

#### 【概要】 上場後の事業成長フェーズにおいて、会計士.jobの公開画面（案件検索・会員登録・セミナー・コラム・法人向け導線）は会員獲得と事業成長に関わる重要な接点だったが、機能追加を重ねた結果として構成が複雑化し、UI改善・SEO・OGP・検索制御・会員導線・法人向け導線を継続的に改善しやすい構成への見直しが必要だった。 #### 【課題・問題点】 - 既存公開画面はNuxt.js 2系で、技術選定当時から数年経過しており保守性が低下 - LP・セミナー・コラム・特設ページなど事業施策の追加が頻繁に発生する一方、機能追加のたびに既存コードへの影響範囲が広がりやすい構造 - SEO / OGP / 検索制御の最適化に手が届きづらく、SSR・メタタグ管理が場当たり的 - 会員マイページの自己情報管理機能（職歴・学歴・スキル・インボイス情報等）が断片的で、会員自身による情報更新の利便性が低い #### 【打ち手・使用した技術】 新公開画面をNext.js 13で技術選定から新規構築し、その後Next.js 14→15.5、React 18→19へ継続的にバージョンアップ： - **技術選定（初期構築：2023年4月時点）**：Next.js 13.2 / React 18 / TypeScript / Zustand / TanStack Query / react-hook-form / zod / framer-motion - **継続更新（2024年6月〜2026年）**：Next.js 14 → 15.5、React 19、Node.js 18 → 22.14 への段階的アップデート - **公開画面**：案件一覧 / 詳細 / 応募、セミナー、コラム、法人向け導線、特設ページ、視聴者専用ページ、OGP、SEO、検索制御を実装 - **会員マイページ**：職歴・学歴CRUD、プロフィール、スキル、インボイス情報編集機能を拡張 - **既存連携**：Nuxt.js管理画面、Django REST Frameworkバックエンド、GCPデプロイ設定、メール・Microsoft Teams連携と整合させながら段階移行 - **新人エンジニアへの技術指導**：日次約1時間のペアレビュー・QA・コードレビューを継続的に実施し、技術的フィードバックを通じてキャッチアップを支援 #### 【工夫した点】 - **コンポーネント設計**：今後のLP追加・特設ページ追加に耐える共通レイアウト・UIコンポーネントを設計し、事業施策の追加コストを低減 - **メタタグ・OGP管理**：Pages Router構成下で、`next-seo`（NextSeo）と `next/head` を活用してSEO・OGP対応を構造化 - **段階的なフォーム実装**：react-hook-form + zodでバリデーション層を統一し、職歴・学歴等の複雑なフォームでも保守性を確保 #### 【成果】 - Next.jsによる新公開画面を技術選定から新規構築し、公開画面の保守性・拡張性を向上 - LP・セミナー・コラム・案件導線の追加・改善を継続的に行える構成を整備 - 会員マイページの自己情報管理機能を拡張し、会員自身による情報更新の利便性を向上 - SEO・OGP対応により、上場後の事業成長フェーズに耐えうるフロントエンド基盤を確立 - 新人エンジニアへの日次指導を通じて、③フェーズ以降の複数名体制移行の基盤を整備

#### 【概要】 参画当初、会計士.jobの全サービス・全環境（公開画面・管理画面・バックエンド・phpMyAdmin・本番／ステージング／develop環境）が単一のCompute Engineインスタンス上で同居運用されており、環境分離・障害影響範囲・アクセス制御・リリース管理・ログ保全の観点で大きな改善余地があった。加えて上場準備に伴う内部管理体制の強化が並行して進んでおり、「誰が管理画面にアクセスできるか」を会社として一元管理できる構成への移行が求められていた。GCPの本格的な利用も認証設計も自身にとって初めての領域だったため、技術ありきではなく「解くべき目的の整理」から着手し、技術選定・設計・実装・リリースまでを一貫して主導した。 #### 【課題・問題点】 - **環境分離不能**：本番／ステージング／develop環境が同一インスタンスで同居しており、検証作業が本番に波及するリスク・リソース競合 - **SPOF（単一障害点）**：1台のホスト障害で全サービス・全環境が同時停止 - **アクセス統制不可**：phpMyAdminを含むDB管理経路が公開画面と同居しており、IAM分離不能 - **認証・認可がアプリ内実装に依存**：管理画面の認証はDjango内の独自実装でGoogleのIDトークンを検証する構成。アクセス可否の管理がアプリケーションコードに閉じており、個人単位の権限管理や異動・退職時の付与／剥奪を会社として一元的に行えなかった - **リリース管理の属人化**：ローカルでNuxtビルド→SCPアップロード→サーバーで`git pull`→`pm2 reload`という手動デプロイで、1サービスあたり15〜30分の作業者拘束、複数サービス同時反映で30〜60分以上を要した - **監査証跡の不備**：上場準備（J-SOX等）で求められるログ保全・アクセス記録・障害検知の体系が未整備 #### 【打ち手・使用した技術】 未知の領域だったため、構成の検討より先に経営陣・同僚エンジニアと議論し、満たすべき要件を言語化した（①承認された社員のみが管理画面を利用できること ②個人単位でアクセス権を管理できること ③異動・退職時に権限を変更・削除しやすいこと）。そのうえでGoogle Cloud公式ドキュメント等の一次情報を調査し、既存の認証フローを確認しながら複数構成を比較。サービス稼働を維持したまま段階的に基盤刷新を推進した。 - **実行基盤の選定**：App Engineを含む複数の実行環境を検証し、処理方式・コスト・運用負荷を比較したうえでCloud Runを採用 - **環境・サービス分離**：単一Compute Engineに同居していた構成を解体し、サービス・環境ごとに専用のCloud Run / Cloud Build / Secret Manager / IAP / Cloud Schedulerを設計・構築 - **デプロイ自動化**：GitHubとCloud Buildを連携し、Dockerfileベースのビルドからデプロイまでを自動化 - **アクセス制御の再設計**：管理画面の認証・認可をアプリ内の独自コードだけに依存させず、IAP × IAM × Google Workspace連携により、アプリケーションへ到達する前段でアクセスを制御する構成へ改修。画面・機能単位の細かな権限はDjango側に残し、「入口のアクセス制御」と「アプリケーション内部の権限制御」を責務分離 - **DB管理経路の分離**：phpMyAdminを含むDB管理経路を本番系から切り離し、会社管理アカウントに基づく経路統制を実現 - **障害検知・監査証跡**：500エラー時のSlack通知、Cloud Storageへのログ保存、メール送信ログ・エラーログ保全、Microsoft Teams連携エラー通知を整備 - **業務機能拡張**：面談管理、会員評価、ランク管理、管理者向けマイページ、CSV出力、問い合わせ・資料請求フォームなどを並行実装 #### 【工夫した点】 - **目的から入る課題設定**：知見のない領域だったからこそ、技術選定より先に経営・開発双方と「解決すべき目的」を合意し、非機能要件として言語化してから構成比較に入ることで、手戻りと過剰設計を回避 - **責務分離による運用性の確保**：「誰を通すか（認証）」をGCPのポリシー側、「何ができるか（認可）」をアプリ側に分離。入退社・異動時の権限運用をアプリ改修なしで完結できる構成とした - **段階的移行**：既存サービスの稼働を止めず、サービス単位で順次Cloud Run化することでリスクを最小化 - **環境テンプレート化**：Cloud Build YAML / Secret Managerテンプレートを整備し、本番／ステージング／develop環境を再現性高く構築できるようにした - **Dockerfile最適化**：`python:3.12-slim`をベースに、lockファイルベースの依存解決と`--no-cache-dir`によるインストールでイメージサイズを抑え、Cloud Runでの安定運用を実現。Next.js側はマルチステージビルドを採用 #### 【成果】 - 単一Compute Engineに依存した構成から、サービス・環境ごとに分離された Cloud Run / Cloud Build / IAP / Secret Manager 構成へ全面刷新 - 管理画面のアクセス権を、アプリ内の独自実装依存から**会社管理アカウント（Google Workspace）とGCPのIAMポリシーによる一元管理**へ移行。異動・退職時の権限変更をアプリ改修なしで運用可能にした - **デプロイ作業時間（手順ベース概算）**：手動15〜30分／回（複数サービスでは30〜60分以上）→ Cloud Build自動化により作業者拘束は数分／回に短縮 - **staging反映頻度（git履歴ベース推定）**：刷新前 月平均約5回 → 刷新直後 月平均約13回（約2.6倍） - 環境分離・障害影響範囲縮小・アクセス統制・デプロイ自動化・監査証跡保全を実現 - 上場準備に必要となるIT統制・セキュリティ・ログ保全・運用基盤の整備を技術面から支援し、**2022年5月30日のTOKYO PRO Market上場、2023年6月26日の東証グロース市場上場**に貢献

#### 【概要】 オンデマンド交通向けAI乗合配車システム「Noruuu」のPoC・新規開発。山口県内の地方自治体・交通事業者との共同実証を前提とし、現地の利用者ニーズを反映したUI/UXとシステム構築が必要だった。 #### 【チーム構成】 - 自身（テックリード・フルスタック） - アルバイトエンジニア1名（高校生） - PM兼セールスエンジニア1名 #### 【使用技術と使用場面】 - **Next.js / React / JavaScript / Bulma / Sass**：利用者向け公開画面、運行事業者・管理者向け管理画面の実装に使用 - **Laravel / PHP / MySQL**：予約管理・ユーザー管理・運行管理APIの実装に使用 - **AWS EC2 / RDS / S3 / Nginx**：アプリケーション実行環境、DB、画像管理、Webサーバー構築に使用 - **外部決済SaaS**：決済連携の実装に使用 #### 【課題・問題点】 - サービス内容が固まりきっていない0→1フェーズで、社長との議論や現地ヒアリングを通じてプロダクトの方向性を具体化する必要があった - デザイン専任者がいない体制のため、UI/UX設計から実装までを一貫して担う必要があった - 利用者・運行事業者・管理者がそれぞれ使えるサービスとして、UI/UX、公開画面、管理画面、バックエンド、DB、インフラ、決済連携を短期間で形にする必要があった - 外注先が開発するタクシー乗務員向けタブレット用ナビゲーションアプリで、現場目線の機能不足が散見された #### 【打ち手・使用した技術】 - **要件定義**：社長との議論、山口県現地でのテストユーザー宅訪問・ヒアリングを通じてサービス内容・画面構成・利用導線を具体化 - **公開画面・管理画面**：Next.js / React / Bulma / Sass で実装 - **バックエンド**：Laravel / PHP / MySQL で予約管理・ユーザー管理・運行管理APIを実装 - **決済連携**：外部決済SaaSとの連携実装 - **インフラ**：AWS EC2 / RDS / S3 / Nginx を設計・構築・運用 - **乗務員向けナビアプリ改善**：自身のタクシー乗務員（飛鳥自動車・約2.5年）の実務経験をもとに、外注先が開発するタブレット用ナビアプリへ乗務員目線での機能追加提案・改修指示を行い、現場課題をプロダクトに反映 #### 【工夫した点】 - **現場感覚の活用**：タクシー乗務員時代の実務経験を、配車システムのUI/UX・運行管理ロジック・ナビアプリ改善に直接反映 - **少人数・デザイン専任者がいない体制での進行**：自身がUI/UXからインフラまで一貫して担当することで、コミュニケーションコストを最小化 #### 【成果】 - サービス構想段階から、利用者・運用者が実際に使えるPoCサービスとして形にし、リリースまで推進 - 自身とアルバイトエンジニア1名（高校生）の少人数体制で、決済連携を含めた一通りのサービスを完成 - 「Noruuu」はその後も自治体・交通事業者向けに展開され、**山口市・宇部市・岩国市・津山市・長門市など複数自治体での実証・本格導入、JR西日本「WESTER」連携**などへ発展