- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存
このコースの最後の回です。書かなかったことは消えずに残り、実装した誰かが黙って決める——その「書かなかったこと」のうち、まだ決められないものの書き方を見ます。
まず結論
決まっていない点を書かずにおくと、読み手には「決めていない」と「書き忘れた」の区別がつかず、実装した誰かが黙って決めます。
だから未決定は未決定と書き、推定値・根拠・誰がいつまでに決めるかを添えます。NASA の要求チェックリストは、TBD を減らし、推定値に TBR の印を付けて担当と期限を書け、と求めています。
NASA のシステムズエンジニアリング・ハンドブック付録C は、まだ決まらない値の書き方について何と書いているでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
書かなかった点と、決めていない点は、読み手には同じに見える
依頼文に書いていない点には2種類あります。書き手の頭の中では決まっているのに書き忘れた点と、まだ誰も決めていない点です。読み手にはこの2つが区別できません。どちらも、紙の上ではただ何も書かれていないからです。
そして何も書かれていない点に出会った読み手は、進むために何かを選びます。人でも AI でも同じです。Parnas と Clements(1986)は、要求文書が要る理由の1つをこう書きました。
We want to avoid making requirements decisions accidentally while designing the program. … Having a complete reference on externally-visible behaviour relieves them of any need to decide what is best for the user.
では、開発を始める時点でまだ決められない点はどうするのか。同じ論文は理想の要求文書の受け入れ基準に、次の1項を入れています。
(3) Where information is not available before development must begin, the areas of incompleteness should be explicitly indicated.
「決まるまで待て」ではありません。不完全な箇所を、不完全だと明示せよです。空白のままにすれば読み手は選び、「未決定」と書いてあれば読み手は選ぶ前に止まれます。
- ・決めていない点について、選ぶ主体を依頼する側に残すのは真ん中の列だけ
- ・右の列でも決定は起きている。記録が無く、選んだ本人も気づきにくい
NASA の要求チェックリストは、何を添えよと言うか
NASA Systems Engineering Handbook(SP-2016-6105 Rev2)付録C は、良い要求の書き方のチェックリストです。C.3 の1項目がこれです(印刷頁197〜198)。
The use of “To Be Determined” (TBD) values should be minimized. It is better to use a best estimate for a value and mark it “To Be Resolved” (TBR) with the rationale along with what should be done to eliminate the TBR, who is responsible for its elimination, and by when it should be eliminated.
読み違えやすい点が1つあります。担当者と期限が付くのは TBD ではなく TBR です。 TBD は減らす対象で、代わりに推定値を置き、それが確定していない印として TBR を付けます。分けると次の5つです。
逐語 添えるものa best estimate for a value 推定値the rationale その値にした根拠what should be done to eliminate the TBR 確定させるために何をするかwho is responsible for its elimination 確定させる担当者by when it should be eliminated いつまでに確定させるか
隣の C.4 は検証の側から同じことを問います。Have all incomplete requirements been captured as TBDs or TBRs and a complete listing of them maintained with the requirements? 印を付けるだけでなく、その一覧を要求とともに保つかどうかです。
推定値を置く意味は、読み手が止まらずに進めることにあります。担当者と期限がある意味は、推定値が推定値のまま製品に残るのを防ぐことです。
NASA 付録C C.3 の項目に照らして、次の記述のうち原文どおりなのはどれですか。
未決定を書く場所は、様式の側に最初からある
未決定があるのは、書き手の怠慢とは限りません。Brooks は No Silver Bullet(1986)にこう書いています。
The hardest single part of building a software system is deciding precisely what to build.
何を作るかを正確に決めるのが最も難しい——この文が言うのはここまでです。ただ、最も難しい仕事なら、始める時点で全部が決まっていないのは普通のことです。
実際、提案を書くための公開テンプレートは、未決定の置き場を最初から持っています。
様式 節 問うものNASA 付録C C.3 TBR 根拠・解消の手順・担当者・期限Rust RFC テンプレート Unresolved questions RFC の過程で解くか、実装で解くかPEP 12 テンプレート Open Issues まだ決定・議論中の点
担当と期限まで求めるのは NASA だけで、Rust は解く時点を、PEP 12 は点の列挙だけを求めます。それでも3つとも共通して、未決定を空白に紛れさせず、名前の付いた場所に書かせます。書いておけば、読み手はそこを選んではいけない点として扱えます。
AI への指示に、未決定の点を書く
AI への指示も依頼文です。Anthropic の Prompting best practices(2026-09-24 取得)には、テストを通すことに偏る振る舞いを避ける節があり、その見本プロンプトの最後の段落に、次の文があります。
If the task is unreasonable or infeasible, or if any of the tests are incorrect, please inform me rather than working around them.
回避させずに知らせてもらう、という形は、未決定の点にもそのまま使えます。
## 未決定の点- 検索結果の1ページの件数: 推定 20 件(TBR)。決めるのは田中、10/3 まで。- 検索語が空のときの動作: 未決定。上の点に関わる実装が必要になったら、選ばずに知らせてください。
1つ目の項目は TBR の形で、推定値で進めてよいが確定ではないと伝えます。2つ目は推定値すら無い点で、ここに出会えば実装は選ぶ前に報告に回ります。
Anthropic の Prompting best practices にある見本 `please inform me rather than working around them` は、どんな場合に知らせるよう頼んでいますか。
要求文書の TBR
NASA 付録C は TBD を減らし、推定値に TBR を付けて根拠・担当者・期限を添えよと求めます。C.4 は、その一覧を要求とともに保つかを問います。
推定値 あり(TBR の印)担当者 あり期限 あり
AI への指示の未決定の欄
Anthropic の見本は、実行不能やテストの誤りに気づいたら回避せず知らせよと頼みます。同じ形を未決定の点に使い、選ばずに知らせてと書くのはこの教材の応用です。
未決定の点 あり(一覧)出会ったとき 選ばずに知らせる決める人 依頼した側
人が読む要求文書と、AI が読む指示文。読み手はまるで違いますが、未決定の点について両者がしていることの共通点は何でしょうか。
何も書かなかった場合、その点を決めるのは誰になるかを、両方で考えてみてください。
この章のまとめ
- 書き忘れと未決定は、読み手には区別できない。どちらも空白で、読み手が黙って選ぶ。
- Parnas と Clements は、開発開始までに情報が無い箇所を不完全と明示せよと受け入れ基準に入れた。
- NASA 付録C は TBD を減らし、推定値に TBR を付けて、根拠・解消の手順・担当者・期限を添えよと言う。担当と期限は TBR の側。
- Rust の RFC と PEP 12 のテンプレートも未決定の置き場を持つ。担当と期限まで問うのは NASA だけ。
- Anthropic の見本の「知らせよ」は実行不能とテストの誤りが条件。未決定の点への転用はこの教材の応用。
- このコースは、曖昧な1文からは正しい実装が2つ以上でき、読んだ側が黙って選ぶ、というところから始めました。書いたことは読み手を縛り、未決定と書いたことは読み手を止めます。書かなかったことだけが、実装した誰かに黙って決められます。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
Parnas と Clements(1986)が理想の要求文書の受け入れ基準に挙げた、開発開始までに情報が得られない箇所の扱いはどれですか。
用語集(3語)
- TBD(To Be Determined)
- 値がまだ決まっていないことを示す印。NASA 付録C C.3 は、TBD の使用は最小化すべきだとする。
- TBR(To Be Resolved)
- 推定値に付けて、まだ確定していないことを示す印。NASA 付録C C.3 は、根拠・解消に要すること・担当者・期限を添えるよう求める。
- 未決定の一覧
- この教材での呼び名。決めていない点を1か所に集めたもの。NASA 付録C C.4 は TBD・TBR の完全な一覧を要求とともに維持しているかを問う。
出典(一次ソース)
- NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev2, Appendix C(C.3 は印刷頁197〜198、C.4 は198) ↗
- D. L. Parnas, P. C. Clements, A Rational Design Process: How and Why to Fake It, IEEE TSE SE-12(2):251–257, 1986-02(リンク先は Tufts 大学の再組版。頁組は IEEE 版と異なる) ↗
- F. P. Brooks, No Silver Bullet, UNC TR86-020(1986-09)§5.2。IEEE Computer 20(4):10–19, 1987 にも掲載 ↗
- Rust RFC テンプレート 0000-template.md(Unresolved questions) ↗
- PEP 12 テンプレート pep-NNNN.rst(Open Issues) ↗
- Anthropic, Prompting best practices — Avoid focusing on passing tests and hardcoding(2026-09-24 取得) ↗