ID:81725さん

## 0. はじめに こちらのプロジェクトは個人開発で発足したプロダクトとなっております。 まずは元々この業界で10年以上見てきた私が業界分析を行い課題を洗い出す段階にあります。 現在はこの業界名義で活動するAritstのブランティングサポートするための開発を第一フェーズとして進めています。 このプロジェクトのモチベーションとしては、即座にリリース自体は目指していません。 業界分析を進めつつ、この業界における本当の課題は何かということを解き明かし解消していくことが目的であり、その課題解決の手段としてプロダクトが構築されていくからです。 プロダクトを作ることがゴールではなく、課題を見つけて開発者自身なりに業界へ寄与するための足掛かりとして発足しており、最終的リリース、検証、業界への寄与することを目指しております。 ## 1. プロジェクト概要 ### ビジョン BeatSinkCentralは日本のビートボックスコミュニティの健全化と持続可能な発展を目指す総合プラットフォームです。プレイヤー、イベント主催者、観客を繋ぐ中心的なハブとして機能し、透明性・安全性・成長を促進します。 ### 現在のステータス MVP段階（フェーズ1）- プレイヤー紹介システムの構築に注力 --- ## 2. 背景・課題認識 ### なぜこのプロジェクトを始めたか #### 業界の現状と課題 同世代のBeatboxer兼オーガナイザーとの対話を通じて、以下の課題が明確になりました： | カテゴリ | 課題 | |---------|------| | **情報の分散** | イベント日程が重複し、観客・参加者が分散。情報が統一されておらず貴重な機会を逃すケースが発生 | | **安全性の欠如** | イベントでの不適切行為（性的被害等）が発生。業界の内輪のみで形成されている狭い世界のため、健全な業界・イベントとして保つことが困難 | | **風評被害への脆弱性** | ネット告発が発生した際、証明が難しく対応が困難。悪魔の証明的な形で立場が弱くなるリスク | | **機会の不平等** | 一部人脈のあるプレイヤーのみが優遇される傾向 | | **収益構造の未整備** | プレイヤー・オーガナイザー双方に持続可能な収益基盤がない | #### オーガナイザーへのヒアリングで判明した課題 **イベント運営の困りごと：** - チケット販売のオーディエンスに対する販売管理が煩雑 - エントリー方法がスマホで完結できない（キャンセル管理、自動メール返信、チケット発行、オンライン決済） - 電子決済のみで行いたいが手数料がネック - スポンサーを募ってお金を出してもらう仕組みがない - 違反者の管理ができていない **プレイヤーブッキングの課題：** - 収益性があるのかわからず博打になってしまう - 珍しいから呼ぶ → ミスマッチが発生 - プレイヤーが受け身な状態（声がかかるのを待つ） --- ## 3. 解決アプローチ ### 表向きの顔：ポータルサイト - イベントの情報集約 - プレイヤー情報の掲載 - 認定制度によるブランド化 ### 裏側の機能：管理・安全基盤 - プレイヤー・オーガナイザーの一元管理 - 行動履歴・評価システム - 違反者管理（ブラックリスト） --- ## 4. ビジネスモデル・収益構造 ### フェーズ別収益化計画 | フェーズ | 内容 | 収益源 | |---------|------|--------| | **Phase 1** (現在) | MVP - プレイヤー紹介 | - | | **Phase 1+** | 基本的なエンゲージメント機能 | - | | **Phase 2** | 収益基盤 | チケット販売手数料、プレミアムメンバーシップ | | **Phase 3** | サービス拡張 | マーケットプレイス手数料、プロモーション | | **Phase 4** | ビジネス展開 | 企業マッチング、スポンサーシップ | ### 収益モデル詳細 #### 1. メンバーシップ収益 | 種別 | 内容 | |------|------| | 基本会員（無料） | 基本的なプロフィール登録のみ | | プロ会員（有料） | 詳細プロフィール、優先エントリー権、プロモーション機会、スポンサーマッチング機会 | | 認定料 | 初回認定・更新料 | #### 2. イベント関連収益 | 種別 | 内容 | |------|------| | 掲載料 | 基本掲載（無料）、プレミアム掲載（有料：優先表示等） | | チケット販売 | 販売手数料（5-10%）、決済システム連携 | #### 3. 広告収益 - バナー広告（トップページ、イベントページ） - スポンサードコンテンツ - 楽器メーカー・音響機器・アパレル等からの広告 #### 4. マーケットプレイス - オリジナルグッズ、練習用教材、機材販売 - 販売手数料（10-15%） #### 5. プロモーションサービス - プレイヤー向け：プロフィール制作支援、PR動画制作、メディア露出機会 - イベント向け：告知物制作、SNS運用支援、集客支援 #### 6. データ活用 - イベント分析レポート（集客傾向、参加者属性、マーケティングインサイト） - 業界トレンドレポート #### 7. 企業向けサービス - タレントマッチング（イベント出演、CM・広告出演、企業イベント出演） - 企業スポンサーシッププログラム --- ## 5. 期待される効果 ### 短期的効果 - イベントの安全性向上 - トラブル対応の標準化 - 情報の透明性確保 ### 中期的効果 - プレイヤーの権利保護強化 - イベントの質的向上 - コミュニティの健全化 ### 長期的効果 - 業界の信頼性向上 - 新規参入の促進 - 市場の拡大 - 企業スポンサーの参入促進 --- ## 6. 出したバリュー・できること ### 0→1 プロダクト構築力 #### 課題発見からソリューション設計まで | やったこと | 詳細 | |-----------|------| | **ドメインエキスパートへのヒアリング** | 同世代のBeatboxer兼オーガナイザーと対話し、業界の課題を構造化 | | **課題の言語化** | 情報の分散、安全性の欠如、収益構造の未整備など、抽象的な課題を具体的な要件に落とし込み | | **ペルソナ定義** | パブリック・プレイヤー・オーガナイザーの3ドメインでターゲットユーザーを明確化 | | **段階的ロードマップ策定** | MVP → 収益基盤 → サービス拡張 → ビジネス展開の4フェーズで開発計画を設計 | #### ビジネス観点での設計 | やったこと | 詳細 | |-----------|------| | **収益モデル設計** | メンバーシップ、チケット販売手数料、広告、マーケットプレイス、企業マッチングの5つの収益源を設計 | | **ステークホルダー分析** | プレイヤー・オーガナイザー・観客・スポンサー企業それぞれの価値提供を整理 | | **競合分析・差別化** | 既存のイベント管理ツールとの違い（業界特化・安全性・認定制度）を明確化 | --- ### 技術選定・アーキテクチャ設計 #### 技術選定の意思決定 | 選定 | 理由・意図 | |------|-----------| | **Monorepo構成（Turborepo）** | UI・API・データベースを横断した開発効率化、パッケージ間の依存管理を一元化 | | **Next.js App Router + Hono統合** | フロントエンドとBFFを同一リポジトリで管理し、開発速度とデプロイ効率を向上 | | **Atomic Design + shadcn/ui** | デザインシステムの一貫性確保、コンポーネント再利用性の最大化 | | **Drizzle ORM + Supabase** | 型安全なDB操作、マイグレーション管理の容易さ、スケーラビリティ | | **Storybook + Chromatic** | コンポーネント駆動開発、ビジュアルリグレッション検知の自動化 | | **Zod** | フロント・バックエンド間のバリデーション統一、型安全性の担保 | #### アーキテクチャ設計の特徴 | 設計方針 | 詳細 | |---------|------| | **UI/アプリケーション分離** | UIコンポーネントはPropsを受け取り表示のみに徹する設計。状態管理・ビジネスロジックとの依存を排除 | | **フレームワーク非依存** | Next.js固有の機能に依存せず、Reactベースで実装。将来の環境移行に対応可能 | | **ドメイン分割** | パブリック・プレイヤー・オーガナイザーの3ドメインで機能を整理 | | **REST API + クライアント自動生成** | API仕様からクライアントコードを自動生成し、型安全な通信を実現 | --- ### UX起点の設計思考 #### ユーザー体験設計 | 設計観点 | 詳細 | |---------|------| | **「知る→理解する→応援する」の導線** | 受動的ユーザーから能動的サポーターへ変化を促す体験設計 | | **デバイス特性に合わせたレスポンシブ設計** | モバイルファーストを意識したUI設計 | | **ペルソナ別の情報設計** | 観客・プレイヤー・オーガナイザーそれぞれに最適化された情報構造 | #### 本業で培ったUX設計の応用 - デザイナーとの協働経験を活かし、エンジニア視点からのUX提案を実践 - 技術的制約とユーザー体験のバランスを取った意思決定 --- ### 開発基盤・品質担保 #### 開発環境の構築 | 構築内容 | 詳細 | |---------|------| | **CI/CD パイプライン** | GitHub Actions + Vercelで、PR作成→プレビュー環境、mainマージ→本番環境の自動デプロイ | | **コード品質管理** | ESLint + Prettier + Code Rabbit AIによる自動レビュー | | **ビジュアルリグレッションテスト** | Storybook × Chromaticで意図しないUI変更を自動検知 | | **環境分離** | 開発 / プレビュー / 本番の3環境を整備 | #### 本業での学びの応用 - VRT導入の背景：「UI変更を人の目で検知するのは困難」という課題を、自動化で解決 - コード規約策定の経験を活かし、個人開発でも一貫したコーディングスタイルを維持 --- ### できること（本プロジェクトで証明されたスキル） | カテゴリ | できること | |---------|-----------| | **プロダクト構築** | 課題発見 → ヒアリング → 要件定義 → 設計 → 実装 → 運用までの0→1全工程 | | **ビジネス設計** | 収益モデル設計、ステークホルダー分析、段階的ロードマップ策定 | | **技術選定** | プロダクト特性を踏まえた技術スタックの選定と意思決定の言語化 | | **アーキテクチャ設計** | Monorepo構成、UI/アプリ分離、ドメイン分割、拡張性を考慮した設計 | | **UX設計** | ペルソナ定義、ユーザージャーニー設計、デバイス特性を考慮したUI設計 | | **品質担保** | CI/CD構築、VRT導入、コード品質管理の仕組み化 | | **ドメイン知識の習得** | 業界特有の課題をヒアリングし、技術で解決するソリューションに落とし込む力 | --- ### 本業との相乗効果 | 本業で培ったスキル | 個人開発での応用 | |-------------------|-----------------| | フロントエンド実装基盤の確立 | Atomic Design + shadcn/uiでの一貫したコンポーネント設計 | | テスト戦略（VRT、コンポーネントテスト） | Storybook × Chromaticの導入 | | デザイナーとの協働経験 | UX起点の設計思考、技術制約を踏まえた体験設計 | | バックエンド領域への拡張 | API設計、DB設計、型安全なバリデーション | | チーム開発での意思決定経験 | 技術選定・設計の「なぜ」を言語化する習慣 | --- ## 7. 技術スタック ### フロントエンド | カテゴリ | 技術 | |---------|------| | フレームワーク | React, Next.js, TypeScript | | スタイリング | Tailwind CSS, Tailwind Variants | | UIコンポーネント | shadcn/ui | | ライブラリ | Lucide React, React Aria Components, Recharts | | ビルド | Turborepo (monorepo構成) | | テスト | Storybook, Chromatic (ビジュアルリグレッションテスト) | ### バックエンド | カテゴリ | 技術 | |---------|------| | フレームワーク | Hono.js, TypeScript | | API設計 | REST API + クライアント自動生成 | | バリデーション | Zod | ### データベース | カテゴリ | 技術 | |---------|------| | DB | PostgreSQL (Supabase) | | ORM | Drizzle ORM | | マイグレーション | Drizzle Kit | ### インフラ・デプロイ | カテゴリ | 技術 | |---------|------| | CI/CD | GitHub Actions | | ホスティング | Vercel | | 環境 | 開発 / プレビュー / 本番 | --- ## 8. ドメイン設計 | ドメイン | 対象ユーザー | 主要機能 | |---------|-------------|---------| | パブリック | 一般観客 | イベント情報閲覧、プレイヤー情報閲覧、基本情報・ガイド | | プレイヤー | メンバー | アカウント管理、イベントエントリー、プロフィール管理、実績管理 | | オーガナイザー | イベント主催者 | イベント管理、プレイヤー評価、運営管理、安全管理 | ### UX設計方針 > 「知る」→「理解する」→「応援する」 - 受動的ユーザーから能動的サポーターへの変化を促す体験設計 - デバイス特性に合わせたレスポンシブなインターフェース --- ## 9. リポジトリ構成 ``` / ├── apps/ │ ├── beatfolio/ # フロントエンドアプリケーション │ └── api-server/ # APIサーバー (BFF) │ └── packages/ ├── ui/ # UIコンポーネントライブラリ ├── data/ # データモデルとモックデータ └── database/ # データベース関連 ``` --- ## 10. 開発ワークフロー ### コード品質 - ESLint / Prettier - GitHub Pull Requests - Code Rabbit AI によるコードレビュー ### デプロイパイプライン ``` PR作成 → プレビュー環境へ自動デプロイ ↓ mainマージ → 本番環境へ自動デプロイ ``` --- ## 11. 実装の特徴 - React + Next.js によるモダンなWebアプリケーション - APIルーティングに Hono を採用（Next.js App Routerと統合） - Tailwind CSS による再利用可能なコンポーネント設計 - Atomic Design ベースのコンポーネント構造 - TypeScript + Zod によるエンドツーエンドの型安全性 --- ## 12. 次のアクション ### 検証活動 - ドメイン関連の人たちにヒアリング継続 - 東京のイベントオーガナイザーとの連携・検証 ### 開発 - プレイヤー情報の一元化をターゲットに体験部分を設計 - UX視点からの見直し（主観を排除）

