Web施策の進行管理は何から始める？目的・担当・期限・成果物を一枚にする方法
「来月、問い合わせ用のページを改善しよう。公開日は月末で」。話が決まった翌日、担当者がタスク管理ツールに「原稿」「デザイン」「実装」を並べたとします。それでも、誰が原稿を確定し、誰が公開を許可し、計測ができる状態を誰が確認するかが決まっていなければ、予定表はすぐに止まります。
初めてWeb施策の進行役になったとき、最初に必要なのは細かなタスクの数ではありません。何のために、何を、誰が、いつまでに完成させるかを関係者とそろえることです。この記事では、小規模な広告・サイト改善を例に、その合意を一枚にまとめる方法を説明します。
まず「目的」と「作るもの」を別々に書く
「ページを公開する」は成果物の完成であって、施策の目的ではありません。目的は、たとえば「資料請求を検討する人が、サービスの対象と利用条件を理解できるようにする」。成果物は、その目的に向けて作るページ、原稿、計測設定などです。
目的を一文で書いたら、今回は何を作り、何を作らないかを決めます。たとえば既存の資料請求ページだけを改修するなら、サイト全体のデザイン刷新は範囲外です。着手後に「ついでにトップページも」と増えたら、同じ期限で引き受ける前に、必要な人手と納期への影響を確認します。
目的は公開後に確かめたい変化にもつながります。ただし、公開した時点で問い合わせが増えるとは限りません。制作の完了と成果の評価は別の時点・別の判定として置きましょう。
成果物には「できた」の条件と確認者を付ける
「原稿作成」とだけ書くと、執筆者は初稿で完了と思い、依頼者は法務確認後を完了と思うかもしれません。成果物ごとに、誰が何を確認すれば次へ渡せるかまで記します。
たとえばページ原稿なら「対象読者と訴求を反映した初稿を提出」「事業担当が内容を確認」「必要なら表現確認を経て確定」と分けます。デザインなら、スマートフォン表示や必要な注記が確認できる版を提出する。計測なら、テスト環境で想定したイベントが発火し、重複がないことを確認する。これらは架空の例で、実際の確認項目は施策と組織によって変わります。
すべてを詳細な仕様書にする必要はありません。最低限、成果物の名前、その完成条件、確認する人の三つがあれば、受け渡しの誤解を減らせます。
「担当」は作業する人と決める人を分ける
「マーケチームが担当」では、修正依頼が来たとき誰が受けるか分かりません。各成果物に進行上の主担当を一人置き、作業を分担する人、内容を確認する人、最終決定する人を分けます。一人が複数の役を担っても構いませんが、判断者が誰かは曖昧にしないことが大切です。
たとえばページ原稿はライターが作成し、社内マーケ担当が取りまとめ、事業責任者が訴求を確認する。計測設定は解析担当が実装し、依頼者がテスト結果を見る。このように書くと、原稿の修正が誰で止まっているかを特定できます。
決裁者が未定なら、仮の名前を埋めて進めず、「決裁者の確定」を未決事項にします。確認権限のない人のOKを積み上げても、最後に差し戻されるためです。
公開日から逆算し、「待つ時間」も予定に入れる
公開日だけを決めても、原稿が確定しなければデザインの最終調整はできず、実装が終わらなければ動作確認もできません。予定は作業の順序でつなぎます。
公開前に何を確認するかを決める。
その確認に必要な完成物と提出日を決める。
各提出物に必要な素材・判断・前工程を確認する。
確認者が返答する時間と、差し戻しに対応する余地を見込む。
たとえば「金曜に公開、木曜に動作確認」なら、木曜朝に初めて実装が終わる計画は余裕がありません。水曜までに何を実装し、誰がテストするかを先に相談します。休日や兼務者の空き時間も確認しましょう。これは日程の例で、どの案件にも使える所要日数ではありません。
重要なのは、遅れた作業だけを赤くすることではなく、次に何が始められなくなるかを見ることです。そこが分かれば、順番を変える、範囲を減らす、公開日を相談するなどの選択ができます。
一枚の着手メモで、最初の合意を取る
架空の「資料請求ページ改善」を例にすると、着手メモは次の程度で十分です。
目的：資料請求を検討する人が、対象サービスと利用条件を誤解なく理解できるようにする。
範囲：既存の資料請求ページのみ改修。サイト全体の刷新は含めない。
成果物と完了条件：確定原稿、確認済みデザイン、実装済みページ、計測テスト結果。公開前に事業担当が内容、解析担当が計測を確認する。
担当と判断者：社内マーケ担当が進行を持つ。原稿・デザイン・実装は各担当者。訴求の最終判断は事業責任者。
期限と順序：公開日から逆算し、原稿確定→デザイン確定→実装→動作・計測確認の提出日と返答日を置く。
未決事項：素材の提供日、表現確認の要否、公開を許可する人。
これを最初の打ち合わせで画面に出し、空欄をその場で確認します。合意できない項目は消さず、決める人と回答期限を残してください。「一枚」はページ数の義務ではなく、重要な判断を一度に見渡せるようにするための目安です。
進行中は「何％終わったか」より、次に止まる点を聞く
週に一度の短い確認なら、各担当に「予定との差」「次に渡すもの」「止まっている判断」を聞きます。原稿が八割書けたという報告より、「利用条件の確認待ちで結論部分が確定できない」のほうが、進行役には役立ちます。
新しい要望が出たときも、その場でタスクへ足す前に、目的に必要か、どの成果物が変わるか、担当者と期限に無理がないかを確認します。増やすなら他を減らす、期限を変える、追加の人手を確保するなど、影響と一緒に判断します。
進行管理は、予定表をきれいに保つ仕事ではありません。最初に約束した成果物を、必要な確認を通して出せる状態にする仕事です。まずは次の施策について、目的、成果物と完了条件、担当と確認者、期限と前工程、未決事項を一枚に書き、関係者に見せるところから始めてください。
参考：Asana「プロジェクト憲章」、Atlassian「プロジェクトの役割」、Atlassian「プロジェクト計画」。一枚の着手メモと資料請求ページの例は、これらを踏まえた本記事の整理であり、実在する案件の成果ではありません。
