何のために承認するのか
公開前の承認は、手続きのためにあるのではありません。公開してから困るものを、公開する前に止めるためにあります。
- 誤り：数字、日付、固有名詞、リンク先の間違い
- ルールに触れる表現：業界の規制や社内規程に照らして、書いてはいけないこと
- 約束：価格、条件、提供時期など、書いたら守らなければならないこと
- 見え方：ブランドや会社としての言い方にそろっているか
何を止めたいのかがはっきりしていれば、誰が見るべきか、どこまで見るべきかも決まります。逆に、目的がぼやけたまま「念のため上長に」を重ねると、承認は増えるのに、止めるべきものは止まらなくなります。
散らばると、何が起きるか
承認の依頼が、メールで送られ、チャットで催促され、最後は廊下で「あれ、いいよ」と口頭で済む。よくある流れです。
誰の確認待ちか分からない
依頼を出した人は、返事が来るまで待っています。依頼された人は、依頼が来ていることに気づいていないかもしれません。途中に誰がいて、いまどこで止まっているのかは、依頼を出した本人に聞かないと分かりません。
何に対してOKが出たのか分からない
メールに添付した原稿にOKが出たあと、ページを少し直した。そのOKは、直したあとの内容にも有効なのか。口頭のOKなら、何を見てOKと言ったのかも残りません。
後から説明できない
公開した内容に問題が見つかり、「これは誰が確認したのか」と聞かれる。受信箱を掘り返し、チャットをさかのぼり、それでも見つからない口頭の分は、記憶に頼ることになります。担当者が異動や退職をしていれば、記憶もありません。
差し戻しの理由が残らない
「ここは直して」と返された理由が、メールの一文や口頭のひと言にしか残っていないと、次に同じ種類のページを作る人は、同じところでまた差し戻されます。
承認の記録に残すこと
承認の経緯として残しておきたいのは、次のことです。
- 誰が、いつ、確認を依頼したか
- 依頼のときに、何を見てほしいと伝えたか
- 誰が、いつ、承認したか
- 差し戻したなら、誰が、いつ、どんな理由で差し戻したか
- 最終的に、どの状態の内容が公開されたか
大事なのは、これが後から集めるものではなく、承認の操作をしたときに自然に残ることです。記録を別に書く手間があると、忙しいときほど書かれなくなります。
承認の重さを分ける
すべてのページに同じ重さの承認をかけると、軽い更新まで待たされ、重い更新は他の依頼に埋もれます。
| 更新の種類 | 承認の例 |
|---|---|
| 誤字の修正、日付の差し替え | 担当者の確認だけ、または1人の承認 |
| 通常のお知らせ、既存ページの改訂 | 上長の承認 |
| 価格・条件の変更、規制に関わる表現、新製品の発表 | 上長の承認のあと、関係部署の承認 |
分け方には、ほかに二つの軸があります。
段階を分ける
上長の承認が済んでから法務が見る、というように、順番を決めて進めます。前の段階で直すべきものを直してから次へ渡せるので、後ろの段階の人の手間が減ります。
全員か、誰か1人か
複数の人に承認を求めるとき、全員のOKが要るのか、誰か1人のOKで進めてよいのか。担当者が3人いて誰が見てもよいなら、1人で足ります。部署ごとに観点が違うなら、全員が要ります。
人ではなく、役割で組む
承認者を「田中さん」と名前で決めておくと、田中さんが異動したとき、休んだとき、承認が止まります。
承認者は、名前ではなく役割で決めておきます。「依頼者の所属長」「広報部」「法務の担当者のうち誰か1人」。こうしておけば、人が替わっても、承認の組み方は直さずに済みます。
あわせて、承認者がいないときの代わりも決めておきます。所属長が出張中なら、誰が代わりに承認するのか。決めていないと、急ぎの更新のたびに、その場で誰かを探すことになります。
承認が形だけにならないために
承認の仕組みが整うと、今度は「とりあえず承認ボタンを押す」ことが起きます。
- 依頼のときに、見てほしい観点を書く。「価格の数字と、提供開始日を確認してください」
- 承認者ごとに、見る観点を決めておく。上長は内容、法務は表現、というように
- 承認者が多すぎないか見直す。5人が見ると、誰もが「ほかの誰かが見ているだろう」と思い始める
- 差し戻しを、悪いことにしない。差し戻しを避けること自体が目的になると、承認が形だけになりやすくなります
writeWiredでは
writeWiredでは、承認の経緯はコンテンツの状態の記録として残ります。
ステータス変更履歴
- コンテンツの状態（制作中・確認依頼・確認中・掲載可）が、いつ・誰の操作で変わったかを、時系列で記録する
- 履歴は、操作にともなって自動で残る
- 確認依頼のときに添えたメッセージも、一緒に残る
- 差し戻しの記録と、そのときのコメントも残る
- 確認依頼を出すと、承認者に通知メールが届く
コンテンツの検索と一覧には、各コンテンツの状態が並びます。いま誰の手元にあるか、確認待ち・承認待ちの状況を、一覧で見渡せます。
承認フローと承認ルート
- 承認フローは組織ごとに定義し、どのコンテンツに適用するかはテンプレートの設定で決める
- 1つの承認フローに承認ルートを複数並べ、上から順に承認を進める
- 承認ルートごとに、承認タイプを「全て承認」か「いずれか承認」から選ぶ
- 承認者（ノード）は、部署の所属長・部署・ロール・部署とロールの組み合わせ・ユーザーのいずれかで指定する
- ノードごとに、代理ノードを付けられる
- ロールは承認ルートで使うための定義で、権限への影響はない
承認の記録に残したいことのうち、誰がいつ依頼し、誰がいつ承認し、差し戻したならどんなコメントだったかは、ステータス変更履歴が自動で持ちます。記録を別に書く手間はかかりません。
承認フローは、テンプレートの設定で適用します。お知らせ、製品ページ、というようにテンプレートが分かれていれば、ページの種類ごとに承認の重さを変えられます。誤字の修正か価格の変更か、という更新の中身による重さの違いは、承認者に伝える観点として運用で補います。段階は承認ルートの並びで、「全員か、誰か1人か」は承認タイプで決めます。承認者を所属長・部署・ロールで指定しておけば、担当者が替わっても承認フローを直さずに済み、不在のときの代わりは代理ノードで決めておけます。
何を承認の対象にするか、承認者がどの観点で見るかは、この仕組みの外側で決める運用です。
この記事の根拠となる機能