# 採用CXCloud フルリプレイスプロジェクト詳細 ## 1. プロジェクト概要 ### 対象サービス - good-for-job（求職者向けプラットフォーム） - 採用CXCloud（企業向け管理画面） - 採用CXCloud管理画面（運営管理画面） ### 目的 上記3つのサービスドメインのフルリプレイス対応 ### 背景 旧アーキテクチャではユーザーへの価値提供のアジリティに限界があり、スクラム体制でフルリプレイスを実施 ### アプローチ - POによるプロダクトビジョンの再定義 - ビジョンに基づき、チームで既存機能の振り分け・要否判断を実施 - **ユーザーへの価値提供**を最重要視した開発 --- ## 2. 技術スタック ### フロントエンド | カテゴリ | 技術 | |---------|------| | フレームワーク | React, Next.js, TypeScript | | スタイリング | Tailwind CSS | | UIコンポーネント | shadcn/ui, Radix UI | | テスト | Storybook, Vitest, Chromatic | ### バックエンド | カテゴリ | 技術 | |---------|------| | 言語 | TypeScript | | フレームワーク | Hono | | ORM | Drizzle ORM | ### インフラ・その他 | カテゴリ | 技術 | |---------|------| | DB | Supabase, PostgreSQL | | 認証 | Auth0 | | 構成 | Monorepo（BFF, core-api） | | CI/CD | GitHub Actions | | ホスティング | Vercel | --- ## 3. 開発体制 ### スクラム開発 | 項目 | 内容 | |------|------| | スプリント期間 | 1週間 | | レビュー | 毎スプリント末にステークホルダーからフィードバック | | 進行管理 | チームメンバーによる当番制 | ### チーム構成（各1名） | 役割 | |------| | PO（プロダクトオーナー） | | VPoE | | 立ち上げ初期 エンジニア 2名、メンバー増員後 5名| | UI/UXデザイナー | --- ## 4. 担当フェーズ ### メイン：フロントエンド #### コンポーネント設計 - **Atomic Design**を採用 - Tailwind CSS + shadcn/uiを基盤 - shadcnは基底コンポーネントとして使用し、プロジェクト用にカスタマイズ #### 技術選定 - 開発環境の技術選定を担当 #### テスト戦略 | テスト種別 | ツール | |-----------|--------| | ビジュアルリグレッション | Storybook × Chromatic | | コンポーネントテスト | Storybook × Vitest | | アクセシビリティテスト | Storybook Addon | #### UXコラボレーション - UI/UXデザイナーとの実装壁打ち - 技術的制約の共有 - ユーザー体験のすり合わせ ### サブ：バックエンド | 担当領域 | |---------| | バックエンド全般の実装 | | API設計・実装 | | DB設計レビュー | --- ## 5. 出したバリュー・できること ### 技術選定・アーキテクチャ設計 #### 技術選定の意思決定 | 選定 | 背景・課題 | 意図・解決策 | |------|-----------|-------------| | **Atomic Design** | UIライブラリ直依存は移行時に全再実装が必要（アンチパターン） | Atom層で薄くラップし依存を抽象化。移行時はAtom層の差し替えのみで対応可能 | | **shadcn/ui** | Material UIのようなライブラリは挙動が固定され自由度が低い | 型は提供されるが自由に使える。プロダクトの自由度と時間制限のバランスを取れる | | **Storybook** | UI仕様がチーム内で共有されず認識ズレが発生 | UI仕様を定義する場として活用。デザイナーとの共通言語化 | | **VRT（Chromatic）** | UI変更を人の目で検知するのは困難でランニングコストが高い | 意図しない変更を自動検知。人間依存を排除し工数を劇的に改善 | | **Vitest** | テストランナーの選定 | Viteベースで高速実行、プロジェクト全体でツール統一、セットアップ容易 | #### アーキテクチャ設計の特徴 | 設計方針 | 詳細 | |---------|------| | **UI/アプリケーション分離** | UIコンポーネントはPropsを受け取り表示のみに徹する。状態管理・ビジネスロジックとの依存を排除 | | **フレームワーク非依存** | React/UIライブラリをベースに、UI関連がNextjsのフレームワークに固有機能に依存しない設計 | | **共通認識ベースの実装** | UIライブラリ・CSSフレームワークを基準として実装。デザイナーとの認識ズレを防止 | #### 意思決定の流れ ``` 抽象的な設計方針（Atomic Design）を決定 ↓ 具体のライブラリ選定（shadcn/ui） ↓ チームでスパイクタスク（PR）で検証 ↓ チーム総意で意思決定 ``` --- ### UX起点の設計思考 #### 求人機能の設計事例 **課題：** - 既存の求人サービスでは、求職者が応募した後に企業が求人情報を更新できる - 応募時点の情報と現在の情報に乖離が発生 - 求職者が「話が違う」と感じ、信頼関係が毀損 **解決策：** - **応募時点の求人情報を保持する設計**を採用 - 機能の問題ではなく「ユーザー間の信頼」という本質的課題に着目 **意図：** - 求職者と採用担当者間の信頼を守ることを設計の軸に - 機能要件ではなく、ステークホルダー間の関係性まで考慮した設計 #### 採用ピッチ資料埋め込み機能 **課題：** - 従来のiframe埋め込みは固定サイズでしか表示できない - 埋め込み先で毎回CSS/JSを個別実装する必要があり保守性が低い **解決策：** - postMessage APIを活用した動的サイズ調整 - 埋め込み元から親ウィンドウにサイズ調整を要求 - 一つのメッセージリスナーだけで対応可能な設計 **効果：** - レスポンシブ対応を実現 - 埋め込み先での実装負荷を大幅に削減 - プレイヤー側の仕様変更に自動追従する保守性の高いアーキテクチャ --- ### 開発プロセスの改善 #### デザインレビューフローの改善 | Before | After | |--------|-------| | 全コンポーネントのデザインPR通過後に実装着手 | デザインレビュー時に仮デザインを共有→仮実装→スタイル調整 | | 実装着手までのリードタイムが長い | リードタイムを解消 | | デザインに対する意見が曖昧 | 明確な意見を持てるようになりFB精度が向上 | #### スプリントレビューフォーマットの改善 **課題：** - ステークホルダー・社内メンバーが「何を確認すべきか」「何をすべきか」不明確 **解決策：** - サービス別整理（Good for Job / CXCompany / CXAdmin） - チケット情報 + 変更内容 + 確認方法を1セット化 - 非エンジニア向けの説明を追加 **効果：** - 閲覧するだけで必要な情報とアクションが明確になる状態を実現 #### 週次課題振り返りの仕組み化 - 水曜日の課題振り返りイベントを発足 - Slackチャンネルを活用した報告の土台を構築 --- ### チームサポート・オンボーディング #### 新メンバーへの伴走支援 | やったこと | 詳細 | |-----------|------| | **ペアプログラミング** | 比較的認識しやすいチケットを対応しながらペアプロでサポート | | **声かけの徹底** | API周りの実装チケットで積極的に声をかけ、質問しやすい雰囲気を構築 | | **伴走範囲** | BFFおよびfetcherの実装まで消化できる状態までサポート継続 | | **暗黙知の言語化** | 技術負債の背景説明、アーキテクチャ・実装方針の共有 | **効果：** - 新規メンバーが開発における判断基準を作れる状態を構築 #### バックエンド領域への積極的関与 - 他メンバーがAuth0のような認証検証に集中できるよう、API関連の実装を積極的に担当 - FBを受けつつバックエンド環境をキャッチアップし、テスト実装まで対応 --- ### 情報共有と認識合わせの推進 #### 構想の言語化 - 他メンバーの頭の中にあった認証周り・採用ピッチ資料の掲載状態に関する構想を言語化 - チケット消化に向けた認識合わせを自ら実施 #### Slackの公開チャンネル上での情報・自己開示 - 対応チケットや実装要件、未確定な要件を公開チャンネルで言語化・公開 - 開発チームメンバーに自身の考えを常に共有 #### ハドルへの積極参加 - 各地で発生しているハドルに参加 - 他メンバーの思考をウォッチして全体の動きを把握 --- ### 課題発生時のリーダーシップ #### 技術的課題への対応 - 実装周りで技術的な初期設定を誤っていた際、全体把握後にチームを巻き込んで認識共有 - 対応方針を先陣切って動き出し、相談を主導 - 状況に応じた意思決定の基準をチームで合意形成 #### 成果物への責任とやり切り - スプリント最終日に成果物提供するため、チームメンバーと連携して遅くまで対応して必ず成果物を達成 - チームメンバーの状態、チケットの進捗を見て声掛けを率先して実施 - 「リリースするものを提供する」という強い意志を持ってやり切り --- ### 成果・実績 #### 定量的成果 | 項目 | 内容 | |------|------| | **フルリプレイス完了** | 4名体制・4ヶ月で完了 | | **デザイン適用** | 6月末までにcxcompany、Good-for-jobはデザインをほぼ適用、1stリリースに間に合わせた | | **求人機能リリース** | 基盤となる機能を開発・リリース完了 | #### 定性的成果 | 項目 | 内容 | |------|------| | **コンポーネント再利用** | Atomic Design導入により実装速度が向上 | | **VRT導入** | デグレ確認工数が削減 | | **新メンバーキャッチアップ** | 伴走支援により短縮 | | **コード規約明文化** | フロントエンド実装規約を整備 | --- ### できること（本プロジェクトで証明されたスキル） | カテゴリ | できること | |---------|-----------| | **技術選定** | プロダクト特性を踏まえた技術スタックの選定と意思決定の言語化（背景・課題・意図を整理） | | **アーキテクチャ設計** | UI/アプリ分離、フレームワーク非依存、将来の技術負債を防ぐ設計 | | **UX起点の設計** | 機能要件ではなくユーザー間の信頼・関係性まで考慮した設計 | | **テスト戦略** | VRT、コンポーネントテスト、アクセシビリティテストの導入と運用 | | **デザイナー協働** | エンジニア視点からの意見提供、レビューフロー改善 | | **開発プロセス改善** | スプリントレビューフォーマット、週次振り返りの仕組み化 | | **チームサポート** | 新メンバー伴走、暗黙知の言語化、質問しやすい雰囲気づくり | | **バックエンド対応** | API設計・実装、DB設計レビュー、テスト実装 | | **リーダーシップ** | 課題発生時の認識共有、対応方針の主導、成果物への責任 | --- ### 成長と変化 #### 1年での変化 | Before | After | |--------|-------| | 教わる側 | 教える側 | | ついていく側 | 引っ張る側 | | 自分のことで精一杯 | チーム全体を見る余裕 | | ルールに従う側 | ルールを作る側 | #### テックリードを目指す上での意識 - コードの品質を担保してUIの動作を担保することを責務として認識 - その品質を担保することでエンジニアとして責務を全うできた状態を目指す - チームをリードして結論まで漕ぎ着けて、指針を示せている状態を実現 --- ## 6. 技術スタック（まとめ） | カテゴリ | 技術 | |---------|------| | Frontend | React, Next.js, TypeScript, Tailwind CSS, shadcn/ui | | Backend | Hono, Drizzle ORM | | Database | Supabase, PostgreSQL | | Auth | Auth0 | | Test | Storybook, Vitest, Chromatic | | CI/CD | GitHub Actions | | Hosting | Vercel | --- ## 7. 開発した主な機能 ### フルリプレイス対応（2024年1月〜7月） #### Good-for-job（求職者向けプラットフォーム） | 機能 | 詳細 | |------|------| | 採用ピッチ資料閲覧 | 企業の採用ピッチ資料を閲覧できるUI実装 | | 採用ピッチ資料詳細ページ | スライド形式での表示、ページネーション、全画面表示機能 | | 企業情報ページ | 企業概要、採用情報、ピッチ資料一覧の表示 | | レスポンシブ対応 | PC/SP両対応のUI実装 | #### 採用CXCloud（企業向け管理画面） | 機能 | 詳細 | |------|------| | 採用ピッチ資料管理 | ピッチ資料のアップロード、編集、削除、公開設定 | | 採用ピッチ資料詳細API | ピッチ資料情報取得API（テストまで含む実装） | | 企業情報管理 | 企業プロフィール、ロゴ、基本情報の管理 | | 認証基盤 | Auth0を用いた認証・認可機能 | #### 採用CXCloud管理画面（運営管理画面） | 機能 | 詳細 | |------|------| | 企業管理 | 登録企業の一覧、詳細、編集機能 | | 運営向け機能 | プラットフォーム全体の管理機能 | --- ### 求人機能基盤開発（2024年7月〜現在） #### Good-for-job（求職者向け） | 機能 | 詳細 | |------|------| | 求人一覧ページ | 求人情報の一覧表示、フィルタリング機能 | | 求人詳細ページ | 求人情報の詳細表示、応募導線 | | 応募フロー | Google Forms連携による応募機能 | | 求人OGP対応 | SNSシェア時に求人タイトル・企業ロゴが表示される機能 | #### 採用CXCloud（企業向け） | 機能 | 詳細 | |------|------| | 求人作成機能 | 求人情報の新規作成フォーム | | 求人編集・削除機能 | 既存求人の編集・削除 | | 求人公開設定 | 公開/非公開の切り替え | | 求人一覧管理 | 自社の求人一覧、ステータス管理 | | 採用フローテンプレート | 選考ステージのテンプレート作成・管理 | | 求人URL出力 | 求職者向けURL・企業向けURLの両方を出力 | #### BFF/API設計・実装 | API | 詳細 | |-----|------| | 求人CRUD API | 求人の作成・取得・更新・削除 | | 求人一覧API | フィルタリング、ページネーション対応 | | 採用フローテンプレートAPI | テンプレートのCRUD操作 | | 求人テンプレート適用API | 求人作成時のテンプレート適用ロジック | | Google Forms連携 | 求人票IDをGoogle Formsに伝播し、スプレッドシートで応募情報を管理 | #### 求人機能の設計思想 **課題：** - 既存の求人サービスでは、応募後に企業が求人情報を更新すると、求職者が見る情報も変わってしまう - 応募時点と現在の情報に乖離が発生し、「話が違う」という不信感につながる **解決策：** - 応募時点の求人情報を保持する設計を採用 - 求職者と採用担当者間の信頼を守ることを設計の軸に --- ### 採用ピッチ資料埋め込み機能 #### 機能概要 Good-for-jobで作成した採用ピッチ資料を、外部の採用サイトやWebページに埋め込めるようにする機能 #### 実装詳細 | 項目 | 詳細 | |------|------| | 埋め込み方式 | iframe形式での埋め込みコード生成 | | Web Components対応 | Shadow DOMによる外部CSS/JSの影響を受けない設計を検討 | | サイズ調整 | postMessage APIを活用した動的サイズ調整 | | レスポンシブ対応 | PC/SP両対応、16:9固定比率での表示 | #### 技術的な工夫 **課題：** - 従来のiframe埋め込みは固定サイズでしか表示できない - 埋め込み先で毎回CSS/JSを個別実装する必要があり保守性が低い **解決策：** - postMessage APIを活用した動的サイズ調整 - 埋め込み元から親ウィンドウにサイズ調整を要求 - 一つのメッセージリスナーだけで対応可能な設計 **効果：** - レスポンシブ対応を実現 - 埋め込み先での実装負荷を大幅に削減 - プレイヤー側の仕様変更に自動追従する保守性の高いアーキテクチャ --- ### 下書き・テンプレート機能 #### 機能概要 企業が求人作成時に使用する選考フローのテンプレートと、求人の下書き機能 #### 設計思想 | 機能 | 責務 | |------|------| | **下書き** | 公開する求人の下準備、一時保存、公開前のメモ的な立ち位置 | | **テンプレート** | 特定のフォーマットを登録して使い回せる雛形 | #### 実装方針 - テンプレートは定義として雛形を提供 - テンプレートから下書きが作成される - 下書きをどのように扱うかはユーザーに委ねる（サービス側の関心事ではない） - 責務を明確に分離し、シンプルな設計を維持 --- ### Feature Flag機能 #### 機能概要 段階的リリースを実現するためのFeature Flag機能 #### 実装詳細 | 項目 | 詳細 | |------|------| | 配置場所 | `packages/config`に集約 | | 共有範囲 | `apps/cxcompany`と`apps/good-for-job`で共有 | | 設計原則 | コロケーションの原則に基づき、使用場所に応じた適切な配置 | #### 効果 - 安全に機能を展開できる - 特定ユーザーへの先行公開が可能 - 問題発生時の即時切り戻しが可能

