AIに任せて個人開発したら設計で漏れが出た話 〜機能一覧・画面一覧を飛ばしてはいけない理由〜

対象読者

• AI(Claude Codeなど)を使って個人開発・ポートフォリオ作成をしている方
• 要件定義のあと、何から設計すればいいか迷っている方

この記事でわかること

• 機能一覧・画面一覧を飛ばして設計すると何が起きるか
• 個人開発でも守りたい設計の順番
• 入力チェック(バリデーション)をフロントとバックの両方で行う理由

結論

個人開発でも、AIがいても、「要件定義 → 機能一覧 → 画面一覧 → 基本設計」の順番は飛ばさない方がいい。

私はこれを飛ばしてテーブル設計に進み、Claudeにレビューしてもらった結果、考慮すべきユースケースが抜けた設計になっていることが判明しました。

後から順番通りに作り直したところ、3つのつもりだったコア機能は45機能、画面は24画面ありました。この差がそのまま設計の漏れになっていたわけです。以下、その失敗と学びをまとめます。

何が起きたか

ポートフォリオとしてWebサービスを作るにあたり、個人開発だからと要件定義のあとすぐに基本設計(DBのテーブル定義書)に着手しました。

当時は知らなかったのですが、実務では基本設計の前に機能一覧と画面一覧を作るのが慣例だそうです。

テーブル定義書をClaudeにレビューしてもらったところ、次のような指摘を受けました。

• 同じCSVファイルを2回取り込んだ場合、取引明細が全件二重登録される(重複を防ぐ制約がない)
• ユーザーがカテゴリを修正したとき、修正前のカテゴリの集計値を減らす手段がない
• 通知バッチが途中で失敗した日に、二重通知になるのか、その日の通知が飛ばないのかが決まっていない

機能や画面を具体的に洗い出していなかったため、「どんな操作が起こりうるか」を想定しきれていなかったのが原因です。

なぜ飛ばしてしまったのか

振り返ると、原因は2つでした。

1. 個人開発だから手順を省いていいと思った
2. AIがいるから、自分が100%理解していなくても何とかなると誤解していた

特に2つ目が大きかったです。AIは質問すれば答えてくれますが、自分が想定できていないことは質問すらできません。設計の漏れに気づけたのは、たまたまレビューを頼んだからでした。

「守破離」という言葉があるように、まずは先人が確立した型を守るべきだと痛感しました。

本来やるべきだった順番

成果物	目的
機能一覧	システムが「何をできるか」を漏れなく並べる
画面一覧	ユーザーが「どこで操作するか」を並べる
画面遷移図	画面同士のつながりから、操作の流れを確認する
ユースケース	「誰が・何を・どうする」を洗い出し、必要なデータを見つける

機能と画面を先に出しておくと、「この画面ではこのデータを表示・登録する」という形でテーブルに必要な項目が自然に見えてきます。いきなりテーブルから考えると、この逆算ができません。

私の場合、作り直した結果は次の通りです。

• コア機能は3つのつもりでしたが、認証・設定・管理者機能まで含めると45機能になりました

• 画面は24画面。うち6画面は管理者向けで、要件定義では「管理者がCSVの形式を管理する」という一行で済ませていた範囲です
• 通知データを保存する設計にしていたのに、それを表示する画面を定義していませんでした
• 自動で振り分けたカテゴリを、ユーザーが後から見直すための画面も抜けていました
• 「取り込み件数の上限は何件か」「確認画面はページかモーダルか」など、決めていなかった仕様が次々と出てきました

特に最後の点が大きく、画面を1枚ずつ数えていく過程で、テーブル設計だけを眺めていたときには出てこなかった疑問が自然と出てきました。

おまけ:バリデーションはフロントとバックの両方で行う

機能一覧をClaudeに作ってもらった際、入力チェックがフロントとバックの両方に入っていたので「重複では？」と指摘したところ、両方必要な理由を説明されました。

