設計書の書き方ガイド / 2026年8月7日
1枚の図に、1つの役割
設計図が読みにくくなる原因の多くは、絵が下手なことではありません。1枚の図に複数の役割を詰め込んでいることです。書いた本人は仕組みが頭に入っているので読めますが、初めて見る人は「図を頭の中で何枚かに分解する」作業から始めることになります。
この資料では、身近な家族の例と、実際の注文書FAX処理システムの例を並べて、その直し方を示します。守っていただきたいことは3つだけです。
次の図は、ある家族3人の夕方の行動を1枚にまとめたものです。書いた人の頭の中では、きちんと整理されています。ですが初めて見る人に「お父さんはどこを通っておばあちゃんの家に着いたか」と聞くと、たいてい10秒では答えられません。実際に目で追ってみてください。

読みにくい原因は、絵の上手・下手ではありません。次の3つです。
3人ぶんの行動が、同じ紙の上で重なっている。「家」と「おばあちゃんの家」には何本もの線が集まっています。読み手はまず、絡まった線をほどく作業から始めることになります。
誰の行動かを、色でしか区別できない。青・緑・赤の意味は凡例にしか書いていません。線を1本追うたびに、図と凡例を目で往復することになります。
番号 ① ② が、図全体の順番になっていない。①が3つあり、それぞれ別の人の1番目です。この図の上には「全体で何が最初か」が存在しません。
読み手にさせているのは「1枚の図を、頭の中で3枚に分解する作業」です。それは本来、書く側が先に済ませておくべき作業です。図を分ければ、読み手の負担はそのままゼロになります。
まったく同じ内容を、人ごとに1枚ずつに分けます。1人ぶんだけなら線は一本道になるので、色分けも凡例も要らなくなります。各図には、その人の行動だけを、左から右へ時間の順に並べます。
17時50分に家を出て、歩いてスーパーへ向かう。
スーパーで、その日の夕食に使う食材を買う。
買った食材を持って、おばあちゃんの家へ向かう。
おばあちゃんの家に着いた時点で、お母さんの移動は終わり。
家を出る時刻:17時50分 / 家 → スーパー:徒歩8分
買うもの:豚こま肉 300g、玉ねぎ 2個、にんじん 1本、カレールー 1箱
スーパー → おばあちゃんの家:徒歩12分 / 到着 18時25分
17時40分におばあちゃんの家を出て、学校へ向かう。
学校の昇降口で、授業を終えた子供と合流する。
子供と一緒に、おばあちゃんの家へ歩いて帰る。
おばあちゃんの家に着いた時点で、おばあちゃんの移動は終わり。
家を出る時刻:17時40分 / おばあちゃんの家 → 学校:徒歩10分
合流場所:学校の昇降口 / 合流時刻:17時50分
学校 → おばあちゃんの家:徒歩10分(子供と一緒なので15分) / 到着 18時05分
18時に仕事を終え、会社を出る。
洋菓子店でケーキを買って帰宅。
身支度をして、おばあちゃんの家へ向かう。
おばあちゃんの家に着いた時点で、お父さんの移動は終わり。
会社を出る時刻:18時00分 / → 洋菓子店まで5分
洋菓子店での滞在: 5分 → 家:電車と徒歩で35分
家での滞在:10分(かばんを置き、上着を替えるだけ)
家 → おばあちゃんの家:徒歩15分 / 到着 19時10分
とても分かりやすくなっていませんか?
3枚に分けた結果、1枚あたりの線は一本道になりました。色分けも凡例も番号も要りません。読み手は3枚を順に見るだけで済みます。
「全員が最後にどこへ集まるか」といった全体の話は、図を重ねるのではなく、次のような表で示せば十分です。
誰が | 出発地 | 経由 | 到着地 | 目的 |
|---|---|---|---|---|
お母さん | 家 | スーパー | おばあちゃんの家 | 夕食の食材を届ける |
おばあちゃん | おばあちゃんの家 | 学校 | おばあちゃんの家 | 子供を迎える |
お父さん | 会社 | 洋菓子店、家 | おばあちゃんの家 | 仕事の後に合流する |
「1つの役割につき1枚の図」+「全体の関係は表か、中身を描かない1枚の図」。この組み合わせが、いちばん読み手の負担が小さくなります。以降のシステムの例も、まったく同じ形で書きます。
この家族のある日の物語を設計図のように書かれていますが、書かれていないことがいくつかあります。これを読んだ人はわかりますよね。
書き手が知っている当たり前のことを読み手は知りません。「ケーキはどうなった?」と読み手の誰もが思っています。
書き終えたら読み手の気持ちになって読み返してみることも大切です。
次の図は、注文書のFAXを複合機で受信し、担当者が内容を確認してから複合機で返信する仕組みを1枚にまとめたものです。家族の図とまったく同じことが起きています。