# AIエージェント開発プロジェクト詳細 ## 1. プロジェクト概要 ### サービス概要 - 複数のデジタルマーケティングAPIを統合したAIチャットアプリケーションの開発 - Google Analytics 4、Google Ads、Google Tag Manager、Search Console、Meta広告などのプラットフォームにAI経由でアクセス可能な統合基盤を構築 - MCP（Model Context Protocol）を採用したマイクロサービス設計により、各マーケティングAPIを独立したサービスとして管理 - 複数のLLMプロバイダー（xAI、OpenAI、Anthropic、Gemini等）に対応したマルチモデル戦略を実現 ### アーキテクチャ - 2リポジトリ構成 - フロントエンド（Next.js）とMCPゲートウェイサーバー（Express + Python）の分離アーキテクチャ - マルチテナント対応（ユーザーごとのOAuthトークン管理） --- ## 2. 技術スタック ### フロントエンド | カテゴリ | 技術 | |---------|------| | フレームワーク | React 19, Next.js 16（App Router）, TypeScript | | スタイリング | Tailwind CSS 4 | | UIコンポーネント | Radix UI, shadcn/ui | ### バックエンド | カテゴリ | 技術 | |---------|------| | 言語 | TypeScript, Python 3 | | フレームワーク | Express 5, Node.js 20 | ### AI/LLM | カテゴリ | 技術 | |---------|------| | SDK | Vercel AI SDK, Anthropic SDK, OpenAI SDK | | モデル | xAI（grok-2）, OpenAI, Anthropic, Gemini | ### MCP Server | カテゴリ | 技術 | |---------|------| | SDK | @modelcontextprotocol/sdk | | プロトコル | JSON-RPC, SSE | ### データベース・認証 | カテゴリ | 技術 | |---------|------| | DB | Supabase（PostgreSQL）, Redis | | ORM | Drizzle ORM | | 認証 | NextAuth 5, OAuth（Google/Meta）, Magic Link（Resend） | ### インフラ・ツール | カテゴリ | 技術 | |---------|------| | ホスティング | Vercel, Fly.io | | コンテナ | Docker | | テスト | Playwright（E2E） | | ツール | GitHub, Biome, Sentry | ### 外部連携API - Google Ads API - GA4 API - GTM API - Search Console API - Meta Ads API --- ## 3. 担当フェーズ ### フロントエンド #### ジョイン前の既存アーキテクチャにおける課題提起 | 課題 | 詳細 | |------|------| | コンポーネント設計の不統一 | 既存実装がAtomic Designに沿っておらず、再利用性が低い | | テスト基盤の欠如 | Storybook未導入、ビジュアルリグレッションテストなし | | 品質担保の仕組みがない | 意図しないUI変更を検知する仕組みがない | #### Atomic Designにおける再設計・実装 | やったこと | 詳細 | |-----------|------| | **コンポーネント設計の見直し** | 既存実装をAtomic Designベースで再設計 | | **UI/ロジック分離** | UIコンポーネントはPropsを受け取り表示のみに徹する設計 | | **shadcn/ui活用** | 基底コンポーネントとして使用し、プロジェクト用にカスタマイズ | | **再利用性の向上** | 汎用的なコンポーネントの抽出・整理 | #### Storybook・リグレッションテストの導入 | やったこと | 詳細 | |-----------|------| | **Storybook導入** | コンポーネントカタログとしてStorybookを構築 | | **VRT導入** | Chromaticと連携しビジュアルリグレッションテストを実現 | | **品質担保の仕組み化** | 意図しないUI変更を自動検知できる状態を構築 | --- ### バックエンド #### Google Tag Manager MCP Serverの開発 **OAuth認証検証** | やったこと | 詳細 | |-----------|------| | **技術調査** | GTM APIがOAuth 2.0必須であること、既存のGoogle Ads/GA4実装を流用可能であることを確認 | | **実現可能性の検証** | 必要なパッケージ、スコープ、実装フローを詳細に調査・整理 | | **既存アーキテクチャとの整合性確認** | 既存の`Integrations`テーブルや`getValidAccessToken`との統合方法を整理 | | **プロトタイプ作成** | `scripts/gtm-prototype.ts`で実際にAPIへの疎通を確認 | **GTM APIの調査・提案** | やったこと | 詳細 | |-----------|------| | **必要なAPIの特定** | 本プロジェクトで必要となるGTM APIを調査し提案 | | **スコープの整理** | `tagmanager.manage.users`スコープは不要であることを確認 | | **懸念点の提案** | チャット側から呼び出す際のGTM APIにおける注意点を整理 | **MCP Server実装** | やったこと | 詳細 | |-----------|------| | **OAuthを用いたGTM API呼び出し実装** | 既存のGoogle Ads実装を参考に、GTM用の認証フローを構築 | | **オープンソース活用** | stape-io/google-tag-manager-mcp-serverを参考に実装 | | **マルチテナント対応** | ユーザーごとのOAuthトークン管理を実現 | --- ## 4. 出したバリュー・できること ### 既存プロジェクトへの課題提起と改善 #### 課題発見から改善提案まで | やったこと | 詳細 | |-----------|------| | **アーキテクチャの課題特定** | ジョイン時に既存実装の課題を構造的に把握 | | **改善提案** | Atomic Design、Storybook、VRT導入を提案 | | **実行** | 提案内容を自ら実装し、開発基盤を整備 | #### 本業で培ったスキルの応用 | 本業での経験 | AIエージェント開発での応用 | |-------------|--------------------------| | Atomic Designベースのコンポーネント設計 | 既存実装の再設計 | | Storybook × Chromatic導入経験 | テスト基盤の構築 | | VRTによる品質担保 | 意図しないUI変更の自動検知 | | shadcn/ui活用経験 | 基底コンポーネントの整理 | --- ### 新技術領域へのキャッチアップ #### MCP（Model Context Protocol）の習得 | やったこと | 詳細 | |-----------|------| | **プロトコルの理解** | JSON-RPC、SSEを用いたAI-API連携の仕組みを理解 | | **実装** | GTM MCP Serverを実際に構築 | | **設計思想の理解** | MCPが「部品」であり、課題解決には上位設計が必要であることを認識 | #### AI/LLMエコシステムの理解 | 学んだこと | 詳細 | |-----------|------| | **Vercel AI SDK** | マルチモデル対応のAIアプリケーション構築方法 | | **OAuth × MCP** | ユーザーごとのAPIアクセス管理の設計 | | **マーケティングAPI統合** | GA4、Google Ads、GTM等のAPI連携実装 | --- ### AI Agentに対する考察 #### MCPの現在地と限界の理解 | 観点 | 考察 | |------|------| | **MCPの本質** | AIにMCPで実行できる関数を公開し、チャットの指示をAIに飛ばしてMCPで何を実行するかを行っているだけ | | **自律性の欠如** | 現状は完全に受動的。ユーザーが指示しない限り何も起きない | | **ドメイン知識の必要性** | ツールがあってもドメイン知識がなければ使えない | #### 「なんでもできる」の罠 | 問題点 | 詳細 | |--------|------| | **汎用性の罠** | 「なんでもできます」は基本何もできないのと同じ | | **素人には使えない** | 高度な専門知識がないとチャットベースでの課題解決は困難 | | **課題発見の難しさ** | 人が感じている課題は感覚的で言語化が困難 | #### 真に価値を発揮するために必要なもの | 必要なもの | 詳細 | |-----------|------| | **AI専用のUIUX設計** | Chatだけでは課題発見・導線設計ができない | | **高度なシステム設計** | 状態管理、コンテキスト保持、マルチステップ実行が必要 | | **ドメイン知識の組み込み** | 特定の課題に特化したソリューション設計 | #### 結論 > AI Agentが真に価値を発揮するには、「ユーザーが課題を言語化できない」前提で設計する必要がある。 > 現状のChat + MCPは「課題がわかっている専門家向けのツール」であり、素人の課題解決には「課題発見→言語化→解決」の全体設計が必要。 --- ## 5. できること（本プロジェクトで証明されたスキル） | カテゴリ | できること | |---------|-----------| | **既存プロジェクトへの参画** | 既存アーキテクチャの課題を特定し、改善提案・実行までできる | | **フロントエンド再設計** | Atomic Designベースでのコンポーネント再設計 | | **テスト基盤構築** | Storybook、VRT導入による品質担保の仕組み化 | | **新技術キャッチアップ** | MCP、AI SDK等の新技術を短期間で習得し実装 | | **バックエンド実装** | OAuth認証、外部API連携の調査・実装 | | **技術調査・提案** | 実現可能性の検証、懸念点の整理、ドキュメント化 | | **AI/LLMエコシステム理解** | MCPの設計思想、限界、活用方法を構造的に理解 | --- ## 6. 成果・実績 | 実績 | 詳細 | |------|------| | **課題提起** | ジョイン前のアーキテクチャ課題を構造的に整理・提案 | | **フロントエンド再設計** | Atomic Designベースでのコンポーネント再設計を実施 | | **Storybook導入** | コンポーネントカタログ・テスト基盤を構築 | | **VRT導入** | Chromaticと連携しビジュアルリグレッションテストを実現 | | **GTM OAuth検証** | 技術調査〜プロトタイプ作成〜実装まで完了 | | **GTM MCP Server実装** | OAuth認証を用いたGTM API呼び出しを実現 | --- ## 7. 技術スタック（まとめ） | カテゴリ | 技術 | |---------|------| | Frontend | React 19, Next.js 16, TypeScript, Tailwind CSS 4, Radix UI, shadcn/ui | | Backend | Express 5, Node.js 20, Python 3 | | AI/LLM | Vercel AI SDK, Anthropic SDK, OpenAI SDK, xAI（grok-2） | | MCP | @modelcontextprotocol/sdk, JSON-RPC, SSE | | Database | Supabase（PostgreSQL）, Drizzle ORM, Redis | | Auth | NextAuth 5, OAuth（Google/Meta）, Magic Link（Resend） | | Infra | Vercel, Fly.io, Docker | | Test | Playwright（E2E）, Storybook, Chromatic | | Tools | GitHub, Biome, Sentry | | External API | Google Ads API, GA4 API, GTM API, Search Console API, Meta Ads API |

