はじめに

レビューを通したはずの課題ほど、あとで油断して触られがちです。正直、これに何度か泣かされてきました。

たとえば、優先度も担当者も期日もそろってレビューを通した課題。ところが実装が終わってふり返ってみると、優先度が「中」から「高」に変わっていたり、担当者が別の人に差し替わっていたりする。誰かが作業のなかで、悪気なくちょっと直しただけなんです。でも、レビューで合意した内容と、実際に動いているものが、静かにズレていく。

これがいちばん効いてくるのが、あとから経緯を追うときです。「この優先度、レビューのときこうだったっけ」「担当、いつ変わったんだろう」。監査やふり返りの場でそれを聞かれても、口頭で決めた変更だと、誰がいつ何を根拠に変えたのかが残っていません。結局、記憶と推測で埋めることになるんですよね。

この「レビュー後の静かな書き換え」を、人の注意力ではなく仕組みで止められないか。社内でいま試している最中の取り組みを、途中経過として共有します。使うのは、ONES.comの次の2つです。

ONES Project：課題やバグを登録して、対応状況やワークフローを管理するプロジェクト管理のツールです。
ONEScript：ONESに組み込まれたスクリプトのレイヤーです。UIで設定するノーコードの自動化ルールでは書ききれない、複雑な条件のチェックや処理を、コードで動かせます。現在は早期プレビュー段階で、今回もその環境で検証しています。

💡「レビュー中は重要項目に触らせない」を自動で効かせる

やりたいことは、ひとことで言えばこうです。課題が「レビュー中」のあいだは、優先度・担当者・タイトル・予定日といった重要項目の変更を、ルールに沿っていなければ受け付けないようにする。

これをONEScriptで書きます。仕組みとしては、課題の変更が確定する手前で条件を検証して、ルール違反の変更ならその場でブロックし、なぜ止めたのかを実行ログに残す、という流れです。ブロックされた人には理由つきのメッセージが返るので、こっそり通り抜けることはできません。

実際にやってみると、こんな感じになります。「レビュー中」の課題で、優先度を「高」から「中」にこっそり下げようとしてみます。

レビュー中の課題で、優先度を「高」から「中」に変えようとしているところ。

保存しようとした瞬間に、こう止められます。

「レビュー中は、タイトル、説明、担当者、優先度、予定開始日、予定終了日、Wikiリンクを変更できません。変更が必要な場合は、レビューを差し戻してから更新してください」と出て、変更がはじかれる。

そして、この止まった操作は、ONEScript側にもちゃんと記録が残ります。「いつ、どのスクリプトが、何を弾いたのか」が後から追えるんです。

ONEScriptの実行ログ。ブロックした実行が「rejected」として、理由（セマンティックログ）つきで残っている。

大事なのは、変更を全部禁止するわけではないところです。どうしても直したいなら、いったん課題を「設計中」など前の状態に戻して、あらためてレビューに出し直す。つまり「変えるな」ではなく「変えるならもう一度レビューを通せ」というルールを、システム側で自動的に守らせているわけです。

ノーコードの自動化ルールだと「この条件のときこう動く」までは書けても、「この状態のときこの変更だけを弾く」という細かい線引きはなかなか表現しきれません。そこをコードで書けるのがONEScriptなんですよね。

📋 まず決めるのは「どの状態で、何を守るか」

この仕組みを自分のチームで組むなら、スクリプトを書く前に、守る対象を先に決めておくとうまくいきます。やることはシンプルで、「どの状態のとき、どの項目を止めるか」を、こんな小さな表に書き出すだけです。

守る状態（ステータス）	変更を止めたい項目	例外的に許す変更
レビュー中	優先度、担当者、タイトル、予定開始日・予定終了日	誤字修正など軽微なもの
承認済み	（必要なら同様に追加）	－

こんなふうに、守りたいものと見逃していいものを最初に線引きしておきます。ここを決めずにいきなり全部を禁止すると、ちょっとした修正まで弾かれて現場が回らなくなるんです。

この表がそのままスクリプトの条件になります。守る状態と項目が言葉で整理できていれば、あとは「この状態で・この項目が変わったら・止める」と書き下すだけ。運用しながら「ここは守りすぎ」「ここは抜けてた」と気づいたら、表を直してスクリプトに反映していけば、チームのルールとして育っていきます。

⏱ 何が変わったか

試してみて手応えが大きいのは、ふり返りのときの安心感です。以前は「レビューの合意と今の中身、本当に一致してる?」を目視で突き合わせていて、これが地味に神経を使う作業でした。ルールを効かせると、重要項目はそれを通さないと変わらないので、そもそもズレが生まれにくくなります。

しかも、正規の手順で変えた分は課題の履歴に「ONEScriptが優先度を更新しました」のように残りますし、ブロックした分は実行ログに残ります。「誰がいつ何を変えたか」を後から推測で埋めなくてよくなるのは、監査やふり返りの場面でかなり効きそうだと感じています。

⚠️ 守りすぎない設計にしておく

ひとつ、正直に書いておきたい注意点があります。この手のルールは、効かせすぎると現場のストレスになります。

なんでもかんでもブロックすると、「タイトルの誤字も直せない」と不満が出て、結局ルールごと無効化される、みたいなことが起きがちなんです。だから守る項目は、本当にレビューの前提を崩すものだけに絞るのがコツです。あとから緩めるより、狭く始めて必要な分だけ広げるほうが、うまく回ります。

もう一点、ONEScriptで書いたスクリプトは、いきなり本番に効かせず、まずドライランで「実際には何も変えずに、どう動くか」を確認できます。公開もレビューと承認の手順を通してから有効になるので、そこを飛ばさずに段階を踏むと安全です。

なお、ONEScript自体はまだ早期プレビューの段階で、正式販売の前です。機能としてはこの記事のとおり動きますが、今のところは希望されたお客様に個別にご提供している状況です。そのため、通常のサインアップですぐ触れるわけではない点だけ、先にお伝えしておきます。

おわりに

レビューを通したという事実は、そのあと中身が守られて初めて意味を持ちます。人の注意力だけに頼っていると、悪意がなくても静かにズレていくんですよね。

そのズレを「気をつける」ではなく「仕組みで止める」に置き換えてみると、ふり返りや監査で慌てる場面がぐっと減りそうな手応えがあります。まずは自分のチームで「どの状態で・何を守るか」を1行書き出してみるところからでも、景色は変わると思います。

ONEScriptはまだ早期プレビューですが、機能自体はこの記事のとおり動いています。レビュー後の書き換えにヒヤッとした経験がある方は、ONES.comからプレビューに申し込めます。ONESの導入を検討中でこの仕組みを試したい場合は、お問い合わせいただければ個別にご案内しています。