ルールには賞味期限があるのかもしれない

＼オカウチワニが1人でやっている okauchiwani-hitori Advent Calendar 2025 8日目の記事です!!!／

組織で働いていると、「なんでこのルール守られていないんだろう？」と疑問に思う瞬間があります。

• ルールは存在しているが、誰もチェックしていない
• ルールを破っても問題が起こっていないように見える
• 新しい例外が増えて、ルールの前提が崩れている

最近とくに感じるのは、ルールには賞味期限があるなということです。
今日はそんな「ルールと現場のリアル」について考えてみます。

ルールは何のために必要なんだろう？

ルールの本質は「迷わず進むための道しるべ」です。
認知コストを減らし、本来の仕事に集中できるようにするための仕組みと言えます。

もしルールがなければ、人は毎回すべてをゼロから判断することになります。

• このタスクは誰に聞くべき？
• どこまで確認すべき？
• どう進めるのが正解？

その負荷を減らすための“補助線”としてルールは存在しています。
つまり、ルールは「縛るため」というより「迷わないため」に必要なんですね。

本当に大事なのはルールの背景の共通理解

ただし、ルールそのものより重要なのは、「なぜそのルールがあるのか」という共通理解です。

背景を知らないままルールだけ渡されると、

• 「なんでこれ守らないといけないの？」
• 「この手順って意味あるの？」
• 「正直、守っても何も変わらなくない？」

といった疑問やストレスが生まれます。

逆に、背景がわかっていれば、多少手間が増えても納得して運用できます。
たとえば「レビュー前にローカル環境でテストを実行し、結果を記載する」というルールも、

• レビュー時間の無駄を減らすため
• デグレを早期にキャッチするため

と背景が共有されていれば、自然と守られるようになります。

多くの場合、ルールが守られない理由は「怠惰」ではなく、
背景が伝わっていないことによる合意形成の不足です。

ルールに反していても、目的が達成できているか？

そして現場で本当に大切なのは"ルールを守ったか"ではなく"目的を達成できたか"です。

ルールはあくまで手段であって、目的ではありません。
だから例外があっても構わないし、状況に応じて柔軟に扱うべきです。

たとえば、

• リリースを優先するために、口頭のレビューで済ませ、エビデンスは後追いにした
• 不具合が多すぎる期間だけ、起票テンプレートを簡略化した

これらが良いかどうかは、目的を妥当に達成できているかで判断されるべきです。

ルールを破ったから悪いわけではありません。
むしろ目的に対して最適なら、ルールの側を見直すべきです。

プロダクトも組織も常に変化します。
役目を終えたルールが出てくるのも自然なことです。

明文化された古いルールが残っていると？

古い守らなくて良いルールが残り続けると、現場には次のような問題が起きます。

• 新しく入った人が、古いルールを"正しいルール"だと思い込む
• すでに不要なルールを真面目に守る人だけが損をする
• 古いルールを守る人が、守らない人を責めてしまう

つまり、ルールそのものより、ルールが情報として古びていることが摩擦を生むのです。

特に怖いのは、「実態に合わなくなったルールが、最新の判断を妨げてしまう」こと。
だからこそルールは、

• 前提や背景が更新されていないか、今も合っているかを見直す
• フィットしなくなったものは調整したり、破棄をする

といった"メンテナンス"が必要です。ソフトウェアと同じですね。

まとめ

ルールは守るためのものではなく、目的を達成しやすくするための補助線です。

• ルールの本質は認知コストを下げ、判断を助けること
• 大事なのは背景の共通理解と、現場との合意形成
• ルール遵守よりも「目的が達成されているか」を考える
• 古いルールは誤解を生むため、定期的な棚卸しをする

開発もQAも、プロセスも日々進化していきます。
守られないルールを責めるより、今のフェーズに合ったルールを一緒に作り直したいですね。