UIモックファーストな実装計画のすすめ：AIとの協働開発で学んだこと

結論

実装計画を作る際は、先にUIモック（完成イメージのスクリーンショットや手書きスケッチ）を作成し、それを計画書に含めておくと良い。

理由：

• 実装範囲が明確になる
• 作業の見落としが減る
• 計画書自体がより具体的になる
• AIに計画を作らせる際も、より正確な計画が生成される

今回の事例

クレカ明細の突き合わせ機能で、結果表示を改善する作業を行った。

課題：ボタン押下後の結果表示が簡素すぎて、実際の状態が伝わらない 原因：実装計画にフロントエンドの表示仕様が含まれていなかった 対策：UIモックを先に作成し、それをもとに全レイヤーの実装を洗い出す

修正前

「突き合わせを実行」ボタンを押すと、結果が「一致 140件」としか表示されない。

しかし実際のデータを見ると、サイドバーには「不一致:1」「重複:1」など詳細な内訳が表示されている。

修正後

4つのカテゴリが色分けされて表示されるようになった。

• 一致（緑）：レシートとマッチしたもの
• 候補（紫）：仕訳ルールの候補があるもの
• 不一致（赤）：マッチしなかったもの
• 重複（オレンジ）：重複しているもの

何が問題だったか

既存の実装計画にはバックエンドのロジックは書かれていた。しかしフロントエンドで「何を表示するか」の詳細は含まれていなかった。

結果として、実装時に以下の作業が追加で必要になった：

バックエンドだけでなく、フロントエンドの型定義、代入処理、テンプレート、CSSまで全レイヤーの修正が必要だった。

学び：UIモックファーストな計画

フロントエンドの表示を変更するには、バックエンドからフロントエンドまで全レイヤーの実装が必要になる。

先にUIモックを作成し、それを実装計画に含めておくと：

1. 実装範囲が明確になる - 「この表示を実現するには何が必要か」が逆算できる
2. 作業の見落としが減る - フロントエンドの変更も計画に含まれる
3. 計画書自体がより具体的になる - 抽象的な「〜を追加」ではなく、具体的な表示が決まる
4. レビュー時に意図が伝わりやすい - 「こう表示したい」が視覚的にわかる

実装計画書のベストプラクティス

1. 先にUIモックを作成 - スクリーンショットや手書きでもOK
2. そのモックを実装計画書に添付 - 画像として埋め込む
3. モックから逆算して必要な実装を洗い出す - API、DB、フロントエンド
4. 各レイヤーの変更を計画書に明記 - 漏れがないようにする

実装チェックリスト

UIの変更を伴う機能を実装する際は、以下を確認する：

• APIレスポンスに必要なフィールドが含まれているか
• フロントエンドの型定義が更新されているか
• データの代入・バインディングが正しいか
• 表示テンプレートが追加されているか
• スタイル（CSS）が定義されているか

AIとの協働開発での活用

AIに計画を作らせる際も、「こう表示したい」というイメージを先に伝えると、より正確な計画が生成される。

❌ 「突き合わせ結果の表示を改善して」
⭕ 「突き合わせ結果を『一致 140件 / 候補 122件 / 不一致 1件 / 重複 1件』のように4カテゴリで表示したい」

具体的なUIイメージがあれば、AIは必要なバックエンド・フロントエンドの変更を洗い出しやすい。ただしAIが正確に計画を立てるには、既存のコード構造や技術スタックの情報も合わせて共有する必要がある。

まとめ

「何を表示するか」を先に決めてから実装計画を作る。これだけで作業漏れが減り、計画の精度が上がる。

AIとの協働開発でも、UIモックを先に共有することで、より正確な計画と実装が可能になる。