この資料の読み方
Day1 のアンケートに、Markdownの書き方と要件定義の作業が分からず、ついていけなかったという声がありました。この資料は、その2つを [15min]ほどで読める量にまとめたものです。
時間に余裕のある方は、目を通しておいてください。Day2の前でも、当日でも構いません。演習の手順は、この資料を読んでいなくても進められるように書いてあります。
Markdownの書き方
記号の意味が分かると、メモ帳で開いたファイルの中身と、Claudeが返したファイルの直しどころが読めます。
7つの記法
研修で作るファイルの大半は、拡張子が.mdのMarkdownです。行頭や文の前後に記号を付けて、見出しや表を文字だけで書く方式で、メモ帳で書けます。Claudeも同じ形式で書くので、記号の意味が分かると、返ってきたファイルの直しどころが見えます。
| 書き方 | 意味 | 研修での使いどころ |
|---|---|---|
# 見出し、## 見出し | 行頭の#で見出しになる。#が増えるほど小さい見出し | 要件定義書の章。画面設計書は##の見出しごとにExcelのシートが1枚できる |
- 項目 | 行頭に-と空白を置くと箇条書き | メモ、確認事項 |
1. 手順 | 行頭に数字と.と空白を置くと番号付きの箇条書き | 手順のメモ |
| 列1 | 列2 | | |で区切ると表。1行目が列名で、2行目の|---|---|が区切り | 要件一覧、確認事項、入力チェック |
**太字** | **で囲んだ部分が太字 | Claudeの応答の強調 |
`コード` | `で囲むと、ファイル名やコマンドを本文と区別できる | Claudeの応答のファイル名 |
```で囲む | ```の行で挟んだ複数行を、そのまま表示する | 図を文字で書くMermaid（画面遷移.md） |
表の1行を読む
要件一覧は、次のような表です。1行が1つの要件で、列は左から、要件ID、要件、分類、根拠、発言者、要確認と並びます。
| 要件ID | 要件 | 分類 | 根拠 | 発言者 | 要確認 | |---|---|---|---|---|---| | REQ-002 | 1日の作業時間の合計が24時間を超えたらエラーにする | 機能 | 改修依頼書_KINTAI-2026-03:L27 | 情報システム課 | | | REQ-022 | 画面は今と同じくらいの速さで表示する | 非機能 | ヒアリングメモ_03:L87 | 佐藤さん | 秒数が無い |
根拠のヒアリングメモ_03:L87は、ヒアリングメモ_03.mdの87行目を示す書き方です。メモ帳で開いてCtrl+Gを押し、87を入れると、その行へ飛べます。要確認の列が空でない行は、メモだけでは決まらない要件を表します。
見出しの入れ子
#の数が章の深さです。次の例は、3章の下に3.1の節がある形です。
## 3. 対象範囲 ### 3.1 改修の対象 - 工数入力画面（KIN030） - 収支ダッシュボード（PJ010、新設）
メモ帳で開くときの設定
#や|が画面に出ません。空行も行数に入らないので、根拠の行番号とずれます。表示の右端で折り返すの印も外しておくと、行番号と画面の行が一致します。つまずきやすいところ
- 表の2行目の
|---|---|を消すと、表として読まれません。Excelへの変換も失敗します。 - 表の区切りの
|が全角の｜になっても、表になりません。 - メモ帳で保存するとき、ファイルの種類はすべてのファイル(*.*)、エンコードはUTF-8にします。違うと、拡張子が.txtになったり、Claudeや変換ツールが文字を読み違えたりします。
要件定義の作業
Day1 で通る5段階と、要件の分類をまとめます。
作業の流れ
要件定義は、依頼書やヒアリングで聞いた話から、システムで実現することを決める作業です。研修のDay1が、次の5段階を順に通ります。
| 段階 | やること | 出てくるもの | 研修での場所 |
|---|---|---|---|
| 話を集める | 依頼書とヒアリングメモを読み、誰が何に困っているかを拾う | 手書きのメモ | D1-1 STEP 1、D1-2 STEP 1 |
| 要件を取り出す | 話を「システムが何をするか」の1文にして、メモの行番号を根拠に付ける | 要件一覧 | D1-2 STEP 2〜4 |
| 食い違いを見つける | 人によって言うことが違う話題に、要確認と書く | 要件一覧の要確認の列 | D1-2 STEP 3 |
| 文書にまとめる | 要件を章立てに並べ、背景や対象範囲を書き足す | 要件定義書 | D1-3 |
| 抜けを探す | データや別の資料から、メモにないことを見つけて、確かめる相手を決める | 確認事項 | D1-4 |
要件の4つの分類
| 分類 | 意味 | 例 |
|---|---|---|
| 機能 | システムが行う動作 | 1日の作業時間の合計が24時間を超えたらエラーにする |
| 非機能 | 速さ、安全さ、使いやすさのような品質 | 画面は今と同じくらいの速さで表示する |
| 制約 | 守らなければならない条件 | 稼働は2027年4月 |
| 課題 | 今の困りごと。解消する要件が別にある | 月末の売上実績表の作成に3日かかっている |
使える要件の条件
1文で、誰が何をするか、またはシステムが何をするかが読み取れる要件を目指します。根拠の行番号が付いていて、数字や条件が要る要件には、それが書いてあることも条件です。「入力はなるべく簡単にする」のように基準がない要件は、消さずに、要確認に「何をもって簡単とするか」と書いて残します。
設計の図と表
普段から図やデータモデルを作っている方は、次の対応表で研修の演習の位置を確かめてください。
Day2 とDay3では、要件を設計に落とします。普段の仕事で作る図や表と、研修の演習は次のように対応します。
| 普段の成果物 | 研修での対応 | AIに頼むときの注意 |
|---|---|---|
| 業務フロー図 | D2-4 請求回収の業務フロー。As-Isの図の上に、To-Beで変わる箇所を色で重ねる | 先に登場する人と帳票を挙げさせ、自分の拾い出しと見比べてから図にさせる |
| 画面一覧、画面遷移図 | D2-1 画面一覧と画面遷移 | 画面ごとに区分（改修、新設、影響あり、影響なし）と要件IDを付けさせる |
| 画面項目定義、入力チェック、メッセージ | D2-2 画面設計書 | 全項目に型、桁、必須、初期値、入力者を書かせる。チェックは単項目、相関、業務ロジックに分ける |
| データモデル、テーブル定義 | D2-2 の設計書にあるテーブル変更のシート。D3-3のデータのつながりの図 | 研修では新しくテーブルを設計しない。現行のテーブル定義書と比べて、足す列と変える列を書かせる |
| 画面イメージ、処理画面イメージ | D2-3 動くモック（HTML） | 設計書どおりに作らせ、設計書にない動きには「設計書に無い」と印を付けさせる |
| DFDなどのデータの流れ図 | 専用の演習はない。D3-3のデータのつながりの図が近い | データの出どころと行き先を先に表にさせてから、図にさせる |
どの図も、AIに描かせる前に、自分の手で3つ書き出します。研修の各演習の最初のSTEPが、その時間です。
必須と発展の見方
どの演習も、必須のSTEPだけで枠の時間に収まるように組んでいます。
各演習のSTEPを、必須と発展に分けました。必須は、枠の時間内に終えるSTEPです。見出しには[Nmin]だけが付いています。発展は、見出しに 発展 のバッジが付き、枠の時間には入っていません。
- 必須のSTEPが終わったら、発展を待たずに次の演習へ進んで構いません。講師も、発展を待たずに進めます。
- 発展のSTEPは、時間が残った方と、研修のあとに続ける方が進めます。
- 発展を飛ばしても、次の回は完了状態のZIPから、全員が同じ状態で始められます。
用語
| 用語 | 意味 |
|---|---|
| 根拠 | 要件の元になった文の、ファイル名と行番号。ヒアリングメモ_01:L68の形で書く |
| 要確認 | メモだけでは決まらず、誰かに確かめる必要がある要件。確かめる相手と聞くことを添える |
| 食い違い | 人によって言うことが違う話題。片方の発言だけで決めず、要確認に残す |
| As-Is、To-Be | As-Isは今の業務の流れ。To-Beはシステムを入れたあとの流れ |
| モック | 設計書どおりに動く、見た目だけの画面。本物のデータベースにはつながらない |
| 完了状態 | 回の終わりに、講師が最後まで終えたときの成果物。次の回の最初に全員へ配る |