大量のページを扱うwebリニューアルでは、Airtableなどのデータベースを使って、ページごとの制作ステータスをうまく管理していくことで見通しがよくなります。が、このステータス項目の作り方・使い方が案外難しいらしいということに気づいたので、ノウハウをまとめてみます。

はじめに：「進捗状況のコード化」という考え方

ビジネス小説、三枝匡さんの『戦略プロフェッショナル』終盤で出てくる、営業の案件管理をコード化するという話。これが基本思想です。コード化の狙いは、状態の明確化と「共通言語化」です。

※上の図はGoogleBooksで検索したら出てきました。ぜひ書籍をどうぞ！

つまり、節目の「アクション」を実行したら次に行くという考え方です。これは非常に明確な指針なので、「誰が、何をしたらステータスを切り替えるか」という視点を常に意識しましょう。

Backlogで「ボールを渡し合う」状態の使い方

プロジェクト管理ツールのBacklogでは、たった4つのステータスで明確に課題の状態が管理できるツールデザインになっています。

次のように運用しています。

1. 未着手（New、担当者にボールを渡す）
2. 処理中（In progress、ボールを受け取った言明）
3. 処理済み（Review、起案者にボールを戻す）
4. 完了（ボールが返ってきた人がボールをしまう）

このように、Backlogでは最小限の個数の「状態」と、「担当者(Assignee)」項目の組み合わせで、明確なタスクの状態管理が可能です。PMは「いかにボールを持たないか」を運用方針を周知し、「誰かが間違ってボールを持っていないか」を監視しながら、適宜ステータスと担当者を変えていけばメンテできます。

この運用は、Asana（要課金）でもカスタム項目で実現できるし、タグやタイトルを工夫すれば「担当者」だけでも運用できます。

＊＊＊

次に、依頼者⇔作業者の２者間ではなく、ステータス管理が複数の作業者・確認者をまたぐ場合を考えます。

たとえばwebサイトのページ登録作業の場合、登録作業者・校正者・ディレクター・クライアント担当者（場合によってはさらにその先）が工程に関わるため、もう少し複雑なステータス項目を持つ方が進捗が明確になります。

BADケース：「～中」を多用するのは✖

今日見かけた、あまりよくないケースは、

など、どの作業工程にいるかをステータス項目にしてしまうケース。

これは、PMが全部中央集権で全部のステータスを切り替える場合は成り立ちますが、作業者の視点に立ったとき、
「どのステータスのリストを見ればいいのか」
「作業を終えたらどのステータスにすればいいのか」
が非常に分かりにくいため、項目が不十分です。原則として、複数の作業者間でボールを繋いでいく場合、期間ではなく点を項目名にするほうがよいです。

「～中」という項目は、ボールを長めに持つことが明確な場合（途中まで仕掛った状態で作業者に渡す「入力途中」や、クライアント担当者が別部門に確認を渡して待っている場合の「CL主管部門確認中」など）に限るのが望ましいです。

ステータス項目の用途を考える

使いやすいステータス項目は、「どの条件で絞り込んだリストを使うか」の運用に密接に関係しています。具体的には、「このステータスのページだけ確認すればOK」という用途をどれだけ想定するか。

・作業者が片っ端から片付けていいリスト（複数人で分担する場合、登録作業者という欄を併用）　⇒「未着手」や「登録待ち」
・校正作業者が見るリスト　⇒「校正待ち」など
・ディレクターが質問に答えないといけないリスト　⇒「質問あり」など
・クライアントが見るリスト
・ディレクターが修正指示を出さないといけないリスト

こういった取り回しは、数十枚以上の規模ではGoogle Spreadsheetでは不可能で、特定のステータス値をフィルタの条件とし、複数のビューを保存できるデータベースが必要になります。AirtableやNotion、サイボウズのkintone等でも実現できると思います。ビュー名にemojiを使って視覚的にわかりやすくするのが最近のマイブームです。

BADケース2：時間の流れに沿っていない並びは×

