ID:82724さん

#### 【概要】 会員数約6,500名規模に達し、収益化施策、紹介プログラム、外部SaaSとのデータ連携、通知基盤の信頼性向上、API性能改善など、サービスを「広げる・深める」フェーズへ移行。 #### 【課題・問題点】 - 課金体系の整備が必要で、決済・購読管理機能の実装が急務 - 会員獲得施策（LP・CTA・紹介プログラム）の継続実装が必要 - 仮登録のまま放置される会員が一定数存在し、登録フロー改善が必要 - Salesforce / Google Workspace / Microsoft連携に加え、複数の非公開の自社サービスとの連携が各所に散在しており、通知基盤として一貫性がなく、管理画面から状態確認・操作できない機能が残っていた。複数の自社サービスを並行運用していたため、運用・保守コストの負担が大きい状態だった - 公開案件サマリAPIで、会員数・案件数の増加に伴いレスポンスタイム劣化リスク - Django・Next.js・決済SDKのバージョンが古く、保守性低下とセキュリティリスク #### 【打ち手・使用した技術】 **決済・購読管理**： - Stripe（Python SDK 14.4.1）による決済機能、会員向け購読管理画面、管理画面での購読状況表示、特定商取引法ページを実装 **LP・会員獲得施策**： - お友達紹介プログラム、キャリア相談LP、外部向けコンテンツ公開対応、CTA改善 **登録・会員管理フロー改善**： - 仮登録者への本登録リマインド、外部アカウント仮登録者の自動退会、登録時の会員判定、新規登録フォーム修正 **外部SaaS連携 / 通知基盤**： - Salesforce API連携（JWT認証）、稼働実績表示改善、Google Workspace / Microsoftアカウント状態確認、Slack通知への移行 - 各所に散在し、運用・保守の負担となっていた複数の自社サービス連携を整理し、必要機能を会計士.job管理画面へ移行することで、運用担当者が管理画面から一元的に状態確認・操作できる体制に改善。あわせて、運用・保守負担となっていた複数の自社サービスを完全に閉じることに貢献し、運用コストと保守対象の縮小を実現 **API・データ基盤改善**： - 公開案件サマリAPIに対し、`status` / `open_at` / `updated_at` / `id` の複合インデックスを追加し、絞り込み・並び替え時のクエリ性能を向上（途中検証で導入したレスポンスキャッシュは、案件公開・更新の鮮度を優先するfreshness戦略に移行する過程で削除） - 案件サマリテーブルに複合インデックス（status, open_at, updated_at, id）追加 - 案件テーブルに複合インデックス（status, open_at, created_at）追加 - 応募管理・案件配信系をページネーション・annotate最適化で全件取得・重い集計を抑制 **テスト・運用基盤強化**： - Playwright E2E再構築、Cloud Runログ整備、DB接続安定化 - **技術更新の連続性**：参画期間（2021/3〜現在）を通じて、Django 4.2 → 5.2、Next.js 13 → 14 → 15.5、React 18 → 19、Node.js 18 → 22.14、Python 3.12への段階的アップデートを継続的に推進。あわせてSendGrid 6.12.5、Stripe Python SDK 14.4.1など外部SDKも最新版へ更新 **効果検証の可視化**： - 会員登録導線（フォーム改善・CTA・仮登録者リマインド・キャリア相談LP・紹介プログラム）の各施策前後における本登録数推移をSQLで可視化 - 改善サイクルを継続的に回せる状態を整備 #### 【工夫した点】 - **インデックス設計**：`status`での絞り込み + `open_at` / `updated_at` / `id` での並び替えに最適化した複合インデックスを選定し、データ増加時のクエリ性能劣化を抑制 - **キャッシュ戦略の判断**：途中で導入したレスポンスキャッシュについて、案件の公開・更新の鮮度（freshness）を優先する方針へ転換し、キャッシュ層を取り外して鮮度優先の構成に再整理 - **段階的なバージョンアップ**：Django 5.2 / React 19 / Next.js 15→16 への移行を、テスト整備（Playwright + Django ユニット）でリグレッションを抑えながら段階的に実施 - **AIツールの開発フローへの統合**：Claude / Codex / GitHub Copilot / Geminiを設計整理・SQL作成・テスト観点整理・レビュー補助・ドキュメント作成に活用。最終判断は自身で行い、既存仕様・セキュリティ・運用影響を確認したうえで取り込み #### 【成果】 - Stripe決済、購読管理画面、特定商取引法ページを実装し、会員向け課金体験と運用側の確認業務を整備 - お友達紹介プログラム、キャリア相談LP、CTA改善などにより、会員獲得・利用促進施策を継続実装できる体制を確立 - Salesforce API連携（JWT認証）、Google Workspace / Microsoftアカウント確認、Slack通知移行により、外部連携と通知基盤の信頼性を向上 - 各所に散在していた自社サービス連携を整理し、必要な機能を会計士.job管理画面へ移行。運用担当者が管理画面から状態確認・操作できる範囲を拡大し、運用負荷を軽減。**あわせて、運用・保守負担となっていた複数の自社サービスを完全に閉じることに貢献し、運用コスト削減と保守対象の縮小を実現** - **API性能**：公開案件サマリAPIに対し、`status` / `open_at` / `updated_at` / `id` の複合インデックスを追加し、データ増加時の絞り込み・並び替えのクエリ性能を向上。同APIへ一時的に導入したレスポンスキャッシュは、案件公開・更新の鮮度を優先する方針に転換した過程で取り外し、鮮度優先の構成として再整理 - React 19 + Next.js 15/16 + Django 5.2 への更新により、最新ランタイムを採用した保守性の高い構成へ移行 - 施策効果の可視化により、登録導線改善のPDCAサイクルを継続的に回せる状態を構築

#### 【概要】 公開画面リニューアルと並行して、会員管理・応募管理・メール配信・管理画面・開発基盤の継続的な改善が必要だった。協力会社エンジニア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」連携**などへ発展