手戻りを防ぐアプリ仕様の制約と非ゴール

仕様で制約を省くと手戻りが起きる理由

手戻りは、動作するものを作ったのにプロジェクトには不適切だったためにやり直すことです。チームは画面を作り直し、ロジックを書き換え、データを移行し、機能を再構築することになります。これは重要な決定が遅れて出てくることで起きます。

よくあるパターンは次のとおりです。想定していたユーザーロールが間違っていてフローを作り直す、モバイル対応が期待されていて再設計する、バージョン1の後に「監査履歴が必要だ」となってデータモデルが変わる、クライアントが第三者サービスを使えず統合を入れ替える、コンプライアンスや地域ルールでホスティングを移す必要が出る、などです。

制約が書かれていないと後で驚きの判断が生まれます。仕様に「CRMを作る」とだけ書いてあると、多くの質問が残ります：誰が使うのか、どのプラットフォームが重要か、どんなセキュリティルールがあるか、何をスコープ外にするか、予算と期限は本当か。回答がコード作成後に出ると、二度手間になります。作るためのコストを支払い、さらに元に戻すためのコストも払うことになります。

例を一つ。創業者が「予約＋リマインダー」を頼んだとします。1週目にメールリマインダーを出してリリースします。2週目になってSMSが必要だと言われますが、その国ではSMSが使えないか予算を超えます。するとリマインダーの設計を変えて画面を変え、テストをやり直す必要が出ます。これはコーディングが下手だったからではなく、制約が遅れて出たからです。

目的は、コードを書く前にやり取りを減らすことです。手で書こうがチャットベースのビルダーを使おうが、出力は与えたルールに従います。ルールが遅れて出ると作業がシフトしてやり直しになります。

長い文書を作る必要はありません。ライトな仕様でも重要な点は厳格にできます。初期段階では次に答えられるようにします。

• 何が固定か（期限、予算、チーム、レビュー頻度）
• 技術的に何が固定か（スタック、ホスティング、データの所在）
• アプリがしないこと（非ゴール）
• 全体計画を覆さずに何が変えられるか

制約と非ゴールを先に書けばガードレールのように働き、驚きや作り直しが減り、初日から判断が明確になります。

制約と非ゴール：1分でわかる違い

制約はプロジェクトが従わなければならない固定の決定です。無視すると出荷できない方向に作ってしまい、二度手間になります。

非ゴールは明確に「やらない」と宣言するものです。書かないと仕様が静かに膨らみ、小さな追加が画面やデータモデルの作り直しを誘発します。

簡単なルール：制約はどう作るかを制限し、非ゴールは何を作らないかを制限します。

制約に当たるもの

制約は、本当に変えられない「必須」です。簡単に「多分」と言えるならまだ制約ではありません。

例：

• 「6週間でローンチする必要がある」
• 「予算は上限15,000ドル」
• 「データ居住性のためEU内で動作させる必要がある」
• 「フロントはReact、バックエンドはGo、データベースはPostgreSQLであること」

制約が本物なら、議論の余地がない一文で書いてください。誰かが「もしかして…」と言えるなら、それはまだ制約ではありません。

非ゴールに当たるもの

非ゴールは「これを作りません」という明確な宣言です。初回リリースを守るための防御策と考えてください。

例：

• 「v1ではモバイルアプリは作らない。ウェブのみ」
• 「ローンチ時に多言語対応はしない」
• 「リアルタイムチャットは作らない。メール通知で十分」

非ゴールは消極的な宣言ではなく、高コストの寄り道を避けるためのものです。例えば「v1でカスタムロールは作らない」は、権限周りの難問を先延ばしにしてデータベースやUIの大幅な見直しを防げます。

ワンライナーと小さな成功定義から始める

詳細を書く前に、プロジェクトを一文でピン止めしてください。これが判断の基準になります。

良いワンライナーは、誰のための何をするかを答えます。

例：

