| name | build-score |
| description | 「それ、本当に作る必要ある？」を判断するスキル。
漠然とした社内の開発リクエストを6つの質問で整理し、
BUILD/DEFER/KILL 判定付きブリーフに変換する。
/build-score で起動。
|
| allowed-tools | ["Bash","Read","Grep","Glob","Write","Edit","AskUserQuestion","WebSearch","Agent"] |
/build-score — 社内要件定義収束スキル
目的
漠然とした社内ツールリクエストを、固定6質問の収束シーケンスで
「BUILD / DEFER / KILL」判定付きの要件ブリーフに変換する。
これはドキュメント生成ツールではない。キルゲートである。
起動時の処理
build-score/knowledges/ 内のファイルをすべて読み込む（存在する場合）requirements/ 内の既存ブリーフを読み込み、類似リクエストの有無を確認する- モード選択に進む
モード選択
AskUserQuestion ツールを使って以下を質問する:
question: 「今日のヒアリングモードを選んでください。」
options:
- A) 単件モード — 1つのリクエストを深掘りする
- B) バッチモード — 複数のリクエストをまとめて登録する
バッチモード
バッチモードが選択された場合:
- 「登録したいリクエストをリストアップしてください。各リクエストにつき、タイトルと一行説明をお願いします。推奨上限は5件/回です。」と案内する
- ユーザーが入力したリクエストごとに、
status: draft の簡易ブリーフを requirements/ に作成する
- 簡易ブリーフには以下を含める:
- title（ユーザー入力）
- date（当日）
- requester（「未定」でも可）
- priority_score: 0（未評価）
- verdict: PENDING
- status: draft
- 本文: ユーザーが入力した一行説明のみ
- 全件作成後、一覧を表示する
- 「個別に深掘りしたいリクエストはありますか？」と質問する
- ある場合 → そのリクエストの既存draftブリーフを読み込み、単件モードのQ1から開始
- ない場合 → 終了
単件モード
以下の収束シーケンスを実行する。
収束シーケンス（固定6質問）
依頼者の発言やリクエスト内容がペーストされたら、以下の6質問を順番に進める。
明らかに回答済みの質問はスキップしてよい。
Q1: これがないと何が起きる？
「なくても困らない」ならKILL候補。
聴き方ガイド:
- 「もしこのツールが永遠に作られなかったとしたら、何が困りますか？」
- 相手の表情や間を観察する。即答できない場合はKILLの可能性が高い
次に進むシグナル: 具体的な業務影響が1つ以上出てきたら次へ
「わからない」への対応:
「先週、この作業がなかったとしたら何が変わりましたか？」と直近の体験に落とす
Q2: 今、誰が、どうやって回避している？
現状のワークアラウンドとそのコストを把握する。
聴き方ガイド:
- 「今、その作業は誰がやっていますか？」
- 「その人はどんな手順でやっていますか？」
- 「Excel? メール? 手作業?」と具体的なツール名を出すと答えやすい
次に進むシグナル: 現在の手順が具体的に描写されたら次へ
「わからない」への対応:
「特に何もしていない」場合は「その作業をスキップしたとき、誰が最初に困りますか？」と影響範囲を確認する
Q3: 誰が困っている？
影響範囲とソリューション規模の判定。
1人だけの問題ならスクリプトやSkillで済む可能性がある。
チーム・部門全体の問題ならWebシステム（ログイン、ユーザー管理、社内データ連携）が必要になる。
この回答がQ6（最小構成）でのアーキテクチャ判断に直結する。
聴き方ガイド:
- 「この問題で困っているのは、あなただけですか？ それともチーム全体ですか？」
- 「同じ作業をしている人は他に何人いますか？」
- 「その人たちも同じやり方でやっていますか？」
次に進むシグナル: 影響を受ける人数と、個人/チーム/部門のどのレベルかが明確になったら次へ
「わからない」への対応:
「あなた以外にこの作業をしている人を1人でも思い浮かべられますか？」と具体的に聞く。
それでも不明な場合は affected_users: unknown として記録する。
ソリューション規模の目安:
- 1人 → スクリプト / Claude Code Skill / CLI ツール
- 2-5人 → 共有スクリプト / 簡易Webツール
- 6人以上 or 複数部門 → Webシステム（認証・ユーザー管理・データ連携）
Q4: 月に何時間かかっている？
ROI定量化の基盤。
聴き方ガイド:
- 「先週1週間で、この作業に何回関わりましたか？」
- 「1回あたり何分くらいですか？」
- 週の数字が出たら×4で月間を推定する
次に進むシグナル: 月間時間の推定値が出たら次へ
「わからない」への対応:
「先週1週間で、この作業に何回関わりましたか？1回あたり何分くらい？」と分解して推定する。
それでも推定不能な場合は monthly_hours_current: unknown とし、priority_scoreを1段階下げる。
Q5: 3ヶ月何もしなかったら？
緊急度の判定。
聴き方ガイド:
- 「もし3ヶ月間このままだったら、何が起きますか？」
- 「誰かが辞める？ クレームが来る？ 何も変わらない？」と選択肢を出す
次に進むシグナル: 影響の有無と程度が明確になったら次へ
「わからない」への対応:
選択肢を提示する: 「A) 業務に支障が出る B) 不便だが回せる C) 特に変わらない」
Q6: 最小構成は何？
スコープの収束。「これだけあれば使える」を強制する。
聴き方ガイド:
- 「全部は作れません。1つだけ機能を選ぶとしたら？」
- 「それがあれば、明日から使いますか？」
- 3つ以上出てきたら「その中で一番効果が大きいのは？」と絞る
次に進むシグナル: MVP機能が最大3つに絞られたら次へ
「わからない」への対応:
「今一番時間がかかっている作業はどれですか？それを自動化するだけでも使いますか？」
過去ブリーフ参照
Q1の回答後、requirements/ 内の既存ブリーフのタイトルと比較し、
類似するリクエストがあれば提示する:
過去に似たリクエストがあります:
- {タイトル} (verdict: {BUILD/DEFER/KILL}, {日付})
重複の可能性がありますが、続けますか？
レビューフェーズ（Q6完了後、ブリーフ出力前に必ず実施）
6質問で収束した内容に対して、3つのレビューを順番に実施する。
このフェーズを経ずにブリーフを出力してはならない。
Step 1: 既存サービス・ツール調査（Landscape Awareness）
プライバシーゲート
検索前に AskUserQuestion で確認する:
question: 「既存サービスや代替手段を調べるために、一般的なカテゴリ用語でWeb検索します。社内の具体的なプロジェクト名や独自の業務内容は検索に含めません。よろしいですか？」
options:
- A) 検索してください
- B) スキップ — 検索なしで進める
B の場合: Step 1 をスキップし、knowledges/ の情報のみで判断して Step 2 へ。
検索キーワード
ユーザーの具体的な業務内容ではなく、一般化されたカテゴリ用語で検索する。
例: 「経理部の請求書転記自動化」ではなく「invoice automation tool」
WebSearch ツールで以下を検索:
- 「{一般化したカテゴリ} existing solutions」
- 「{一般化したカテゴリ} open source alternatives」
- 「best {カテゴリ} {現在の年}」
上位2-3件の結果を読む。
3層分析
検索結果をもとに3層で分析する:
- Layer 1（常識）: この分野で誰もが知っていること。定番のツールやアプローチ
- Layer 2（最新動向）: 検索結果が示す現在の選択肢と議論
- Layer 3（独自の洞察）: Q1-Q6のヒアリングで得た情報を踏まえると、一般的なアプローチがこの社内環境に合わない理由はあるか？
Eurekaチェック
Layer 3 で本当のインサイトが見つかった場合:
"EUREKA: 一般的には{アプローチ}が定番だが、{ヒアリングの証拠}を踏まえると、ここでは{別のアプローチ}が正しい。なぜなら{理由}。"
見つからなければ:
"既存のアプローチは妥当です。それをベースに進めます。"
判定
3層分析の結果から判定する:
- 既存サービスで完全に代替可能 → verdict を KILL に変更。「{サービス名} で実現可能です」と報告
- 部分的に代替可能 → MVP Scope から代替可能な機能を除外。残りが価値を持つか再評価
- 代替なし → そのまま続行
build-score/knowledges/existing-tools.md に記載された社内既存ツールの組み合わせで
解決できないかも確認する。
結果をユーザーに提示する:
既存サービス調査結果:
Layer 1（常識）: {この分野の定番}
Layer 2（最新動向）: {検索で見つかったサービス・ツール}
Layer 3（独自の洞察）: {社内環境を踏まえた判断}
判定: {代替可能 / 部分的に代替 / 代替なし}
{Eurekaがあれば記載}
続行しますか？
Step 2: 実装規模の最小化チェック
build-score/rules/solution-scale.md に定義された優先順位に従い、最も軽量な手段を推奨する。
検討前に必ず build-score/rules/solution-scale.md を読み込み、そのルールに従うこと。
Q3（影響人数）と Q6（最小構成）の回答をもとに、上位の手段で解決できるなら下位の手段を選ばない。
デフォルトの優先順位（カスタマイズされていない場合）:
| 優先度 | 手段 | 適用条件 | 例 |
|---|
| 1 | 既存ツールの設定変更 | 設定だけで解決する場合 | Google Formsの通知設定、Slackワークフロー |
| 2 | Claude Code Skill / スラッシュコマンド | エンジニアが使う定型作業 | /build-score のような対話型ワークフロー |
| 3 | シェルスクリプト / claude -p スクリプト | 定期実行やバッチ処理 | cron + スクリプトで日次レポート生成 |
| 4 | 既存スキルの組み合わせ | 複数の既存ツールの連携 | GAS + Slack Webhook |
| 5 | 簡易Webツール（認証なし） | 2-5人が使う簡単な画面 | 静的HTML + API |
| 6 | Webシステム（認証・DB付き） | 6人以上、複数部門、データ永続化が必要 | フルスタックアプリ |
組織固有のルールが build-score/rules/solution-scale.md に定義されている場合、そちらが優先される。
検討結果をユーザーに提示する:
実装規模チェック:
- 推奨手段: {手段}
- 理由: {なぜこの規模で十分か}
- もし上位の手段で不十分な場合: {何が足りないか}
ブリーフの solution_scale にこの結果を反映する。
Step 3: 批判的レビュー（CEO/経営視点）
チェックリストではなく、思考の枠組みでレビューする。
以下の3段階を順番に実施し、最後にセカンドオピニオンを取る。
3A. 前提チャレンジ（Premise Challenge）
ヒアリング結果から導かれた前提を明示し、それぞれを疑う:
-
これは正しい問題か？
別のフレーミングで劇的にシンプルな解決策が出ないか？
例: 「請求書の自動生成が必要」→ 本当の問題は「転記ミスの防止」ではないか？
-
これは代理問題ではないか？
依頼者が言う問題と、実際のビジネス成果は一致しているか？
「自分の仕事を楽にしたい」と「組織の課題を解決したい」は違う。
-
何もしなかったらどうなるか？
Q5（3ヶ月放置）の回答を批判的に再検証する。
本当の痛みか、仮説上の痛みか。月間時間の自己申告は過大になりがち。
前提を明確な文として出力する:
前提:
1. {文} — 同意 / 異議あり？
2. {文} — 同意 / 異議あり？
3. {文} — 同意 / 異議あり？
AskUserQuestion で確認する。異議があれば理解を修正してやり直す。
3B. Dream State Mapping
12ヶ月後の理想状態を描き、このリクエストがそこに向かうか離れるかを評価する:
現在の状態 このリクエスト 12ヶ月後の理想
{現在の業務プロセス} → {提案されたMVP} → {組織としてのあるべき姿}
評価観点:
- このMVPは12ヶ月後の理想に向かう一歩か、それとも一時的なパッチか？
- 作ったものが使われ続けるか？「あったら便利」と「毎日使う」の違い
- 導入後の運用は？ 誰がメンテするか、誰が教育するか
3C. 反転思考 + リスク評価
反転思考（Inversion）: 「どうすれば成功するか」ではなく「何がこのプロジェクトを失敗させるか」を問う。
失敗シナリオを具体的に列挙する:
| 失敗シナリオ | 確率 | 影響度 | 対策 |
|---|
| 作ったが使われない | ? | ? | ? |
| 依頼者が異動/退職 | ? | ? | ? |
| 3ヶ月後に要件が変わる | ? | ? | ? |
| 運用コストが削減効果を上回る | ? | ? | ? |
タイミング判定: 今やるべきか？
- 他の進行中プロジェクトとのリソース競合
- 3ヶ月後に状況が変わる可能性（組織変更、ツール導入等）
requirements/ 内の他ブリーフと優先度を比較
引き算のフォーカス: Step 2 で推奨した手段で本当に十分か？
もっと小さく始められないか？ 過剰な解決策になっていないか？
3D. セカンドオピニオン（Outside Voice）
AskUserQuestion で確認する:
question: 「レビューが完了しました。独立した視点からの批判的レビュー（セカンドオピニオン）を取りますか？ ヒアリング結果の要約を別のAIに渡し、論理的な穴や見落としを指摘してもらいます。」
options:
- A) セカンドオピニオンを取る（推奨）
- B) スキップして結果に進む
B の場合: スキップしてレビュー結果の提示へ。
A の場合: Agent ツールで独立したサブエージェントを起動する。
サブエージェントへのプロンプト:
「あなたは社内ツール開発の投資判断をレビューする独立したアドバイザーです。
以下のヒアリング結果を批判的にレビューしてください。
{Q1-Q6の回答要約}
{Step 1の既存サービス調査結果}
{Step 2の実装規模チェック結果}
{3A-3Cのレビュー結果}
以下を回答してください:
- この要件の最も強い解釈は何か？（Steelman）
- 見落とされている最大のリスクは何か？
- 前提のうち、間違っていると思うものは？ その根拠は？
- もしあなたが意思決定者なら、BUILD / DEFER / KILL のどれを選ぶか？ なぜ？
直接的に、簡潔に答えてください。」
サブエージェントの結果を提示する:
セカンドオピニオン:
{サブエージェントの出力をそのまま表示}
セカンドオピニオンとレビュー結果が異なる場合、両方の見解を提示し、
AskUserQuestion でユーザーに判断を委ねる:
question: 「レビューでは{X}と判断しましたが、セカンドオピニオンは{Y}と指摘しています。どちらを採用しますか？」
options:
- A) セカンドオピニオンの指摘を反映する
- B) 現在のレビュー結果を維持する
ユーザー主権: セカンドオピニオンの提案は情報であり、自動的にverdictに反映しない。
各提案を個別にAskUserQuestionで確認し、ユーザーが決定する。
レビュー結果の提示
3A-3D の結果を統合して提示する:
批判的レビュー結果:
前提チャレンジ: {合意された前提 / 修正された前提}
Dream State: {12ヶ月後の理想との整合性}
リスク: {主要な失敗シナリオと対策}
セカンドオピニオン: {実施した場合の要約 / スキップ}
総合判定: {verdict の変更提案があれば}
verdict を変更する場合は AskUserQuestion でユーザーに確認を取る。
ROI計算
レビューフェーズ完了後、ブリーフ出力前に以下を質問する:
この業務の担当者の想定時給はいくらですか？（例: 3,000円/時）
未入力の場合はデフォルト3,000円/時で計算します。
計算式:
- 月間削減時間（1人あたり） = monthly_hours_current - monthly_hours_projected
- 月間削減時間（合計） = 1人あたり削減時間 × affected_users
- 月間削減コスト = 合計削減時間 × 時給
- 年間削減コスト = 月間削減コスト × 12
affected_users が unknown の場合は1人として計算する。
工数見積り
ROI計算の後、build-score/rules/effort-estimate.md に定義された基準で開発工数を1〜5段階で見積もる。
ブリーフ出力前に必ず build-score/rules/effort-estimate.md を読み込み、そのルールに従うこと。
以下の4軸を評価し、総合して工数レベルを算出する:
- 機能の技術的難易度 — CRUD か複雑ロジックか、外部API連携の数
- 利用ツール・構築ツールの難易度 — チームの習熟度、学習コスト
- 要件定義の難易度 — 利用人数、ステークホルダー数、部門間調整
- 運用・インフラの複雑さ — デプロイ環境、監視、メンテナンス
各軸の評価根拠をブリーフの Effort Estimate セクションに記載する。
デフォルトの工数レベル定義（カスタマイズされていない場合）:
| Level | 目安期間 | 条件 |
|---|
| 1 | 半日〜1日 | 既存ツールの設定変更、単一スクリプト。技術的な不確実性がほぼない |
| 2 | 2〜3日 | 複数スクリプトの組み合わせ、API連携1つ。使い慣れたツールで完結 |
| 3 | 1〜2週間 | 簡易Webツール、外部API連携2つ以上。設計判断が必要 |
| 4 | 2〜4週間 | Webシステム（認証・DB付き）、テスト・デプロイ環境の構築が必要 |
| 5 | 1ヶ月以上 | 複数部門が使うシステム、複雑な権限管理、段階的リリースが必要 |
組織固有のルールが build-score/rules/effort-estimate.md に定義されている場合、そちらが優先される。
Priority Score ルブリック
5質問の回答をもとに、build-score/rules/priority-score.md に定義されたルブリックでスコアを算出する。
ブリーフ出力前に必ず build-score/rules/priority-score.md を読み込み、そのルールに従うこと。
デフォルトのルブリック（カスタマイズされていない場合）:
| Score | Verdict | 条件 |
|---|
| 5 | BUILD | 月間20h以上 + ワークアラウンドが苦痛 + 3ヶ月放置で業務に支障 |
| 4 | BUILD | 月間10-19h + ワークアラウンドあり + 最小構成が明確 |
| 3 | DEFER | 月間5-9h + ワークアラウンドで当面回せる |
| 2 | DEFER | 月間5h未満 or 3ヶ月放置しても影響なし |
| 1 | KILL | 「なくても困らない」or 既存ツールで代替可能 |
組織固有のルールが build-score/rules/priority-score.md に定義されている場合、そちらが優先される。
ブリーフ出力
build-score/templates/requirement.md のテンプレートに従い、
requirements/ ディレクトリに以下のファイル名で出力する:
requirements/{date}-{title-slug}.md
例: requirements/2026-04-08-invoice-automation.md
出力後、内容をユーザーに表示し、確認を求める:
ブリーフを作成しました。内容を確認してください。
修正が必要な箇所はありますか？
修正がなければ status: draft → status: reviewed に更新する。
DEFER案件の再評価
DEFER判定のブリーフは status: deferred となる。
次回 /build-score 実行時に、3ヶ月以上前のDEFER案件があれば自動的に通知する:
以下のDEFER案件が3ヶ月以上経過しています。再評価しますか？
再評価する場合、前回のブリーフを読み込み、Q1-Q6の差分のみ確認する。
knowledges/ の活用
build-score/knowledges/ 内のファイルは、ヒアリング中の判断に利用する:
- security-policy.md: セキュリティ上実現不可能な要件を早期に検出する
- existing-tools.md: 既存ツールで代替可能な場合にKILL判定の根拠にする
- constraints.md: 技術的制約を考慮してMVPスコープを現実的にする
各ファイルが空または存在しない場合は、その制約なしで進める。
出力例
---
title: 請求書自動生成ツール
date: 2026-04-08
requester: 経理部 田中
priority_score: 4
affected_users: 3
solution_scale: simple_web
monthly_hours_current: 15
monthly_hours_projected: 3
effort_level: 3
verdict: BUILD
status: reviewed
---
## Problem Statement
毎月の請求書作成に経理部が15時間費やしている。手作業でExcelテンプレートに転記しており、転記ミスが月2-3件発生。
## Current Workaround
Excelテンプレートに手動転記。ダブルチェックで2名体制。
## ROI Estimate
- 月間削減: 12時間
- 時給: 3,000円
- 月間削減コスト: 36,000円
- 年間削減コスト: 432,000円
## MVP Scope
- 売上データからの自動転記
- PDF出力
- 月次バッチ実行
## Effort Estimate
- 工数レベル: 3 / 5（1〜2週間）
### 根拠
| 評価軸 | 評価 | 理由 |
|--------|------|------|
| 機能の技術的難易度 | 中 | 売上データの取得・変換・PDF生成。外部API連携は売上システムの1つ |
| 利用ツール・構築ツールの難易度 | 低 | Node.js + PDFライブラリで実現可能。チームが習熟済み |
| 要件定義の難易度 | 中 | 3人が利用。経理部内で請求書フォーマットのすり合わせが必要 |
| 運用・インフラの複雑さ | 低 | 月次バッチ実行のみ。cronまたはGitHub Actionsで十分 |
## Critical Review
### 前提チャレンジ
- 「請求書の自動生成が必要」→ 本当の問題は「転記ミスの防止」ではないか？ → 依頼者確認済み、時間削減が主目的
- 自己申告の月間15時間は妥当か → ダブルチェック体制込みで整合性あり
### リスク評価
| 失敗シナリオ | 確率 | 影響度 | 対策 |
|-------------|------|--------|------|
| 作ったが使われない | 低 | 高 | 既に苦痛なワークアラウンドがあり利用動機は強い |
| 売上データのフォーマット変更 | 中 | 中 | 変換ロジックを分離して対応 |
### セカンドオピニオン
実施済み。転記ミス防止の観点からもBUILD妥当との判断。
## Verdict: BUILD
月間15時間の削減効果。ワークアラウンド（手動転記）が苦痛で転記ミスも発生。
3ヶ月放置すると繁忙期に対応できないリスクあり。最小構成が明確。
## Raw Notes
（ヒアリング時のメモをここに記録）
