マニュアル
依頼を受けた直後に開く1冊です。相手の頭の中にある要件を引き出し、他人が読んで作業できる形に落とすまでを扱います。仕様書が無ければ、作業を分けることも、AIに任せることもできません。すべてはここから始まります。
定義 仕様書とは、その場にいない人が読んで作業できる文書です。
依頼者にも、自分にも、質問できない状態で読まれることを前提に書きます。
形式ではなく、性質で判定してください。次の4つを満たしていれば、章立てが何であっても仕様書として機能します。逆に1つ欠けると、読んだ人がそこで止まるか、自分で埋めて進みます。後者のほうが危険です。
| 性質 | 満たしていない状態 |
|---|---|
| ① 完了条件が、他人に判定できる形で書いてある | 「使いやすくなっている」のように、書いた本人にしか判定できない |
| ② 担当ごとに切り分けられる構造になっている | 全体が1つの塊で、どこからどこまでを誰が担当するか決められない |
| ③ 決まっていないことが、未決として明示されている | 未決が空欄になっている。または決まった風に書かれている |
| ④ 前提と制約に、根拠が書いてある | 「4月まで」とだけあり、なぜ4月かが分からない |
4つのうち最も欠けやすいのは③です。依頼を受けた時点で決まっていないことは必ずあります。それを空欄にすると、読んだ人が自分で埋めます。複数人・複数のAIで作業する場合、各自が違う前提で埋めるため、統合したときに破綻します。
仕様書ができて初めて、作業を分けるかどうかの判断に進めます。
仕様書を書く段階は、分割しません。ここで並列にすると、担当ごとに違う前提の仕様書ができます。分割の判断は、仕様書が確定してからです。
所要時間の目安は、案件全体の1割です。3日かかる案件なら3時間程度。これを超える場合は、依頼の範囲が広すぎるか、決まっていないことが多すぎます。どちらも、仕様書を書き続けるのではなく、依頼者に戻すべき状態です。
依頼は「全体を見直したい」「これをまとめてほしい」の形で来ます。要件は相手の頭の中にあり、多くの場合、相手自身も言語化していません。
次の15問を順に聞きます。全問を一度に聞かないでください。群ごとに区切り、答えを記録してから次に進みます。
| 実際に口に出す言葉 | この質問が防ぐこと |
|---|---|
| 群1 目的|なぜやるのか | |
| これをやらなかったら、何が困りますか | 目的が曖昧なまま、体裁だけ整った成果物ができる |
| 終わったとき、誰の何が変わっていますか | 成果物の受け手が不明で、粒度が決められない |
| うまくいったと判断するのは、どなたですか | 承認者が不在で、いつまでも確定しない |
| 群2 範囲|どこまでやるのか | |
| 今回は対象に含めない、と決めているものはありますか | 範囲が際限なく広がる |
| 似ているけれど、別扱いにするものはありますか | 担当境界が引けず、分割できない |
| 関係する部署や取引先は、どこまでですか | 後から関係者が増え、前提が変わる |
| 群3 制約|動かせない条件は何か | |
| 動かせない期限や条件はありますか。その根拠は何ですか | 根拠のない制約に縛られ、無理な設計になる |
| 変えてはいけないもの、触ってはいけないものはありますか | 取り返しのつかない変更 |
| 過去に同じことを試して、うまくいかなかったことはありますか | 同じ失敗を繰り返す |
| 群4 判定|何ができたら終わりか | |
| できあがったものを、どなたが、何を見て確認しますか | 完了条件が形容詞になる |
| これがあったら差し戻し、というものはありますか | 提出後の大きな手戻り |
| いつまでに確認できますか | 確認待ちで作業全体が止まる |
| 群5 未決|まだ決まっていないことは何か | |
| 今の時点で、まだ決まっていないことはどれですか | 決まった風の記述が仕様書に入る |
| それは、いつ、どなたが決めますか | 未決が放置され、締切直前に露見する |
| 決まるまで待つべきですか。仮に決めて進めてよいですか | 作業者が勝手な前提で進める |
群5を必ず聞いてください。群1〜4だけで終えると、答えられなかった箇所が空欄になり、それが未決なのか、聞き漏らしなのか、区別できなくなります。群5は「答えられなかったこと」を未決として確定させるための質問です。
「わからない」「お任せします」と返ってくることがあります。そこで引き下がらず、次の順に試してください。
3で終えることは失敗ではありません。未決だと分かっている状態は、決まったと誤解している状態よりはるかに安全です。
同じ質問でも、聞き方で得られる情報が変わります。
相手は反射的に同意します。とくに相手が忙しいときほど同意率が上がり、後から違ったと分かります。
「対象は正社員のみでよろしいですか」
「正社員以外を対象に含めるとしたら、どういう場合ですか」
言い換えると意味が変わります。とくに業界用語や社内の呼び名は、こちらの解釈で置き換えないでください。意味が分からない語は、その場で聞いて、聞いた説明ごと記録します。
4問以上まとめて聞くと、相手は答えやすいものだけ答えます。答えなかった問いは、聞いていない扱いになって消えます。群ごとに区切るのはこのためです。
3回以上重ねると詰問になります。2回で根拠に届かない場合は、「その決まりは、いつ頃からのものですか」と、時期を聞く形に切り替えてください。制約の根拠が組織の慣習である場合、これで背景まで出てきます。
聞いた内容をその場で箇条書きにし、画面か紙で相手に見せます。認識のずれは、文字にした瞬間に見つかります。持ち帰ってから清書すると、ずれたまま確定します。
業務の種類によらず、この7項目で成立します。業務ごとの中身は、この枠の中に入れてください。
分量の上限は、担当1つあたり1ページです。3担当に分ける想定なら3ページ。これを超える仕様書は読まれません。超える場合は、範囲が広すぎるか、作業手順まで書き込んでいます。仕様書に手順は書きません。何ができたら終わりかだけを書きます。
7項目のうち、最も省略されやすく、最も効く欄です。含まないものが書いていない仕様書は、作業者が範囲を自分で判断します。「今回は触らない」と明記された箇所は、誰も触りません。この1行が、後半の手戻りをまとめて防ぎます。
さらに一歩進めて、やれるがやらない理由を添えてください。理由が無いと、次に読んだ人が「なぜやらなかったのか」を考え、良かれと思って足します。
対象外:多言語対応
対象外:多言語対応(対応は可能だが、今回の利用者は日本語のみのため。必要になった時点で別案件とする)
誰が確認して確定させるかを、目的の欄に1行で入れてください。項目を増やすと守られなくなるため、独立した欄にはしません。承認者が書かれていない仕様書は、完成しても確定しません。確認待ちで止まったとき、誰に催促すればよいか分からなくなります。
次の語は、読んだ人が意味を自分で決めます。とくに「等」「など」は、その中身を作業者が勝手に定義します。
| 使わない語 | 置き換え方 |
|---|---|
| 等、など | 中身を全部列挙する。列挙できないなら「以下に限る」と書く。それもできないなら、未決事項に移す |
| 原則として、基本的に | 例外を列挙する。例外が思いつかないなら、この語を削る |
| 必要に応じて、適宜 | どういう場合かを条件で書く。「◯◯のときは」の形にする |
| 速やかに、可能な限り | 期限を日数か時間で書く |
確定前に、この4組を検索して確認してください。1件も見つからない仕様書は稀です。
この章がこのマニュアルの中心です。
未決を書くとき、内容だけを書いて終わりにしないでください。決まるまでどうするかを、必ず3つのうち1つに決めます。
選ばないという選択肢はありません。空欄にすると、作業者が自動的に「仮置きで進める」を選び、しかもその仮の値を書き残しません。
| 扱い | 選ぶ条件 |
|---|---|
| 停止する | その未決が、他の作業の前提になっている場合。決まらないまま進めると、決まった後に全部やり直しになる |
| 仮置きで進める | 後から差し替えられる場合。仮の値と、差し替え箇所を明記する |
| 両方作る | 期限が近く、どちらに決まっても間に合わせる必要がある場合。工数が2倍になるので、他に手がないときだけ |
対象部署について調整中
→ 誰がいつ決めるか不明。読んだ人が待つべきか進むべきか判断できない
対象部署の範囲|決定者:先方の総務部長|期限:3月10日|扱い:仮置きで進める(仮に本社3部署とし、第2章の該当箇所に印を付ける)
未決が0件の仕様書は疑ってください。着手時点で全部決まっていることは、ほぼありません。0件と書かれている場合、聞けていないだけの可能性が高い。第3章の群5を実施したか確認してください。
判定は1つです。第三者が◯×を付けられるか。
自分にしか判定できない完了条件は、完了条件ではありません。作業を任せた相手が「終わりました」と言ってきたとき、その判断が正しいか確認できる形にしてください。
使いやすい管理画面になっている
管理者が、3クリック以内に対象者を検索して停止できる
規程が最新の法令に対応している
指定した改正5件それぞれについて、該当条文の新旧対照表が存在する
分かりやすい資料になっている
対象読者3名に読んでもらい、追加質問なしで内容を説明できる
「使いやすい」「分かりやすい」「適切な」「十分な」が出てきたら、そこは未完成です。次の問いで置き換えてください。
3問すべてに答えられない完了条件は、仕様書から外してください。判定できない条件を残すと、そこだけが最後まで確定せず、案件全体の完了が止まります。
判定できる形をさらに一歩進めると、そのまま点検手順になります。ソフトウェア開発では、完了条件をこの形式で書くのが標準です。
退職者が一覧に表示される
前提:退職済みの従業員が1名いる
操作:管理者がその人を氏名で検索する
結果:一覧に表示され、状態が「退職」と出る
この形にすると、完了条件がそのまま確認手順になります。別に点検表を作る必要がなくなります。作業を任せる相手にも、この3点セットをそのまま渡せます。
ここが、経験のある書き手とそうでない書き手の差が最も出る箇所です。うまくいく場合だけを書いた仕様書は、半分しか書けていません。残り半分を書かないと、作業者が自分で決めます。
| 種別 | 問い | 非コード案件での例 |
|---|---|---|
| 異常系 | 該当しないとき、権限が無いとき、既にその状態のときはどうするか | 就業規則で、規定の対象者に該当しない人が出た場合の扱い |
| 境界値 | 0件のとき、1件のとき、極端に多いときはどうするか | 該当者が0人のとき/月の途中で入社し、同月に退社したとき |
| 重複・同時 | 2つ以上が同時に当てはまったらどうするか | 複数の手当の支給要件を同時に満たす場合、両方支給するか一方か |
3種別それぞれについて、1つも書くことが無いという結論は稀です。思いつかない場合、まだ対象を具体的に想像できていません。第3章の群2(範囲)に戻ってください。
対象が「在籍・休職・退職」のように状態を持つ場合、取りうる状態を全部挙げ、どの状態からどの状態へ移れるかを表にします。
| 現在 \ 次 | 在籍 | 休職 | 退職 | 削除済 |
|---|---|---|---|---|
| 在籍 | — | 可 | 可 | 不可 |
| 休職 | 可 | — | 可 | 不可 |
| 退職 | ? | 不可 | — | 可 |
| 削除済 | 不可 | 不可 | 不可 | — |
この表を作ると、必ず「?」の欄が出ます。退職者を在籍に戻せるか。誰も考えていなかった箇所です。書かないまま進めると、作業者が「たぶん可」で作ります。「?」が出た欄は、その場で決めるか、第6章の未決事項に移してください。
分割並列型を使う予定がある場合、仕様書の段階で対応しておきます。
仕様書が完成しても、そのままでは分割できないことがあります。原因は1つで、対象範囲が塊で書かれているためです。
就業規則の全体を、最新法令に合わせて見直す
就業規則のうち、第2章(服務)、第3章(労働時間)、第4章(賃金)、第6章(懲戒)を見直す。第1章・第5章は今回対象外
違いは、章番号で列挙されているかどうかだけです。右の書き方であれば、そのまま4担当に割り当てられます。左の書き方だと、分割の前に範囲を確定させる作業が別途発生します。
分割する場合、担当をまたいで使われるものが必ずあります。用語の定義、書式、参照する数値、判断基準など。これらを仕様書の段階で洗い出し、7項目のうち「用語定義」に入れておいてください。
洗い出しの問いは1つです。「複数の担当が同じものを見る必要があるのは何か」。これに挙がったものが、分割並列型でいう土台担当の作業対象になります。
採用した案だけを書くと、読んだ人が「もっと良い方法があるのでは」と考え、検討済みの案に戻ります。検討したが採用しなかった案を2〜3個、却下理由つきで書いてください。
効果は2つあります。作業者が迂回するのを防げること。そして半年後に自分が読み返したとき、なぜこの形になったかを思い出せることです。
AIに作業を任せる場合、この欄が特に効きます。却下理由が書かれていないと、AIは良かれと思って却下済みの案を提案してきます。担当が複数あれば、その分だけ同じ提案が繰り返されます。
仕様書は必ず変わります。担当ごとに違う版を見ている状態は、分割並列型では致命的です。土台担当が確定させた版を全担当が参照していることを、保証できなくなります。
担当への指示には、版番号まで書いて渡してください。「仕様書を見て」ではなく「仕様書 v1.2 を見て」と書く。版が上がったら、全担当に更新を伝え、影響がある箇所を名指しします。
ここまで済んだら、分割並列型の教材 第4章の4問に進んでください。仕様書ができている状態なら、問1と問2はほぼ確実に判定できます。
仕様書を確定させる前に、全項目を照合してください。
| 失敗 | 早い段階で現れる兆候 | 対処 |
|---|---|---|
| 依頼者の言葉を要約して、意味が変わった | 仕様書に、依頼者が使っていない語が出てくる | 元の言葉に戻し、意味が分からない語はその場で聞く。要約は確定後にする |
| 未決を空欄にした | 未決事項の欄が0件、または内容だけで決定者が無い | 第3章の群5を実施し直す。0件のまま進めない |
| 完了条件が形容詞のまま残った | 「判定者は誰か」に答えられない条件がある | 第7章の3問で置き換える。答えられないものは削除する |
| 仕様書に作業手順を書き込んだ | 分量が想定の2倍を超えた | 手順を削る。仕様書は「何ができたら終わりか」だけを書く |
| 制約の根拠が分からないまま設計した | 「なぜこの期限か」に答えられない | 依頼者に時期を聞く。根拠が慣習なら、変更可能かを確認する |
| 正常系だけ書いて、例外の扱いを書かなかった | 完了条件がすべて「〜できる」で終わっている | 第7章の3種別(異常系・境界値・重複)で洗い直す。作業者が自分で決めた箇所を全件確認する |
| 担当ごとに違う版の仕様書を見ていた | 指示に版番号を書かず「仕様書を見て」とだけ伝えた | 版番号を付けて配り直し、差分を名指しで伝える。統合後に発覚した場合、影響範囲の特定に時間がかかる |
| 仕様書を見せずに作業を始めた | 依頼者の確認を「後でまとめて」にした | 予防のみ。着手前に必ず見せる。この失敗は、作業が進むほど損失が大きくなる |
最も損失が大きいのは最終行です。仕様書は、依頼者に見せて一致を確認した時点で初めて成立します。見せていない文書は、自分の理解のメモにすぎません。