Plan Review デュアルモード：CEO 思考 + エンジニアアーキテクチャ、なぜ分けて使うのか

多くのエンジニアは機能を設計する時、2 つの最も重要な質問を飛ばしてしまいます：

「この機能は作る価値があるか？」——ほとんどの人は「もちろん、要件がもう来ているから。」と仮定します。
「このアーキテクチャに隠れた failure mode はないか？」——ほとんどの人は「書き終わって動けば OK」と仮定します。

この 2 つの質問を、Gstack の Plan Review はそれぞれ担当します。

2 つの Skill、2 つのまったく異なる思考周波数

/plan-ceo-review と /plan-eng-review は見た目どちらも「計画レビュー」ですが、問いかける質問がまったく異なります——

/plan-ceo-review は Founder / CEO の視点：

/plan-eng-review は Engineering Manager / Tech Lead の視点：

一方は後退して「価値があるか」を問い、もう一方は前進して「どうやれば正しいか」を問います。混ぜると、どちらも上手くできません。

例えば Gstack に「EC プラットフォームに商品比較機能を追加したい。ユーザーが同時に 3 つの商品のスペックを比較できるようにしたい。」と伝えるとします。

通常の AI アシスタントなら、直接比較テーブルの設計案を出してくれるでしょう。

/plan-ceo-review を使うと、まずこんなことを聞いてきます：

これらの質問は、あなたの PM が聞いたかもしれないし、聞いていないかもしれません——でも Gstack は必ず聞きます、毎回。間違った問いに対して正しい解を積み上げさせてくれません。

同じ機能で /plan-eng-review に切り替えると、Gstack の出力フォーマットが大きく変わります：

これらをすべて毎回実行する必要はありませんが、「これらの問いは考える価値がある」というチェックリストがあるだけで、ゼロから考えるより遥かに時間を節約できます。

標準フロー：まず CEO、次にエンジニア。

この順序には論理があります——/plan-ceo-review の後で機能の定義やスコープを変えたなら、/plan-eng-review は再実行する必要があります。逆の場合、作る価値のない機能のために大量のアーキテクチャ設計時間を費やすことになるかもしれません。

まず「価値がある」を確認し、次に「どうやれば正しいか」を確認する。

小さな機能の場合：どちらか一方だけでも可。

すべての機能に CEO 思考のプレッシャーテストが必要なわけではありません——ボタンの色変更に「これは価値があるか」を問う必要はありません。
すべての意思決定に Engineering Manager の深堀りが必要なわけでもありません——設定項目の追加のアーキテクチャは通常シンプルです。

判断基準はシンプルです：この決定が間違っていたら、どれだけ痛い？ 痛みが大きいほど、Plan Review をかける価値があります。

Gstack の Plan Review でよくある誤用は：コードを全部書き終わってから実行すること。

この時点で Plan Review を実行して、CEO が「この機能の定義は違うはずだ」と言ったら、どうしますか？作り直すか無視するか？どちらも良くありません。

Plan Review のタイミングは意思決定がまだ固まっておらず、コードがまだ動き始める前——文字通り「計画段階のレビュー」です。作業開始前の強制思考プロセスとして扱い、事後のチェックリストとして扱わないでください。

Gstack との対話でリアルタイムに機能を説明する必要はありません。要件ドキュメント、user story、デザイン仕様の説明を直接貼り付けて、コマンドでトリガーできます：

/plan-ceo-review

[要件ドキュメントまたは user story]

提供した素材から始めて、CEO の思考フレームワークで分析します——実行が速くなり、詳細を見逃しにくくなります。

Plan Review ができました、次のステップ：コードを書き終わったら、どうやって production 品質のレビューをして、ワンクリックで納品するか。

この記事は Gstack シリーズの第 3 回で、Plan Review デュアルモードに焦点を当てています。完全な読書ルートと他の記事のトピックは Gstack 入門コース に戻って確認してください。