• 「個人教師向けに、学生がセッションを予約してリマインダーを受け取れるシンプルなウェブアプリ」
• 「小さな診療所向けに、スタッフが当日の予約を確認し簡単な診療メモを記録できるモバイルアプリ」

次に小さな成功定義を3〜5の成果で書きます。機能ではなくユーザーが達成できる結果で書いてください。

チューター予約の例：

• チューターが数分で1週間分の空き時間を設定できる
• 学生が電話やメール不要でセッションを予約できる
• 両者が確認とリマインダーを受け取る
• チューターが電話・PCで日別の予定を明確に見られる

まだ指標が無ければ言葉で成功を表現します。「速い」は曖昧ですが「スマホで速く感じる」は十分です。「簡単」も「導入に説明不要」のように具体化できます。

このセクションは短く保ち、以降のすべての文脈（何が必須か、何がしてはいけないか、何が変えられるか）の基礎にします。

固定するプロジェクト制約（時間、予算、人）を書こう

手戻りはスケジュールや意思決定プロセスが誰かの頭の中にだけあるときに起きます。画面や機能を説明する前に、プロジェクト制約を仕様書に入れてください。

プレーンでテスト可能な文にします：

• 期限とマイルストーン：ローンチ日と2〜3のチェックポイント（仕様承認、プロトタイプ承認、初回リリース準備）。初回リリースに含まれるものを明示する。
• 予算：上限か目標レンジか。何が含まれるか（開発、デザイン、テスト、ホスティング、サポート）を明記する。
• 人員と稼働時間：誰がレビューし、どれくらいの速さで応答するか。遅いフィードバックは制約である。
• 決定権者：トレードオフが出たときに「Yes/No」が出せる人。

簡単な例：

「初回リリースは5月30日までに出す。ログイン、基本的な顧客リスト、月次レポート1つを含む。v1では統合なし。予算は最初の1か月のホスティングを含めて8,000ドルが上限。レビューは平日24時間以内に行う。プロダクトオーナーはSamで、スコープ変更を承認するのはSam。」

フィードバックの速さは独立した一行に値します。これが進め方を左右するからです。関係者のレビューが週1回しかできないなら、仕様は小さなリリースと少ない例外を優先すべきです。

現実に合うレビュー頻度を選んでください：即日、平日24〜48時間、週次ミーティングのみ、または（稀に）「フィードバック不要」の選択肢など。

固定する技術的制約（スタックとホスティング）を書こう

技術的な制約を早く書かないと、人は勝手に前提を埋めてしまいます。その結果、作業中に画面やマイグレーション、統合をやり直すことになります。

まず、何がロックされていて何が優先希望にすぎないかを明確にします。「Reactが望ましい」は「Reactでなければならない」とは違います。理由があれば一文で示してください。

スタックをロックする（本当に変えられない部分だけ）

アプリ全体（Web、バックエンド、DB、モバイル）で明示します。柔軟なら境界を示します（例：「v1ではモバイルはWebのみ」）。

書き方の例：

• Web/UI：Xを使う（理由）、またはX/Yで可（決定者）
• Backend：Xを使う（理由）。APIはRESTまたはGraphQLで公開する
• Database：Xを使う。マルチテナントが必要かどうか
• Mobile：ネイティブ/Flutter、または「v1では対象外」
• 開発とデリバリ：ソースコードのエクスポートが必要か、dev/stage/prod環境の有無

続けて避けられない統合を列挙します。支払い、メール、分析、CRMなどのシステム名を書き、ハードな制限を書きます。例：「課金はStripeで行う必要がある」、「メールは既存プロバイダ経由で送ること」、「分析は個人データを追跡しないこと」。認証が固定なら（SSO、Googleログイン、パスワードレス）それも明記してください。

ホスティング、リージョン、データ規則（平易な言葉で）

ホスティングの選択はアーキテクチャを変えます。アプリをどこで動かす必要があるかと理由を書いてください：例「ドイツでデプロイする必要がある」「データはEU内に留める」「グローバルで動かして良い」など。

コンプライアンスがあるなら具体的にしてください：保存期間、削除ルール、監査要件。

