最終更新: 2026/06/22 18:56
commonid: rq-033-hiring-strategy-prompttype: promptstatus: active
pagejtbd: JTBD-002rq: RQ-033

MAS-331 相談プロンプト: 開発を 1 名に委任する場合の人材像

用途: Gemini 2.5 Pro（aistudio.google.com）または Gemini Deep Research に投入するための完成版プロンプト。以下「---」以降をそのままコピペして使用する。

作成日: 2026-04-22 Generated from: MAS-331 メタプロンプト

あなたは日本のスタートアップ・中小企業向けの CTO 採用アドバイザーです。本相談では、プロダクト現状を示す事実抜粋 5 パッケージを前提に、開発を 1 名に委任する場合の最適人材像・採用戦略・契約形態・引き継ぎ方法・リスクと対策を構造化して提案してください。

背景と相談の目的

bizlp-gas-accounting は、代表者 1 名体制の法人（bizlp、設立初年度・資本金 300 万円）が開発・運用する管理会計 ERP です。Google Apps Script（GAS）+ Google Workspace + Vertex AI（Gemini + Claude）を基盤とし、将来的に GCP 移行・SaaS 展開を見据えます。

代表者は現在、年間売上の 100% をクライアントワーク（受託業務・顧客貸与 PC で実施）で稼ぎながら、空き時間で本プロダクトを R&D 投資として自社開発しています。Claude Code + Gemini Pro メタプロンプトパイプラインによる AI 支援開発で現状は少人数運用が成立していますが、代表者自身を経営・顧客折衝・製品戦略・R&D 税制対応に専念させるため、実装作業を 1 名に委任したいと考えています。

しかしプロダクトの性質上、単純な Web エンジニアでは務まらない可能性が高く、人材像の定義自体が非自明です。以下 5 パッケージの事実をもとに、外部視点で構造化された意見を提示してください。

パッケージ 1: プロジェクト概要

本事業の目的（docs/index.md より抜粋）:

本事業は、管理会計 ERP の開発・運用を通じて、2 つの目的を同時に追求する。

目的 1: 経営判断の自動化と可視化

中小企業の経営者が「勘と経験」ではなくデータに基づいて意思決定できる管理会計基盤を提供する。月次決算の自動化、PJ 別損益の可視化、キャッシュフロー予測により、経営判断のスピードと精度を向上させる。

受託開発＋自社プロダクトのハイブリッド型スタートアップ（従業員 10 名未満）が直面する管理会計上の課題を、役割別に整理する。中小企業の 75% がいまだスプレッドシートで予算管理を行っており（Gartner 調査）、本システムはその脱却を目指す。

事業展開戦略（docs/prd.md より抜粋）:

Phase 1〜4 は GAS プラットフォーム上で完結する機能開発であり、AI 支援（Claude Code）により当初計画の 50-65% の期間で完了する見込みとなっている。一方、GCP 移行（Phase 5）はインフラ構築・認証設定・セキュリティ対策など、コンソール操作や外部サービス連携が中心となるため、同等の速度は見込めない。

この状況を踏まえ、GCP 移行前に GAS 版で簡易 SaaS 化し、PMF 検証を行う段階的アプローチを検討する。

ターゲット: 創業〜数年の小規模法人（月次仕訳 100 件以下）、税理士が freee/MF で記帳しつつ、管理会計・FP&A だけ自前で持ちたい層

パッケージ 2: 技術スタックと開発フロー

ブランチ運用・デプロイ（CLAUDE.md より抜粋）:

main — 本番ブランチ（PR 経由でマージ。直接 push 禁止）

