MENU

プログラム未経験からPSDDで作る在庫管理ツール

この記事を最後まで進めると、倉庫の在庫を管理する小さなソフトが手元で動きます。品目を登録し、在庫数を書き換え、棚卸で理論在庫と実際の数を突き合わせる——この3つを画面から操作できるところまで作ります。さらに、棚卸の集計結果が、あらかじめ人が用意した正解と一致することまで確かめて終わります。動いただけでは止まりません。

使うのはPSDD(プロンプト仕様駆動開発)の多機能モードです。プログラムは書けなくて構いません。黒い画面(ターミナル)を触ったことがなくても、画面のあるソフトを作った経験がなくても、手順どおりに進めれば一周できます。仕様づくりはWeb版のClaude、実装と検証はClaude Codeという道具に任せ、こちらは日本語で指示と確認をするだけです。

この記事で作った要求仕様書・設計仕様書・テスト一式・完成プログラム・サンプルデータは、最後にまとめてダウンロードできます。手を動かしながら読み、必要なら現物を開いて確かめてください。

※登場する品目・数量・単価などのデータはすべて架空です。

目次

在庫管理ツールとは

作る在庫管理ツールの中身

作るのは、倉庫に置いた1台のパソコンで動く在庫管理ツールです。データベースの専用ソフトは使わず、Excelファイルをそのままデータ置き場として読み書きします。品目の一覧や在庫数はExcelに入り、ツールはそれを開いて書き換えます。画面はタブで3つの機能に分かれ、担当者はマウスとキーボードだけで操作します。

このツールが持つ3つの機能
  • 品目マスタ管理 … 品目の一覧・追加・変更・削除。品番はP-016のように自動で採番する。
  • 在庫数の変更 … 品目を選び、理論在庫数を書き換える。入出庫があったときに使う。
  • 棚卸 … 実際に数えた数を入力し、理論在庫との差異を出して確定する。結果はExcelに出力する。

この記事の検証で軸にするのは、3つめの棚卸です。差異は「実際に数えた数 − 理論在庫数」で決まり、その値が0なら一致、0でなければ差異、数え忘れなら棚卸漏れ、と区分が決まります。計算の答えが数字で一意に決まるので、正しく作れたかどうかを人が用意した正解表と突き合わせて確かめられます。完成した画面は次のようになります。

品目マスタの画面

在庫管理画面

棚卸し

単機能と多機能の分かれ目

砂糖さん

PSDDに単機能と多機能があるのは知ってるけど、今回はどうして多機能なの?書類も増えて大変そう。

PSDDは、作るものの重さに合わせて2つのモードを使い分けます。分ける基準は「機能がいくつあるのか」「失敗したときの影響の大きさ(リスクの大きさ)」です。具体的には、機能が1つか、そして失敗しても元に戻せるかの2点で見ます。小さくて戻せるものは単機能モード、機能が複数あるか、戻せない操作を含むものは多機能モードで作ります。

モードが変わると、作る書類の量と、設計の持ち方が変わります。単機能は身軽に、多機能は先に設計を固めてから作ります。

スクロールできます
単機能モード多機能モード
作る書類要求仕様書と期待値表だけそれに加えて設計仕様書・テスト設計仕様書などを作る
設計の持ち方設計書は作らず、実装しながら決める設計書で関数の役割を先に決めてから作る
向くもの機能が1つで、失敗しても戻せる機能が複数、または戻せない操作を含む

今回の在庫管理ツールは、品目・在庫・棚卸という3つの機能を持ちます。加えて、棚卸を確定すると理論在庫数を実際の数で上書きします。これは一度実行するとやり直しの効かない操作です。数え間違えた実棚数で確定してしまえば、正しかったはずの在庫が書き換わってしまいます。

機能が複数あり、戻せない在庫の上書きを含む。だから在庫管理ツールは多機能モードで作ります。

書類が増えるのは手間に見えますが、狙いは「作る前に正しさ設計・テスト設計の基準を固めておく」ことにあります。

