ハンズオンガイドDay1 ヒアリングメモから要件定義書へ

題材の歩き方

3回とも、同じ架空の会社の、同じシステムの改修を扱います。導入の時間に、ここを一緒に見ます。

サンプル情報サービス株式会社（架空）

独立系の SIer で、社員は約300名です。第1開発部が金融、第2開発部が公共と運輸の案件を持ち、ほかに管理部があります。

この会社で全社員が使う唯一の Web システムが、勤怠・工数管理システム KINTAI です。2014年に稼働し、JSP、Spring MVC、MyBatis で作られています。TERASOLUNA 5.x がベースです。研修で Java のコードを読む場面はありません。TERASOLUNA は Day2 で、入力チェックの書き分け方の決まりとしてだけ使います。

改修依頼の4項目

情報システム課が起票した 資料/day1/改修依頼書_KINTAI-2026-03.md に、次の4項目が書いてあります。

1. 工数入力画面（KIN030）に「予定工数」を入力できるようにする
2. 1日の作業時間の合計が24時間を超えたら入力エラーにする
3. プロジェクトの収支を見る画面（PJ010 収支ダッシュボード）を新設する
4. 希望時期は2027年4月。詳細は各部のヒアリングで確認すること

4つ目にあるとおり、依頼書だけでは要件になりません。誰が、いつ、何に困っていて、どこまで直せばよいのかは、ヒアリングメモの中にあります。しかも、メモ同士で言っていることが合わない箇所があります。

登場人物

人物は名字と役職だけで表します。取引先は「A社（架空・信託銀行）」の形で、実在の会社ではありません。

現行画面

配布フォルダの 現行画面/index.html をダブルクリックすると、ブラウザで KINTAI の現行画面のモックが開きます。サーバは要りません。導入の時間に、次の5画面を一通り触ってください。

• KIN030 で 行を追加 を押し、プロジェクトと作業区分を選んで作業時間に「25」を入れ、保存 を押してみる。どのエラーが、画面のどこに出るか
• KIN020 の実働が8時間の日に、KIN030 で合計10時間の工数を入れてみる。エラーになるか
• KIN050 で、締め状態とロック予定の日時がどう書いてあるか

ここで見たことは、D1-2 以降で要件を読むときの手がかりになります。気づいたことはメモしておいてください。

配布フォルダの構成

事前準備で、配布 ZIP をデスクトップに展開してあります。Claude に渡すファイルも、作ったファイルの置き場所も、すべてこのフォルダの中です。

idup-handson/
├── はじめにお読みください.md
├── CLAUDE.md            Claude が最初に読む。AGENTS.md を読み込む
├── AGENTS.md            この研修での約束ごと
├── 資料/                読むだけ。書き換えない
│   ├── day1/            ヒアリングメモ3本、改修依頼書
│   ├── day2/            経理のヒアリングメモ
│   ├── day3/            レビュー対象の画面設計書
│   ├── データ/          勤怠工数CSV、マスタ、売上実績表、請求回収
│   └── 参考/            TERASOLUNA の書き分け、用語集
├── 現行画面/            KINTAI の現行画面。ブラウザで開く
├── テンプレート/        要件定義書、画面設計書などの雛形6本
├── tools/               Markdown を Word・Excel・PowerPoint にする変換ツール
└── 成果物/
    ├── day1/  day2/  day3/   作ったものはここに置く
    └── 合流用/          講師が配る合流版を入れる場所

Claude はフォルダを開くと CLAUDE.md を読み、そこから AGENTS.md の約束ごとを読み込みます。回答は日本語のです・ます調、ヒアリングメモにないことを要件として足さない、推測で埋めた箇所には「（要確認）」を付ける、要件や指摘には ヒアリングメモ_01:L23 の形で根拠を付ける、の4つが要です。送る文面の中で毎回くり返さなくても、Claude はこれを守ろうとします。

手書きメモの置き場所

どの演習も、STEP 1 は AI を開かずに自分で書きます。書く道具は Windows のメモ帳です。書いたメモは、STEP 2 で Claude に送る文面の <ここに…> のところへ貼ります。

1. スタートメニューで「メモ帳」と入れて開きます。
2. メモを書いたら、ファイル → 名前を付けて保存 を選びます。
3. 保存先に idup-handson の中の 成果物 → day1 を選びます。
4. ファイル名を メモ_D1-1.md のように「メモ_演習番号.md」にします。ファイルの種類 は すべてのファイル (*.*)、エンコード は UTF-8 を選んで保存します。

架空データの扱い

題材の会社、取引先、人物、金額、勤怠と工数のデータは、すべて研修のために作った架空のものです。研修中に、自分の案件の資料や実在のお客様の情報を Claude に渡さないでください。自分の案件で試すときの手順は、Day3 のあとに配る持ち帰り演習集にあります。

D1-1 文脈の有無による出力の違い

ねらい

同じ依頼でも、何を渡し、何を禁じるかで、出力がどれだけ変わるかを自分の目で見ます。ここで決める指示の型を、このあとの全演習で使います。

できあがりの目安

