たとえば商社で、見積もり承認アプリを作るとします。「一定以上の値引きは上司が承認する」という依頼だけでは、外貨の見積もりをどう扱うか、承認者が不在なら誰に回すかが決まりません。画面ができてから相談を始めると、業務ルールの調整と実装の修正を同時に進めることになります。
開発前に「この条件を満たせば業務で使える」を書き出せれば、企画担当の依頼の仕方も変わり得ます。コードを書かなくても、値引き率の扱いや承認の例外を具体化し、完成後に確かめる条件を開発担当者と共有できます。
GitHub Spec Kitは、仕様を中心にソフトウェア開発を進める公開ツールキットです。GitHubの説明によると、仕様、技術的な計画、作業タスク、実装という段階を設け、品質のチェックリストや、仕様・計画・タスクの食い違いを調べる手順を提供しています。業務で使う条件を、開発の各段階につなぐ使い方が考えられます。
業務で満たしたい条件を、計画と作業に落とす
仕組みを、入力する内容、途中で行うこと、出力として残るものの順に見てみます。
入力として人が整理するのは、作りたいものの目的や満たすべき条件です。見積もり承認アプリなら、現行の承認規程、見積書の項目、担当者が判断に迷った過去のケースを参照し、仕様を具体化する使い方が考えられます。これらは業務担当者が条件を整理するための資料の例です。資料を渡すだけで、正しい業務ルールが自動的に決まるという意味ではありません。
次に、仕様を起点に技術的な計画を立て、作業タスクに分けて、実装へ進みます。各段階の役割は、仕様で「何を満たすか」、計画で「どう実現するか」、タスクで「どの作業を行うか」を具体化することだと捉えられます。業務担当者が決めた条件を、開発担当者が実装できる形へつなぐ流れです。
各段階の成果物はMarkdownで扱います。Markdownは、見出しなどを簡単な記号で表せるテキスト形式です。条件や計画を文書として残すことで、後の工程でも参照しながら開発を進める構成になっています。
この構成の使いどころは、最初に決めた条件が計画やタスクに引き継がれているかを確かめる場面にあると考えられます。たとえば仕様に承認者が不在の場合の処理を書いたのに、その処理を作るタスクがなければ、実装前に見直す理由になります。ただし、こうした抜けをツールの確認手順がどこまで検出できるかは、実際に試して確かめる必要があります。
値引き率、通貨、不在時の扱いを判定できる形にする
ここからは、見積もり承認アプリでの使い方を具体的に考えます。実際の導入事例ではなく、仕様を整理するための例です。
値引き率なら、何を基準額として計算するか、承認が必要になる境界の値をどう扱うかを決めます。通貨なら、通貨ごとに条件を設けるのか、換算して判定するのかを確認します。承認者が不在なら、代理者に回すのか、復帰まで保留するのかを決めます。具体的な率や換算の基準は、自社の規程と責任者の判断で定める内容です。
これらを、完成したものを業務で使えるか判定する「受け入れ条件」にします。「承認できること」だけでは、期待どおりに動くかを確かめにくいものです。境界に当たる見積もりは誰に回るか、代理者も不在ならどうなるかまで具体化すれば、業務担当者と開発担当者が同じケースについて話せます。
企画担当にとっては、大まかな要望を渡して完成を待つ進め方から、実装前に判断が分かれる場面を整理し、確認できる条件を渡す進め方へ移せる可能性があります。Spec Kitの段階構成は、その条件を後の工程でも参照する助けになると考えられます。
ただし、曖昧な社内ルールを文書に移しただけでは、曖昧さも残ります。営業と経理で通貨の扱いが違うなら、どちらに合わせるかを決めるのは関係者です。仕様と計画が食い違っていないことと、仕様に書いたルールが業務上妥当であることは、それぞれ確かめる必要があります。Spec Kitは、文書を書けば業務の正しさが保証される仕組みではありません。
架空の見積もりで、最初の仕様を作ってみる
公式手順に沿って、承認アプリの仕様を作る使い方を見てみましょう。ここで使うのは、実在の顧客や社内規程を含まない架空の条件です。目標は完成したアプリではなく、営業と開発担当者が一緒に読める、最初の仕様書です。
準備するものはPython 3.11以降、Git、パッケージ管理ツールのuv、設定済みのCodex CLIです。以下は2026年9月11日に確認したSpec Kitの手順に基づく例です。初めて環境を用意する場合は、開発担当者と一緒に進めると取りかかりやすくなります。利用するエージェントのアカウントと料金条件も確認し、試作には架空の情報を使います。
- ターミナルで作業用フォルダーへ移動し、次のコマンドを順に実行します。
quote-demoはこの例で新しく作るフォルダー名です。同じ名前の既存フォルダーがない場所を選んでください。
uv tool install specify-cli
specify init quote-demo --integration codex
cd quote-demo
codexSpec Kitをインストールし、Codex CLI向けの設定を入れたプロジェクトを開く流れです。初期設定で選択肢が出たら、利用する環境に合わせて選びます。
- ここからはCodex CLIの入力欄へ、まず試作の共通ルールを送ります。
$speckit-constitutionはSpec Kitが用意するスキルの呼び出しです。以下の業務条件は、この例のために用意した入力文です。
$speckit-constitution
見積もり承認アプリの試作です。実在の顧客情報は使いません。
業務ルールの未決定事項は推測で埋めず、質問として残してください。
仕様書は営業担当者も読める日本語にしてください。- 続けて、作りたいものと確認したい条件を送ります。
$speckit-specify
営業担当が見積もりを申請し、上司が承認するアプリを作りたいです。
架空の条件として、値引き率が10%以上なら上司の承認を必要とします。
上司が不在のときは代理者へ回します。
外貨の見積もりと、代理者も不在の場合の扱いは未決定です。
通常の申請、承認が必要な境界、未決定事項を分けて整理してください。- できた仕様書を営業担当者と開発担当者で読み、「10%ちょうどは承認が必要か」「代理者も不在なら止めるのか」を確認します。質問が返ってきたら、業務側で決めた範囲を答えます。先へ進む前に、この例の条件が仕様へ残っているかを照合します。
期待する成果物は、作りたい機能、利用者の操作、確認する条件を話し合える文書です。実際の出力は利用環境や応答によって変わります。未決定の点をチームで決められたら、計画、作業タスク、実装へ進む材料になります。
営業企画なら、まず申請から承認までの一つの流れを題材にできます。企画書を渡して終わるのではなく、「この条件なら使える」を開発担当者と一緒に確かめる。Spec Kitは、その会話を始める道具としても面白そうです。