この1枚には、次の7つの役割が同時に描かれています。
# | 役割 | この図の中でしていること |
|---|---|---|
1 | 取引先 | 注文書をFAXで送る |
2 | 受信側 複合機 | FAXを受け取り、PDFにして保存する |
3 | アプリ①(受信FAX振り分け) | ファイル名のFAX番号でCSVを引き、担当者に配信する |
4 | 担当者A・B・C | 内容を確認し、必要なら返信FAXを用意する |
5 | アプリ②(返信FAX送信) | ファイル名のFAX番号を宛先として送信を指示する |
6 | 送信側 複合機 | 実際にFAXを送る |
7 | サーバー・設定ファイル・ログ | 上記の置き場所と、記録 |
右下に「凡例(処理の流れ)」と「処理フロー(概要)」の2つがあります。図の外に説明を足さないと読めない図は、図として成立していません。しかも「処理フロー(概要)」に ① 〜 ⑨ の9行が書けているのなら、その9行こそが本体です。図はその9行を分解して描くべきものでした。
同じ「→」で、次の3つが描かれています。読み手は矢印を1本見るたびに、これがどれなのかを判断することになります。
物が移動する(FAXの用紙、PDFファイル)
プログラムが参照する(CSVを読む、設定ファイルを読む=点線)
人が判断して次へ渡す(担当者が確認して返信を用意する)
図の中に「受信FAX番号」と「宛先FAX番号」が出てきます。どちらも取引先の番号ですが、前者は「送ってきた人の番号」、後者は「これから送る先の番号」で、システムの中では別々に扱われます。初めて読む人がいちばんつまずくのがここです。
この図は、丁寧に描かれています。アイコンも配置も整っていて、情報も正確です。問題は、描き方ではなく「1枚に詰め込んだこと」だけです。次の章では、この図をそのまま4枚に分けます。絵の描き方は一切変えません。
図を役割ごとに分けると、図と図をつなぐものは線ではなく「どこに、何という名前で置くか」だけになります。ですから最初に、置き場所の名前を決めて一覧にします。以降の図と文章では、ここに載っている名前しか使いません。
全体図に重要な情報はかかない。
役割ごとに分けると「全体でどうつながっているか」が見えにくくなります。それを補うのが、この1枚です。処理の中身は一切描きません。誰がいて、何を、どこ経由で渡すかだけを書きます。
※ 送信側の複合機は ④ の中に出てきます。アプリ②が「送りなさい」と指示する相手だからです。この図に登場する箱の数が全体の役割の数で、以降の4枚がその中身にあたります。
取引先が注文書をFAXで送信すると、受信側複合機がそれを受け取る。
受け取った用紙のイメージを、1件の通信につき1つのPDFにまとめる(3枚送られてきたら3ページのPDFになる)。
共有フォルダ \\SERVER\FAX\10_受信\ に、次の規則で名前を付けて保存する。
「送信元のFAX番号 10桁」+「_」+「受信した日時 14桁」+「.pdf」
保存したら、複合機の仕事は終わり。誰にも通知しない。この後はアプリ①がフォルダを見に来る。
送信元のFAX番号:03-1234-5678 → ハイフンを取り除いて 0312345678
受信した日時:2025年6月1日 10時15分00秒 → 20250601101500
できあがるファイル:
\\SERVER\FAX\10_受信\0312345678_20250601101500.pdf
送信元が番号非通知の場合、番号の部分が unknown になります(例:unknown_20250601101500.pdf)。このPDFは次のアプリ①で担当者を特定できないため、「一致する行が無かったとき」の扱いになります。
\\SERVER\FAX\10_受信\ を見て、増えているPDFを1つ取り出す。
ファイル名の「_」より前の部分を、送信元のFAX番号として取り出す。
担当者マスタ.csv を1行ずつ読み、1列目(受信FAX番号)が 2 で取り出した番号と一致する行を探す。
一致する行が見つかったら、その行の4列目(メールアドレス)宛に、PDFを添付したメールを送る。
一致する行が見つからなかったら、あらかじめ決めておいた未割当担当者宛に送り、件名の先頭に【要確認】を付ける。
送り終えたPDFを 11_受信済み へ移す。同じPDFを二度配信しないためである。
増えているPDFが無くなるまで、1 〜 6 を繰り返す。
取り出したファイル名:0312345678_20250601101500.pdf
「_」より前 → 0312345678
担当者マスタ.csv の中身(1行目は見出し):
受信FAX番号,担当者名,担当者コード,メールアドレス 0312345678,担当者A,A,a@example.com 0355551234,担当者B,B,b@example.com 0666669876,担当者C,C,c@example.com
1列目が一致する行 → 2行目。担当者A(a@example.com)と分かる。送るメールは次のとおり。
宛先:a@example.com 件名:注文書FAXを受信しました(0312345678 / 06-01 10:15) 添付:0312345678_20250601101500.pdf
一致する行が無かったとき(例:unknown_20250601101500.pdf):
宛先:kanri@example.com(未割当担当者) 件名:【要確認】担当者が特定できないFAXを受信しました(unknown) 添付:unknown_20250601101500.pdf
届いたメールを開き、添付のPDFで注文書の内容を確認する。
返信が要らない注文書であれば、ここで終わり。フォルダには何も置かない。
返信が要る場合は、返信する文書を作ってPDFにする。
そのPDFのファイル名を、返信先のFAX番号だけにする。ハイフンや文字は入れず、数字だけにする。
\\SERVER\FAX\20_送信\ に置く。置いた時点で担当者の作業は終わり。送信はアプリ②が行うので、複合機を操作する必要はない。
受け取ったメールの件名:注文書FAXを受信しました(0312345678 / 06-01 10:15)
返信先のFAX番号:05-2222-3333 → ハイフンを取り除いて 0522223333
置くファイル:
\\SERVER\FAX\20_送信\0522223333.pdf
返信_0522223333.pdf や 0522223333(1).pdf のように文字を足すと、数字以外が入っているためアプリ②は送信せず 90_エラー へ移します。
同じ宛先へ短い間に2通送るとき、ファイル名が重なります。2通目はどう置きますか。
0522223333_2.pdf のように「_」+連番を認め、アプリ②は「_」より前を宛先として扱う、という取り決めにします。例を1つ書いたことで見つかった抜けです。
\\SERVER\FAX\20_送信\ を見て、増えているPDFを1つ取り出す。
ファイル名から拡張子(.pdf)を除く。「_」が含まれていれば、その前までを取り出す。取り出した文字列を宛先FAX番号とする。
宛先FAX番号が数字だけかを確かめる。数字以外が入っていたら送信せず、90_エラー へ移して 5 の記録だけを行う。
送信側複合機に、宛先FAX番号とPDFを渡して送信を指示する。複合機からは、送信の成功か失敗が返ってくる。
送信結果ログ.csv に1行書き足す(日時・宛先FAX番号・ファイル名・結果・エラー内容)。
成功したPDFは 21_送信済み へ、失敗したPDFは 90_エラー へ移す。
増えているPDFが無くなるまで、1 〜 6 を繰り返す。
取り出したファイル:0522223333.pdf → 宛先FAX番号 0522223333
連番が付いていた場合:0522223333_2.pdf → 宛先FAX番号 0522223333
送信結果ログ.csv に書き足す1行(成功・失敗・ファイル名不正の順):
2025/06/01 10:36,0522223333,0522223333.pdf,OK, 2025/06/01 10:37,0987654321,0987654321.pdf,NG,通信エラー(相手先話中) 2025/06/01 10:38,,返信_0522223333.pdf,NG,ファイル名に数字以外が含まれる
複合機の仕事が言い切れるようになった。元の1枚では複合機が2か所に登場し、「複合機とは何をする箱なのか」がぼやけていました。分けたことで、受信側は「保存して終わり・通知しない」、送信側は「指示されたら送るだけ」と1行で言えるようになりました。
CSVとログの担当がはっきりした。CSVを読むのはアプリ①だけ、ログを書くのはアプリ②だけです。元の1枚では、どちらもサーバーの箱の中にあり、誰が触るのか図からは読めませんでした。
設計の抜けが1つ見つかった。同じ宛先へ2通送るときのファイル名の重なり(4-5 の付箋)です。図を眺めているだけでは出てこず、手順を順番に文章で書き、実際のファイル名の例を並べた瞬間に気づきました。
ここまでの内容は、次の3つに集約できます。作図ツールも記法も問いません。手書きでも構いません。この3つだけ守ってください。
1枚の図に描くのは、1つの役割(1人・1台・1本のプログラム)の動きだけにします。他の役割は、図の左端に「どこから受け取るか」、右端に「どこへ渡すか」として出てくるだけにします。
役割の数だけ図を作ります。7つの役割があれば7枚です。1枚が小さくなることを恐れる必要はありません。図は枚数ではなく、1枚あたりの読みやすさで評価されます。
見分け方 ―― その図に凡例が必要なら、たいてい役割が混ざっています。1つの役割だけを描いた図は線が一本道になるので、色分けそのものが要らなくなります。
取引先 → 複合機 → サーバー → アプリ① → 担当者 → アプリ② → 複合機 → 送信先を1枚に。
矢印9本 / 線の色4種類 / 凡例2つ / 読むのに凡例との往復が必要。
① 受信側複合機 / ② アプリ① / ③ 担当者 / ④ アプリ② の4枚。
1枚あたり矢印3本 / 色分けなし / 凡例なし / 上から順に読むだけ。
図は「どこに何があるか」は示せますが、「どういうときに、何をするか」は示せません。そこは文章の仕事です。図で説明しきろうとせず、図と文章で分担します。
番号を振り、1文に1つの動作だけを書く。
主語(誰が・何が)を毎回書く。省くと、読み手は前の文から推測することになる。
「〜する」と言い切る。「〜される」「〜となる」は誰がするのか消えてしまう。
① 動くきっかけ
誰が・いつ動かすのか。人が押すのか、常駐して監視しているのか、決まった時刻なのか。
② 受け取るもの
どこから、何を受け取って始まるのか。フォルダ名・ファイル名まで書く。
③ 判断すること
どういうときに、どちらへ進むのか。「一致したら」「無かったら」を両方書く。
④ 渡すもの
どこに、何を置いて終わるのか。ここが次の役割の「② 受け取るもの」と一致する。
受信FAXを解析し、担当者を特定して適切に配信する。
「解析」「特定」「適切に」が何を指すのか、読み手には分かりません。作る人ごとに別のものができます。
10_受信 を10秒ごとに見て、増えたPDFを1つ取り出す。
ファイル名の「_」より前を、送信元FAX番号として取り出す。
担当者マスタ.csv の1列目と照合し、一致した行の4列目のアドレスへPDFを添付して送る。
一致しなければ、未割当担当者へ【要確認】を付けて送る。
「適切に」「必要に応じて」「よしなに」「所定の」——これらが出てきたら、そこはまだ決めていない箇所です。何をもって適切とするかを書けば、そのまま設計になります。
文章で丁寧に書いても、読み手が思い浮かべる「実物」は書き手のものと違います。実物を1つ載せれば、その差はその場で消えます。
実際のファイル名と、フォルダのフルパス
CSV・ログ・設定ファイルの中身を数行そのまま
メールの宛先・件名、画面に出るメッセージの文言
変換の前と後(03-1234-5678 → 0312345678 のように)
例は「それっぽい名前」ではなく、実際に動かしたときに出てくる文字列をそのまま貼ります。ファイル名.pdf ではなく 0312345678_20250601101500.pdf です。
ファイル名はFAX番号+日時とする。
区切り文字は? ハイフンは入る? 日時は何桁? 番号が取れなかったら? ——すべて読み手の想像に任されています。
0312345678_20250601101500.pdf
FAX番号10桁(ハイフンなし)+「_」+受信日時14桁。番号非通知のときは unknown_20250601101500.pdf。
この資料でも実際に起きました。返信PDFの例を 0522223333.pdf と書いた瞬間に、「同じ宛先に2通送ったらファイル名が重なる」ことに気づいています(4-5)。例は、読み手のためだけでなく、書き手が自分の設計を点検するための道具でもあります。
以下は、上の3つを実際にやってみると必ずぶつかることへの備えです。3つのポイントほど絶対ではありませんが、効果の大きいものを選びました。
役割ごとに分けると、全体のつながりが見えにくくなります。これが分割の唯一の副作用です。対策は、箱は役割名だけ・矢印には受け渡すものの名前だけを書き、処理は一切描かない図を1枚だけ作ることです(4-2 がそれにあたります)。この1枚が目次の役割をします。
この図が複雑になるなら、それは図ではなくシステムの役割分担そのものが複雑だという合図です。
分けた図をつなぐのは、線ではなく名前です。役割①の出口に書いた 10_受信 と、役割②の入口に書いた 10_受信 が同じ文字列であることだけが、2枚のつながりを保証しています。
よくある失敗は、役割①では「受信フォルダ」、役割②では「FAX保存先」と書いてしまうことです。書いた人には同じものでも、読む人には別のものに見えます。4-1 のような受け渡し場所の一覧を先に作り、以降はそこに載っている名前しか使わないようにします。
設計書で最も抜けやすいのがこれです。書いていないと、運用する人は「止まっているのか、まだ動いていないだけなのか」を判断できません。
役割 | 動くきっかけ | 間隔・タイミング |
|---|---|---|
① 受信側複合機 | FAXの着信 | 常時待ち受け |
② アプリ① | フォルダ監視(自動) | 10秒ごと |
③ 担当者 | メールの受信(人が行う) | 業務時間内 |
④ アプリ② | フォルダ監視(自動) | 10秒ごと |
この表があると、「FAXが届いてから担当者のメールに届くまで最大何秒か」が計算できます(最大10秒+メール送信時間)。書いていなければ、誰にも答えられません。
正常に流れたときの一本道をまず描き切り、失敗したときの行き先は表にします。一つの処理毎に失敗する可能性を考えて洗い出します。
どういうとき | ファイルの行き先 | 記録 | 誰が気づくか |
|---|---|---|---|
受信FAX番号がCSVに無い | 11_受信済み | — | 未割当担当者(メールで届く) |
宛先が話中で送れない | 90_エラー | ログに NG/通信エラー | 決まっていない |
ファイル名に数字以外がある | 90_エラー | ログに NG/ファイル名不正 | 決まっていない |
90_エラー に入ったファイルは、誰がいつ見ますか。
毎朝の当番が見るのか、失敗時にメールを出すのかを決めておかないと「送ったつもり」が起きます。表を作ると、決まっていない欄が自分から浮かび上がります。
人が入力したデータは必ずチェックしてください。すべてエラーにせず、補正が可能なものは補正を行ってから加工後の文字のチェックを行うとよい設計になります。
プログラムで簡単に加工が可能な処理というのは以下のようなものがあります。
先頭と末尾のスペースを除去。
大文字・小文字の統一。
処理系によって簡単にできない場合もある処理
全角から半角に変換。
ひらがな・カタカナの変換。
同じものを2通りの言葉で呼ぶと、読み手はその都度「同じものか」を考えます。特に今回のような、似た番号をいくつも扱う仕組みでは致命的です。
この資料での言い方 | 意味 | 例 |
|---|---|---|
受信FAX番号 | 注文書を送ってきた取引先の番号。受信PDFのファイル名の先頭に入る |
|
宛先FAX番号 | 返信FAXを送る先の番号。送信PDFのファイル名そのもの |
|
受信PDF | 複合機が保存した、注文書のPDF |
|
送信PDF | 担当者が作った、返信のPDF |
|
担当者マスタ | 受信FAX番号と担当者を対応づけたCSV |
|
「FAX番号」とだけ書かないこと。受信側か宛先かで、まったく別の番号です。元の1枚の図では両方が「FAX番号」と書かれており、初めて読む人がいちばんつまずく箇所でした。
ひとつの処理で扱うデータはその処理の記事内にできるだけ集約してください。
離れた場所に情報があると、仕様書の場所を行き来することになり、理解にとても時間がかかります。
設計書を書き終えたら、次の項目を確認してください。自分で読み返すより、その仕組みを知らない人に1枚だけ見せて、読んでもらうのがいちばん確実です。詰まったところが直すべき箇所です。
この図に描かれている役割は、1つだけか
図に凡例が必要になっていないか(必要なら、まだ混ざっている)
図の左端に「どこから受け取るか」、右端に「どこへ渡すか」が書いてあるか
その名前は、前後の図で使っている名前と一字一句同じか
誰が・いつこの処理を動かすのかが書いてあるか
手順は番号付きで、1文に1つの動作になっているか
「適切に」「必要に応じて」で済ませた箇所が残っていないか
実際のファイル名・フォルダ名・データの中身の例が載っているか
失敗したときの行き先と、それに誰が気づくかが書いてあるか
同じものを、2通りの言葉で呼んでいないか
情報の記載場所は適切か
読み手の気持ちで読んでみたか
この資料自体も、3つのポイントに沿って書いています。図は1枚に1つの役割だけ、手順は番号付きの文章、例はすべて実際に出てくる文字列です。特別な技術は使っていません。分けて、順番に書いて、実物を1つ載せる。それだけで、初めて読む人に伝わる設計書になります。