目次
クライアント案件は、コード品質より前の段階で失敗することが多いです。
典型的な原因:
- 要件が曖昧
- 進行の確認ポイントが弱い
- 変更管理がない
- 引き継ぎが不十分
ここでは、問い合わせから納品までを安定させる運用フローを整理します。
フェーズ1: 問い合わせ段階で情報品質を上げる
問い合わせフォームは「連絡窓口」だけではなく、技術判断の入力点です。
最低限必要な項目:
- プロジェクトの目的
- 想定ユーザー
- 希望時期
- 予算帯
- 現在の技術スタック(ある場合)
これだけで、初回打ち合わせの質が大きく改善します。
フェーズ2: ディスカバリーの成果物を固定する
初回ミーティングのゴールは「相談」ではなく、意思決定です。
- 進める
- 保留
- 見送り
終了時に残すべき成果:
- 課題定義
- 対応範囲(in/out)
- 主なリスク
- 最初のマイルストーン
成果物がない状態で実装を始めないことが重要です。
フェーズ3: 実装可能なスコープに落とす
有効なスコープ文書には次を含めます。
- システム境界(フロント/バック/外部連携)
- 環境(dev/staging/prod)
- セキュリティ基準(認証、ヘッダー、秘密情報管理)
- 多言語対応範囲(EN/JA/AR)
- マイルストーンごとの受け入れ条件
測れない要件は、受け入れできません。
フェーズ4: マイルストーンは「証拠」で進める
各マイルストーンで必須にするもの:
- 動作デモ
- コード差分
- 運用メモ(環境変更・テスト結果)
これにより、進捗が「説明」ではなく「検証可能」になります。
フェーズ5: 連絡は低ノイズ高密度で
毎日会議する必要はありませんが、定期報告は必要です。
おすすめ運用:
- 週2回程度の非同期アップデート
- ブロッカーは当日エスカレーション
- 要件変更は意思決定ログに記録
コミュニケーションを仕組みにすると、認識ズレが減ります。
フェーズ6: 変更要求を無秩序に受けない
途中変更は必ず発生します。重要なのは分類です。
- バグ修正
- 同スコープ内の調整
- 新規機能追加
その上で、工数・コスト・リスクを見積もり、書面合意後に着手します。
フェーズ7: 本番リリース前チェック
リリース前に確認する項目:
- 環境変数と秘密情報の設定
- CSP/CORS/セキュリティヘッダー
- フォームとWebhook失敗時の挙動
- 解析・広告連携(必要時)
- ロールバック手順
- アカウント/ドメイン/ドキュメントの引き継ぎ
多くの障害は、ここを省略したときに発生します。
フェーズ8: 引き継ぎ + 安定化期間
納品完了の定義に、引き継ぎを含めます。
引き継ぎパック:
- 構成図
- デプロイ手順
- 既知の制約
- 保守提案
- 障害連絡経路
加えて、短期安定化期間(例: 30日)を設けると運用が安定します。
最終チェック
安定した納品は、個人の頑張りではなく運用設計で作られます。