案件ごとにワークフローはこう変わる ── 40ページと200ページの設計の違い

株式会社ファストコーディングでフロントエンド開発と技術戦略を担当している黒田です。

以前の記事で、AIコーディングのワークフローに必要な役割分担や検証、ルールの共有、人間の確認について書きました。今回は、それを案件の規模に合わせてどう組み替えるか、という話です。

40ページと200ページでは、作業量だけが違うわけではありません。共通部品を直したときの影響、例外状態の数、確認待ちの発生場所が変わります。ここをページ数の掛け算だけで考えると、実装は速くても検査が追いつかなくなります。

同じ手順を、そのまま大きくすると詰まる

ページの実装が終わってから、まとめて検査する。少数のページでは管理できても、ページ数が増えると、同じ問題を含む実装が検査前に広がる恐れがあります。

例えば、共通カードの画像比率に問題がある場合。基準ページで見つかれば修正対象は限られますが、全ページへ展開した後では、関連するページと画面幅を確認し直す必要があります。

以下は、規模による設計の違いを説明するために、案件条件を一般化した例です。40ページや200ページを、サービスの受付条件として区切る話ではありません。

コーポレートサイト40ページで、トップ、内容ページ、フォームの三つの代表パターンがある場合を考えます。まず共通部品と、各パターン固有の表示・動作を整理します。

AIがベース実装を進め、コーダーが共通化の範囲とレスポンシブの方針を判断します。代表ページを確認し、基準が揃ったところから後続ページへ展開します。

検査へ渡す単位は、「すべて完成したら」ではなく、代表パターンと進行状況に合わせて決めます。例えば、内容ページの基準が確認できたら、そのグループを先に検査へ回す進め方です。

このとき、共有する規約と検査記録を分けておくと、何を基準に、どの版を確認したかが分かります。実装担当と検査担当は同じ仕様を参照しつつ、作った本人の思い込みに依存せず確認します。

ECサイト200ページでは、商品一覧、商品詳細、カート、マイページなど、表示と動作の関係が増えます。ページを一人ずつに割り振る前に、テンプレートと共通部品、状態の依存関係を整理します。

例えば、価格表示のルールを変える場合、商品詳細だけでなく、一覧、関連商品、カートにも影響するかもしれません。どの部品をどこで使うかが分からないと、修正対象の特定に時間がかかります。

実装と検査は、構造の近いページ群など、確認しやすい単位へ分けます。共通部品の変更が入ったら、関連するグループの検査へ戻せるようにします。

表示の確認とコードの監査も、同じ作業として扱いません。見た目が合っていても構造に問題はあり得ますし、コードが規約に沿っていても中間幅で崩れることはあります。検査方法ごとに担当と完了条件を定めます。

工程設計で確認したいのは、ページ数、テンプレート数、共通部品、動作や状態の複雑さです。同じ200ページでも、定型ページが多い案件と、個別UIが多い案件では、必要な確認が変わります。

例えば、商品詳細では通常表示だけでなく、長い商品名、画像なし、在庫切れ、選択肢の増減を確認します。何を例外状態として扱うかは、Figmaと仕様を基に人が判断します。

考え方を整理すると、次の違いがあります。

違いは、検査を省くか増やすかだけではありません。どの順番で渡し、誰が判断し、何を確認したら次へ進めるかを、案件に合わせることです。

工程表を作っても、「確認済み」の意味が人によって違えば、運用で抜けが出ます。検査待ち、修正待ち、人の判断待ちを区別し、修正後の再確認も別の作業として残す必要があります。

当社では、こうしたワークフローをAIMES上で実行します。AI、コーダー、専任QC、検査ツールの担当と順序をつなぎ、検査結果、差し戻し、修正、再確認、承認状態を管理します。

ワークフローの考え方そのものは、特別なものではありません。実際の案件で決めた工程を、確認漏れなく回すためにツールを使う、という関係です。規模が変わっても、完了の根拠を追える状態を保ちます。

ページ一覧ができたら、次の三つを工程設計の材料にしてみてください。

これが整理できれば、ページ数だけで人員を増やす計画から、確認を含めて回せる計画へ進めます。AIで生成する速さを活かすためにも、受け渡しと検査の設計が必要です。