使う4つのExcelデータを1つずつ見る

仕様づくりに入る前に、このツールが扱うデータを1つずつ確認します。ここで見る4つのExcelを作業フォルダに置いて渡すと、あとの工程が具体的な数字の上で進みます。抽象的な説明よりも、実物のデータがあるほうが、作るものの輪郭がはっきりします。どれも架空の数値です。

品目マスタ:扱う品目の台帳

1つめは品目マスタです。倉庫で扱う品目そのものの台帳で、今回は13品目が入っています。列は、品番・品名・単価・発注点・補充目標の5つです。品番は「P-001」のような形式で、この番号が品目を一意に指します。ツールで品目を追加すると、この台帳に1行増えます。

現在在庫:いまの理論在庫数

2つめは現在在庫です。品番と理論在庫数の2列だけの、シンプルなファイルです。理論在庫数とは、記録の上ではこれだけあるはず、という数です。品番で品目マスタとつながっていて、同じ13品目ぶんの在庫数が入っています。在庫管理の画面では、この数を書き換えます。

実棚結果:棚卸で数えた実際の数

3つめは実棚結果です。棚卸で実際に数えた数を、品番ごとに書いたファイルです。棚卸画面では、この数を1品目ずつ入力していきます。注目したいのは件数で、品目マスタは13品目あるのに、この実棚結果は11品目しかありません。P-011とP-012の2つが入っていないのは、数え忘れを表しています。この2つは、あとで「棚卸漏れ」として扱われます。

棚卸の正解表:あるべき差異と修正後の在庫

4つめは棚卸の正解表です。これはツールが作るものではなく、作る前に人が用意しておく答えです。理論在庫数と実棚数を突き合わせたとき、差異がいくつになり、どう区分され、確定後の在庫がいくつになるべきか——そのあるべき姿を書いた物差しです。差異一覧と在庫修正後の2つのシートに分かれています。この正解表が、あとで「ツールが正しく作れたか」を判定する基準になります。

この4つのデータを渡す準備ができました。ここから、これらを入力に、要求・設計・テストの仕様を固めていきます。

Web版Claudeで仕様一式を作る

いきなりコードは書きません。まず「何を・どう作り・どうなれば正しいか」を、Web版のClaudeとのやりとりで文書に固めます。入力になるのは、前章で見た4つのExcelです。ここから、要求・設計・テスト設計の順に、決めたことを積み上げていきます。工程は決まった合言葉で呼び出します。

Web版のClaudeのモデルはOpus 4.8を想定しています。

「要求」で要求を起こす

前章の4つのExcelを作業フォルダに置いたら、最初の合言葉を打ちます。合言葉はそのままコピーして使えます。

これで問診が始まります。要求では、「このツールが何をするか」を決めます。問診に答えていくと、このツールがどんな機能を持つのか整理されていきます。

問診とその回答

スクロールできます
聞かれたこと答えた内容
① 誰のための、何の道具か倉庫の在庫管理担当者(複数人)が、1台のPCで使うローカル完結の在庫管理ツール
② いま何に困っているか紙で在庫管理・数量チェックをしていて、在庫情報を正確に管理できていない。いつ誰が何を変えたかも追えない
③ この道具で何をしたいか(ゴール)ExcelをデータベースがわりにExcelを直接読み書きし、品目・理論在庫・棚卸を一元管理する
④ なぜ今ある方法では足りないか紙管理では在庫の正確性が保てない
⑤ 何人で使い、画面はどうするか倉庫にPCを1台置き、複数人が同じ1台で使う。tkinterのローカル画面。4画面構成(品目マスタ/在庫管理/棚卸/差異確認)
⑥ 何を渡すか(入力)品目マスタ.xlsx(品番・品名・単価・発注点・補充目標)と現在在庫.xlsx(品番・理論在庫数)を直接読み書き。棚卸のときは画面で品目ごとに実棚数を手入力
⑦ 何が返ると嬉しいか(出力)差異一覧のExcel(品番・品名・理論在庫数・実棚数・差異・区分)。棚卸確定後は、現在在庫.xlsxを実棚数で上書き
⑧ 判定や計算で使う基準差異=実棚数−理論在庫数/区分は「一致」(差異0)・「差異」(差異≠0)・「棚卸漏れ」(実棚数なし)の3種/品番は全角→半角・前後空白除去で正規化/棚卸漏れ品は上書きせず理論在庫を維持
⑨ うまくいかない入力の扱い品番は自動発番(P-001の連番法則)で重複を防ぐ/数値欄に数値以外・空欄のまま保存はエラーで弾く
⑩ 今回やらないこと発注点アラート・自動発注・発注金額計算・ログイン/ユーザー管理・操作者名の選択入力・ネットワーク通信
⑪ 使う人に持たせたい安心品目削除・棚卸確定の前に確認ダイアログ/全データ変更操作をログに残す(複数人で使うため、いつ何を変えたかを追える)
⑫ 前提にする技術・道具Python/tkinter(画面)/openpyxl(Excel読み書き)/ローカル完結
⑬ モードの判定4画面・複数機能(品目CRUD・在庫変更・棚卸・差異確認・ログ出力)を束ねるため「多機能」

