---
title: うさうさ_合意設計_スコープと判断軸_ローズ版
tags:  #poc  
author: [smile_yukiko_it](https://www.docswell.com/user/smile_yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/3EK9LD14ED.jpg?width=480
description: うさうさ_合意設計_スコープと判断軸_ローズ版 by smile_yukiko_it
published: June 22, 26
canonical: https://www.docswell.com/s/smile_yukiko_it/51QQVE-2026-06-22-195647
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/3EK9LD14ED.jpg)

PoC ・ 受託 ・ 研修現場のための
「どこまでやるか」問題を
仕組みで解く
判断軸と“やり直し回数”を、お客さんに負担をかけず先に合意する技術
判断軸を先に握る
うさうさ先生
/ うさうさ研修工房
誰が・いつ・何を
2026-06-22 ・ v2.0（ローズ版）
やり直しN回ルール
暗黙知→形式知


# Page. 2

![Page Image](https://bcdn.docswell.com/page/L73W3RQD75.jpg)

この資料で断ち切る「うっ…」の悪循環
誠実な人・がんばる人ほどハマる。これは個人の努力ではなく“循環”の問題です。
曖昧なまま着手
線引きを“空気”で判断
“ついでに”が積もる
→
↻
↑
終盤に作り直し
“思ってたのと違う”
範囲がじわじわ膨張
↓
やり直しが無限化
←
変更と区別がない
断ち切り方：判断を「意志」ではなく「仕組み」に逃がす。次ページから、その5つの仕組みを。
うさうさ研修工房
合意設計
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/87DK4Y92JG.jpg)

なぜ放っておくと、必ず曖昧になるのか
「気合い不足」ではなく、人間の標準仕様。3つの研究が構造を説明します。
プランニング・
ファラシー
コミットメントの
エスカレーション
スコープクリープ
自分の作業は実際より短く見積もる。
99%確実の締切に間に合った人は半数未
満。
自分が始めた失敗案件ほど損切りできず
、さらに資源を注ぐ（サンクコスト）。
“コントロールされていない”範囲拡大。
変更が悪いのでなく、手続きなき変更が
悪い。
Buehler, Griffin & Ross (1994)
Staw (1976)
PMI / PMBOK Guide
感覚・責任感・善意
うさうさ研修工房
合意設計
→
に頼った瞬間
→
範囲が膨張する
だから「外側の仕組み」に
逃がす
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/VJPKM6ZLE8.jpg)

★ 全体像 ── 合意設計の地図
着手前に“先に握る”ものから、走りながら“見える化”するものへ。5つの仕組みの並び。
→
→
→
→
①判断軸
②役割
③やり直し
④形式知化
⑤見える化
IN / OUT を先に
誰が・いつ・何を
N回→仕様変更
暗黙知を渡す
チェックリスト
着手前に“先に握る”
走りながら“見える化”
すべて「うさうさラーメン店」のたとえ：注文（IN/OUT）→担当→作り直しルール→レシピ化→提供チェック。
うさうさ研修工房
合意設計
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/2EVV93W6EQ.jpg)

01 判断軸 ── IN / OUT の境界線を先に引く
人は IN（やること）は書くが OUT（やらないこと）を書かない。揉めるのは毎回 OUT。
OUT ・ やらないこと ★
IN ・ やること
境界線
•
RAG実装（PoC範囲）
•
プロンプト設計
•
精度評価レポート
•
1環境での検証
→
この線を
“着手前に”引く。
迷ったら優先：
品質 / 納期 / コスト
→
•
本番環境への導入
•
他システム連携
•
運用・保守
•
UIの作り込み
OUTを一行書くだけで、後の“言った言わない”がほぼ消える。叩き台はこちらから出すと、相手の負担にならない。
うさうさ研修工房
合意設計
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/57GLZ3D2EL.jpg)

02 役割 ── 誰が・いつ・何を（タイムライン）
「やる/やらない」だけだと“いつ”が抜ける。“いつ”が抜けた約束は守られない。
キックオフ
+2営業日
合意
判断軸・役割を握る
環境構築→疎通確認
完了 or 仕様変更へ
両者
自分
両者
+3営業日
提出+5日
検証データ提供
レビュー（コメント返却）
お客さん
お客さん
「完了の判定」を各ステップに：水掛け論は“完了の定義がない”から起きる。提供＝丼を渡した時点か、満足した時点か。決めておく。
うさうさ研修工房
合意設計
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/4EQYL519JP.jpg)