例：「記録を7年間保持、検証済みの削除要求から30日以内に削除、記録を見た人の監査ログを保持、患者が住む国のみでデプロイ」。これらはリリース直前のサプライズを防ぎます。

スコープを守るために非ゴールを追加する

非ゴールは仕様のガードレールです。初回リリースで作らない、サポートしない、完璧を目指さない項目を明確にします。多くの「小さな」要求が後で来て全体計画を変えてしまうのを防ぐ最速の方法です。

良い非ゴールは1文でスコープの膨張に気づけるように具体的で、時間軸があることが望ましい。「v1ではない」は「やらない」より明確です。

初回リリースで作らないもの

人が含まれていると想定しやすい機能から始めます。簡単な予約アプリなら：

• v1で管理者用ポータルは作らない（基本的なスタッフツールのみ）
• v1で多言語やローカリゼーションは行わない
• オフラインモードや同期は作らない
• 複雑なダッシュボードは作らない（簡単な週次サマリーのみ）
• v1で外部統合（支払い、カレンダー、メールツール）はなし

これらは悪い機能ではなくコストの高い機能です。書いておくと初回リリースが集中できます。

役割や権限、例外フローのような『詳細』項目も明記してください。例えば「カスタムロールは作らない。ロールはOwnerとMemberの2つだけ」。これだけで数週間を節約できます。

最適化やサポートしないもの

機能以外の非ゴールも書き残します。これがないと後で痛いリワークになります。

例："v1で100万人を想定してチューニングしない。v1は週500アクティブユーザーまでを想定する"、"Internet Explorerはサポートしない"、"タブレット専用レイアウトは作らない"、"ログインはメールとパスワードのみ（SSOやマジックリンクなし）"、など。

全体を覆さずに何が変えられるか決める

仕様は小さな判断を進化させられる余地があると安心です。固定事項だけ書くと新しいアイデアごとに大議論になります。短い「変更して良い項目」リストを作ると、重大な機能追加ではない改善を進められます。

実践的に。最初に学ぶであろう点に関する項目に絞ってください。柔軟項目の例：UIテキスト、小さなフローの修正、レポートの列、名称（ロール、ステータス、カテゴリ）、基本的なレイアウトなど。

次に、変更の受け入れ方法を決めます。承認ルールがないと「ちょっとした修正」が知らぬ間にスコープを広げます。

多くの小規模チームに有効なシンプルなワークフロー例：

• 誰でも変更を提案できるが、1人のオーナーが承認する。
• 変更は決められた頻度でレビューする（毎日か毎週）。
• 承認された変更は仕様に1文で追記する。
• 期限やコストに影響する変更はトレードオフを記載する。

重要なルール：柔軟な変更は固定された制約を壊してはいけない。スタックがReact + Go + PostgreSQLに固定なら、それを「バックエンドを切り替える」ための変更にはできません。期限が固定なら「新しいモジュールを追加して2週間延長する」は許されません。

共通のトレードオフ例を1つ用意して合意しておくと良いです。「新しいユーザーロールを追加するなら、高度なレポート機能をフェーズ2に延期する」など。

仕様にコピペできるステップ形式

良い仕様は選択肢を絞ることから始まります。この形式は誰かが作り始める前にルールを書くことを強制します。

コピペ用フォーマット（空欄を埋める）

ヘッダーとしてドキュメントに貼って使ってください：

SPEC v0.1 (date)
Owner:
Reviewers:

1) One-liner
- Build: [what it is]
- For: [who]
- So they can: [main benefit]

2) Success definition (3 outcomes)
- Outcome 1: [measurable result]
- Outcome 2: [measurable result]
- Outcome 3: [measurable result]

3) Fixed constraints (cannot change without re-approval)
- Deadline: [date]
- Budget: [$ or hours]
- People: [who is available]
- Tech stack: [fixed choices]
- Hosting/region: [where it must run]

4) Non-goals (must NOT happen)
- [explicit “no”]
- [explicit “not in v1”]
- [explicit “we won’t support”]