問診をもとにWeb Claudeが出力した要求仕様書がこちらになります。どんなツールなのか、どういった内容で設計するかなど細かく記載されています。これをもとに設計仕様書やテスト設計仕様書などの作成が行われます。

入出力するファイル

入力するファイル

  • デモデータ(4つのエクセルファイル)

出力されるファイル

  • inv_要求仕様書_第1.0版.docx
  • spec_ids.json
  • inv_版管理票.md

「設計」で設計仕様書と期待値(正解)を決める

設計はWeb版Claudeで/psdd 設計で呼び出します。要求仕様書を渡すと、Claudeが「どう作るか」を設計します。単機能モードでは正解(期待値)を決めることに専念していましたが、多機能モードでは、設計仕様書としてドキュメントを作成することになります。だから、受け取る文書は設計仕様書と期待値表の2つになります。
 設計仕様書とは何か?プログラムをどう分けるか、どの関数がどんな値を返すかを決めた文章になります。このあたりはClaudeが設計する部分で、ユーザーが細かく決める必要はありません。

砂糖さん

正解の期待値も、Claudeが計算して用意してくれるってこと?

MATSU

期待値は単機能のときと同じで、Claudeが行う問診で決めていく形になります。

設計はClaude任せにしていますが、期待値はユーザーが決めるものになります。問診で決めた内容は以下の表に集約されます。

設計時の期待値表

スクロールできます
カテゴリ試した入力確定した期待出力出所
正常系(全体)品目マスタ13品目・現在在庫13品目・実棚結果11品目(2品目は棚卸漏れ)差異一覧13行が、人が手で作った期待値ファイルと完全一致実データ照合
正常系(差異算出)理論在庫200・実棚195差異 −5・区分「差異」実データ照合
正常系(一致)理論在庫100・実棚100差異 0・区分「一致」実データ照合
正常系(棚卸漏れ)理論在庫120・実棚なし差異なし・区分「棚卸漏れ」実データ照合
正常系(在庫更新)在庫13件+差異13件確定品は実棚数で上書き、棚卸漏れ品は元の値を維持実データ照合
境界(発番)既存品番 P-001・P-002・P-015次は P-016(最大番号+1)要求 REQ-1.2.1
境界(発番・0件)既存品番なし最初は P-001設計で定義
境界(正規化)「 P-015 」(全角+前後空白)「P-015」要求 REQ-3.2.3+凡例
境界(正規化・変換不要)「P-001」(半角そのまま)「P-001」(変えない)設計で定義
境界(品目入力・正常)品名「六角ボルト」・単価「10」・発注点「50」・補充目標「200」エラーなし。単価10・発注点50・補充目標200として取り込む添付サンプル
境界(品目入力・空品名)品名が空「品名は必須です」エラー要求 REQ-1.2.2
境界(品目入力・空白のみ品名)品名が空白だけ「品名は必須です」エラー(空白のみ=空欄扱い)設計で定義
境界(品目入力・任意項目空欄)品名だけ入力、単価等は空エラーなし。単価・発注点・補充目標は0をセット要求 REQ-1.2.3
境界(品目入力・小数)単価「12.5」単価エラー(整数のみ)設計+利用者の判断
境界(品目入力・負)単価「−5」単価エラー利用者の判断
境界(品目入力・文字列)単価「abc」単価エラー要求 REQ-1.2.4
境界(在庫入力・正常)在庫数「150」エラーなし・150要求 REQ-2.1.1
境界(在庫入力・負)在庫数「−1」エラーなし・−1(負の在庫は許容)要求 REQ-2.1.3
境界(在庫入力・非数値)在庫数「abc」エラー要求 REQ-2.1.2
境界(ロック)棚卸中に在庫数を変更しようとする「棚卸中のため在庫数を変更できません」エラー要求 REQ-3.5.1+利用者の判断
定義(ログ・変更)品目変更:単価 8→12日時・操作「変更」・品番「P-002」・内容「単価: 8 → 12」を記録利用者の判断
定義(ログ・在庫変更)在庫変更:理論在庫 200→195日時・操作「在庫変更」・品番「P-002」・内容「理論在庫数: 200 → 195」を記録要求 REQ-4.1.2+利用者の判断
未言語化棚卸画面の操作感現物を見て判断(保留)

