ID:64774さん

### 概要 全社のAI活用推進と営業部門のSalesforceデータ取得工数を削減するため、MCP（Model Context Protocol）によるSalesforce連携MCPサーバーを構築。固定IP制約や認可要件（OAuth）を満たしつつ、ステートレスな連携基盤を整備し、Claude等のAIツールから安全に利用できるMCPサーバーを営業本部(社内476名)へ展開。 ### 役割・責任 - PM/実装として、要件定義（固定IP/OAuth/ログ/件数制御/更新性）から設計・デプロイまで一人で実施。 - 社内勉強会・資料を整備し、MCP連携の社内展開とAI駆動開発の手法を開発本部に展開 - AI駆動開発の運用設計（プロンプト/ツールスキーマ/ガードレール）を整備し、実務に組み込み。 ### 主要タスク - 要件定義と代替案比較（Cloudflare推奨案→固定IP制約で不適合を判断し、Cloud Run採用）。 - Streamable HTTPでのステートレス化、mcp-remote導入によるDesktop連携の確立。 - gcloudコマンド自動生成によるCloud Runへのノークリック・デプロイの仕組み化。 ### 技術的論点・工夫 - 認可と監査: OAuthフロー、リクエストログ、件数/レート制御をサーバー側で強制。 - 接続要件: 固定IP要件を満たすため、Cloud Run＋適切な出口制御を選定。 - DX最適化: AI駆動開発（Claude/Cursor）で設定/実装を高速化し、検証リードタイムを短縮。 ### AI駆動開発（方針と実践） - 開発プロセス: Claude Code/CursorのAI駆動開発で実装。 MCPサーバーの仕組みと相性がいいTDDで開発 - ナレッジ展開: 本PJで得たAI駆動開発の知見を社内の技術カンファレンスで開発本部(100名超え)に発表。社内向けサンプルMCP連携勉強（Google Drive等）とハンズオン資料を整備し、17名規模の勉強会で横展開。 ### 成果・影響 - 外注費 約150万円削減（AIコーディング活用で1.5ヶ月相当を内製化）。 - 営業工数 概算380h/月削減（4h×476名×利用率20%）。 - 開発本部でAI駆動開発の展開、MCP連携の社内勉強会

### 概要 執行役員PO/開発本部長から指名を受け、新規事業「GX PF」のPMに任命。カーアフターマーケット事業者（整備/鈑金/車販）のCO2排出量可視化と削減を支援するアプリケーションの企画/要件定義を担当（主要な企画はPOの執行役員）。 自動車業界のGX機運が年々高まる中、POが主導した7件のPoCを経て本格要件定義フェーズに移行。 ### 役割・責任 - PMとして、PO要求に対してビジネス/技術の両面から提案を実施。 - Figmaを導入しモックを整備、代表取締役向け社長レビューを実施（デザインはSESデザイナーが担当）。 - MTG中の調査事項はChatGPTやFelo等のAI検索を活用して即時調査・共有し、意思決定スピードを向上。 - MVP（CO2可視化）については、自分自身でAI駆動開発（Cursor/Claude Code）でプロトタイピングを実施。 ### 主要タスク - GX領域キャッチアップ（関連書籍3冊の読了、炭素会計アドバイザー3級の取得）。 - 要求のビジネス/技術両面の整理と、MVPスコープの具体化。 - Figmaモックアップ作成とステークホルダー合意形成の場（社長レビュー）の設計・運営。 - MVPプロトタイプ開発（Next.js, TypeScript, Vercel, Supabase 等）。 ### 技術的論点・工夫 - 早期にUX仮説を可視化するため、デザイン/実装の両面でAI支援を取り入れ、検証サイクルを短縮。 - 会議内での即時調査/共有を標準化し、要件の曖昧さをその場で解消。 ### 体制・規模 - 初期WG: PO（執行役員）、PdM（業務委託）、開発PM（自分）、SES（エンジニア2名・デザイナー1名） ### 成果・影響 - 7件のPoC知見を要件定義へ反映し、CO2可視化MVPのモック/プロトタイプを提示。経営層レビューまで到達し、以降の意思決定の土台を形成。 - AI活用により、会議〜意思決定までのリードタイムを短縮。要件定義の解像度向上に寄与。 ### ステータス - 2025年3月、POである執行役員の退任によりプロジェクトは半凍結中。