もう一つ遭遇した良くないケースは以下のような形です。画面設計・日英翻訳・CMS登録までを一貫して管理する用途ですが、作業工程が正しい順序に並んでおらず、ステータスを順々に上げていくことができません。

ちなみに、このようにステータス名の冒頭に数字を振って、工程を追うごとに数字が繰り上がっていく形にするのは、効果的なテクニックです。こうした工夫も、冒頭に紹介した三枝流の「一度先に行ったら原則として後戻りしない」項目設計のポイントです。

ただしweb制作の場合は、手戻り再作業や複数回の修正反映などがあるため、ある程度ループする（ある条件の場合にステータスを戻す）ことを織り込むことは必要です。

Doneで書くか、Readyで書くか

本質的には同じなのですが、例えば「登録作業を終えたので校正よろしく」の状態になっているページのステータスを表現するのに、2通りの方法があります。

(1) 登録者の視点で「登録済み」と書く (done)
(2) 校正者の視点で「校正待ち」と書く (ready to do)

完全に同じことを言っていますが、個人的には次工程の作業対象であることを明示するため、(2) の方式を気に入っています。

ということで使いやすいステータス項目の例２つを紹介します

🔸コンテンツ移行管理に筆者がよく使っているステータス項目

1_未着手
1a_入力途中　※部分的にサンプル入力して渡す場合など
1b_質問有り　※登録者の作業中の質問を受け付け
2_校正待ち　※登録者が作業を終えたら2にする
3_CL確認待ち　※校正者が作業を終えたら3にする
4_CL確認中　※主に他部署確認中の時に使う
5_LW要修正　※LWはloftworkの略、適宜自社名で運用してください
6_LW修正中　※テンプレート修正など別工程に戻す場合に使う
7_FIX

※「1b_質問有り」と「5_LW要修正」を黄色にし、この２つだけを抽出するビューを作成。1日1回以上このビューを確認して、全件クリアにする。Airtableは変更履歴が見られるので、1bで回答済みのものは1aか2に戻す。5は原則クライアント指摘によるので、修正完了したら再度 3_CL確認待ち に戻す。

※クライアント向けには、3〜7だけをフィルタしたビューを作り、「3を見て、7か5にしてください」という依頼をすればだいたい通じます。ステータスでグルーピングしておくと分かりやすいです。

※このフローだと、「校正完了」と「クライアント確認開始」の間にディレクターは全件チェックをしません。通常の移行ガイドラインでは、「クロスチェックまでしたので確認お願いします」という握りにしておくことが多いですが、実運用上はデータベースが一式3_CL確認待ちになったところで、自分でざっと全部目視チェックした上で、Backlogで「準備できましたのでこのビューで確認お願いします」とクライアントに通知することが多いです。

※クライアントがなかなか7_FIXにしてくれないことが多いので、つついて回ります。自主的にFIXにしてくださる担当の方に当たると涙が出そうになります。

================

🔹BAD CASE2の改善例（英語版サイトの画面設計管理）

0_未着手
1_WF作成中　※WF = ワイヤーフレーム。社内レビュー含む
2_WFレビュー　※クライアント提出してFixするまで
3_デザイン制作
4_デザインCLレビュー　※修正反映・Fixまで
5_コーディング
6_CMS登録
7_CLレビュー
8_ページ要修正
9_FIX

※「中央集権型」でディレクターが１枚１枚制作ステータスを精査したい場合の設計です。細かく見ていくと「デザイン制作着手指示待ち」「デザインチェックバック修正指示中」とか細分化しうるんですが、粒度を揃えて端折っています。ほぼ「戻らない」設計になっています。

このように単一ステータスで管理するほか、WFレビュー通過日・デザインレビュー通過日などを別の列にして日付を入力していく管理方法もあります。Spreadsheetの場合、この形も効果的です。

================

以上です。次回以降の記事では、大規模ページ管理に欠かせない「作業ID」の振り方についても書いていきたいと思います。