第1回では、計器の校正期限管理ツールの要求仕様書を作りました。今回はそれを「種」にして、設計仕様書を作り、Claude Codeで実装するところまで進みます。ポイントは、AIが書いた設計を、コードが読めなくても質問して中身を確かめること。丸投げにしない進め方です。
1. 設計でやること（要求仕様書を「作り方」に翻訳する）
設計とは、要求仕様書（何を作るか）を、作り方に翻訳する工程です。ここでも決まった設計プロンプトを使います。第1回で作った要求仕様書を添付して、このプロンプトをWeb Claudeに渡すだけです。
あなたは、非エンジニアの開発相談相手です。
添付の「要求仕様書」を読み、それを実現する設計を1本にまとめてください。
計算・判定の中身（コア）と、画面（UI）を、同じ仕様書の中で節に分けて書きます。
下の「設計仕様書の構成」に沿ってください。
【守ってほしいこと】
- 要求仕様書の「やらないこと」を超えない。最小構成を保つ。
- 判定や処理の考え方を、まず日本語で説明してから、Pythonコードを示す。
私（非エンジニア）が、説明だけ読んでも筋が分かるようにする。
- コードはPythonで統一。外部ライブラリは最小限にし、使う場合は理由を一言添える。
- コア（データ読み込み・計算・判定）とUI（画面）は役割を分けて書く。
UIはコアを呼ぶだけにし、コアのロジックには手を入れない。
- 要求仕様書に書かれていない判断が必要なときは、勝手に決めず質問する。
【設計仕様書の構成】
1. 全体像（何を受け取り、何を返し、画面はどう使うか）
2. コア
2-1. 入力データの読み込み
2-2. 入力と出力のデータ（項目名・型）
2-3. 判定・計算の考え方（日本語）
2-4. ロジック（Python）
2-5. しきい値・設定値
2-6. エラー時のふるまい
3. UI
3-1. 画面構成
3-2. 操作の流れ
3-3. 結果の見せ方（色分けなど）
3-4. コアとのつなぎ方（Python）
4. 使う技術とやらないことこのプロンプトのいちばん大事なところは、コア（計算・判定）とUI（画面）を分けて書かせることです。計算の中身と画面を分けておくと、あとで画面を変えても計算が壊れません。
設計を作る途中で、Claudeから1つ確認が入りました。予約タイミングをを過ぎてしまった機器について、表示の確認です。例えば、6月に点検期限をむける計器のケースにおいて、4月に予約タイミングがくる場合、要求仕様書のとおりにすると5月の点検予定リストには何も表示されない。要求仕様書の漏れです。
Web Claude予約のタイミングを「過ぎてしまった」計器の扱いに、2案あります。A案＝予約期限が今月末までに来ているもの（過ぎた分も含む）を出す。B案＝その月ぶんだけ出す。最初の一回や、回し忘れた月があると、B案では取りこぼします。期限切れを防ぐ目的なら、推しはA案です。
MATSUA案でお願いします。多少しつこく出ても、取りこぼしがない方が安全です。
A案の選択後、設計仕様書ができあがりました。でも、ここで「できたから次へ」とはしません。コードが読めなくても、中身を質問で確かめます。
2. 質問で、設計仕様書の中身を確かめる
できあがった設計仕様書を、そのまま信じてしまうと、「AIに丸投げ」と同じです。そこで、設計に対して質問していきます。3つは、他の設計仕様書にも使い回せるような内容にしてあります。
論点①：計算ルールは、正しく入っているか
MATSU要求仕様書の計算ルールが正しく入っているか、コードではなく言葉で説明してください。特に、期限切れ（赤）と点検予定（黄）のパターンを。
Web Claude校正期限・予約期限・赤（期限切れ）・グレー（不備）は、要求仕様書どおりに入っています。ただ、黄（点検予定）だけ要求仕様書の文面とズレています。設計では、さきほど選んだA案（過ぎた分も含めて出す）で作ってあります。設計のほうが正しいのですが、要求仕様書の文面が古いままなので、直しておくのがおすすめです。
この質問のおかげで、要求仕様書の文面と、設計で選んだA案が食い違っていたことが見つかりました。設計が正しいので、要求仕様書のほうをA案に合わせて更新し、版をv1.1に上げました。どうして要求仕様を変更したのか、後からわかるように記録を残しつつ、要求仕様書の版を上げていく必要があります。よくあることです。
論点②：抜け漏れるケースはないか
MATSUこの設計で、抜け漏れるケースがあるとしたら、どんなケースでしょうか。
Web Claudeいちばん怖いのは「黙って画面から消える」計器です。台帳に載せ忘れた計器、前回校正日に未来の日付が誤って入った計器、校正実績の更新ミス——これらは黄にも赤にもならず消えます。いずれも台帳そのものの正しさに頼っている部分で、ツールの安全範囲の外です。業者名の表記ゆれや、赤が多くて黄が埋もれる件は、グレーや赤で可視化はされます。
MATSU「台帳の正しさはツールの外」と線引きできるのは大きいですね。台帳更新はプログラムではなく、運用ルールで補います。
論点③：外部ライブラリは最小か
MATSU使っている外部ライブラリは最小になっていますか。それぞれ、どんな働きをするか教えてください。
Web Claude外部は openpyxl 1つだけです。エクセルを読み書きし、色を塗り、印刷設定をする部品で、標準のPythonにはこの機能がないので必要です。画面の tkinter、日付計算の datetime、月末を出す calendar は、Pythonに最初から入っています。pandas を足すとコードは短くなりますが、重くて過剰なので入れていません。
砂糖さん道具が少ないと、あとで動かなくなる心配も減りますね。
3つの質問で、計算ルール・抜け漏れ・道具立てが確かめられました。コードを読まなかったとしても確認できることは可能です。全て対応とは現実難しいと思いますが、気になる点・心配な点はなるべく質問して聞いておくべきです。
3. 要求仕様書 v1.1 と設計仕様書をもとに実装する
仕様が固まったので、Claude Codeに実装してもらいます。ここでPlanモードを使います。いきなりコードを書かせるのではなく、「何をどう作るか」の計画を先に見せてもらい、納得してから実装に進む——設計仕様書をベースに計画だてて実行するため、Claude Codeの計画も大きな修正もなく実行できます。
添付の設計仕様書のとおりに実装してください。
いきなり書き始めず、まず Plan モードで「何を・どの順で作るか」の計画を見せてください。
計画を確認してOKを出してから、実装に進んでください。
計画に問題がなければ、承認して実装に進みます。出来上がったら、動かして確かめます。要求仕様書の正解データだけ、確認してみましょう。デモ台帳の実データで計算した正解の表（QA-001は期限切れ＝赤、など）が載っています。画面の結果が、その表と一致しているかを確認します。
画面の色と状態が、正解値の表どおり出ています。仕様書通りに動いていますね。ただ、用意したデモデータが期限切れが多いので、実運用とかけ離れています。第4回で実際の運用に近づけた形で評価してみましょう。
4. まとめ
- 設計プロンプトで、要求仕様書を「作り方」に翻訳した（コアとUIを分けて設計）
- できた設計は、3つの質問（計算ルール・抜け漏れ・ライブラリ）でコードを読まずに確認した
- 質問のおかげで要求仕様書との食い違いが見つかり、種を v1.1 に更新（変更管理）
- 実装はPlanモードで計画を見てから承認。動作確認は要求仕様書の正解値と照らした
動かして正解値と合うところまで来ましたが、これで「正しい」と言い切るには、まだ足りません。境目（月末ちょうど・うるう年・不備データ）でも正しく動くかは、目視だけでは確かめきれないからです。次回は、この「正しさ」を機械的に確かめるテストの段階に進みます。
使用しているデータ・業者名・計器名はすべて架空のものです。実在の企業・校正機関とは関係ありません。
コメント