本日のゴール
別チームが書いた収支ダッシュボードの画面設計書を観点ごとにレビューし、要件との対応を確かめてから、動くダッシュボードを作って数字を検算します。最後に、3回の成果物をレビュー会資料にまとめ、自分のチームの AI の利用ルールのたたき台を書きます。
成果物/day3/レビュー記録.xlsx。指摘が8件以上あり、自分で見つけたものが3件以上成果物/day3/対応表.xlsx。全要件に対応先か「対応なし」があり、対応なしには扱いが決まっている成果物/day3/PJ010_収支ダッシュボード.html。PJ-2026-014 の9月の原価が、自分の検算と一致している成果物/day3/レビュー会資料.pptxと成果物/day3/利用ルール_たたき台.docx
3回で作ったものは、配布フォルダの 成果物/ にそろっています。このガイドの最後に、持ち帰り資料5点の案内があります。
当日の流れ
全体で [180min] です。講義のあとには、必ず演習か理解度チェックが入ります。
| 枠 | 中身 | 形式 | 時間 |
|---|---|---|---|
| 振り返り | Day2 の設計書とモック、レビュー対象の配布 | 説明 | [10min] |
| D3-1 | 観点を分けた設計レビュー | 個人演習 | [35min] |
| D3-2 | 要件と画面の対応表 | 個人演習 | [25min] |
| 休憩 | [10min] | ||
| D3-3 | 収支ダッシュボードの作成 | 個人演習 | [45min] |
| D3-4 | 成果物のまとめ | 個人演習 | [30min] |
| まとめ | 3回の成果物の一覧、現場での最初の一歩、理解度チェック | まとめ | [10min] |
| 質疑・アンケート | 質疑 | [15min] |
Zoom での進め方
- 講師が Zoom で画面を共有し、同じ操作を見せながら進めます。手元では Claude デスクトップアプリと、エクスプローラー、メモ帳、LibreOffice を使います。画面が1枚の方は、Zoom の画面を小さくして横に並べると作業しやすくなります。
- 演習はすべて個人で進めます。発表や、ほかの受講者との話し合いはありません。
- 質問や、詰まったときは、Zoom のチャットに「D1-2 STEP 3 変換で文字化け」のように、演習の番号、STEP、起きていることを書いてください。講師が順に答えます。画面を見る必要があるときは、講師から画面共有をお願いすることがあります。
- 各 STEP の [Nmin] は目安です。時間になったら講師が次の STEP へ進めます。途中でも、次の STEP へ移って構いません。終わらなかった分は、研修のあとに同じ手順で続けられます。
Day2 からの合流
Day2 の画面設計書が v0.2 まで届かなかった方は、講師が配る合流版で Day3 を始めます。自分の v0.2 がある方は、そのまま自分のものを使ってください。
講師が振り返りの時間に、画面一覧.md、画面設計書_KIN030_v0.2.md、画面設計書_KIN030_v0.2.xlsx を配ります。受け取り方は Zoom で案内します。
- 自分の途中のファイルが
成果物/day2/にあれば、名前の末尾に_自分を付けて残します。上書きで消さないためです。 - 受け取ったファイルを
成果物/合流用/に置きます。 成果物/合流用/の画面一覧.md、画面設計書_KIN030_v0.2.md、画面設計書_KIN030_v0.2.xlsxを成果物/day2/にコピーします。
このガイドの送る文面は、どれも 成果物/day2/ のファイルを指しています。コピーしておけば、文面はそのまま使えます。
D3-1 観点を分けた設計レビュー
ねらい
「レビューして」とだけ頼むと、指摘は目につきやすい表面に寄ります。観点を1つずつに分けて頼み、指摘の根拠を自分で確かめてから採るかどうかを決めます。
できあがりの目安
成果物/day3/レビュー記録.xlsxに指摘が8件以上ある- そのうち、自分で見つけたものが3件以上ある
- 全件に、根拠のシート名と行がある
- AI の指摘のうち採らなかったものが1件以上あり、理由が書いてある
使うファイルと作るファイル
| 区分 | ファイル | 使い方 |
|---|---|---|
| 使う | 資料/day3/レビュー対象_画面設計書_PJ010_収支ダッシュボード.xlsx | 自分で読むときは Calc で開きます |
| 使う | 資料/day3/レビュー対象_画面設計書_PJ010_収支ダッシュボード.md | 同じ中身の Markdown。Claude にはこちらを渡します |
| 使う | テンプレート/レビュー記録テンプレート.md | レビュー記録の形 |
| 使う | 成果物/day1/要件定義書_v0.2.md | 要件と食い違う指摘を見つけるため |
| 作る | 成果物/day3/メモ_D3-1.md | STEP 1 の自分の指摘と、STEP 3 の判定 |
| 作る |
| md が正本。xlsx は変換したもの |
レビュー対象
別チームが書いた、PJ010 収支ダッシュボードの画面設計書です。改修依頼の3つ目で新設する画面にあたります。シートは、画面概要、項目定義、入力チェック、計算式、権限、メッセージ、画面遷移の7枚です。行は、画面概要と画面遷移は No、項目定義・入力チェック・計算式・メッセージは ID（PJ010-I-005 など）、権限は機能名で指します。
6つの観点
| 観点 | 見るところ |
|---|---|
| 要件漏れ | 要件定義書やヒアリングメモにあることが、設計書のどこにもない |
| 矛盾 | 同じことが、シートによって違う書き方になっている。計算式が業務の言葉の意味と合わない |
| 曖昧表現 | 読む人によって作るものが変わる言葉。数や基準がなく、テストで確かめられない |
| 例外系 | エラー、データがない、月の途中で変わる、といった通常でない場面の扱い |
| 非機能 | 権限、性能、データ量のように、機能の外側の決まり |
| 項目定義・形式 | 項目の型・桁・必須と、ID やメッセージの書き方がシートの間でそろっているか |
STEP 1 観点ごとの自分の指摘 AIを開かない [8min]
レビュー対象_画面設計書_PJ010_収支ダッシュボード.xlsx を LibreOffice Calc で開き、7枚のシートを読みます。観点ごとに自分で指摘を書きます。目標は3件です。
成果物/day3/メモ_D3-1.md に、1行に1件、観点、シート名、行、指摘の中身を書きます。行は、画面概要と画面遷移は No、項目定義・入力チェック・計算式・メッセージは ID（PJ010-I-005 など）、権限は機能名で指します。Claude にも同じ指し方をさせるので、あとで突き合わせやすくなります。
- 観点: 項目定義・形式 / シート: 項目定義 / 行: PJ010-I-005 / 指摘: - 観点: / シート: / 行: / 指摘:
資料/ の中は書き換えない約束です。STEP 2 観点ごとの依頼 [12min]
観点を1つずつ、6回に分けて頼みます。まとめて頼まないでください。1回ごとに、次の文面の <ここに観点を1つだけ書く> を差し替えて送ります。自分の指摘はまだ見せません。
@資料/day3/レビュー対象_画面設計書_PJ010_収支ダッシュボード.md
@成果物/day1/要件定義書_v0.2.md
この画面設計書を「<ここに観点を1つだけ書く>」の観点だけでレビューしてください。ほかの観点の指摘は出さないでください。
- 指摘ごとに、根拠のシート名と行を必ず付ける。行は、画面概要と画面遷移は No、項目定義・入力チェック・計算式・メッセージは ID、権限は機能名で書く
- 要件定義書と食い違う指摘には、要件IDも付ける
- 指摘は重さ（高・中・低）の順に並べる
- 直し方の案はまだ書かない6回が終わったら、観点ごとの件数を メモ_D3-1.md に書いておきます。
STEP 3 採用・不採用・保留の判定 AIを開かない [10min]
Claude の指摘を1件ずつ、Calc で根拠のシートと行を開いて確かめます。根拠の行が実物にない指摘、設計書の範囲の外の指摘、要件定義書に照らすと誤りの指摘は、不採用にします。決められないものは保留にし、誰に確かめるかを書きます。
判定と理由を メモ_D3-1.md に書いたら、自分の指摘と合わせてレビュー記録にまとめさせます。
@テンプレート/レビュー記録テンプレート.md ここまでの6つの観点の指摘と、私が先に書いた指摘をまとめて、レビュー記録テンプレートの形で 成果物/day3/レビュー記録.md に書いてください。 - 見つけた人の列に「自分」「AI」「両方」のどれかを入れる - 判定の列には、私が決めた次の判定をそのまま入れ、理由も書き写す - 根拠のシート名と行は、全件に入れる 私が先に書いた指摘: <ここに STEP 1 の自分の指摘を貼る> AI の指摘への判定: <ここに、AI の指摘ごとの 採用・不採用・保留 と理由を書いて貼る>
資料/記入例/記入例_レビュー記録_抜粋_会議室予約.md を開きます。別の題材で、行・項目IDの指し方と、不採用の理由の書き方が見られます。不採用にする指摘の見分け方
「画面の配色や文字の大きさを見直すべき」のような好みの指摘は、要件定義書にもヒアリングメモにも根拠がありません。「セキュリティ対策を検討すべき」のように、何をどう直すかが書いていない指摘も採れません。根拠のシートと行を開いて、そこに書いてあることと指摘の中身が合っているかを、1件ずつ見てください。
STEP 4 Excel への変換 [5min]
成果物/day3/レビュー記録.md を tools/md_to_xlsx.py で Excel にして、成果物/day3/レビュー記録.xlsx に保存してください。
Calc で開き、見つけた人の列で絞り込んで、自分の指摘の数と、不採用の数を数えます。
- 指摘が8件以上
- 見つけた人が「自分」か「両方」のものが3件以上
- 根拠が空いている行がない
- 不採用が1件以上あり、理由が書いてある
うまくいかないとき
根拠のシートや行が、実物に見当たらない
Claude が行を読み違えているか、ありもしない行を書いています。どちらでも、その指摘は根拠が確かめられないので不採用か保留にします。「この指摘の根拠の行を、設計書から原文のまま引用してください」と送ると、読み違いかどうかが分かります。
観点を1つに絞ったのに、ほかの観点の指摘が混ざる
混ざった指摘は、その観点の回では数えずに消します。次の回の文面の最後に「ほかの観点に当たる指摘は、出さずに件数だけ書いてください」と足してください。
Excel を Claude に直接読ませたら、中身がおかしい
Claude に渡すのは Markdown の方です。xlsx を渡したいときは、「tools/xlsx_to_md.py で Markdown にしてから読んでください」と送ります。
python が見つからない、変換で文字化けする
「py で実行してください」と送ります。化けるときは、Markdown をメモ帳で開いて化けていないかを先に見ます。メモ帳で書き換えた場合は、エンコード を UTF-8 にして保存し直してから変換します。
LibreOffice で開けない
xlsx が 0 KB なら変換が失敗しています。Claude の応答に出たエラーの文を貼り、直させてから変換し直します。
早く終わった方へ
追加と考察
観点を分けずに1回で頼んだ場合と比べます。新しく次の文面を送り、出てきた指摘の数と、深さを比べてください。深さは、根拠が付いているか、計算式や権限の中まで入っているかで見ます。
@資料/day3/レビュー対象_画面設計書_PJ010_収支ダッシュボード.md この画面設計書をまとめてレビューしてください。
発展課題
採用した指摘ごとに修正案を書かせ、修正案が別の不備を生んでいないかを確かめます。
@資料/day3/レビュー対象_画面設計書_PJ010_収支ダッシュボード.md @成果物/day3/レビュー記録.md レビュー記録で「採用」にした指摘ごとに、設計書の修正案を書いてください。 修正案を当てたときに、ほかのシートの記述と食い違うところが出ないかも、指摘ごとに確かめて書いてください。
たとえば、ある計算式を直すと、その式を使っている項目定義やメッセージにも手が入ります。1か所の修正で済まない指摘ほど、レビュー会で時間をとるべき指摘です。
時間があれば、2本目の設計書に同じレビューをかけます。資料/発展/D3-1_レビュー対象2_画面設計書_KIN040_交通費申請.md を、まず自分で読んで観点ごとに指摘を書き、そのあと観点を1つずつ Claude に頼みます。文面は STEP 2 と同じで、設計書のファイルだけを替えます。
@資料/発展/D3-1_レビュー対象2_画面設計書_KIN040_交通費申請.md
この画面設計書を「<ここに観点を1つだけ書く>」の観点だけでレビューしてください。ほかの観点の指摘は出さないでください。
- 指摘ごとに、根拠のシート名と行を必ず付ける
- 指摘は重さ（高・中・低）の順に並べるPJ010 のときと比べて、自分で先に見つけた指摘が増えたかを数えます。増えていれば、観点が自分の目に入ってきたということです。
D3-2 要件と画面の対応表
ねらい
要件が設計のどこで実現されるかを表にします。対応先のない要件と、根拠となる要件のない設計の項目を見つけます。
できあがりの目安
成果物/day3/対応表.xlsxで、全要件に対応先があるか、「対応なし」と書いてある- 対応なしの要件ごとに、扱い（次版・対象外・設計に足す）が決まっている
使うファイルと作るファイル
| 区分 | ファイル | 使い方 |
|---|---|---|
| 使う | 成果物/day1/要件一覧.md | Day1 の要件一覧か合流版 |
| 使う | 成果物/day2/画面設計書_KIN030_v0.2.md | Day2 の設計書か合流版 |
| 使う |
| PJ010 はレビュー記録で採用した指摘を直した前提で見ます |
| 使う | テンプレート/対応表テンプレート.md | 対応表の形 |
| 作る | 成果物/day3/メモ_D3-2.md | STEP 1 で自分でたどった3件 |
| 作る |
| md が正本。xlsx は変換したもの |
STEP 1 重要な要件3つの追跡 AIを開かない [5min]
要件一覧から、改修で外せない要件を3つ選びます。それぞれが、KIN030 の設計書と PJ010 の設計書のどのシートの、どの項目やチェックで実現されているかを、自分で設計書をたどって探します。
成果物/day3/メモ_D3-2.md に、要件ID、対応先（設計書・シート・項目）、見つからなかったときは「対応なし」と書きます。
STEP 2 対応表の作成 [8min]
@テンプレート/対応表テンプレート.md
@成果物/day1/要件一覧.md
@成果物/day2/画面設計書_KIN030_v0.2.md
@資料/day3/レビュー対象_画面設計書_PJ010_収支ダッシュボード.md
@成果物/day3/レビュー記録.md
要件と設計の対応表を、テンプレートの形で 成果物/day3/対応表.md に作ってください。
- PJ010 の設計書は、レビュー記録で「採用」にした指摘を直した内容として見る
- 要件一覧の全要件について、対応する設計書・シート・項目を書く。見つからなければ「対応なし」と書く
- 逆向きに、設計書の項目やチェックのうち、どの要件にも対応しないものを別の表に挙げる
- 対応先は「全体」「各画面」のようにまとめず、シートと項目まで書く
私が自分でたどった3件は次のとおりです。表の中でこの3件が私と違っていたら、理由を書いてください。
<ここに STEP 1 のメモを貼る>STEP 3 自分の3件との照合 [7min]
対応表の中から、自分の3件を探して見比べます。違っていたら、設計書を開いて、どちらが正しいかを確かめます。
続けて、対応なしの要件の数と、どの要件にも対応しない設計の項目の数を数え、メモ_D3-2.md に書きます。数えるのは Claude に頼んでも構いません。
どの要件にも対応しない項目は、設計者が気を利かせて足したものか、要件定義書の書き漏らしのどちらかです。どちらなのかを1件ずつ考えます。
STEP 4 扱いの決定と Excel 化 AIを開かない [5min]
対応なしの要件ごとに、扱いを自分で決めます。次版に回す、今回の対象外にする、設計に足す、の3つです。決めたことを書いてから送ります。
成果物/day3/対応表.md の「対応なし」の要件に、扱いの列を足して、次のとおり入れてください。
<ここに、対応なしの要件IDごとに 次版・対象外・設計に足す のどれかと、理由を書いて貼る>
入れたら tools/md_to_xlsx.py で 成果物/day3/対応表.xlsx を作ってください。対応表.xlsxが Calc で開ける- 対応先の列が空いている要件がない
- 対応なしの要件すべてに、扱いと理由がある
うまくいかないとき
要件が多くて、表が途中で切れる
「続けてください」と送ります。何度も切れるときは、「要件IDの前半と後半に分けて、2回に分けて書いてください」と頼みます。
対応先が「全体」「各画面」のように粗い
「対応先が画面より粗い行を挙げ、シートと項目まで書き直してください」と送ります。書き直せない要件は、要件そのものが粗すぎる合図です。
合流版を使っていて、要件IDが自分のものと合わない
対応表は、合流版の要件一覧で作ってください。自分の要件一覧と比べたいときは、研修のあとに同じ手順を自分の一覧で回します。
変換で文字化けする、LibreOffice で開けない
Markdown をメモ帳で開いて化けていないかを先に見ます。xlsx が 0 KB なら変換が失敗しているので、Claude の応答に出たエラーの文を貼って直させます。
早く終わった方へ
追加と考察
要件が細かすぎるときと、粗すぎるときに、対応表がどうなるかを考えます。細かすぎると、1つの項目に要件が何件もぶら下がり、表が要件の数だけ長くなります。粗すぎると、1つの要件に対応先が並び、どこまで実現したら満たしたと言えるのかが分からなくなります。自分の対応表で、どちらの行があったかを探してください。
発展課題
対応表を、変更の影響を調べる道具として使います。資料/発展/D3-2_変更要求_2026-10.md に、10月に届いた変更要求が2件あります。
@成果物/day3/対応表.md @資料/発展/D3-2_変更要求_2026-10.md @資料/参考/現行_テーブル定義書_KINTAI.md @資料/参考/現行_CSV出力仕様書_KIN050.md @資料/参考/月次締め運用手順書.md 変更要求の2件について、対応表のどの行に手が入るかを挙げてください。 対応表に載っていないところ（テーブル、CSV、運用の手順書）で手が入るところも、ファイル名と箇所を書いてください。 保存先は 成果物/day3/変更要求の影響.md です。
対応表に載っていないところで手が入る箇所が多いなら、対応表の対応先が画面に寄りすぎているということです。
続けて、対応表から、テスト観点の一覧を作らせます。
@成果物/day3/対応表.md 対応表の対応先ごとに、テスト観点の一覧を作ってください。正常、異常、境界値に分け、どの要件を確かめる観点かを要件IDで示してください。 保存先は 成果物/day3/テスト観点.md です。
要件から設計、設計からテストまで要件IDでつながると、どの要件がテストされていないかも表で数えられます。
D3-3 収支ダッシュボードの作成
ねらい
レビューで直した設計書から、値を書き換えられる収支ダッシュボードを作ります。画面に出た数字を、自分で検算します。
できあがりの目安
成果物/day3/PJ010_収支ダッシュボード.htmlがダブルクリックで開く- 設計書の項目が、全部画面にある
- 予定工数か単価を書き換えると、集計がその場で変わる
- PJ-2026-014 の9月の原価を自分で検算し、画面の数字と一致している
使うファイルと作るファイル
| 区分 | ファイル | 使い方 |
|---|---|---|
| 使う |
| 設計書は、レビュー記録で採用した指摘を直した前提で読ませます |
| 使う | 資料/データ/勤怠工数CSV_202609.csv | 社員の9月の工数 |
| 使う | 資料/データ/プロジェクトマスタ.csv | PJ ごとの受注額と契約 |
| 使う | 資料/データ/要員マスタ.csv | 社員ごとの等級。単価を決めるのに使います |
| 使う | 資料/データ/原価単価.csv | 等級ごとの単価と、パートナーの精算の決まり |
| 使う | 資料/データ/パートナー作業実績_202609.csv | パートナーの工数。週単位です |
| 使う | 資料/データ/予定工数表_2026下期.xlsx | 田中課長が手で作っている予定工数。ダッシュボードの予定工数の初期値にします |
| 作る | 成果物/day3/メモ_D3-3.md | STEP 1 の場面と、STEP 3 の検算 |
| 作る | 成果物/day3/PJ010_収支ダッシュボード.html | 動くダッシュボード |
STEP 1 月末の場面 AIを開かない [5min]
リーダーが月末にこの画面を開いて、何を見て、何を直すかを、1つの場面として 成果物/day3/メモ_D3-3.md に書きます。誰が、いつ、どの PJ の、どの数字を見て、何に気づき、画面で何を書き換えるか。
場面の書き方の例を見る
「10月の第1週、田中課長が PJ-2026-014 の9月の粗利率を見る。予定より低いので、原価の内訳でパートナーの工数を確かめる。10月の予定工数を担当1名分減らして入れ直し、粗利率がどこまで戻るかを見る」
STEP 2 ダッシュボードの作成 [15min]
@資料/day3/レビュー対象_画面設計書_PJ010_収支ダッシュボード.md
@成果物/day3/レビュー記録.md
@資料/データ/勤怠工数CSV_202609.csv
@資料/データ/プロジェクトマスタ.csv
@資料/データ/要員マスタ.csv
@資料/データ/原価単価.csv
@資料/データ/パートナー作業実績_202609.csv
@資料/データ/予定工数表_2026下期.xlsx
PJ010 収支ダッシュボードを 成果物/day3/PJ010_収支ダッシュボード.html に作ってください。
- 設計書は、レビュー記録で「採用」にした指摘を直した内容として読む
- データは CSV から集計して、HTML の中に埋め込む。HTML と JavaScript だけで1ファイルにまとめ、外部のライブラリと Web サーバは使わない
- 予定工数と単価は画面で書き換えられるようにし、書き換えたら集計がその場で変わるようにする
- 予定工数の初期値は、予定工数表を tools/xlsx_to_md.py で読んで入れる。数字として読めない値や合計の合わない箇所は、直さずに集計の前提に書く
- 画面の下に、PJ ごと・要員ごとの工数と原価の内訳の表を出す
- データの扱いで判断が要ったところは、画面の下に「集計の前提」として全部書く
この画面は、次の場面で使います。この場面の操作ができるようにしてください。
<ここに STEP 1 の場面を貼る>できたらダブルクリックで開き、設計書の項目が画面に全部あるかを見ます。
STEP 3 場面どおりの操作と検算 AIを開かない [15min]
STEP 1 で書いた場面のとおりに操作します。予定工数か単価を書き換え、集計がその場で変わるかを確かめます。
次に、PJ-2026-014 の9月の原価を、LibreOffice Calc で自分で計算します。Claude には頼みません。画面と同じ読み違いをしたまま、同じ答えを返すことがあるからです。
社員の原価
勤怠工数CSV_202609.csvを Calc で開きます。テキストのインポート では Unicode (UTF-8) と コンマ を選びます。- データ → オートフィルター で、PJコードを PJ-2026-014 に絞ります。
- 社員ごとに作業分を合計し、60 で割って時間にします。
要員マスタ.csvで社員の等級を見て、原価単価.csvの単価（課長 8,000円、主任 6,500円、担当 5,200円の時給）を掛けます。
合計は、空いたセルに式で出せます。たとえば社員 S1004 の作業分の合計なら次の式です。列の位置は、開いた CSV の見出しに合わせてください。
=SUMIFS(K:K;I:I;"PJ-2026-014";A:A;"S1004")
パートナーの原価
パートナー作業実績_202609.csv は週単位です。PJ-2026-014 の行の時間を月で合計します。E社の契約は月額 800,000円で、精算幅は140〜180時間です。
| 月の合計時間 | その月の原価 |
|---|---|
| 140時間以上、180時間以下 | 800,000円 |
| 140時間未満 | 800,000円 −（140 − 合計時間）× 5,000円 |
| 180時間を超える | 800,000円 +（合計時間 − 180）× 5,000円 |
社員とパートナーを足した原価を、画面の PJ-2026-014 の原価と比べます。計算の途中の表を メモ_D3-3.md に残してください。
| 要員 | 等級 | 作業分の合計 | 時間 | 単価 | 原価 | |---|---|---|---|---|---| | | | | | | | パートナー: 合計時間 / 精算 / 原価 PJ-2026-014 の9月の原価（自分）: PJ-2026-014 の9月の原価（画面）:
; で書いておくと、設定にかかわらず通ります。CSV を閉じるときは 保存しない を選びます。計算を残したい方は、名前を付けて保存 で 成果物/day3/ に別の名前で保存してください。STEP 4 差の原因探しと修正 [10min]
画面と自分の数字が合わなければ、原因を探します。まず画面の「集計の前提」と内訳の表を読み、自分の計算と違う扱いをしている行を探します。合っていた方も、「集計の前提」に自分が決めていない扱いが書かれていないかを読みます。
- PJコードの取り違えを、どう扱っているか。数字の並びが逆なだけのコードがあります
- パートナーの原価を、精算幅の決まりどおりに出しているか
- 締めたあとに修正した行を、入れているか外しているか
原因が分かったら、どちらに合わせるかを自分で決めて送ります。
画面の PJ-2026-014 の9月の原価が、私の検算と合いません。 私の検算: <ここに自分の計算の結果と途中の表を貼る> 私が考える原因と、どちらに合わせるか: <ここに自分で書く> 原因を確かめ、成果物/day3/PJ010_収支ダッシュボード.html を直してください。直したら、集計の前提にも書き足してください。
うまくいかないとき
ダッシュボードが白い画面になる
ブラウザで F12 を押し、コンソール の赤い文字をコピーして、「ダッシュボードが白い画面でした」と一緒に送ります。CSV を埋め込まずに、別のファイルとして読みに行こうとしていることが多い原因です。
数字が空欄や NaN になる
CSV の先頭の BOM、金額のカンマ、空の行のどれかで読み違えていることが多いです。「NaN になっている項目と、その元のデータの読み方を確かめて直してください」と送ります。
単価を書き換えても、集計が変わらない
「単価の入力欄を変えたとき、どの集計が変わるはずで、実際は変わっていないか」を書いて送ります。入力欄が画面の表示用だけで、計算に使われていないことがあります。
CSV を Calc で開いたら文字化けした
テキストのインポート で Unicode (UTF-8) を選び直してください。保存せずに閉じてから開き直します。
AI が設計書にない要件を足してくる
グラフ、予測、アラートの通知など、設計書にない表示が付いていたら、「設計書にない表示を挙げ、画面から外してください」と送ります。
早く終わった方へ
追加と考察
田中課長が手で作っている売上実績表と、画面の数字がずれるのはどこかを探します。売上実績表は Excel なので、Markdown にしてから Claude に渡します。
python tools/xlsx_to_md.py で 資料/データ/売上実績表_202609.xlsx を Markdown にして読み、ダッシュボードの PJ ごとの原価・粗利・粗利率と並べてください。 ずれている PJ と、ずれの理由の候補を挙げてください。理由は私が確かめるので、決めつけずに候補として書いてください。
挙がった候補のうち1つを、売上実績表を Calc で開いて自分で確かめます。
発展課題
要件一覧にあって、ダッシュボードに出ていない要件を1つ選び、画面に足させます。
@成果物/day3/PJ010_収支ダッシュボード.html
@成果物/day3/レビュー記録.md
@成果物/day1/要件一覧.md
要件一覧のうち、<ここに選んだ要件IDを書く> をダッシュボードに足してください。
しきい値や計算のしかたは、要件一覧の根拠の行にあるメモを読んで決め、決めた内容を集計の前提に書いてください。足した要件が、レビュー対象の設計書のどこに書いてあったかを探します。書いていなければ、D3-1 か D3-2 で拾えていたかを見返してください。
もう1つ、ダッシュボードの数字を、管理部が毎月の会議に出している収支表の形で出させます。資料/発展/D3-3_月次会議資料の収支表様式.md の列と決まりに合わせ、印刷用の表を画面に足します。累計の列には、7月と8月の CSV を使います。
@成果物/day3/PJ010_収支ダッシュボード.html @資料/発展/D3-3_月次会議資料の収支表様式.md @資料/データ/過去分/勤怠工数CSV_202607.csv @資料/データ/過去分/勤怠工数CSV_202608.csv 様式の列と決まりに合わせた印刷用の収支表を、ダッシュボードに足してください。 累計の列は、7月と8月の CSV と9月のデータから集計してください。 様式の決まりのうち、今のデータでは満たせないものがあれば、集計の前提に書いてください。
満たせない決まりが出てきたら、それは管理部が今、手でどこかから数字を持ってきているということです。
D3-4 成果物のまとめ
ねらい
3回の成果物から、社内のレビュー会に出す資料を作ります。あわせて、自分のチームで AI を使うときのルールのたたき台を書きます。
できあがりの目安
成果物/day3/レビュー会資料.pptxが LibreOffice Impress で開け、8〜10枚ある成果物/day3/利用ルール_たたき台.docxに、入力してよい情報と禁止する情報（5種以上）がある- 同じ docx に、レビュー責任者、成果物の承認者、お客様に示す利用範囲の文面がある
使うファイルと作るファイル
| 区分 | ファイル | 使い方 |
|---|---|---|
| 使う |
| 2つの形 |
| 使う | 成果物/day1/成果物/day2/成果物/day3/ | 3回の成果物 |
| 作る | 成果物/day3/メモ_D3-4.md | レビュー会で決めたいことと、利用ルールの手書き |
| 作る |
| md が正本。pptx は変換したもの |
| 作る |
| md が正本。docx は変換したもの |
STEP 1 レビュー会資料 最初の [3min] はAIを開かない [10min]
最初の3分は Claude を使いません。成果物/day3/メモ_D3-4.md に、レビュー会に誰が出るか、その場で決めてほしいことを2つ書きます。決めてほしいことがない資料は、読み上げて終わる会になります。
決めてほしいことの例を見る
- Day1 で食い違いとして挙げた話題のうち、どれをこの会で決めるか
- PJ010 のレビュー指摘のうち、保留にした2件をいつまでに誰が確かめるか
@テンプレート/レビュー会資料テンプレート.md
@成果物/day1/要件定義書_v0.2.md
@成果物/day2/画面設計書_KIN030_v0.2.md
@成果物/day3/レビュー記録.md
@成果物/day3/対応表.md
レビュー会資料を、テンプレートの形で 成果物/day3/レビュー会資料.md に書いてください。
- テンプレートの「書き方」の章に従い、書き終えたらその章は消す
- # を表紙、## ごとに1枚で、8〜10枚にする
- 「本日決めたいこと」の枚には、私が書いた次の2つを入れる
- 数字や指摘の件数は、渡したファイルから書き写し、根拠のファイル名を枚の下に添える
出席者と、この会で決めてほしいことです。
<ここに、出席者と決めてほしいこと2つを貼る>
書けたら tools/md_to_pptx.py で 成果物/day3/レビュー会資料.pptx にしてください。レビュー会資料.pptx を LibreOffice Impress で開き、枚数と、文字が枠からはみ出していないかを見ます。
STEP 2 利用ルールの手書き AIを開かない [7min]
テンプレート/利用ルールテンプレート.md をメモ帳で開き、見出しを見ます。メモ_D3-4.md に、自分のチームのつもりで次を書きます。
- AI に入力してよい情報
- 入力を禁止する情報を5つ
- AI が作った成果物を、誰がレビューするか
- お客様に出す前に、誰が最後に見て承認するか
3回の研修で Claude に渡したものを思い出しながら書いてください。ヒアリングメモ、勤怠のデータ、原価の単価、別チームの設計書。実案件なら、どれを渡せて、どれを渡せないか。
STEP 3 お客様向けの文面 [8min]
@テンプレート/利用ルールテンプレート.md
私が書いた利用ルールのメモを、テンプレートの形で 成果物/day3/利用ルール_たたき台.md にしてください。
- 私が決めたこと（禁止する情報、レビュー責任者、承認者）は書き換えない
- 抜けていそうなことは、書き足さずに「検討事項」の見出しの下に挙げる
- 最後に、お客様に AI の利用を説明するときの文面を、200字程度で書く。何に使い、何に使わず、誰が確かめるかが分かるようにする
- 社内の規程名や条番号は、実在を確かめられないので書かない
<ここに STEP 2 のメモを貼る>「検討事項」に挙がったものを読み、採るものは自分の言葉で本文に書き足します。お客様向けの文面は、自分のお客様の顔を思い浮かべて読み、言い切りすぎていないか、逆に曖昧すぎないかを直します。
STEP 4 Word への変換 [5min]
成果物/day3/利用ルール_たたき台.md を tools/md_to_docx.py で Word にして、成果物/day3/利用ルール_たたき台.docx に保存してください。
利用ルール_たたき台.docxが Writer で開ける- 禁止する情報が5種以上ある
- レビュー責任者と承認者が、役割の名前で書いてある
- お客様に示す利用範囲の文面がある
うまくいかないとき
スライドの文字が枠からはみ出す
「1枚の箇条書きを5行以内、1行を40字以内にして、はみ出す枚は2枚に分けてください」と送り、変換し直します。
枚数が多すぎる、少なすぎる
「## の数を8〜10にそろえてください」と送ります。少なすぎるときは、決めてほしいことの背景（食い違いの中身、レビューの件数）を1枚ずつ足させます。
python が見つからない、LibreOffice で開けない
「py で実行してください」と送ります。pptx や docx が 0 KB なら、変換が失敗しています。Claude の応答に出たエラーの文を貼って直させます。
利用ルールに、社内規程の名前や条番号が勝手に入る
実在を確かめられない規程名は、消させるか「（要確認）」を付けさせます。自分の会社の規程は、研修のあとに自分で確かめて書き足してください。
早く終わった方へ
追加と考察
今回の研修で AI に渡したデータのうち、実案件なら渡せないものはどれかを書き出します。勤怠のデータには社員ごとの働いた時間が、原価単価には等級ごとの時給が入っていました。お客様のヒアリングメモなら、何を消せば渡せるようになるのか。書き出したものを、利用ルールの禁止する情報と見比べてください。
発展課題
利用ルールをもとに、案件の始まりにお客様と確かめるチェックリストを作らせます。
@成果物/day3/利用ルール_たたき台.md この利用ルールをもとに、案件の始まりにお客様と確かめるチェックリストを作ってください。1項目ずつ「はい・いいえ」で答えられる形にし、10項目以内にしてください。 保存先は 成果物/day3/お客様確認チェックリスト.md です。
最後に、実際にお客様から届いた問い合わせに、利用ルールだけで答えられるかを試します。
@成果物/day3/利用ルール_たたき台.md @資料/発展/D3-4_A社からの生成AI利用に関する確認依頼.md A社の8つの質問に、利用ルールに書いてあることだけで答えてください。利用ルールに書いていないことを補って答えないでください。 答えられない質問は、答えずに「決めることの一覧」として、何を誰が決めればよいかを表にしてください。 保存先は 成果物/day3/A社への回答案.md です。
決めることの一覧が、利用ルールの次の版で足す章になります。
持ち帰り資料
研修のあとに自分の案件で使えるよう、5点を持ち帰ります。1と2は配布フォルダの中にあり、3から5は教材サイトからダウンロードします。
| # | 中身 | 置き場所 |
|---|---|---|
| 1 | 研修中に作った成果物。要件一覧、要件定義書、画面設計書、モック2本、業務フロー、レビュー記録、対応表、レビュー会資料、利用ルール | 配布フォルダの 成果物/ |
| 2 | 雛形。テンプレート6本と変換ツール | 配布フォルダの テンプレート/ と tools/ |
| 3 | プロンプトサンプル集 10本。用途、全文、差し替える箇所、出力を使う前の確かめ方 | 教材サイトの持ち帰り資料。PDF とコピー用の txt |
| 4 | 持ち帰り演習集 3本。議事メモから要件一覧、既存画面の改修設計とモック、設計書の観点別レビューを、自分の案件で回す | 教材サイトの持ち帰り資料。PDF |
| 5 | チェックリスト。AI に渡す前の5項目と、出力を使う前の5項目 | 教材サイトの持ち帰り資料。PDF 1枚 |
配布フォルダの 資料/記入例/ と 資料/発展/ も手元に残ります。研修中に手を付けられなかった発展課題は、研修のあとに同じ文面で続けられます。
配布フォルダの CLAUDE.md、AGENTS.md、tools/ は、そのまま自分の案件のフォルダにコピーして使えます。AGENTS.md の約束ごとのうち、題材に合わせて書いたもの（架空の題材であること）は、自分の案件に合わせて書き換えてください。
よくある質問
合流版は、どうやって受け取りますか
振り返りの時間に、講師が 成果物/合流用/ に入れるファイルを配ります。受け取り方は Zoom で案内します。
レビューで AI の指摘を全部採ってはいけませんか
根拠の行を開いて確かめたものは採って構いません。確かめずに採ると、AI の読み違いがそのままレビュー記録に残ります。レビュー記録は、あとで誰かがそれを見て設計を直す文書です。
検算が画面と合いません。どこから見ればよいですか
PJ を1つに絞り、社員の原価、パートナーの原価、売上の順に、画面の数字と自分の検算を1行ずつ並べます。ずれた行が見つかったら、画面の「集計の前提」と 原価単価.csv の契約条件を読み比べます。
研修のあとも、この配布フォルダで Claude を使えますか
フォルダはそのまま手元に残ります。Claude デスクトップアプリを研修のあとも使えるかは、貴社のご判断によります。社内のご担当者にお確かめください。
作った利用ルールを、社内で使ってもよいですか
たたき台としてお使いください。社内の規程やお客様との契約に照らして、法務や情報システムのご担当者と確かめてから展開してください。
持ち帰り資料はいつまでダウンロードできますか
教材サイトの公開期間は、貴社のご担当者からご案内します。必要なものは、研修の期間中に保存しておいてください。