なぜあなたの仕事はうまく進まないのか？ — AI時代の「仕様駆動」に学ぶ、今日から使える仕事術
📊この記事の図解版があります。内容を視覚的にまとめたページで、全体像をサッと把握できます
図解を見るなぜあなたの仕事はうまく進まないのか？ — AI時代の「仕様駆動」に学ぶ、今日から使える仕事術
はじめに — なぜ「やり直し」は発生するのか
ある設定作業を終えたはずなのに、1 週間後に「あれ、どこまでやったっけ」と分からなくなる。チームメンバーに聞いても「たぶんやったと思うけど……」と曖昧な返答が返ってくる。結局、最初から調べ直す。同じ作業をもう一度やる。
こうした「やり直し」は、どんな職場でも起きている。
原因は能力不足ではない。記録がないことだ。もっと正確に言えば、「何を、なぜ、どういう方針で進めて、どこまで完了したか」が、誰でも見える形で残っていないことだ。
頭の中にはある。Slack のどこかで話した気もする。でも、1 週間後の自分には思い出せない。ましてや他の人には伝わらない。
AI ツールの登場で、この問題はさらに加速している。ChatGPT や Claude Code に頼んで設定やコードを作ってもらう。便利だ。しかし、AI とのやり取りは基本的にその場限りで消える。何を指示して、何が生成されて、どこに反映したのか。セッションが終われば、残るのは成果物だけで、「なぜそうしたか」の文脈は失われる。
ソフトウェア業界では、この問題に対するひとつの回答が生まれつつある。**仕様駆動開発（Spec-Driven Development）**という考え方だ。
「仕様」と聞くと堅苦しく聞こえるが、要は 「やることを、やる前に書き出しておく」 だけのことだ。そして、これはエンジニアだけの話ではない。
仕様駆動開発（SDD）— ソフトウェア業界で起きている変化
「作る」が簡単になった時代の新しい問題
2024 年以降、ソフトウェア開発の風景が一変した。AI コーディングツール（GitHub Copilot、Cursor、Claude Code など）の登場で、コードを書く速度が劇的に上がった。「こういう機能がほしい」と伝えれば、AI が数秒でコードを生成してくれる。
この流れの中で生まれたのが、バイブコーディング（vibe coding） と呼ばれるスタイルだ。「細かい設計は考えず、AI にざっくり指示して、動くものをとりあえず作る」というアプローチで、AI 研究者の Andrej Karpathy が名付けて広まった。
小さなツールやプロトタイプには有効だ。しかし、ある一定の規模を超えると限界が来る。
「何を作るか」が曖昧なまま作り始めて、後から「これじゃなかった」と気づく。 機能が増えるたびにコードは複雑になり、AI に修正を頼んでも「どこを直せばいいか」を説明するだけで一苦労になる。作るスピードが上がった分、やり直しの回数も増える。
AI 時代でも変わらない 2 つのこだわり
「AI が書いてくれるなら、設計やコード品質は気にしなくていいのでは？」と思うかもしれない。実際は逆だ。AI 時代だからこそ、2 つの点への妥協は禁物だと実感している。
1. 設計へのこだわり
AI コーディングツールにはコンテキストウィンドウ（一度に読み込める情報量の上限）がある。設計書がなければ、AI はコードそのものを読んで全体像を把握しようとする。しかし、コードを読み込むだけでコンテキストウィンドウが消費され、肝心の作業に使える余地が減る。
整理された設計書があれば、AI は「このファイルのこの部分を変えればいい」と最短ルートで作業に取りかかれる。設計書は、AI にとっての地図だ。
2. コードの美しさ
「動けばいい」で書かれたコードは、人間にも AI にも読みづらい。AI が既存コードを読み解いて修正・拡張する場面では、整理されたコードのほうが情報の読み取り効率が高い。変数名が明確で、関数が適切に分割されていれば、AI は少ないコンテキストで正確な修正ができる。
美しいコードとは、見た目の問題ではない。AI を含むすべての読み手にとっての「情報伝達効率」 の問題だ。
業界が出した答え — 「作る前に書く」
バイブコーディングの限界に、業界の有識者たちも気づいている。
ThoughtWorks（世界的なソフトウェアコンサルティング企業）は、2025 年の重要エンジニアリング実践として**仕様駆動開発（Spec-Driven Development、以下 SDD）**を選定した。「AI がコードを書く時代に、人間が書くべきなのは仕様だ」という主張だ。
Martin Fowler（ソフトウェア設計の世界的権威）は、SDD を 3 つの段階に整理した。
| 段階 | 名前 | 意味 |
|---|---|---|
| 1 | Spec-first | 最初だけ仕様を書き、あとは実装に集中する |
| 2 | Spec-anchored | 実装中も仕様を更新し続け、常に「今どうなっているか」を反映する |
| 3 | Spec-as-source | 仕様そのものが最終成果物。コードは仕様から自動生成される |
現実的に多くのチームが目指すべきは段階 2 の Spec-anchored（仕様を実態に合わせ続ける）だ。仕様を「書いて終わり」にせず、「使いながら育てる」。
Amazon も 2025 年に Kiro という AI コーディングツールをリリースし、その中核に SDD を据えた。「要件 → 設計 → タスク」の 3 ステップを経てから実装に入るワークフローが組み込まれている。
エンジニアだけの話ではない
SDD の本質は、技術的な話ではない。「実行する前に、何をなぜどうやるか書き出しておく」 という、仕事の進め方そのものだ。
ソフトウェア業界は「AI が実行を担うようになったからこそ、計画の質が問われる」という教訓を、身をもって学んでいる最中だ。そして、この教訓はプログラミングに限らず、あらゆる仕事に当てはまる。
次のセクションで、SDD の考え方を日常の仕事に当てはめてみよう。
4 ステップで仕事が変わる — 「なぜ → 何を → どう → タスク」
SDD で使われる 4 つのステップを、日常の仕事に当てはめてみよう。
ステップ 1: なぜやるのか（Proposal）
最初に書くのは「なぜこの仕事をするのか」だ。目的、背景、スコープ（やること・やらないこと）を 1 ページにまとめる。
ソフトウェア業界では Proposal（提案書）と呼ぶが、やっていることは「企画書の最初の 1 ページ」と同じだ。
日常の例:
- 社内の業務フロー改善を提案するとき → 「なぜ今のフローに問題があるのか」「改善するとどうなるのか」を先に書く
- AI ツールに作業を頼むとき → 「何のためにこの作業をするのか」を最初に伝える
ポイントは 「やらないこと」を明示する ことだ。スコープを絞らないと、仕事はどこまでも膨らんでいく。
ステップ 2: 何を実現するのか（Specs）
次に「具体的に何が実現されていればよいか」を書く。SDD では Specs（仕様書）と呼ぶ。
仕様書と言っても難しく考える必要はない。「こうなったら OK」という完了条件を、具体的な場面で書くだけだ。
■ 場面: 新入社員がフィロソフィーを知りたいとき
- いつ: 入社オリエンテーションで
- どうなる: 1 つのドキュメントを渡すだけで、ミッション・ビジョン・コンセプトが理解できる
■ 場面: 経営会議でブランド方針を確認するとき
- いつ: 四半期レビューで
- どうなる: 確定事項と未確定事項が一覧で見え、「次に何を決めるべきか」がわかるこの「場面」と「どうなる」のセットは、ソフトウェアの世界では Given/When/Then パターンと呼ばれ、BDD（振る舞い駆動開発）という手法に由来する。しかし本質は 「合格基準を先に決める」 ということで、仕事のジャンルを問わない。
ステップ 3: どうやるのか（Design）
「なぜ」と「何を」が決まったら、「どうやって実現するか」を書く。技術的な方法だけでなく、判断の根拠 も記録する。
ここで大事なのは、「なぜその方法を選んだか」と「なぜ他の方法を選ばなかったか」を両方書く ことだ。
たとえば、自社の訪問看護事業のフィロソフィーを整理したとき、こんな設計判断を記録した。
■ 判断: フィロソフィーとブランドを 2 つの仕様書に分けるか、1 つにまとめるか
- 採用案: 2 つに分ける（Philosophy Spec と Brand Spec）
→ 理由: 更新頻度が異なる。フィロソフィーは年単位、ブランドは四半期で見直す可能性がある
- 不採用案: 1 つにまとめる
→ 理由: ファイルが肥大化し、「どこを見ればいいか」が曖昧になる1 年後の自分が「なぜこう決めたんだっけ？」と迷わないための保険だ。この記録がなければ、同じ議論をもう一度することになる。
ステップ 4: 何をするか（Tasks）
最後に、やることをチェックリストに落とし込む。
## フィロソフィー整理タスク
- [x] 過去 1 年半の Slack・議事録から決定事項を収集する
- [x] ミッション・ビジョン・コンセプトを階層構造に整理する
- [x] 確定事項と未確定事項をステータス分けする
- [ ] チームにレビュー図解を共有し、フィードバックを集める
- [ ] フィードバックを反映して仕様書を確定するチェックリストの利点は 2 つある。進捗が目に見える ことと、途中で中断しても再開できる ことだ。
4 ステップで何が変わったか — 実例
実際にこの 4 ステップで自社のフィロソフィーを整理したところ、チームの反応が変わった。
約 1 年半にわたって Slack や会議で断片的に議論してきた内容を、OpenSpec の流れに沿って 4 つのドキュメントにまとめた。さらに、そのドキュメントを AI で図解に変換してチームに共有した。
反応はこうだった。
「チャットで消えてしまっていたものが、ドキュメントに残しておくことでコンテキストとして残るようになり、それを振り返ることができるようになった」
「過去の流れで決まったことが整理されていて、わかりやすかった。今後はこれを更新していかないと」
「openspec は外部メモリ、という言葉でとても理解が進みました」
外部メモリ。この比喩がまさに SDD の本質を言い表している。人間の記憶は揮発性だ。会議で話したこと、Slack でやり取りしたこと。1 週間もすれば細部は曖昧になる。
そして、AI も同じだ。ChatGPT も Claude も、セッションを切り替えれば前回のやり取りをすべて忘れる。「先週頼んだあの作業の続きをやって」と言っても、AI は何も覚えていない。人間と AI の両方が揮発性のメモリで動いている以上、外部に書き出さなければ、チームの知識は毎回ゼロからやり直しになる。ドキュメントに書き出すことは、人間にとっても AI にとっても、記憶を外部ストレージに保存することに等しい。
ドキュメントは「副産物」を生む
「仕様を書く」と聞くと、手間が増えるように感じるかもしれない。しかし実際に運用してみると、ドキュメントそのものが別の価値を生み出すことに気づく。
図解という副産物
前のセクションで紹介したフィロソフィーの整理では、4 ステップで作ったドキュメントを AI に渡して図解に変換した。ミッション・ビジョン・コンセプトの階層をピラミッドで表現し、確定事項と未確定事項を色分けし、タスクの依存関係をフロー図にした。
この図解は、もともと作る予定はなかった。ドキュメントが構造化されていたから、AI に「これを図解にして」と頼むだけで自然に生まれた副産物だ。
そしてチームに共有したとき、テキストのドキュメントよりも図解のほうがはるかに反応が良かった。「めちゃくちゃわかりやすい」「過去の流れで決まったことが整理されていて、一目でわかる」。伝えたい内容は同じなのに、形を変えるだけで伝わり方が変わる。
ここで重要なのは、図解を最初から作ろうとしたわけではないということだ。構造化されたドキュメントがあれば、スライドでも図解でも、必要な形にいつでも変換できる。 AI 時代において、ドキュメントは「読み物」ではなく「変換元データ」として機能する。
リーダーにとっての価値 — レビューコストの削減
もしあなたがチームのリーダーや上司の立場なら、ドキュメント作成をルール化することで得られるメリットは大きい。
部下から「こういうことをやりたいんですけど」と口頭で相談を受けるとき、頭の中で「目的は何か」「スコープはどこまでか」「リスクは何か」を組み立てながら聞かなければならない。これはレビューする側にとって認知コストが高い。
一方、4 ステップに沿ったドキュメント、あるいはそれを図解にしたものが事前に提出されていれば、話は変わる。「なぜ・何を・どう・タスク」が整理された状態で目の前にあるので、レビューは「抜け漏れがないか確認する」作業になる。 ゼロから理解する必要がない。
これは部下にとってもメリットがある。ドキュメントを書く過程で自分の考えが整理されるし、上司に説明するときも「この図解を見てください」で済む。口頭での説明がうまくなくても、ドキュメントが代弁してくれる。
「計画を立てて進める」文化が根づく
ドキュメント提出をルール化する最大の効果は、チームに 「計画を立てながら物事を進める」 という文化が根づくことだ。
最初は面倒に感じるメンバーもいるだろう。しかし、自分が書いたドキュメントが図解に変わり、チームのレビューがスムーズになり、半年後に「あのとき何を決めたか」を振り返れる体験を一度すれば、その価値は実感できる。
「計画なんていらない」は認知の歪み
人はタスクの規模を小さく見積もる
「これくらいなら、わざわざ計画を立てなくていいだろう」
この判断が正しかった経験は、どれくらいあるだろうか。
心理学には**計画錯誤（Planning Fallacy）**という概念がある。ノーベル経済学賞を受賞した Daniel Kahneman らの研究で明らかになった認知バイアスで、人は作業にかかる時間・コスト・リスクを、実際よりも楽観的に見積もる傾向があるというものだ。
「1 時間で終わるだろう」と思った作業が半日かかる。「この変更は小さい」と思って着手したら、想定外の依存関係が見つかって手戻りが発生する。これは能力の問題ではなく、人間の認知構造に組み込まれた傾向だ。
「不測の事態」は不測ではない
振り返ってみれば、後から出てくる問題には共通点がある。
- 前提条件の確認漏れ — 「当然こうだろう」と思っていた前提が、実は違っていた
- 関係者の認識ズレ — 自分が思っていたスコープと、相手が期待していたスコープが違う
- 過去の経緯の忘却 — 以前に同じ問題を検討して却下した理由を忘れ、同じ議論を繰り返す
これらは「不測の事態」と呼ばれがちだが、実際には計画段階で 5 分考えれば気づけたことが大半だ。
4 ステップの最初、Proposal で「なぜやるのか」「やらないことは何か」を書き出すだけで、前提条件の確認漏れとスコープのズレはかなり防げる。Design で「なぜこの方法を選んだか」を記録しておけば、過去の経緯を忘れて同じ議論を繰り返すこともない。
「書くコスト」と「やり直すコスト」の比較
ドキュメントを書くには時間がかかる。4 ステップをすべて埋めれば、30 分から 1 時間はかかるだろう。
しかし、やり直しのコストはそれ以上だ。作業をやり直す時間だけでなく、「あれ、どうなってたっけ」と調べ直す時間、関係者に確認する時間、認識のズレを修正する会議の時間。これらを合算すれば、30 分の計画で数時間の手戻りを防げるケースは珍しくない。
習慣にするための基準
とはいえ、すべてのタスクに 4 ステップのドキュメントを書くのは非現実的だ。「メールを 1 通返す」ために Proposal は書かない。
目安として、こんな基準はどうだろう。
| タスクの性質 | ドキュメント | 理由 |
|---|---|---|
| 15 分以内で完了する定型作業 | 不要 | 書くコストのほうが高い |
| 1 時間以上かかりそうな作業 | 書く | 計画錯誤の対象になりやすい |
| 他の人に引き継ぐ可能性がある作業 | 書く | 未来の誰かが文脈を必要とする |
| 「たぶん簡単」と感じる作業 | 書く | その直感こそが計画錯誤のサイン |
最後の行が一番大事だ。「簡単そうだからドキュメントはいらない」と感じたときこそ、5 分だけ使って書き出してみる。 本当に簡単なら 5 分で終わる。想定外の複雑さに気づいたなら、その 5 分が数時間の手戻りを防いでくれる。
OpenSpec — この考え方を仕組み化したツール
フレームワークだけでは続かない
ここまで紹介した「なぜ → 何を → どう → タスク」の 4 ステップは、紙とペンでも実践できる。しかし正直に言えば、手作業で続けるのは難しい。
「今回は急ぎだから」「このタスクは小さいから」。例外が 1 つできると、例外が標準になる。これは個人の意志力の問題ではなく、仕組みがないことの問題だ。
OpenSpec は、この 4 ステップをソフトウェア開発の現場で仕組み化するために生まれたオープンソースツールだ。Fission-AI 社が開発し、GitHub で公開されている。
OpenSpec の仕組み
OpenSpec を導入すると、プロジェクトに openspec/ というフォルダが作られる。ここが「チームの外部メモリ」の置き場所になる。
openspec/
├── config.yaml ← プロジェクトの基本設定
├── changes/ ← 進行中の変更
│ ├── add-chat-search/ ← 変更ごとに 1 フォルダ
│ │ ├── proposal.md ← なぜやるのか
│ │ ├── specs/ ← 何を実現するのか
│ │ ├── design.md ← どうやるのか
│ │ └── tasks.md ← 何をするか
│ └── archive/ ← 完了した変更の記録
│ ├── 2026-01-21-add-issues-reviewer-feature/
│ └── ...
└── specs/ ← プロジェクト全体の仕様書（最新版）ここまで説明してきた 4 ステップが、そのままフォルダ構成に反映されている。proposal.md → specs/ → design.md → tasks.md の順に書き進め、完了したら archive/ に移す。
AI コーディングツールとの連携
OpenSpec の特徴は、Claude Code や Cursor など 23 種類の AI ツールと連携できる ことだ。導入時に使っているツールを指定すると、そのツール向けのコマンドが自動生成される。
たとえば Claude Code では、以下のようなコマンドで 4 ステップを進められる。
| コマンド | やること |
|---|---|
/opsx:new | 新しい変更を始める（フォルダと proposal のテンプレートを作成） |
/opsx:continue | 次のステップのドキュメントを 1 つ作成する |
/opsx:ff | 全ステップのドキュメントを一括生成する（急ぎのとき） |
/opsx:apply | tasks.md のチェックリストに沿って実装を進める |
/opsx:verify | ドキュメントと実装の整合性を検証する |
/opsx:archive | 完了した変更を記録してアーカイブする |
AI が proposal を読んで specs の下書きを作り、specs と design を読んで tasks を洗い出す。人間が「なぜやるか」を書けば、AI が「何を・どう・タスク」を構造化してくれる。 もちろん AI の出力は確認・修正が必要だが、ゼロから全部書くよりはるかに速い。
導入方法
Node.js（バージョン 20.19.0 以上）がインストールされた環境で、以下のコマンドを実行するだけだ。
npm install -g @fission-ai/openspec@latest
cd your-project
openspec initopenspec init を実行すると、対話形式で使用する AI ツールを選択でき、プロジェクトに合わせた設定ファイルとコマンドが自動生成される。
自社での運用実績
筆者のチームでは、OpenSpec を導入してから 35 以上の変更をこのワークフローで回してきた。機能追加、バグ修正、業務フローの整理、さらには前のセクションで紹介したフィロソフィーの体系化まで、ソフトウェア開発に限らない用途で活用している。
完了した変更は日付付きでアーカイブされるので、「あの変更はいつ、なぜ、どういう方針で進めたか」を後からいつでも辿れる。これが、セクション 1 で述べた「やり直し」を防ぐ仕組みの正体だ。
まとめ — 明日の仕事から試せること
この記事で伝えたかったこと
仕事がうまく進まない原因の多くは、能力不足ではなく記録の不在だ。
- 何をどこまで進めたか分からなくなる
- 人に聞いても「どうだっけ」と返ってくる
- AI に頼んでも、セッションが変われば文脈はゼロに戻る
ソフトウェア業界はこの問題に対し、仕様駆動開発（SDD） という答えを出しつつある。「なぜ → 何を → どう → タスク」の 4 ステップでドキュメントを書いてから動く。それだけで、手戻りが減り、チームの認識が揃い、AI の出力精度が上がる。
そして、この考え方はプログラミングに限らない。業務改善、フィロソフィーの整理、社内提案——あらゆる仕事に当てはまる。
今日からできること
OpenSpec を導入しなくても、4 ステップの考え方は今日から使える。
| ステップ | やること | 所要時間の目安 |
|---|---|---|
| 1. なぜ | 目的とスコープ（やること・やらないこと）を 3 行で書く | 5 分 |
| 2. 何を | 「こうなったら OK」という完了条件を箇条書きにする | 5 分 |
| 3. どう | 方法と、なぜその方法を選んだかを書く | 10 分 |
| 4. タスク | やることをチェックリストにする | 5 分 |
合計 25 分。この 25 分が、数時間のやり直しを防ぐ保険になる。
もう一歩踏み込みたい人へ
OpenSpec を使えば、この 4 ステップが仕組みとして定着する。
最初の一歩としておすすめなのは、explore コマンドを使ってみることだ。いきなり本番のタスクに適用する必要はない。簡単なことでいい。「社内の勉強会を企画する」「チームの週次ミーティングの進め方を見直す」——そんな身近なテーマで、1 つ change を作ってみる。
# OpenSpec をインストールして初期化
npm install -g @fission-ai/openspec@latest
cd your-project
openspec init
# explore コマンドで、テーマを整理するところから始める
# （Claude Code の場合）
/opsx:explore/opsx:explore は「まだ何をするか決まっていないけど、考えを整理したい」ときに使うコマンドだ。AI と対話しながら、テーマの輪郭を掴み、change として記録するかどうかを判断できる。
まずは 1 つ。小さな change を作ってみてほしい。ドキュメントが「面倒な作業」から「チームの外部メモリ」に変わる体験が、きっと得られるはずだ。
関連記事
- 認知ファーストの原則 — AIに作らせても「わからない」なら意味がない — 仕様駆動の根底にある「理解を最優先にする」考え方
- AIとの対話術 — コンテキスト管理の実践 — 仕様駆動をAIツールで実践するときのコンテキスト管理手法