Menú
要求分析をして定量的に判断できるようにするスキル。 漠然とした社内の開発リクエストを6つの質問で整理し、 BUILD/DEFER/KILL 判定付きブリーフに変換する。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | build-score |
| description | 要求分析をして定量的に判断できるようにするスキル。 漠然とした社内の開発リクエストを6つの質問で整理し、 BUILD/DEFER/KILL 判定付きブリーフに変換する。 |
| allowed-tools | ["Bash","Read","Grep","Glob","Write","Edit","AskUserQuestion","WebSearch","Agent"] |
漠然とした社内ツールリクエストを、固定6質問の収束シーケンスで 「BUILD / DEFER / KILL」判定付きの要件ブリーフに変換する。
これはドキュメント生成ツールではない。キルゲートである。
build-score/knowledges/ 内のファイルをすべて読み込む（存在する場合）requirements/ 内の既存ブリーフを読み込み、類似リクエストの有無を確認するAskUserQuestion ツールを使って以下を質問する:
question: 「今日のヒアリングモードを選んでください。」 options:
バッチモードが選択された場合:
status: draft の簡易ブリーフを requirements/ に作成する以下の収束シーケンスを実行する。
依頼者の発言やリクエスト内容がペーストされたら、以下の6質問を順番に進める。 明らかに回答済みの質問はスキップしてよい。
「なくても困らない」ならKILL候補。
聴き方ガイド:
次に進むシグナル: 具体的な業務影響が1つ以上出てきたら次へ
「わからない」への対応: 「先週、この作業がなかったとしたら何が変わりましたか？」と直近の体験に落とす
現状のワークアラウンドとそのコストを把握する。
聴き方ガイド:
次に進むシグナル: 現在の手順が具体的に描写されたら次へ
「わからない」への対応: 「特に何もしていない」場合は「その作業をスキップしたとき、誰が最初に困りますか？」と影響範囲を確認する
影響範囲とソリューション規模の判定。 1人だけの問題ならスクリプトやSkillで済む可能性がある。 チーム・部門全体の問題ならWebシステム（ログイン、ユーザー管理、社内データ連携）が必要になる。 この回答がQ6（最小構成）でのアーキテクチャ判断に直結する。
聴き方ガイド:
次に進むシグナル: 影響を受ける人数と、個人/チーム/部門のどのレベルかが明確になったら次へ
「わからない」への対応:
「あなた以外にこの作業をしている人を1人でも思い浮かべられますか？」と具体的に聞く。
それでも不明な場合は affected_users: unknown として記録する。
ソリューション規模の目安:
ROI定量化の基盤。
聴き方ガイド:
次に進むシグナル: 月間時間の推定値が出たら次へ
「わからない」への対応:
「先週1週間で、この作業に何回関わりましたか？1回あたり何分くらい？」と分解して推定する。
それでも推定不能な場合は monthly_hours_current: unknown とし、priority_scoreを1段階下げる。
緊急度の判定。
聴き方ガイド:
次に進むシグナル: 影響の有無と程度が明確になったら次へ
「わからない」への対応: 選択肢を提示する: 「A) 業務に支障が出る B) 不便だが回せる C) 特に変わらない」
スコープの収束。「これだけあれば使える」を強制する。
聴き方ガイド:
次に進むシグナル: MVP機能が最大3つに絞られたら次へ
「わからない」への対応: 「今一番時間がかかっている作業はどれですか？それを自動化するだけでも使いますか？」
Q1の回答後、requirements/ 内の既存ブリーフのタイトルと比較し、
類似するリクエストがあれば提示する:
過去に似たリクエストがあります:
- {タイトル} (verdict: {BUILD/DEFER/KILL}, {日付})
重複の可能性がありますが、続けますか？
6質問で収束した内容に対して、3つのレビューを順番に実施する。 このフェーズを経ずにブリーフを出力してはならない。
検索前に AskUserQuestion で確認する:
question: 「既存サービスや代替手段を調べるために、一般的なカテゴリ用語でWeb検索します。社内の具体的なプロジェクト名や独自の業務内容は検索に含めません。よろしいですか？」 options:
B の場合: Step 1 をスキップし、knowledges/ の情報のみで判断して Step 2 へ。
ユーザーの具体的な業務内容ではなく、一般化されたカテゴリ用語で検索する。 例: 「経理部の請求書転記自動化」ではなく「invoice automation tool」
WebSearch ツールで以下を検索:
上位2-3件の結果を読む。
検索結果をもとに3層で分析する:
Layer 3 で本当のインサイトが見つかった場合:
"EUREKA: 一般的には{アプローチ}が定番だが、{ヒアリングの証拠}を踏まえると、ここでは{別のアプローチ}が正しい。なぜなら{理由}。"
見つからなければ:
"既存のアプローチは妥当です。それをベースに進めます。"
3層分析の結果から判定する:
build-score/knowledges/existing-tools.md に記載された社内既存ツールの組み合わせで
解決できないかも確認する。
結果をユーザーに提示する:
既存サービス調査結果:
Layer 1（常識）: {この分野の定番} Layer 2（最新動向）: {検索で見つかったサービス・ツール} Layer 3（独自の洞察）: {社内環境を踏まえた判断}
判定: {代替可能 / 部分的に代替 / 代替なし} {Eurekaがあれば記載}
続行しますか？
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 にこの結果を反映する。
チェックリストではなく、思考の枠組みでレビューする。 以下の3段階を順番に実施し、最後にセカンドオピニオンを取る。
ヒアリング結果から導かれた前提を明示し、それぞれを疑う:
これは正しい問題か？ 別のフレーミングで劇的にシンプルな解決策が出ないか？ 例: 「請求書の自動生成が必要」→ 本当の問題は「転記ミスの防止」ではないか？
これは代理問題ではないか？ 依頼者が言う問題と、実際のビジネス成果は一致しているか？ 「自分の仕事を楽にしたい」と「組織の課題を解決したい」は違う。
何もしなかったらどうなるか？ Q5（3ヶ月放置）の回答を批判的に再検証する。 本当の痛みか、仮説上の痛みか。月間時間の自己申告は過大になりがち。
前提を明確な文として出力する:
前提:
1. {文} — 同意 / 異議あり？
2. {文} — 同意 / 異議あり？
3. {文} — 同意 / 異議あり？
AskUserQuestion で確認する。異議があれば理解を修正してやり直す。
12ヶ月後の理想状態を描き、このリクエストがそこに向かうか離れるかを評価する:
現在の状態 このリクエスト 12ヶ月後の理想
{現在の業務プロセス} → {提案されたMVP} → {組織としてのあるべき姿}
評価観点:
反転思考（Inversion）: 「どうすれば成功するか」ではなく「何がこのプロジェクトを失敗させるか」を問う。
失敗シナリオを具体的に列挙する:
| 失敗シナリオ | 確率 | 影響度 | 対策 |
|---|---|---|---|
| 作ったが使われない | ? | ? | ? |
| 依頼者が異動/退職 | ? | ? | ? |
| 3ヶ月後に要件が変わる | ? | ? | ? |
| 運用コストが削減効果を上回る | ? | ? | ? |
タイミング判定: 今やるべきか？
requirements/ 内の他ブリーフと優先度を比較引き算のフォーカス: Step 2 で推奨した手段で本当に十分か？ もっと小さく始められないか？ 過剰な解決策になっていないか？
AskUserQuestion で確認する:
question: 「レビューが完了しました。独立した視点からの批判的レビュー（セカンドオピニオン）を取りますか？ ヒアリング結果の要約を別のAIに渡し、論理的な穴や見落としを指摘してもらいます。」 options:
B の場合: スキップしてレビュー結果の提示へ。
A の場合: Agent ツールで独立したサブエージェントを起動する。
サブエージェントへのプロンプト: 「あなたは社内ツール開発の投資判断をレビューする独立したアドバイザーです。 以下のヒアリング結果を批判的にレビューしてください。
{Q1-Q6の回答要約} {Step 1の既存サービス調査結果} {Step 2の実装規模チェック結果} {3A-3Cのレビュー結果}
以下を回答してください:
直接的に、簡潔に答えてください。」
サブエージェントの結果を提示する:
セカンドオピニオン: {サブエージェントの出力をそのまま表示}
セカンドオピニオンとレビュー結果が異なる場合、両方の見解を提示し、 AskUserQuestion でユーザーに判断を委ねる:
question: 「レビューでは{X}と判断しましたが、セカンドオピニオンは{Y}と指摘しています。どちらを採用しますか？」 options:
ユーザー主権: セカンドオピニオンの提案は情報であり、自動的にverdictに反映しない。 各提案を個別にAskUserQuestionで確認し、ユーザーが決定する。
3A-3D の結果を統合して提示する:
批判的レビュー結果:
前提チャレンジ: {合意された前提 / 修正された前提} Dream State: {12ヶ月後の理想との整合性} リスク: {主要な失敗シナリオと対策} セカンドオピニオン: {実施した場合の要約 / スキップ}
総合判定: {verdict の変更提案があれば}
verdict を変更する場合は AskUserQuestion でユーザーに確認を取る。
レビューフェーズ完了後、ブリーフ出力前に以下を質問する:
この業務の担当者の想定時給はいくらですか？（例: 3,000円/時） 未入力の場合はデフォルト3,000円/時で計算します。
計算式:
affected_users が unknown の場合は1人として計算する。
ROI計算の後、build-score/rules/effort-estimate.md に定義された基準で開発工数を1〜5段階で見積もる。
ブリーフ出力前に必ず build-score/rules/effort-estimate.md を読み込み、そのルールに従うこと。
以下の4軸を評価し、総合して工数レベルを算出する:
各軸の評価根拠をブリーフの 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 に定義されている場合、そちらが優先される。
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判定のブリーフは status: deferred となる。
次回 /build-score 実行時に、3ヶ月以上前のDEFER案件があれば自動的に通知する:
以下のDEFER案件が3ヶ月以上経過しています。再評価しますか？
- {タイトル} (deferred: {日付})
再評価する場合、前回のブリーフを読み込み、Q1-Q6の差分のみ確認する。
build-score/knowledges/ 内のファイルは、ヒアリング中の判断に利用する:
各ファイルが空または存在しない場合は、その制約なしで進める。
---
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で十分 |
## Verdict: BUILD
月間15時間の削減効果。ワークアラウンド（手動転記）が苦痛で転記ミスも発生。
3ヶ月放置すると繁忙期に対応できないリスクあり。最小構成が明確。
## Raw Notes
（ヒアリング時のメモをここに記録）