03 やり直しは何回まで？ ── 決定フロー
レビューが来たら、この分岐を機械的に通す。今日いちばん言いたいこと。
レビュー指摘
が届く
→
誤字・バグ？
→
回数に含めず
すぐ直す
「あと1回くらい」は構造的
に止まらない (Staw)。意志
でなくルールで止める。
No ↓
伝え方のコツ
「断る」のではなく「変更
として正しく扱う」。相手
の利益にもなる、と伝える
。
うさうさ研修工房
合意設計
往復は
2〜3回以内？
なぜ回数で？
→
標準対応として
修正する
回数明記＝品質責任の逃げ
に見せないため、バグは別
枠に。
超過 ↓
“仕様変更”として扱う
工数・納期・費用を見える化し再合意
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/KJ4WD96R71.jpg)

04 暗黙知 → 形式知（SECIのスパイラル）
判断軸はベテランの“暗黙知”。頭の中にある限り、共有も再現もできない。
S 共同化 （暗黙→暗黙）
現場で“こう線を引く”を見て覚え
る
↑
E 表出化 （暗黙→形式）
→
⟳ SECI
I 内面化 （形式→暗黙）
判断軸メモ・役割表に言語化（外
化）
↓
C 連結化 （形式→形式）
←
使ううちに身につき、また現場へ
チェックリスト・テンプレに統合
Nonaka (1994)：仕組み①〜③は、あなたの判断軸を“外化（E）”する作業そのもの。研修講師の本業と同じスキルです。
うさうさ研修工房
合意設計
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/LE1YZKVV7G.jpg)

05 チェックリストは効く ── 実証されている
「ベテランに補助輪は不要」は誤解。熟練者ですら見落とす“当たり前”を確実に拾う仕組み。
11% → 7%
1.5% → 0.8%
19項目
主要合併症
院内死亡
チェックリスト
世界8都市の病院で低下
40%超の減少
サインイン/タイムアウト/サインアウト
Haynes et al. (2009, NEJM)：世界トップクラスの外科医がいる現場でもチェックリストは効いた。「どこまでやるか」の合意も、当たり
前なのに毎回抜ける系の代表格。だからリスト化する価値がある。
うさうさ研修工房
合意設計
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GEWG9DL3J2.jpg)

1枚で使える「合意設計チェックリスト」
着手前に上から確認するだけ。案件メモに貼って使ってください。
ゴールと範囲
役割
やり直しと変更
伝え方と外化
“できた”状態を一文で
各作業を誰が・いつ・何を
往復の上限回数（推奨2〜3
）
こちらから叩き台を出す
やること（IN）
各作業に「完了の判定」
上限超え＝仕様変更で扱う
口約束を1枚の表に見える化
やらないこと（OUT）★
技術判断／ビジネス判断の
担当
バグ・誤字は回数に含めな
い
「断る」でなく「正しく扱
う」
迷ったら優先：品質/納期/コ
スト
v2.0 ・ うさうさ研修工房 ・ 2026-06-22
うさうさ研修工房
合意設計
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/47ZL9GMGJ3.jpg)

判断を、意志でがんばらず、仕組みに逃がす。
それは相手を疑うことではなく、お互いを「言った言わない」から守ること。
明日のキックオフ、5分だけ。判断軸を口頭で握ってみてください。
面白きこともなき世を面白く。
— うさうさ先生 / うさうさ研修工房
参考文献（すべて実在の査読論文・標準資料）
Buehler, Griffin & Ross (1994). Exploring the “planning fallacy”. J. Personality and Social Psychology, 67(3), 366–381.
Staw (1976). Knee-deep in the Big Muddy. Organizational Behavior and Human Performance, 16(1), 27–44.
Nonaka (1994). A Dynamic Theory of Organizational Knowledge Creation. Organization Science, 5(1), 14–37.
Haynes et al. (2009). A Surgical Safety Checklist… New England Journal of Medicine, 360(5), 491–499.
PMI. A Guide to the Project Management Body of Knowledge (PMBOK Guide). ※“scope creep”の定義として参照