長期化・中断・担当交代したWeb制作を、安全に再開するには

中断した制作には、さまざまなものが残っています。

• デザインデータ
• HTMLやCMSのソース
• 原稿と画像
• Backlogなどの課題
• メールやチャットのやり取り
• 見積りやスケジュール
• 公開環境や確認用URL

しかし、ファイルが残っているだけでは、どれが確定版か、なぜその案を採用したか、誰が承認したかは分かりません。また、当時利用していたCMS、ライブラリ、外部サービス、アカウントが現在も使えるとは限りません。

再開前には、成果物の有無だけでなく、その成果物を成立させていた前提を確認します。

過去の資料と残作業を、次の四つに分けます。

担当者が交代すると、完成画面は共有されても、なぜその構成や表現を選んだかが失われやすくなります。その結果、同じ論点を再検討したり、一部分の変更によって全体方針が崩れたりします。

引き継ぎでは、次を残します。

• 採用した案と理由
• 採用しなかった案と理由
• 共通仕様と個別仕様
• 変更すると他ページへ影響する項目
• 現在保留している論点
• 次に判断する担当者
• 公開後に見直す項目

詳細な議事録をすべて読み直してもらうより、現在の判断状態へ整理して渡す方が再開しやすくなります。

確認期間が長い案件では、すべてが確定するまで作業を止める方法と、すべてを暫定状態で進める方法のどちらにも問題があります。

ページや機能を、例えば次の状態へ分けます。

• 確定済み
• 確認中
• 追加対応
• 公開条件待ち
• 公開後対応

変更指示には、変更箇所だけでなく、理由と影響範囲を添えます。時間が空いた後も、何を守り、どこから再開すればよいか判断できるためです。

確定済みのコードやデザインへ変更を加える場合は、該当箇所だけでなく、共通部や関連ページへの影響を確認します。「確定済み」は二度と変えないという意味ではなく、変更時に影響を確認する基準です。

将来公開するページを見越して共通ヘッダーや部品を作っていても、未公開の導線まで先に表示してよいとは限りません。

段階ごとに、次を整理します。

• 対象URL
• 必要素材
• 共通部への変更
• 現在表示してよい導線
• 確認者と承認状態
• 公開条件
• 次段階へ送る変更

同じコードを利用することと、同じタイミングで公開することは別の判断です。担当交代時にも、実装済み、未反映、確認待ちを区別します。

再開時の打ち合わせでは、残作業だけを並べません。

1. 現在の目的と対象者
2. 中断前に確定したこと
3. 中断後に変わったこと
4. 再確認が必要なこと
5. 現在の担当者と承認者
6. 素材・データ・権限の状態
7. 公開環境と公開方法
8. 残作業と追加作業
9. 新しい確認・公開スケジュール
10. 次回中断しても再開できる記録方法

再開を急ぐほど、最初の棚卸しを省きたくなります。しかし、過去の前提が変わっている場合、早く作り始めることが手戻りにつながります。