GitHub Actions (deploy.yml) は main push 時に自動デプロイ。docs/** *.md はトリガー対象外

コード変更時の順序: git commit → npm run push:dev → GAS 動作確認 → git push → PR → main マージ

動作未確認のコードを GitHub に push しない。

ファイル番号体系（CLAUDE.md より抜粋）:

GAS はフルパスのアルファベット順にロードされる。3 桁番号プレフィックスで読込順とレイヤーを制御する。

  • 百の位 = レイヤー（ディレクトリと一致）
  • 十・一の位 = ディレクトリ内の順序
ディレクトリレイヤー
000_infra/共通基盤（Env / Constants / Contracts / Utils）
100_config/システム設定（101_sys_config.js）
200_data/データアクセス層（Repository パターン）
300_ui/UI / トリガー
400_domain/ドメインサービス（RPA / 仕訳エンジン / PJ 原価）
500_import/外部データ取込（CC / 銀行 / 領収書 OCR）
600_report/データマート / レポーティング
800_ops/運用・マイグレーション

コーディング規約（CLAUDE.md より抜粋）:

  • 列参照はヘッダー名ベース（indexOf / buildHeaderIndex_）。列番号ハードコード禁止
  • 有効フラグ=FALSE の行は全処理でスキップ
  • 科目マスタ（11_mst_account）に未登録の科目名はエラー。キーワード推測による自動分類禁止
  • 仕訳振替の判定は === "仕訳振替" の完全一致

AI 支援開発の特徴:

  • scripts/1_generate_prompts_gemini.js: Gemini 2.5 Pro が failure_patterns.md / dev_spec_prompt_template.md / コアコード 4 ファイルを読み込んで、Claude Code 向けの設計指示プロンプトを自動生成。Claude Sonnet が実行者目線で添削
  • scripts/2_run_writers.sh: 生成された設計指示プロンプトを Claude Code に順次投入して仕様書を量産
  • Claude Code による実装自体は、14 セクション仕様書テンプレート + failure_patterns #1-#27 の反映を義務化

パッケージ 3: 5 年ロードマップ

Phase 別実装計画（docs/_internal/TODO_future.md §2 より抜粋）:

フェーズ主テーマ状態
Phase 1基盤構築 + 手入力削減 + 監査強化約半分完了、残 P1 20 件程度
Phase 1.5自動入力パイプライン（即効）完了 5 件、残 6 件
Phase 2計画強化・実務要件 + サイドバー SPA 化60+ 件、FP&A 系中心
Phase 3予測高度化・GCP 移行基盤 + Web App 中間段階23 件、GCP 移行・商用化準備
Phase 4運用改善・SaaS 運用基盤12 件、外部監査対応
Phase 5GCP 移行・SaaS 化 + データ主権基盤（TEE/DP/P マーク）データ主権アーキテクチャで差別化

ADR-0009 活動領域分離戦略（docs/adr/0009-separation-strategy.md より抜粋）:

フェーズ期間主な状態分離レベル
Phase 1現在（2026-04〜）D（R&D）主、99% dev 利用物理分離なし、運用規律のみ
Phase 2bizlp 自社本格運用開始B 本格稼働、dev → prod 移行現行の dev/prod 分離で対応
Phase 3初 PoC / 商用化時E 並行開始、商用テナント新設別 GCP プロジェクト、顧客データ物理分離
Phase 4成熟期（IPO 準備 / SOC 2 取得）フル分離R&D サンドボックス分離、ゼロトラスト構成

代表者の活動領域（同 ADR より）:

  • A: 法人運営（bizlp 社内業務）
  • B: 自社会計システムの運用
  • C: プロダクト開発（コード・仕様書）
  • D: R&D（新機能・新技術実験）
  • E: 将来の商用プロダクト運用
  • F: クライアントワーク（受託業務、bizlp の主力収益事業）

パッケージ 4: 複雑度の肌感（具体例 3 件 + 運用落とし穴 1 件）

MAS-010 中長期（5 カ年）財務モデリング（docs/dev/dev_mas-010_financial_modeling.md より抜粋）:

過去 12〜36 ヶ月の実績（42_trn_journal の仕訳データ + 11_mst_account の固変区分）から成長率・費用構造を自動抽出し、向こう 60 ヶ月（5 年）分の月次 P/L ベースライン予測を一括生成する。MVP は P/L のみに集中し、B/S・CF 予測は MAS-018 完了後に段階拡張する。

売上 CAGR + 季節性指数 + 変動費率 + 固定費月平均 + Constants.TAX_RATES 累進税率を組み合わせて計算。

MAS-147 請求書 PDF 自動起票（docs/dev/dev_mas-147_invoice_ocr_auto_posting.md より抜粋）:

顧客から受領した請求書 PDF を OCR + AI でパースし、既存の予算マスタ（20 番台タブ）と突合して 32 タブに自動起票する。責務分離:

  • Document AI（Fact 抽出）: T 番号・金額・日付・明細行座標など、税法上 1 円のブレも許されない確定値を機械学習確率モデル（0.0-1.0）で抽出
  • Gemini（Reasoning 推論）: 真のベンダー推定・請求タイプ判定・請求構造判定などの意味的推論のみ

マッチングは多段 Pass 0〜6（T 番号優先 → 金額一致 → Subset Sum 分割マッチ → Gemini 曖昧検索）、複合確信度スコア + 即死ルール。

MAS-018 財務 3 表完全連動モデリング（docs/dev/dev_mas-018_financial_statement_linkage.md より抜粋）:

CAPEX（設備投資・借入）を代表的な入力とし、1 レコードの入力が P/L（減価償却費・支払利息）、B/S（固定資産・借入残高）、C/F（元金返済・投資キャッシュアウト）の 3 表すべてに矛盾なく反映される仕組みを整える。

failure_patterns #26（運用落とし穴の実例、2026-04-20）（docs/_internal/failure_patterns.md より抜粋）:

appsscript.json の oauthScopes を部分宣言したことで、GAS のスコープ自動検出が完全オフになり、既存機能（SpreadsheetApp / DriveApp / MailApp / Utils.auditLog 等）が一斉に "Specified permissions are not sufficient" で動作不能に。

根本原因: 「明示宣言 = 自動検出完全オフ」という GAS の排他仕様。部分宣言すると自動検出されていた spreadsheets / drive / mail / ui 等が全て消失する。

対策: Advanced Service で済むスコープは enabledAdvancedServices に宣言し自動付与。手動宣言が必要な場合は GAS エディタのプロジェクト設定から既存スコープを完全列挙してから追加。

補足: failure_patterns は現在 #1〜#27 まで蓄積。仕様書作成時に該当パターンへの対策をインライン引用することを義務化している。

パッケージ 5: 代表者の状況と制約

労働時間の配分（docs/adr/0009-separation-strategy.md より抜粋）:

代表者の労働時間は、メインがクライアントワーク（顧客貸与 PC で実施、bizlp アカウントではログインしない）で、空き時間で bizlp-gas-accounting を R&D している構造

bizlp-gas-accounting は将来の SaaS プロダクト化を見据えた自己投資的な試験研究活動

R&D 税制・役員報酬按分の前提:

bizlp の売上 100% がクライアントワーク（F）である以上、F 時間の正確な記録なくして R&D 比率・役員報酬按分は主張できない。研究開発税制の役員報酬按分における唯一かつ必須のエビデンス

予算と契約の想定:

  • 正社員: 月額 35-45 万 + 社保負担（社労士費用 月 3-5 万）
  • 業務委託: 月額 40-60 万（6-12 ヶ月契約、成果物ベース）
  • インターン: 時給 2000-2500 円（週 20h、学生前提）
  • 入社想定時期: 2026-10（180 日後、D-180 ロードマップあり）
  • 採用ルート想定: Findy / Forkwell（成功報酬 30-35%）+ Wantedly 直接求人の並行運用
  • PC: 会社支給（MacBook + Google Workspace Endpoint Management 想定）

既整備のオンボーディング基盤（案件 MAS-223〜MAS-230 で仕様書完了）:

  • Jr オンボーディングドキュメント（1 日環境構築 + 1 週目 PR）
  • GitHub Actions CI パイプライン + Branch protection + CODEOWNERS
  • Good-first-issue セレクション（10-15 件キュレーション）
  • コードレビュー運用ルール（ADR-0010 候補、SLA 24h/48h）
  • 業務委託契約書テンプレ + 社労士連携窓口
  • Jr 特権分離（GAS / GCP / Workspace 最小権限設計）

相談したいこと

以下 7 項目について、順番に論じてください。代表者が意思決定に使える定量性（レンジ・希少度・費用感）と定性分析（強み・弱み・代替案）を両方含めてください。

1. 最適な人材像の 3 候補を提示してほしい

プロファイル A / B / C として、それぞれ以下を記載:

  • 職歴・スキルセット（必須 / 歓迎を分離）
  • 経験年数レンジ
  • 志向性（フロント寄り / バックエンド寄り / 会計知識 / SaaS スタートアップ経験 等）
  • 想定年収（正社員）or 業務委託月額
  • 日本市場での希少性・採用難易度（★1-5）
  • 本プロダクトでの強み / 弱み
  • 推奨度（★1-5）

2. 各プロファイルのリスクと対策

以下のケース別に、代表者側が取るべき具体的打ち手を提案してください:

  • 会計知識が薄い場合
  • GAS 実務経験がない場合
  • 多年契約（2 年以上）を結べない場合
  • ドキュメント読解に時間がかかる場合
  • AI 支援開発（Claude Code）に不慣れな場合

3. 契約形態の推奨

  • 正社員 / 業務委託 / フラクショナル CTO / コントラクタの使い分け
  • 試用期間 / 段階雇用 / RSU（ストックオプション）の活用可否
  • R&D 税制の役員報酬按分への影響（雇用形態で優遇計算が変わるため特に重要）
  • 税務上の留意点（業務委託 vs 給与所得の線引き、偽装請負リスク）

4. 引き継ぎ戦略

  • 最初の 1 ヶ月 / 3 ヶ月 / 6 ヶ月で達成すべきマイルストーン
  • ドキュメント起点の教育 vs ペアプロ起点の教育のバランス
  • 代表者の残関与度合い（週何時間のレビュー・承認に絞れるか）
  • ドキュメント資産の活用方法（仕様書 46 件 / ADR 9 件 / failure_patterns 27 件をどう渡すか）

5. 1 人雇用 vs 分業の比較

  • 「全部やれる 1 人」vs「会計知識のある業務委託 0.5 人 + フロント React/TS 0.5 人 = 2 人体制」の得失
  • 代表者が「手放す領域」の優先順位（バックエンド / フロント / 会計ロジック / インフラ の どれを最後まで保持するか）
  • 3 人体制（MAS-230 の想定）との関係性

6. 採用ルートの具体提案

  • 日本市場で上記プロファイルにリーチできる媒体・エージェント・コミュニティ
  • カジュアル面談 → 技術課題 → 契約 の標準フローと各段階の要点
  • 代表者の時間予算（週 2-3 時間を採用活動に使う想定）での現実的な流量
  • 「GAS + 会計 + AI 支援開発」というニッチな要件を言語化して求人票に書く際の具体文言

7. 半年以内に見つからない場合の代替プラン

  • 継続 AI 支援での独力運用
  • 一部外注（GAS → React 移行のみ委託、会計ロジックのみ委託等）
  • スコープ絞り込み（Phase 5 商用化を延期し当面は自社利用に留める）
  • 「採用をやらない」という選択肢の評価

出力フォーマット

  • 各セクションは見出し付き、箇条書き中心で 400-600 字程度
  • 数値・レンジは具体的に（「経験 5-7 年」「月額 50-70 万」等）
  • 推奨度は ★1-5 または 推奨/非推奨 で明示
  • 最終セクションで「代表者への提言サマリー（5 行以内）」を含めること

以上です。構造化された回答をお願いします。