# クラウドファンディングプラットフォーム開発プロジェクト ## 1. プロジェクト概要 ### サービス概要 - 日本の人気クラウドファンディングプラットフォームを参考にした、クラウドファンディングシステムの開発 - クライアント企業が指定する決済API・商品管理APIを統合した独自の商品情報管理システムを構築 ### 開発体制 - **1人開発**：要件定義から運用保守まで全フェーズを一人で担当 - **期間**：2024年7月〜2025年11月（約1年4ヶ月） ### 主要目標 1. 使いやすいクラウドファンディングプラットフォームの構築 2. 安全で効率的な決済システムの実装 3. 柔軟な商品管理システムの開発 4. ユーザーフレンドリーな管理画面の設計と実装 --- ## 2. 技術スタック | カテゴリ | 技術 | |---------|------| | フロントエンド | Blade, HTML, CSS, JavaScript | | バックエンド | Laravel, PHP | | データベース | MySQL | | インフラ | Heroku | | バージョン管理 | Git | | API連携 | RESTful API, JSON | --- ## 3. 担当フェーズ ### 要件定義・設計 | 担当業務 | 詳細 | |---------|------| | クライアント折衝 | クライアントとの直接対話を通じた要件の詳細化 | | アーキテクチャ設計 | システム全体のアーキテクチャ設計 | | データベース設計 | ER図作成、テーブル設計、リレーション設計 | | UI/UX設計 | デザインをもとにした画面設計・実装方針策定 | --- ### 開発 | 担当業務 | 詳細 | |---------|------| | フロントエンド実装 | Blade（Laravel）を用いた全面的な実装 | | バックエンド実装 | Laravel（PHP）を用いた全面的な実装 | | 決済API統合 | クライアント指定の決済APIとの連携実装 | | 商品管理API統合 | クライアント指定の商品管理APIとの連携実装 | | 管理画面実装 | 直感的で使いやすい管理者インターフェースの設計・実装 | | CI/CD実装 | デプロイパイプラインの構築 | #### API統合の詳細 - クライアント指定の決済APIと商品管理APIの詳細な仕様書の解析 - APIとの安全かつ効率的な通信を確立するためのインターフェース設計 - セキュリティを考慮したAPI認証システムの実装 #### 管理画面の主要機能 - プロジェクト作成、編集、管理機能 - 資金調達状況のリアルタイム可視化ダッシュボード - ユーザー管理、決済履歴、商品在庫管理 --- ### テスト | 担当業務 | 詳細 | |---------|------| | 単体テスト | PHPUnit等を用いた単体テストの実装 | | ユーザー受け入れテスト | クライアントと協力してのUATの実施 | --- ### リリース | 担当業務 | 詳細 | |---------|------| | デプロイメント計画 | デプロイメントプランの策定 | | 本番環境構築 | 本番環境のセットアップ | | ステージング環境構築 | ステージング環境のセットアップ | | 環境分離 | Development / Staging / Production の3環境整備 | #### 環境構成 | 環境 | 用途 | |------|------| | Development | 開発者が自由に操作 | | Staging | 新機能をテスト、コミットごとに生成 | | Production | 本番環境、リリース時に新機能へ切り替え | --- ### 運用保守 | 担当業務 | 詳細 | |---------|------| | エラー通知管理 | システムエラーの通知システム導入・管理 | | エラー対応 | エラー発生時の調査・対応 | | パフォーマンス最適化 | データベースクエリの最適化、レスポンス時間の改善 | | セキュリティ管理 | セキュリティパッチの適用とアップデート管理 | --- ## 4. 開発した主な機能 ### ユーザー向け機能（フロントエンド） | 機能 | 詳細 | |------|------| | プロジェクト一覧ページ | クラウドファンディングプロジェクトの一覧表示 | | プロジェクト詳細ページ | プロジェクトの詳細情報、目標金額、達成率、支援者数の表示 | | 購入フロー | 商品選択、決済、購入完了までのフロー | | 購入セット | 複数商品をセットにした購入の仕組み | ### 管理者向け機能（管理画面） | 機能 | 詳細 | |------|------| | プロジェクト管理 | プロジェクトの作成、編集、削除、公開設定 | | 商品管理 | 商品の追加、変更、写真の入れ替え、文章の編集 | | WYSIWYGエディタ | 商品本文用のリッチテキストエディタ | | 画像アップロード | 商品画像のアップロード・管理機能 | | 資金調達ダッシュボード | 資金調達状況のリアルタイム可視化 | | ユーザー管理 | 支援者情報の管理 | | 決済履歴管理 | 決済情報の確認・管理 | | 在庫管理 | 商品在庫数の管理・調整 | ### 決済・在庫管理機能 | 機能 | 詳細 | |------|------| | 決済API連携 | クライアント指定の決済APIとの連携 | | 商品管理API連携 | クライアント指定の商品管理APIとの連携 | | 在庫同期 | クラファン側DB在庫数とAPI側在庫数の同期 | | 金額按分計算 | 複数応援購入セットでの金額按分ロジック | ### 特殊機能 | 機能 | 詳細 | |------|------| | 金額管理モード | プロジェクトの盛り上がり演出のための金額操作機能 | | 整合性維持 | 売上・在庫数・サポーター人数の整合性を保つロジック | --- ## 5. 出したバリュー・できること ### 0→1 プロダクト構築力 #### クライアント折衝・要件定義 - クライアントとの直接対話を通じた要件の詳細化 - 参考サービス（Makuake）の分析に基づく要件整理 - ビジネス要件を技術要件に落とし込む力 #### 技術選定 | 選定 | 背景・理由 | |------|-----------| | **Laravel** | 決済・在庫管理という複雑なビジネスロジックを扱うため、フルスタックフレームワークを選定 | | **Blade** | Laravelとの親和性、サーバーサイドレンダリングによるSEO対応 | | **MySQL** | 決済情報の整合性を担保するためのRDBMS選定 | ### システム設計力 #### API統合設計 - 外部API（決済・商品管理）との安全かつ効率的な連携設計 - エラーハンドリング、リトライロジックの実装 - API認証システムの設計・実装 #### データベース設計 - プロジェクト、商品、応援購入セット、決済履歴などの複雑なリレーション設計 - 在庫管理のトランザクション設計 - 金額計算の整合性を担保するデータモデル設計 ### 1人開発ならではの成果 | 項目 | 詳細 | |------|------| | **全工程一貫対応** | 要件定義→設計→開発→テスト→デプロイ→運用保守まで全フェーズを一人で担当 | | **自己管理能力** | タスク管理、進捗管理、品質管理を一人で実施 | | **技術的な幅** | フロントエンド〜バックエンド〜インフラまで一人で対応 | | **クライアント対応** | 要件定義からUATまでクライアントと直接コミュニケーション | ### 品質担保 | 項目 | 詳細 | |------|------| | 単体テスト | PHPUnitを用いたテスト実装 | | CI/CD | デプロイパイプラインの構築 | | 環境分離 | Dev/Staging/Productionの3環境整備 | | エラー監視 | エラー通知システムの導入 | --- ## 6. できること（本プロジェクトで証明されたスキル） | カテゴリ | できること | |---------|-----------| | **0→1開発** | 要件定義から運用保守まで全フェーズを一人で完遂 | | **クライアント折衝** | クライアントとの直接対話による要件定義 | | **API設計・統合** | 外部API（決済・商品管理）との連携設計・実装 | | **データベース設計** | 複雑なビジネスロジックを支えるDB設計 | | **管理画面開発** | 直感的で使いやすい管理者インターフェースの構築 | | **決済システム** | 安全で効率的な決済システムの実装 | | **在庫管理** | 整合性を担保した在庫管理システムの構築 | | **CI/CD** | デプロイパイプラインの構築・運用 | | **運用保守** | エラー対応、パフォーマンス最適化 | --- ## 7. 本業との相乗効果 | 本業で培ったスキル | クラファン開発での応用 | |-------------------|----------------------| | Laravel/PHPの基礎 | フルスタック開発への応用 | | API開発経験 | 外部API統合の設計・実装 | | DB設計経験 | 複雑なリレーション設計 | | クライアント対応経験 | 要件定義、UAT実施 | | クラファン開発で得たスキル | 今後の開発での活用 | |-------------------------|------------------| | 0→1の全フェーズ経験 | プロジェクト全体の見通しを持った開発 | | 決済システム経験 | 堅牢なシステム設計への応用 | | 1人開発の自己管理能力 | チーム開発でのリーダーシップ | | クライアント折衝能力 | ステークホルダーとのコミュニケーション |

