文書化されたプロダクション計画に含めるべきこと

プロダクション計画は、整ったバックログではありません。設計、実装、ローンチ、運用を同じ方向へ進めるために必要な、最小限の意思決定を文章にしたものです。

コードは、議論されていない曖昧さも必ず何らかの形で解決します。ワークフロー、権限、失敗状態、運用責任が未定義でも、実装中に誰かが判断することになります。ただしその時点では文脈が少なく、後戻りのコストが高くなっています。

まず、実現したい業務上の変化から始める

最初のページに書くべきなのは、必要な画面ではなく、市場や業務で何が実現されるべきかです。

有用な冒頭には、次の問いへの答えがあります。

• 現在の課題を誰が経験しているか。
• その人は今、どのように対処しているか。
• プロダクトが機能すると、何が可能になるか。
• その変化に、なぜ事業上または業務上の意味があるか。
• 課題が実在すると示す根拠は何か。

これにより、以降のすべての判断に基準ができます。業務上の変化を支える機能は含め、支えないものは後回しにできます。

ユーザーを責任で記述する

役割名だけでは不十分です。「管理者」「顧客」「オペレーター」といった言葉は、権限設計やワークフロー設計を難しくする重要な違いを隠します。

意味のある役割ごとに、次を記述します。

• その人が何に責任を持つか。
• どの情報を見られるか。
• どの判断を行えるか。
• どの操作に承認が必要か。
• 間違えた場合に何が起きるか。
• 例外を誰が解決するか。

これらの答えは、ナビゲーション、権限、監査履歴、通知、管理機能の形を決めます。同じ役割名が、実際には複数の仕事を表している場合も明らかになります。

中核ワークフローを検証可能にする

計画には、きっかけから運用上の成果までの主な経路を示します。同時に、その経路がよく失敗する状況も含めます。

ワークフローごとに、次を定めます。

1. 何が開始条件か。
2. どの情報が必要か。
3. プロダクト内でどの判断を行うか。
4. プロダクト外に残る作業は何か。
5. 成功すると、システム上の何が変わるか。
6. 遅延、拒否、重複、中断が起きたとき、ユーザーに何を示すか。

正常系だけの図は、まだプロトタイプ仕様にすぎません。

画面が固まる前にデータを定義する

インターフェースとデータモデルは、同時に考える必要があります。単純に見える画面でも、所有ルール、履歴、同期、削除、派生レコードといった複雑な条件に依存することがあります。

完成したデータベーススキーマは不要ですが、少なくとも次を特定します。

• 主なレコードとその関係。
• 各レコードの所有者。
• 正式な情報源。
• 保持と削除の期待。
• インポートまたは同期されるデータ。
• 機密性の高いフィールド。
• 検証可能な状態で残すべき履歴。

ここで、多くの見かけ上のUI課題が、実はプロダクトポリシーの課題だと分かります。

プロダクト全体の境界を描く

本番スコープには、顧客向けアプリケーション以外も含まれます。成果を提供し、運用するために必要なすべての面を示します。

• 顧客・オペレーター向けインターフェース。
• バックエンドとデータの挙動。
• 認証と認可。
• 決済と外部連携。
• 管理・サポートツール。
• デプロイ環境。
• 監視、復旧、継続的な責任。

最初のフェーズですべてを構築する必要はありません。ただし必要な面はすべて見えるようにし、見落としではなく意図的な延期にします。

制約を設計入力として記録する

制約をリスク付録に追いやってはいけません。制約はプロダクトの形を決めます。

オフライン業務、規制対象データ、動かせないローンチ日、品質の低い外部API、アプリストア審査、既存の顧客契約、手作業の運用チーム。いずれも、適切なアーキテクチャとインターフェースを変えます。

Scoutbaseでは、不安定な通信はインフラ上の注記ではありませんでした。現場スタッフのフロー、同期の挙動、信頼、操作を完了とみなせる条件そのものを変えました。

有用な計画は、制約を早い段階で示し、それがどの判断に影響するかを明記します。

最初の本番スコープで締めくくる

最初のスコープは、運用し、検証し、学べるだけの意味を持たせます。作りやすい機能を切り離して並べただけでは不十分です。

含める能力ごとに、次へ答えます。

• どの成果を可能にするか。
• 本番環境で機能するために、何が必要か。
• どのように検証するか。
• 何を意図的に延期するか。
• 何が起きたらスコープを変えるか。

最終文書では、市場に詳しい人にも、実装する人にも、優先順位とトレードオフが読めるようにします。

文書は意思決定の基盤になる

計画の価値はページ数ではありません。重要な判断を、高価なコード、データ、運用挙動になる前にレビューできることです。

良いプロダクション計画は実装中も役立ちます。システムがなぜその形になったかを説明し、レビューできる具体物を提供し、その後の変更を偶然ではなく意図的なものにします。