設計の問診では、機能ごとに「正常なとき・境界のとき・おかしな入力のとき」を一巡し、Claudeが出した正解の候補を人が承認して確定させます。多機能なので期待値は23件と多くなりますが、問診を通じて決めていきます

実際に完成した期待値表は以下の内容になります。あわせて作られた設計仕様書は以下の通りになります。

設計仕様書

期待値表

入出力するファイル

入力するファイル

  • デモデータ(4つのエクセルファイル)
  • inv_要求仕様書_第1.0版.docx
  • inv_版管理票.md

出力されるファイル

  • inv_設計仕様書_第1.1版.docx
  • inv_期待値表_第1.0版.xlsx
  • inv_版管理票.md

「テスト設計」でテスト仕様書を作る

テスト設計はWeb版Claudeで/psdd テスト設計で呼び出します。要求・設計・期待値表を渡すと、Claudeが「どこを・どう確かめるか」を決めます。ここでは問診はありません。そのため、Claudeがテスト設計仕様書と対応表(トレーサビリティマトリクス)を作ることを待ちます。

トレーサビリティマトリクスについて説明します。PSDDでは要求仕様書からコード、テスト内容が発生します。要求に対して、対応するコード、テスト内容があって初めて実装されるもの、それを評価するテストが存在するということになります。要求、コード、テストにはそれぞれ固有のIDを割り振って設計します。要求が、どのコード、どのテストに対応しているかIDで確認する表がトレーサビリティマトリクスになります。実際のトレーサビリティマトリックスは以下のものになります。

いくらコードが読めなかったとしても、どんなテストをして評価されているのか、把握する必要があります。そして、それは以下の検証レベルの表に基づいて判断できるように設計されています。計算過程などは自動的に評価するツールが存在する一方で、画面表示、操作についてはClaude Codeが実行できるツールがありません。そのため、ユーザー側が実機で確認して評価する必要があることを理解しておく必要があります。

レベル何を確かめるか誰がやるか件数
単体核の計算・判定(差異算出など)を関数単位でClaude Code(自動)12
結合Excel読み書きなど部品をつないでClaude Code(自動)16+15(単体+結合)
通し起動→追加→棚卸確定→出力までを丸ごとClaude Code(自動)1(結合+通し)
手動画面の表示・操作感・確認ダイアログユーザー(実機で目視)10

最終的にできたテスト設計仕様書は次の工程に回す形になります。テスト仕様書については以下の内容な形で出力されます。

入出力するファイル