• 成果物/day1/D1-1_比較.md に、①②③の3回分の出力が見出しを分けて並んでいる
• ①の出力のうち、改修依頼書にもメモにも書いていない要件の数が書いてある
• ③の根拠のうち2つを、メモ帳で開いて確かめた結果が書いてある
• 違いが自分の言葉で3点、指示の型が1行で書いてある

使うファイルと作るファイル

ファイルは読まずに、あなたの知識だけで答えてください。
勤怠システムの工数入力に予定工数を足す要件を書いて。
書いた内容は 成果物/day1/D1-1_比較.md を新しく作り、「## ① 何も渡さない」の見出しの下に保存してください。

@資料/day1/改修依頼書_KINTAI-2026-03.md
@資料/day1/ヒアリングメモ_01_第1開発部_田中課長.md
@資料/day1/ヒアリングメモ_02_第2開発部_鈴木主任.md
@資料/day1/ヒアリングメモ_03_管理部_佐藤さん.md

この4つを読んで、勤怠システムの工数入力に予定工数を足す要件を書いて。
書いた内容は 成果物/day1/D1-1_比較.md の末尾に「## ② 資料を渡す」の見出しを足して、その下に保存してください。

@資料/day1/改修依頼書_KINTAI-2026-03.md
@資料/day1/ヒアリングメモ_01_第1開発部_田中課長.md
@資料/day1/ヒアリングメモ_02_第2開発部_鈴木主任.md
@資料/day1/ヒアリングメモ_03_管理部_佐藤さん.md

この4つを読んで、勤怠システムの工数入力に予定工数を足す要件を書いて。
- メモにないことは書かない
- 各要件に、根拠のファイル名と行番号を付ける（例 ヒアリングメモ_01:L23）
- 次の2つも守る
<ここに STEP 1 で書いた「禁じること」2行を貼る>
書いた内容は 成果物/day1/D1-1_比較.md の末尾に「## ③ 禁止と根拠を足す」の見出しを足して、その下に保存してください。

うまくいかないとき

早く終わった方へ

追加と考察

③の根拠を全部開き、行番号がずれている要件の数を数えます。ずれていたら、なぜずれたのかを考えます。見出しや空行を数えに入れたのか、2行にまたがる発言の1行目と2行目のどちらを指したのか。根拠の付いた出力でも、そのまま信じてよいとは限りません。

発展課題

③の文面の最後に、次の1行を足して送り直します。

分からないところは、要件を書く前に、私への質問として返してください。

返ってきた質問を読み、ヒアリングで本当に聞くべきものに印を付けます。聞くべき質問が多いほど、メモだけでは要件が決まらないということです。D1-4 の確認事項リストの下書きになります。

D1-3 要件定義書のドラフト作成

ねらい

要件一覧をテンプレートに流し込み、Word の要件定義書にします。分からない箇所は推測で埋めず、「要確認」と確認の相手を書いて残します。

できあがりの目安

• 成果物/day1/要件定義書_v0.1.docx が LibreOffice Writer で開ける
• テンプレートの「書き方」の章を除いて、見出しが全部ある
• 空欄がない。書けない箇所には「要確認」と、確認する相手が書いてある

使うファイルと作るファイル

@テンプレート/要件定義書テンプレート.md
@成果物/day1/要件一覧.md

テンプレートの見出しと順番をそのまま使い、要件一覧の中身を流し込んで、要件定義書を Markdown で書いてください。保存先は 成果物/day1/要件定義書_v0.1.md です。
- 「書き方」の章は守る決まりとして読み、書き終えたら消す
- ほかの見出しは消さない。書くことがない章も見出しを残し、「要確認」と書く
- 要件一覧にないことを推測で書いた文には、文末に「（要確認: 確認する相手）」を付ける
- 各要件には、要件一覧の要件IDを残す
- 要件一覧で「食い違い」になっている要件は、どちらかに決めずに両方の言い分を並べる

私が一番書きにくいと思った章と、確認する相手は次のとおりです。この章は特に、推測で埋めずに要確認で残してください。
<ここに STEP 1 のメモ2行を貼る>

成果物/day1/要件定義書_v0.1.md を tools/md_to_docx.py で Word にして、成果物/day1/要件定義書_v0.1.docx に保存してください。

うまくいかないとき

早く終わった方へ

追加と考察

非機能要件の章に、メモにない数字が入っていないかを見ます。応答3秒、同時接続100人、稼働率99.9%のような数字は、要件定義書らしく見えるので AI が入れがちです。メモにある速さの言い方を、どの数字にして誰に確かめるかを書き出してください。

発展課題

用語集の章を足し、ヒアリングメモで言い方が揺れている語をそろえさせます。

@成果物/day1/要件定義書_v0.1.md
@資料/参考/用語集.md

要件定義書に「用語集」の章を足してください。ヒアリングメモで言い方が揺れている「工数」「作業時間」「稼働」を中心に、同じものを指す言葉を1つにそろえ、本文もそろえた言葉に直してください。
資料/参考/用語集.md と定義が違う語があれば、直さずに要確認にしてください。

よくある質問