業務フローと課題の整理
誰の、どの作業を、どれだけ減らすのか。ここが言語化できていない依頼は、実装しても使われません。
- やること
-
- 現状の作業手順を、担当者・所要時間つきで書き出す
- そのうち何を無くすのか、何を残すのかを線引きする
- システム化せずに運用変更で解決できないかを一度検討する
- 成果物
- As-Is 業務フロー、To-Be 業務フロー、課題一覧
- 完了条件
- 「この機能によって、誰の何分／月が減るか」を数字で言える
全体像
6つの工程を順に通します。各工程には成果物と完了条件があり、完了条件を満たさないまま次に進まないことが、この手順の唯一のルールです。
| 工程 | 成果物 | この工程で潰すリスク |
|---|---|---|
| 1業務フローと課題の整理 | As-Is／To-Be の業務フロー、課題一覧 | そもそも作る必要のないものを作る |
| 2データモデル設計 | テーブル定義、ER図、権限マトリクス | 後から作り直すと最も高くつく変更 |
| 3Excel 試作 | 計算ロジックの検証ブック | 業務ルールの解釈違い、計算誤り |
| 4画面モック | 画面イメージ、遷移の流れ | 操作導線の認識ズレ |
| 5仕様書への統合 | 機能単位の仕様書、受け入れ基準 | 「正しく動く」の定義が曖昧なまま実装 |
| 6縦切り実装 | 1機能が通しで動く状態 | 認証・権限・デプロイの後付け |
この順番である理由
画面から入ると、業務のほうが「作れそうな画面」に引っ張られます。データ構造から入ると、業務のほうが主で画面が従になる。工程2を工程4より前に置いているのは、この一点のためです。
各工程の詳細
「完了条件」は、次の工程に進んでよいかの判定基準です。曖昧な表現ではなく、他人が見て◯×を付けられる形にしてあります。
データモデル設計
後から一番高くつく変更がスキーマ変更です。画面は何度でも直せますが、テーブル構造の作り直しは既存データの移行を伴います。ここに一番時間をかけます。
- やること
-
- 主要テーブルと項目、型、必須／任意を決める
- テーブル間の関連（1対多・多対多）を確定する
- 誰がどの行を見られるかの権限マトリクスを作り、RLS の方針に落とす
- 履歴を残す必要がある項目を洗い出す（改定履歴・改姓・異動など）
- 成果物
- テーブル定義、ER図、権限マトリクス
- 完了条件
- 想定される検索・集計を、そのテーブル構成で表現できることを確認済み
Excel 試作でロジックを検証する
Excel は「実行可能な仕様書」です。計算ロジックをコードを書く前に、実際の担当者と数字で合意できます。当所のシステムは計算ルールが正しいかどうかが価値の大半なので、ここを最優先で潰します。
- やること
-
- 実データに近いサンプルで、入力から出力までを1枚で再現する
- 端数処理、按分、日割り、上限・下限の扱いを明文化する
- 例外パターン（月中入社、休職、二重加入など）を別行で用意する
- 成果物
- 検証ブック（そのままテストデータとして使う）
- 完了条件
- 担当者が実案件の数字を入れて、期待どおりの結果になることを確認済み
画面モックで合意する
確認するのは操作の流れだけです。色や余白、文言の細部はここで詰めません。動かしてから直したほうが速い領域です。
- やること
-
- 主要画面のラフと、画面間の遷移を並べる
- 1画面あたり「何ができれば完了か」を1行で添える
- 権限による表示差（見える人・見えない人）を明示する
- 成果物
- 画面モック画像、遷移図
- 完了条件
- 利用者が、モックだけを見て一連の作業を口頭で再現できる
仕様書に統合する
Claude Code に対して最も効く情報は、受け入れ基準です。「正しく動く」の定義が渡っていないと、それらしく動くだけのものが出来上がります。
- やること
-
- 機能単位でファイルを分け、
docs/に置く - 受け入れ基準は「入力A・Bのとき、出力はCになること」の形式で書く
- Excel 試作の1行を、そのまま受け入れ基準として転記する
- やらないこと（スコープ外）も明記する
- 機能単位でファイルを分け、
- 成果物
- 機能別仕様書、受け入れ基準一覧、
CLAUDE.md - 完了条件
- 受け入れ基準が、すべて数字か◯×で判定できる書き方になっている
縦切りで実装する
全機能の設計を完璧にしてから作り始めるのではなく、最小の1機能を DB から画面まで一本貫通させます。認証・権限・デプロイまで先に通しておくと、以降の機能追加が急に速くなります。
- やること
-
- 最も代表的な1機能を選び、DB → API → 画面 → デプロイまで通す
- そのうえで機能を1つずつ足す。1コミット1機能
- 常に動く状態を保つ。壊れたまま次に進まない
- 成果物
- 本番環境で動作する最小構成
- 完了条件
- 実際の利用者が、本番環境で1件分の業務を完了できる
Claude Code への渡し方
前工程の成果物をどう渡すかで、出力の質が大きく変わります。守るのは3点だけです。
原則 1仕様は分割して渡す
1ファイルの大作にせず、docs/ に機能単位で分割し、CLAUDE.md から参照させます。長大な仕様を一度に渡すと、後半の指示ほど精度が落ちます。
原則 2実装の前に設計案を出させる
「まず設計案と、変更対象ファイルの一覧を出してください。実装はまだしないでください」と指示し、内容を確認してから実装に進みます。このひと手間が、手戻りを最も減らします。
原則 3小さく変更し、都度動かす
1コミット1機能。動かないコードを積み上げないこと。まとめて指示するほど、どこで壊れたかの特定に時間がかかります。
よくある失敗
前工程を丁寧にやっているときほど起きやすい失敗です。
失敗 AExcel の構造をそのままテーブルにしてしまう
Excel は横に項目を並べますが、データベースは縦持ち・正規化が基本です。Excel シートをそのまま列に置き換えると、項目が増えるたびにスキーマ変更が必要な構造になります。
対処：Excel は「ロジックの検証装置」であって「テーブル設計図」ではない、と切り分ける。工程2と工程3は別物として扱う。
失敗 BExcel を作り込みすぎる
検証のつもりが完成品になり、「Excel で足りるのでは」となる。
対処：それが正しい答えなら素直に受け入れる。開発しないという判断も、この手順の正常な出力です。
失敗 C権限設計を後回しにする
給与、マイナンバー、健康情報を扱う以上、「誰がどのデータを見られるか」は最も後付けが苦しい領域です。画面を先に量産してから権限を入れると、ほぼ全画面の作り直しになります。
対処：工程2でテーブル定義と同時に権限マトリクスを作り、RLS の方針まで決めておく。
失敗 D受け入れ基準が「〜できること」で書かれている
「賃金を正しく計算できること」では判定できません。実装者にとっても、Claude Code にとっても情報量がゼロです。
対処：「月給25万円・月中10日入社の場合、日割り支給額は◯円になること」の形式に直す。
決める順番の判断軸
5人規模の事務所で、要件定義書・基本設計書・詳細設計書と積むのは過剰です。判断基準は一つ、変更コストが高いものだけ先に決めることです。
先に決める
後から変えると高くつくもの
- データモデル（テーブル・関連・履歴の持ち方）
- 業務ルール（計算式、端数処理、例外の扱い）
- 権限とデータの見える範囲
- 受け入れ基準
- 外部連携の有無と方式
動かしてから決める
後から変えても安いもの
- 画面レイアウト、余白、色
- ボタンやラベルの文言
- 一覧の並び順、初期表示件数
- 絞り込み条件の追加
- 細かい操作性の改善
運用への落とし込み
「スクリーンショット → モック → 合意 → 実装」の進め方は、右側（動かしてから決める領域）の運用としてよく機能します。その手前に、左側の合意を一段挟むこと。それだけで後半のスピードがそのまま成果になります。
テンプレート
そのままコピーして使えるひな形です。
ドキュメント構成CLAUDE.md ← 全体方針。docs/ への参照を書く
docs/
00_overview.md ← 目的、利用者、スコープ外
01_data_model.md ← テーブル定義、ER図、権限マトリクス
02_rules.md ← 業務ルール・計算ロジック
10_feature_xxx.md ← 機能ごとに1ファイル
90_acceptance.md ← 受け入れ基準一覧
data/
sample.xlsx ← 工程3の検証ブック
機能仕様書のひな形
# 機能名
## 目的
誰の、どの作業を、どう変えるか（1〜2行）
## 利用者と権限
- 管理者：
- 一般：
## 入力
| 項目 | 型 | 必須 | 備考 |
## 処理ルール
- 端数処理：
- 例外パターン：
## 出力
## 受け入れ基準
- [ ] 入力Aのとき、出力はBになること
- [ ] 一般権限では、他部署の行が表示されないこと
## スコープ外
- 今回やらないこと
Claude Code への初回指示
docs/ の 00, 01, 02, 10_feature_xxx を読んでください。
そのうえで、まず以下だけを出してください。実装はまだしないでください。
1. 実装方針（どういう構成にするか）
2. 変更・新規作成するファイルの一覧
3. 仕様の中で判断がつかなかった点、確認したい点
確認後に実装を依頼します。
受け入れ基準の書き方
悪い例
- 賃金を正しく計算できること
- 権限に応じて表示が変わること
良い例
- 月給250,000円・月中10日入社の場合、
日割り支給額は80,645円（円未満切捨て）になること
- 一般権限でログインした場合、
所属部署以外の従業員が一覧に表示されないこと
着手前チェックリスト
Claude Code に最初の実装を依頼する前に、これらがすべて埋まっていることを確認します。