入力するファイル

  • デモデータ(4つのエクセルファイル)
  • inv_要求仕様書_第1.0版.docx
  • inv_設計仕様書_第1.0版.docx
  • inv_期待値表_第1.0版.xlsx
  • spec_ids.json
  • inv_版管理票.md

出力されるファイル

  • inv_テスト設計仕様書_第1.0版.docx
  • inv_マトリクス_第1.0版.xlsx
  • spec_ids.json(手動作業が含まれている場合のみ出力される更新版)
  • inv_版管理票.md

「テストコード」でテストコードを作る

最後の工程であるテストコードはWeb版Claudeで/psdd テストコードで呼び出します。この工程でも引き続きClaudeにテストコードをつくってもらうことになり、問診などは不要です。

出力されたテストコードを回収したら、いよいよClaude Codeによるコードの実装とテストの実行になります。

入出力するファイル

入力するファイル

  • デモデータ(4つのエクセルファイル)
  • spec_ids.json(更新版)
  • inv_設計仕様書_第1.0版.docx
  • inv_期待値表_第1.0版.xlsx
  • inv_テスト設計仕様書_第1.0版.docx
  • inv_版管理票.md

出力されるファイル

  • inv_test.py
  • inv_版管理票.md

Claude Codeで実装・テスト実行する

仕様一式ができたら、実装に移ります。ここからはClaude Codeに任せます。コードを書くチャットと、答え合わせをするチャットは分けて実装とテスト実行をします。理由は実装とテスト実行をわけて管理するためです。版が上がるタイミングでテストの内容を実装側が見れないようにチャットそのものを分断する制限を設けています。

仕様書類はinputフォルダを作って置く

実装に入る前に、置き場所を用意します。やることは3つだけです。

  1. コードを実装する作業用の親フォルダを1つ作る
  2. その中に input という名前のフォルダを作る
  3. これまでに作ったファイルを、まとめて input に入れる

inputに入れるのは、ここまでのフェーズで作った成果物です。整理はしなくてよく、まとめて置くだけです。

使う人は、inputに入れるところまでやればよいだけです。フォルダを分けたり、ファイル名を整えたりする必要はありません。実装作業をClaude Codeが実行したときに勝手にフォルダ分けしてくれます。

親フォルダとinputフォルダを作り、成果物をinputに入れれば、準備は完了です。

仕様書からコードを実装する

Claude Codeで/psdd-codeを入力してください。選択式でダイアログが出るようになっています。

実装を選択して実装作業を行います。Claude Codeは自動で、仮想環境の起ち上げ、必要なライブラリの取得など複数の作業をこなします。実行途中で作業環境を変更することなどは、許可を求めて来ることがあります。変更を許可しないと進まないため許可するようにします。

最終的に実装完了とチャットにでるのでその画面がでたら、テスト実行に移る案内が出ます。

テストコードでテスト実行

実装ができたら、新しいチャットを開いて再度/psdd-codeを打ちます。同じように選択式ダイアログが出てくるので今度はテスト実行を選択します。

テスト実行を選択したら、Claude Codeがテストを走らせ結果を報告します。多機能モードでは、テストの合否だけでなく、決めた要求と設計がコードにきちんと結びついているか(ID整合)など、詳細なチェックが入ります。自動で検証される項目は以下のとおりになります。

スクロールできます
確認したこと結果
テストの合否(pytest)40件すべて緑
要求ID・設計IDの整合指摘ゼロ(未実装0・確かめ忘れ0)
使う部品に既知の欠陥がないかなし
パスワード等の直書きがないかなし

Claude Codeができる自動テストが全て完了出会った場合、作成した版は正式に「完成(クローズ)」となります。完成したら、exe化して配布する、更に変更を加えるなど対応することができます。

もし、テスト実行でエラーが出る場合は、チャットにどこが誤っているか案内が出ます。案内に従ってそのまま問題箇所を修正をして再度テスト実行まで戻り、Claude Codeのテスト完了まで対応します。

実際にアプリを動かして確認する

