はじめに
承認フローは作った直後がいちばんきちんと回ります。
問題はそのあとです。半年ほど運用していると、だいたいこうなっていきます。
- 承認は取ったのに、そのあと誰かがフィールドを直している
- リリース前に「これ、承認したときと同じ内容ですよね?」の確認が毎回発生する
- 承認済みかどうかを確かめるために、チャットの履歴をさかのぼっている
- 仕様書のほうは、承認された版がどれだったのか誰も分からない
承認する行為そのものは、みんなちゃんとやっているんです。崩れるのは、承認が終わったあとなんですよね。承認が「通せば終わりの手続き」になっていて、通したあとの状態を誰も守っていない。
「承認後は触らないでください」と言って回るのをやめました
そこで、承認の位置づけを変えました。通せば終わる手続きではなく、通した先は勝手に触れなくなる仕組みにするという発想です。承認が下りた項目はその場で凍結され、あとから変えたくなったら、もう一度変更承認を通してもらいます。
増えたのは設定だけで、運用ルールは1つも足していません。むしろ、これまで人の記憶と善意に任せていた部分を設定側に移した、という感覚に近いです。
登場するONES.comの製品は2つだけです。
- ONES Project：課題を登録して、担当者・ステータス・ワークフローを管理するプロジェクト管理のツールです。
- ONES Wiki：仕様書や規程などのドキュメントを書いて貯めておける、ナレッジベース管理のツールです。
🔒 承認が下りたフィールドは、そのまま凍る
ONES Projectには課題承認という仕組みがあります。ポイントは、承認そのものより承認後にフィールドが凍結されるところです。
使うには、まずプロジェクト設定のプロジェクトコンポーネントから「承認」コンポーネントをナビゲーションに追加します。承認だけを単独でオンにする切り替えはなくて、このコンポーネントを入れると使えるようになる、という作りです。
そのあと、プロジェクト設定の課題承認でルールを作ります。決めるのは主に3つです。
- どのステータス遷移で承認を起こすか（例：「レビュー待ち」から「レビュー完了」へ移るとき）
- 何を凍結するか（フィールドを個別に指定するか、課題全体をまとめて対象にするか）
-
誰が承認するか
承認が始まると、課題は承認中の表示になり、ステータスはその場で止まります。承認が下りて初めて、システムが目標のステータスへ移してくれます。承認を待たずに先へ進んでしまう、ということが起きません。
✏️ 変えたくなったときは、変更承認を通す
凍結したら二度と直せない、では運用になりません。凍結されたフィールドをクリックすると、いま凍結されている旨の案内が出て、そこから変更承認を始められます。複数まとめて変えたいときは、課題のクイック操作から一括で申請することもできます。
ここが個人的にいちばん良いと思っている点なんですが、入力した変更値はその場では課題に書き込まれません。 承認申請と一緒に流れていって、承認が完了してから反映されます。
承認申請の画面には「変更を表示」があって、変更前と変更後の値を並べて確認できます。承認する側が、何がどう変わるのかを見てから判断できるわけです。結果として「誰が、いつ、どのフィールドを、なぜ変えたか」が、課題に紐づいた記録として残ります。
📄 仕様書のほうも、同じ考え方で揃える
課題だけ締めても、仕様書が野放しだと意味がありません。ONES Wikiにもページ承認があります。
スペース設定のページ承認ルールから有効にします。考え方は課題側とほぼ同じですが、ドキュメントならではの設定が1つあります。承認が完了するまでの表示範囲を選べるところです。編集者・承認者・CC対象者だけに見せるか、スペースの参照権限を持つメンバー全員に見せるかを選びます。
規程や基準のように、確定していない案が独り歩きすると困るものは前者にします。先に共有して議論したい設計メモなら後者です。ここを分けられるので、「まだ承認前なのに参照されてしまった」が起きにくくなります。
ページを公開したあとは、上部の「承認を開始」から申請します。承認中はページを編集できなくなり、移動・アーカイブ・削除・名前変更も止まります。承認済みのページを直して出し直せば、上書きされずに変更承認へ入ります。課題側とまったく同じ発想です。
そして思った以上に効いたのが、課題の承認もページの承認も同じ承認センターに集まることです。承認する側からすると、処理待ちを見る場所が1つで済みます。ドキュメントの承認だけ別のツールに置いていたころは、そこを見に行くのを忘れて止まる、というのがよく起きていました。
📋 ルールを作る前に決めておいた4つ
そのまま真似できるように、社内で承認ルールを組むときに先に決めている項目を出しておきます。ONESに限らず、承認フローを設計するときの観点としてそのまま使えると思います。
| 決めること | 実際にどうしているか |
|---|---|
| どの遷移で止めるか | まず1箇所だけにする。全部の遷移に承認を置くと、ただの渋滞になります |
| 何を凍結するか | 最初はタイトル・説明・優先度など数個から。いきなり課題全体を選ばない |
| 誰が承認するか | 個人名で固定せず、課題のメンバーフィールドやプロジェクトロールから動的に決める |
| 承認者が見つからなかったら | 自動承認・指定ユーザーへ転送・プロジェクト管理者へ転送のどれかを必ず選んでおく |
4つ目は目立たない項目ですが、いちばん事故になりやすいところです。承認者を担当者フィールドから引く設定にしていると、担当者が空の課題が来た瞬間にフローが止まります。ここを決めていないと、止まったことに誰も気づけません。
⏱ 「これ承認済みでしたっけ」がなくなった
数字で厳密に測ったわけではないので、あくまで体感です。
| 導入前 | 導入後 | |
|---|---|---|
| リリース前の突き合わせ確認 | 1回あたり30分ほど、承認時の内容と現状を目視で比較 | 承認履歴の差分を開くだけで数分 |
| 「これ承認済みですか」の確認 | 週に4〜5回、チャットで往復 | 課題とページの表示で分かるので、ほぼ発生しない |
| 承認後の書き換え | 起きても気づけない | そもそも凍結されていて起きない |
3行目が本題です。以前は、承認後に書き換わっていたことに気づけたのが、たいていリリース直前でした。今は書き換えようとした時点で変更承認に入るので、気づくもなにも、承認する側の目を必ず通ります。
⚠️ 何でも凍らせられるわけではない
運用してみて分かった制約も書いておきます。
- 凍結できないフィールドがあります。 計算式や滞在時間などの計算フィールド、記録時間・予定時間といった工数フィールド、ID・作成者・作成日時のようにそもそも変更できないフィールド、スクリプトフィールドは対象外です。これらを承認の担保にはできません
- 同じ課題で同時に進められる承認は1件だけです。 内容承認と変更承認を並行させることはできません
- 承認中の課題は、課題タイプの一括変更や他プロジェクトへの一括移動ができません。 移行作業を予定しているなら、承認を先に片付けておく必要があります
そして一番大事なのは、承認を置く場所を欲張らないことでした。あれもこれも対象にした結果、処理待ちが溜まって形骸化しかけたことがあります。本当に止めたい節目を1つか2つ。それくらいがちょうどよかったです。
おわりに
承認フローがうまく回らないとき、原因を「承認する人が忙しいから」に求めがちです。でも実際に詰まっていたのは、承認したあとの状態を誰も守っていなかったことのほうでした。守るのを人の善意に任せている限り、いつか必ずズレます。
手元のプロジェクトで、直近に承認を取った課題を1件開いてみてください。承認したときの内容と今の内容、本当に同じでしょうか。もし自信を持って言えないなら、承認そのものではなく、そのあとの設計を見直すタイミングかもしれません。
承認ルールの作りを実際に触って確かめたい方は、ONES.com から試せます。自社の承認フローをそのまま再現できるか見てほしい場合は、support@ones.com までご連絡ください。