# 国家公務員時代のプロジェクト経歴 ## 1. 基本情報 | 項目 | 内容 | |------|------| | 所属 | 総務省所管 独立行政法人統計センター | | 期間 | 2018年4月〜2022年12月（4年9ヶ月） | | 雇用形態 | 正社員（国家公務員） | --- ## 2. プロジェクト概要 ### 2-1. 経済センサス活動調査 | 項目 | 内容 | |------|------| | 期間 | 2018年4月〜2019年10月（1年7ヶ月） | | 職種 | 組み込みエンジニア（統計プログラマー） | | チーム規模 | 10-50人 | | 役割 | メンバー | #### 調査の概要 統計法に基づく基幹統計調査として、以下を目的とする： - 全産業分野における売上（収入）金額、費用などの経理項目を同一時点で網羅的に把握 - 我が国における事業所・企業の経済活動を全国的及び地域的に明らかにする - 事業所及び企業を対象とした各種統計調査の母集団情報を得る #### 担当業務 | 業務 | 詳細 | |------|------| | 集計プログラム実装 | 全産業の事業所・企業の経済活動実態を把握するための集計プログラムを実装 | | コードレビュー | 外部エンジニアのコードレビューを担当し、プログラムの品質管理を実施 | | メッシュデータ作成 | 調査結果を地理的に細分化したメッシュデータを作成 | | データ提供 | 詳細な地域経済分析が可能なデータ提供を実施 | #### メッシュデータについて メッシュデータは、日本全国を緯度・経度に基づいて網の目（メッシュ）状に区分けしたもの： | メッシュサイズ | 名称 | |--------------|------| | 1kmメッシュ | 3次メッシュ | | 500mメッシュ | 4次メッシュ | | 250mメッシュ | 5次メッシュ | **データの内容：** - 事業所数 - 従業者数 - 売上（収入）金額 - 業種別のデータ **利用目的：** - 地域経済の分析 - 商圏分析 - 都市計画 - 防災計画 #### 使用技術 | カテゴリ | 技術 | |---------|------| | プログラミング言語 | VB（Visual Basic） | | ツール | Excel マクロ | | データ処理 | 統計データの集計・分析 | --- ### 2-2. 経済構造実態調査 製表 | 項目 | 内容 | |------|------| | 期間 | 2019年11月〜2022年12月（3年2ヶ月） | | 職種 | その他（統計調査運営） | | マネジメント | 職種その他 | | チーム規模 | 50-100人 | | 役割 | メンバー | #### 調査の概要 統計法に基づく基幹統計調査として、以下を目的とする： - 全ての産業の付加価値等の構造とその変化を明らかにする - 国民経済計算の精度向上等に資する - 5年ごとに実施する「経済センサス‐活動調査」の中間年の実態を把握する #### 担当業務 | 業務 | 詳細 | |------|------| | 調査企画 | 調査の企画立案から運営までを担当 | | 調査票設計 | 調査票設計の検討・作成 | | 現場運営サポート | 調査運営スタッフへのサポート | | マクロツール開発 | 業務効率化のためのマクロツール作成 | | データ整理・分析 | 収集データの整理・分析 | #### 開発したツール | ツール | 目的 | |--------|------| | 業務効率化マクロ | データ収集・整理プロセスの効率化 | | 調査運営用ツール | 調査運営担当者向けの業務支援ツール | | データ分析ツール | 収集データの初期分析用ツール | --- ## 3. 出したバリュー・できること ### プログラミングスキル | スキル | 詳細 | |--------|------| | VBプログラミング | 統計調査に必要なデータ収集・分析ツールの開発 | | Excelマクロ | 業務効率化ツールの作成 | | データ処理 | 調査データの収集、整理、分析の一連のプロセス | ### 品質管理 | スキル | 詳細 | |--------|------| | コードレビュー | 外部エンジニアのコードレビューによるプログラム品質管理 | | データ品質管理 | 統計データの精度向上への貢献 | ### 業務改善 | スキル | 詳細 | |--------|------| | 業務効率化 | マクロツールによる作業時間短縮 | | プロセス改善 | データ収集・整理プロセスの最適化 | ### 調査運営 | スキル | 詳細 | |--------|------| | 調査設計 | 調査票設計の検討・作成 | | 運営サポート | 現場運営スタッフへのサポート | | データマネジメント | 収集データの整理・分析・品質管理 | --- ## 4. できること（本期間で証明されたスキル） | カテゴリ | できること | |---------|-----------| | **プログラミング** | VB、Excelマクロを用いた業務ツール開発 | | **データ処理** | 大規模統計データの集計・分析 | | **品質管理** | コードレビューによるプログラム品質担保 | | **業務改善** | マクロツールによる業務効率化 | | **調査設計** | 調査票設計の検討・作成 | | **地理情報処理** | メッシュデータの作成・提供 | | **チーム連携** | 外部エンジニア・調査運営スタッフとの協働 | --- ## 5. 成長と学び ### 技術的成長 - プログラミングの面白さに目覚め、エンジニアへの転職を決意 - 大規模データ処理の経験を通じて、データ品質と精度の重要性を理解 - 業務効率化ツールの開発を通じて、ユーザーのペインポイントを解決する喜びを実感 ### ビジネス的成長 - 国の基幹統計調査という社会的影響の大きいプロジェクトに従事 - 調査設計から運営までの全フェーズを経験 - チーム規模50-100人のプロジェクトでの協働経験 ### エンジニアへの転職につながった経験 - 統計プログラマーとして1年半の開発経験 - コードレビューを通じた品質意識の醸成 - 業務効率化ツール開発を通じた「開発で価値を生み出す」経験 --- ## 6. 本業との相乗効果 | 国家公務員時代で培ったスキル | 現在の開発業務での活用 | |-----------------------------|----------------------| | VB/マクロ開発経験 | プログラミング基礎力として継続活用 | | 大規模データ処理 | API設計・DB設計時のデータ設計力 | | コードレビュー経験 | チーム開発でのレビュー文化構築 | | 調査設計・要件整理 | 要件定義・設計フェーズでの論理的思考 | | 業務効率化ツール開発 | ユーザーペインからの課題発見・解決力 | | チーム協働経験（50-100人規模） | 大規模プロジェクトでのコミュニケーション力 | --- ## 7. キャリアサマリー ``` 【国家公務員としての5年間】 ├─ 2018年4月〜2019年10月: 経済センサス活動調査（統計プログラマー） │ └─ 集計プログラム実装、コードレビュー、メッシュデータ作成 │ └─ 2019年11月〜2022年12月: 経済構造実態調査（調査運営） └─ 調査企画、調査票設計、マクロツール開発、データ整理・分析 【転職への転機】 ・統計プログラマーとしての1年半の開発経験でプログラミングの面白さに目覚める ・業務効率化ツール開発を通じて「開発で価値を生み出す」喜びを実感 ・エンジニアとしてのキャリアを志望し、Web開発の道へ ``` --- ## 8. 詳細業務内容 ### 経済センサス活動調査（簡潔版） > 国家公務員として5年間勤務し、統計関連のプログラミングに1年半従事しました。経済センサス活動調査において、全産業の事業所・企業の経済活動実態を把握するための集計プログラムを実装しました。外部エンジニアのコードレビューも担当し、プログラムの品質管理を行いました。また、調査結果を地理的に細分化したメッシュデータを作成し、詳細な地域経済分析が可能なデータ提供を行いました。使用言語は主にVBでした。 ### 経済構造実態調査（簡潔版） > 経済構造実態調査において、調査の企画から運営までを担当しました。主な業務には、調査票設計の検討・作成、現場運営のサポートが含まれます。また、業務効率化のためのマクロツール開発や、収集データの整理・分析も行いました。