5) Open questions
- Q: [question]
  Owner: [name]
  Due: [date]

6) Lock rule
- After review: changes require: [what approval looks like]

速く終わらせるための5ステップワークフロー

1. まずワンライナーと3つの成果を書く。これが決められないなら機能を決める準備ができていない。
2. 次に固定制約を埋める：期限、予算、チーム、スタック、ホスティング地域。
3. 非ゴールを守るために「やらない」リストを書く。
4. オープンクエスチョンに1人のオーナーを付ける。
5. 15分のレビューをしてバージョンをロックする。以降の変更はカジュアルな編集ではなく新しいリクエストとして扱う。

後で驚きになる一般的な落とし穴

ほとんどの驚きは運ではなく解釈の違いから起きます。仕様が異なる解釈を許すと後で問題になります。

一つは目標と解決策を混同することです。画面やフローに飛びつく前に、期限・予算・技術スタックといった固定事項を書かないと、見た目は良くても制約に合わない計画になります。

もう一つは曖昧な非ゴールです。「余分な機能は作らない」は厳しく聞こえても、「ちょっとしたレポート」や「簡単な管理パネル」が来たときに何も止められません。非ゴールは具体的でテスト可能にしてください。

隠れた予算や“ゆるい”期限もスコープ爆弾です。実際の予算が5,000ドルなのに仕様が50,000ドル相当に見えると、チームは間違ったものを作ります。嫌な数字でも文章に入れてください。

統合とデータ所有権も静かな驚きを生みます。「Stripeに接続する」と書いても、どのイベントを受け取るか、どのフィールドを送るか、誰がデータを所有するかを定義していないと同じ決定を何度も話すことになります。

最後の落とし穴は、開発途中で制約を変えることをトレードオフなしに行うことです。「ウェブのみ」から「ウェブ＋モバイル」に変えたり、「Postgres」から「安い方にする」に変更すると計画が変わります。変更はできますが、必ずスコープ・期限・品質のいずれかを更新してください。

これらを避ける簡単な方法

仕様に短い注記を加えて5点に答えられるようにします：

• 何が固定か（期限、予算範囲、誰が作るか）
• 技術的に何が固定か（スタック、ホスティング、必須のセキュリティルール）
• 明確に含めないもの（3〜5の非ゴール）
• 初回リリースの「完了」の定義（1つの測定可能な成果）
• 何が変更可能で、誰が承認するか

コード生成前の簡単チェックリストと次のステップ

誰かが作り始める前に「何が固定か？」の質問にすぐ答えられる状態にしてください。

早いチェック：

• 期限、予算範囲、誰が使えるか（あるいは使えないか）は見つかるか？
• 技術的選択は固定として書かれており、使わないものも明記されているか？
• ホスティングは地域と簡単なデータルール（データの所在、越境できないもの）が明確か？
• スコープ膨張を防ぐ短い非ゴールリストがあるか？
• 何が変えられるか、誰が承認するかが明確か？

これらが欠けていると最初のビルドは行われますが、本当のビルドは二回目になります。

勢いを維持しながら悪い決定に縛られない次のステップ：

1. 機能より前に仕様の上部に制約と非ゴールを置く。
2. 変更を承認する人たちと短い計画パスを行い、非ゴールを口頭でも確認する（沈黙は同意ではないことが多い）。
3. 小さな反復で最初のバージョンを作り、学んだら仕様を締める。

もしKoder.ai（koder.ai）を使うなら、"Planning Mode"と明確な制約・非ゴールセクションを使うと、プラットフォームがあなたのスタック、ホスティング地域、スコープに合った初回ドラフトを生成しやすくなります。優先度が変わった場合はスナップショットとロールバックで安定したベースラインを保ちつつ変更を試せます。ソースコードのエクスポート機能があれば、後でレビュー・移行・引き継ぎをする際に役立ちます。

これらのルールを早期に書いておくと、機能の議論が楽になります。みんなが何を固定するか、何を動かして良いかを知っているからです。