### 概要 株式会社ブロードリーフは全国のカーアフターマーケット事業者（整備/鈑金/車販/部品商）向けにSaaSを提供。部品商や大手団体/企業を代理店とした販売制度があり、SA（紹介）/CS（仕切り）の形態でバックオフィスが制度に基づき手数料を支払う運用となっている。 現行制度・システムでは「代理店⇔整備工場」が1対1に固定され、複数プロダクトと代理店の得意領域（例：鈑金特化）との組み合わせで販売機会の取りこぼしが発生。システム上も1アカウント1代理店の制約があったため、複数代理店の登録・運用を可能にすることを目的とした。 ### 役割・責任 開発本部 契約管理チームのPMとして、営業/バックオフィスと制度要件をすり合わせ、システム対応範囲・データモデル・契約/支払フローの見直し方針を策定。要件定義〜優先度付け〜リリース計画を取りまとめ、実装をドライブ。 ### 体制・規模 - 約10名（PM: 自分、契約管理社員 1名、SESエンジニア 5名、バックオフィス 2名、営業 2名） ### 主要タスク - プロジェクトのスコープを定義。代理店登録方式をマップ化（1. SA複数/CS複数、2. SA1:CS複数、3. SA1:CS1、4. SA or CS［現状］）し、各方式のシステム対応範囲と「できること/できないこと」を整理・共有。 - 開発予算・対応時期・制度上の現実解を踏まえ、関係部門と協議のうえ「2. SA1:CS複数」「3. SA1:CS1」を実装スコープとして決定（SA複数/CS複数は制度上のカニバリズム懸念により除外）。 - 契約方式別フロー（SA=ユーザーがSaaS上でWeb契約可、CS=代理店との紙/外部契約→BO承認→裏側で商品契約）に合わせ、画面制御/業務ロジックをSESと共同で設計書に落とし込み、実装を委託。 ### 技術的論点・工夫 - 「1アカウント=1代理店」の既存制約を崩さず、特例時のみ複数代理店の関連付けを許容するデータモデル/状態遷移を設計。監査・運用のため特例フラグ/承認情報を保持。 - SA/CS混在時の優先順位、手数料計算、承認フロー分岐を画面制御ロジックとバックエンド設定で表現し、一貫性と可観測性を確保。 - 制度の覚書（代理店間）＋社内承認に基づく運用をシステム上のガードレールとして実装し、制度と実装の整合性を担保。 ### 成果・影響 - 制度・システム両面で「特例下の複数代理店運用」の道筋を確立し、対象アカウントで複数代理店登録を可能化。 - 営業/バックオフィスの運用負荷と手戻りを抑制。トータルマネジメントショップ向けのクロスセル機会損失を縮小（定量値は社内指標に依存）。 ### 運用方針 - 本PJ後も、複数代理店は特例として扱い、代理店同士の覚書＋ブロードリーフ承認を前提に登録・運用可能とする方針を確立。

# プロジェクト概要 LINE公式アカウント上でサブスク販売/決済、サブスクに連動したEC・モバイルオーダー・予約できるCRMのSaaSの上流工程からコーディングやテストなどを行う下流工程までを一貫して担当。PM業務も兼任 スタートアップ企業の立ち上げ事業 https://subscline.com/lp/2023 # 役割 テックリード・PMとしてプロジェクトを推進 会社エンジニアメンバーが自分含め2人~3人の中、主要な機能は自分が開発。 ・要件定義~保守運用 ・バックエンド基盤開発 ・フロントエンド開発 ・インフラ構築 ・PRレビュー ・PM ・インターン採用・教育 # 成果 ・基盤機能のDB設計 ・Stripeによる決済基盤開発 (サブスク決済・単発決済) ・Stripe Connectによるマーケットプレイス化 (ユーザー ⇔ サブスクライン ⇔ クライアント) ・LINE関連機能の開発 ・サブスクに連動したEC・モバイルオーダーの機能実装 ・Fargateを使用したインフラ構成 ・github actions → Fargateへの自動デプロイ ・インターン向けの開発ドキュメント作成 ・retoolによるバックオフィス用タスクの自動化 # 使用技術 ## フロントエンド ・Typescript v4.43 ・Svelte v.3.48 ・Routify v.2.18 ・TailwindCSS v3.1.8 ・Zod v3.18 ・LIFF・LINEミニアプリ v2.19 ## バックエンド - NestJS v9.2 - TypeORM v.0.3.1 - LINE (MessagingAPI) - Stripe Connect (プラットフォームのマーケットプレイス化) - Jest ## 共通 - Stripe - Cognito (会員登録) ## インフラ - Amplify - Fargate - EC2 (Cron, Queue) - Code Deploy (EC2へのデプロイ) - github actions (Fargate・Amplifyへのデプロイ) # 頑張ったこと 前任CTOや他のエンジニアが退職となり、エンジニア経験6ヶ月で新規開発のリードエンジニアを任されることになった。 新規開発で、上位者のFBも貰えない状態だったが、トヨタ時代に得たソフトスキルと最小限の要件(MVP)を意識し、日々勉強・検証・実装を繰り返すことで、約1ヶ月でローンチ。 現在までサービスを安定稼働させることができている。 ●工夫点 ・日々分からないことをネット、本、動画、社外の人から情報を仕入れてすぐに実践した。 ・顧客に求められる必要最小要件を考え、その機能を仮説検証しながら繰り返すことで、1ヶ月でベータ版をリリースし店舗に導入、さらに3ヶ月で正式ローンチした。 ・仕組み化を意識し、開発ドキュメントやルールを策定した。