実装場所	役割	片方だけだと…
フロントエンド	入力ミスをすぐ知らせて、無駄な通信を減らす	ブラウザ側のコードは書き換えられるため、セキュリティ対策にならない
バックエンド	不正なデータを最終的に確実に弾く	入力ミスのたびに通信が発生し、使い勝手が悪くなる

つまり、フロントは「使いやすさ」、バックは「安全性」のためのチェックです。これまで効率ばかり意識して開発していたので、この視点は今後大事にしたいと思います。

AIとの役割分担で気づいたこと

今回、機能一覧・画面一覧・画面遷移図の作成はClaudeに任せ、私はレビューを担当しました。

ただ、レビューする側に知識がないと、指摘すべき点にも気づけません。AIに作業を任せるほど、人間側には「判断できるだけの理解」が必要になると感じました。

まとめ

• 個人開発でも「機能一覧 → 画面一覧 → 基本設計」の順番は飛ばさない
• AIは「想定できていないこと」までは補ってくれない
• バリデーションはフロント(使いやすさ)とバック(安全性)の両方で行う

同じようにAIと個人開発を進めている方の参考になれば嬉しいです。誤りや改善点があれば、コメントで教えてください！

ポートフォリオ作成

当記事は自身の貴重なアウトプットの場とするとともに、
ポートフォリオ作成で学んだことを記録しておき、
新米プログラマのだれかのためになればと思って作成しています。
変な点やつっこみどころがあればどんどんお願いします！

目次

1. 学び
2. 作業内容
3. 最後に

学び

「既存の開発手法を尊重するべし」

開発の進め方として、個人開発ということをいいことに、
要件定義後すぐに基本設計に踏み切りました。
その当時はしらなかったのですが、機能一覧と画面一覧をこの前に作成するのが慣例だそうです。

その結果何が起きたかというと、機能や画面を具体的に抽出できていなかったために、
基本設計で漏れが多く発生しました。
DBのテーブル定義書を作成しClaudeにレビューを依頼したところ、
考慮するべきユースケースを想定できていない設計となっていることが判明しました。

Youtubeである動画を拝見した際に、
物事を理解する際には 「解像度を上げること」 が大切だと言っていました。
物事を広く深く、様々な角度からみることで、
自身で言語化できるレベルで解像度を上げるといいそうです。

AIを用いて開発を行う過程で、自身で100％理解していなくてもいいのではないかと誤解してしまっていたようです。
（その動画も自戒のために後でもう一度見直します。）
先人達が確立した開発手法を信頼せず、自身を過信した結果です。
守破離という言葉があるように、
まずは既存の型を大切にしようとおもいます。

今日は機能一覧、画面一覧を念入りに見直しながら作成したので、
明日からはそれをもとにユースケースを洗い出し、テーブル設計書を作成する準備を進めます。

作業内容

作業名	進捗	備考
テーブル定義書	中断	優先タスクが発生したため
機能一覧	100%
画面一覧	100%
画面遷移図	100%

ポートフォリオとして作成するWebサービスの機能と作成する画面一覧を作成し、
各画面の関係性をまとめた画面遷移図を作成しました。
作業自体はCaludeに代行してもらい、レビューを主に担当しました。
頼りになる後輩をもったようで、先輩として知識不足を痛感します。

特に機能一覧でバリデーションチェックをフロント、エンドどちらもで行う仕様になっていたので指摘したのですが、
セキュリティ上フロントのみではコードを書き換えられる可能性があり、
バックのみでは無駄な通信を行う可能性があるためどちらも必要とのことでした。
情けない、、、
今まではセキュリティなどの上流の考えをもたず、ひたすら効率を求めて開発を主に行っていたので、こういった視点は今後大切にしたいです。

最後に

プロンプトの内容は簡単なWebサービスの予定ですが、
変更するかもしれないので、内容については完成したさいに記事にします。
それまでは、日々の気づきをアウトプットする場にさせて頂きます。
今日もお疲れ様です(^▽^)/