実践例: EASE

商談・案件管理SaaS「EASE」を企画からマージまで通して動かした実行記録。何が起きたかのケーススタディ

商談・案件管理SaaS「EASE」を例に、NexusArchitectのバックログ運用スキルを最初から最後まで動かした実際の流れを紹介します。フェーズ6のロールアップレビューで見つかった問題が、フェーズ7で新しい作業を生み出し、フェーズ8の実装がまた次のIssueへつながっていく——という循環になっている点に注目してください。

フェーズ1: プロダクト企画(/product:start, fullプロファイル)

VisionからScope、アーキテクチャ設計まで、全23フェーズの企画作業を行いました。この作業でreports/フォルダに約30個のファイルができました。 North Star Metric(最も重視する指標のこと。ここでは案件情報がどれだけ新しく保たれているかを示す「案件更新鮮度率」)を基準にして、プロダクト名の候補「EASE」を選びました。 EASEは、Effortless(簡単)・Always-updated(常に最新)・Shared(共有されている)・Everyone(みんなが使える) の頭文字です。

フェーズ2: バックログ起票(/architect:export-backlog)

12件のIssue(Epic 1件、Sub-Epic 3件、Issue 8件)をGitLabに作成しました。使っていたのは個人のネームスペース(自分専用の作業スペース)だったため、GitLabのEpic機能が使えず、ラベルとタスクリストで代わりに親子関係を管理する方式にしました。

フェーズ3: 実装(/architect:implement-backlog)

Java 21、Spring Boot 4.0.7、PostgreSQLを使って実装しました。 4つのブランチ(feature/I1.3.1-... → I1.3.2-... → I1.1.1-... → I1.2.1-...)を順に積み重ねる形で作業し、12件のIssueをすべて実装しました。最終的にテストは35件、すべて成功しました。

フェーズ4: レビュー(/architect:review-issue)

レビューを4回に分けて実施しました。 1件のブロッカー(必ず直すべき問題。[B-1]: roleを昇格させる操作に対するチェックが漏れていた)を見つけて修正しました。レビューを終えたIssueごとに、合計4件のMR(マージリクエスト。変更をmainブランチに取り込むための申請)を作成しました。

フェーズ5: マージ(/architect:merge-issue)

作成した4件のMRを順番にマージし、Epicの作業を完了しました。マージ後にpushしたところ、セキュリティ上のfinding(レビューで見つかった問題点)がもう1件見つかりました ([changedByの値が存在するかどうかの確認漏れ]、KN-4)。これはすぐに修正し、再度レビューしました。

フェーズ6: Epicロールアップレビュー(implement-backlog --review-epic=E1)

個別のIssueごとのレビューでは見つからなかった、重要なfindingが2件見つかりました。

[S-1] PUT /users/{userId}(ユーザー情報を更新するAPI)のroleガード(権限チェック)に不整合がありました。ユーザー作成時のチェックは修正済みでしたが、更新時のチェックは直っていませんでした。
[S-2] テスト35件は全て、モック(本物の代わりに使う仮のオブジェクト)だけを使ったテストでした。 Web層・データ保存層・機能間の連携を確認する統合テストは1件もありませんでした。

フェーズ7: 次サイクルの自動生成(/architect:export-backlog再実行)

ロールアップレビューで見つかった問題を元に、新しいSub-Epic「SE1.4 Identity & Access Management (認証・認可の管理)」と、それに紐づく5件のIssueを新たに起票しました。これは、レビューで見つかった問題がそのまま次の作業のもとになった例です。

フェーズ8: 実装継続

SE1.4の最初のIssue(Spring Securityの基盤づくり)を実装しました。認証方式にはHTTP Basic認証を採用し、ログインIDにはUser.id(UUID)を使うという設計判断を decisions.mdに記録しました。実装を終えた後、Epic全体の整合性チェックで新しいfindingを見つけました。最初のユーザーをどうやって作るか(ブートストラップ問題)という課題で、これも記録しました。

まとめ: NexusArchitectが解決する問題

この一連の作業から分かるのは、NexusArchitectが単発のコード生成ツールではないということです。レビューで見つかった問題が、そのまま次の作業のきっかけになる仕組みを持っています。実際に、フェーズ6のロールアップレビューで見つかった[S-1][S-2]の問題が、フェーズ7で新しいSub-Epic 「SE1.4」の起票につながりました。

NexusArchitectの各コマンドは、次のような役割を持っています。

export-backlog: 企画の内容を、プログラムが読み取れる形式(backlog-manifest.json)に変換する
implement-backlog: Epic全体の背景を踏まえたまま実装する。コストを抑えるため通常は軽いモデルを使い、判断が難しい箇所ではopus(より高性能なモデル)を使う
review-issue: 1件のIssueだけでなく、関連するIssueやEpic全体との整合性もチェックする。見つかった教訓はreview-knowledge.mdにまとめ、以降のレビューでも使う恒久的なチェック項目にする
merge-issue: 厳格な事前チェックを通過した場合だけマージを実行し、完了状況を正確に記録する

さらに、Sub-Epicの作業が完了したタイミングでは、Epicロールアップレビューを行います。このレビューは、個別のIssueレビューだけでは気づけない問題を見つけるためのものです。今回のセッションでは、「roleガードの修正漏れ(作成時は直したが更新時は直していない)」と「テストが全てモックで、実際の統合テストがない」という2つの問題が、このロールアップレビューで初めて見つかりました。そして、その結果がそのまま次のSub-Epicの起票(フェーズ7)につながりました。このように、レビューの結果が次の具体的な作業を生み出す仕組みこそが、NexusArchitectのバックログ管理の中心的な役割です。

このセッションで実際に踏んだ問題はトラブルシューティングにまとめています。