# プロジェクト概要 ユーザーがLINE上で美容クリニックの予約、管理画面(web)で予約管理できるアプリの受託開発。 Phase2から従事 # 役割 ・顧客折衝 ・PM ・要件定義~保守運用 ・バックエンド開発 ・フロントエンド開発 # 成果 ・マルチアカウント機能実装。cognitoを使用して、サブアカウントの作成・削除・一次URLの発行 ・Stripe導入による、月額料金決済・オプション決済。オプションに連動したサービス権限の設定を実装。 ・クライアントとのグループにエンジニアの代表として、要件定義や顧客対応し、タスクの割り振り ・勤怠管理アプリとLINE連携する設定手順をNotionで作成し共有 # 使用技術 ## フロントエンド ・Typescript v4.43 ・Svelte v.3.42 ・Routify v.218 ・Zod v3.9 ・LIFF v2.19 ## バックエンド - NestJS 7.5 - TypeORM v.0.2 - LINE (MessagingAPI) - Cognito (会員登録) ## 共通 - Cognito (会員登録) ## インフラ - Amplify - Fargate - EC2 (Cron, Queue) - Code Deploy (EC2へのデプロイ) - github actions (Fargate・Amplifyへのデプロイ) # 頑張ったこと 未経験からエンジニア転職し、初めて任されたプロジェクトから決済や会員登録機能など実装難易度が高かったが、実現したいことと実装内容を言語化し、認識合わせとFBをもらいながら自走した。 業後や休日に基本的なNestJS、TypeORMの技術について、仕事で分からないことをキャッチアップした。

# プロジェクト概要 ユーザーがLINE上で美容クリニックの予約、管理画面(web)で予約管理できるアプリの受託開発。 Phase2から従事 # 役割 ・顧客折衝 ・PM ・要件定義~保守運用 ・バックエンド開発 ・フロントエンド開発 ・レビュー # 成果 ・予約ステータス変更によるLINEメッセージ送信機能実装 ・クーポン機能実装 ・細かいバグをクライアントと共有できるシートを作成し共有 ・システム使用説明書をNotionで作成し共有 # 使用技術 ## フロントエンド ・Typescript v4.43 ・Svelte v.3.42 ・Routify v.218 ・Zod v3.9 ・LIFF v2.19 ## バックエンド - NestJS 7.5 - TypeORM v.0.2 - LINE (MessagingAPI) - Cognito (会員登録) ## 共通 - Cognito (会員登録) ## インフラ - Amplify - Fargate - EC2 (Cron, Queue) - Code Deploy (EC2へのデプロイ) - github actions (Fargate・Amplifyへのデプロイ) # 頑張ったこと 先方の要望がかなり細かく、週1回のMTGのたびにデザイン/機能面で細かい調整が必要だった。 細かいタスクでも、先方MTG → 自分がissue作成 → インターンへのタスク伝達が必要で工数がかかっていたので、非同期で不具合共有できるようにスプレッドシートを作成。 先方は要望が思いついたタイミングで、スプレッドシートにフォーマットに沿って記入 → インターンが自己判断でタスクを自走するルールにすることで、オペレーション工数を低減した。