自動テストは通りました。最後に、実際に画面を動かして確かめます。テストが緑でも、画面の見た目や操作の流れは、人が目で見ないと分かりません。ここは人がやる仕上げの工程です。

棚卸を入力して差異を確認する

ツールを起動すると、品目マスタ・在庫管理・棚卸の3つのタブが出ます。棚卸タブで、実棚結果のとおりに数を入力していきます。P-011とP-012は入力しません(数え忘れの再現です)。入力し終えると、差異一覧が画面に表示されます。

棚卸し画面

棚卸し操作後

棚卸し結果の出力

棚卸し結果を出力したエクセルファイルでは実数が一致すれば「一致」、増減があれば「差異」、棚卸しができていないものは「棚卸漏れ」として記録されていました。自動テストで確かめた計算が、実際の画面でもそのまま出ていることを確認できます。一連の操作で不具合になることもないのを確認できました。

自動テストと手動確認の切り分け

ここで確かめているのは、自動テストが担えない部分です。前に見た対応表で「手動」に振り分けた項目(10件)——画面の一覧表示や、削除・棚卸確定の前に出る確認ダイアログなど——は、機械では測りにくいので人が目視します。自動テストで確認されている箇所、人が確かめる箇所を切り分けて評価する。この切り分けを忘れないことが、正しくアプリを仕上げるコツです。

番外編:exeファイル化で配布する

番外編として、配布できる形式にして出力する方法を紹介します。exe化とは何か。どんな環境でもつくったプログラムが動くとは限りません。つくったコードや動かすために必要なライブラリーをまとめてPC環境に依存せず、動くファイル(.exe)として配布することができます。これでどんなPCでも動作させることができるようになります。

Claude Codeのチャットで/psdd-codeを入力して配布(exe化)を選択します。

アプリ名を聞かれるの回答します。

アイコンを設定できるようにしました。アイコンがあったほうが誤操作防止できるため、アイコンを付けることをおすすめします。

後は自動で全て実行してくれます。distフォルダにexe化されたファイルがあります。また、exe化されたファイルの他にコードやライブラリーが含まれているフォルダ、在庫管理システムにおけるデータを格納するフォルダがあります。そのフォルダもまとめて移動して配布してください。また、exe化されたデータはデモデータと異なる様になっているはずです。一度、実際に開いて確認することをおすすめします。

余談になりますが、アイコンは以下のサイトより使用させていただいています。

完成と一括ダウンロード

これで一周しました。既存のExcelを出発点に、要求・設計・テストの仕様を固め、Claude Codeで実装し、別のチャットで答え合わせをして、実機で棚卸しを通しました。品目・在庫・棚卸・操作ログの4つの機能を持つ、多機能の在庫管理ツールが手元で動いています。

棚卸の集計は、期待値表と動作が一致しました。動いただけでなく、Claude Codeによる機械チェックとユーザーによる動作確認でアプリをチェックした状態です。

この記事で作ったものを、下のボタンから一式ダウンロードできます。同じ手順を自分の手元でなぞることやアプリそのものを手元で再度作るための、出発点として使ってください。

ダウンロードに含まれるもの
  • 仕様一式 … 要求仕様書・設計仕様書・期待値表・テスト設計仕様書・対応・テストコード
  • サンプルデータ … 品目マスタ・現在在庫・実棚結果・棚卸の正解表

まとめ

多機能モードのPSDDを、最初から最後まで一周しました。ここで身についたのは、ツールの作り方そのものよりも、正しさの確かめ方です。振り返っておきます。

この一周で身についたこと
  • 正解は人が決める … 期待値はAIに計算させず、人が用意した正解表を物差しにする。
  • コード実装とテスト実行を分ける … 実装とテスト実行を別のチャットにして、答えを見ながら作らせない。
  • テストを自動と手動で切り分ける … 計算・判定は自動テスト、画面の見た目などは人が目視する。

最初に宣言したとおり、棚卸の集計が人の決めた正解と一致するところまで確認して終えられました。次は、この土台の上で機能を足したり、別の現場の課題に応用したりできます。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

CAPTCHA


目次