「透明性を上げよう」が施策を溺れさせる理由

ある製造業の情報システム部門で、ベンダーが重大な脆弱性を公表した。

担当者が対応に動くと、別の部署がすでに同じモジュールを別のものに置き換えていたことが判明した。情報が部署間で共有されていなかったせいで、客先を巻き込んだ騒ぎになった。この経緯は、はてなブログを書くしんざき氏が公開している(出典)。

騒ぎが収まったあと、原因分析が行われた。脆弱性が見過ごされた要因は「システム統括部署の不明確さ」「情報連携の不備」「バージョン管理台帳の更新不足」「営業の独断」の四つに切り分けられていたという。それぞれに対策を打てば済む話だったはずだ。

ところが、実際に業務目標として掲げられたのは、この四つの個別課題ではなかった。一段抽象化された「組織の透明性を高める」というテーマが目標に据えられた。

抽象化された目標に何が起きたか

目標が立った直後から、次々と施策が動き出した。

• 各部署の活動報告会を現場レベルでも増やす
• メンバーのスキルや担当業務を可視化するナレッジ共有チャット
• 会議議事録の詳細化と部署間共有
• 各種KPIダッシュボードの社内公開
• 部署を跨いだシャッフルランチ

一つひとつは、悪い施策ではない。問題は数ではなく、止め方が用意されていなかったことだ。しんざき氏は、これらを後から整理するのに要した期間をこう書いている。

これ、簡単に言ってますが、半年以上かかってます。すげー大変だった。

(出典)

Parryは「Why（なぜこの変更か）」と「Risk（影響範囲）」をPR作成時の必須項目にしている。しんざき氏の記事は、Parryが2026年7月に生まれるより前から、この二つの軸が欠けた組織で何が起きるかを記録していたことになる。先に問題を体験していた人の報告として読める。

意志の弱さの問題だと思っていた

最初にこの記事を読んだとき、施策が乱立した理由は「誰も『これはやめよう』と言い出せなかったから」だと考えた。声の大きい提案者に押し切られる、という組織にありがちな失敗の一種だと思ったわけだ。

しかし、しんざき氏自身の分析はそこにとどまっていない。氏は「透明性」を業務目標に据えたこと自体を問題視している。

そもそも、「透明性」は手段であって目的ではありません。 効果測定もしにくいし、一見良いことのように思えるため反対もしにくいからです。

(出典)

ここで気づく。「意志が弱いから止められない」のではない。「透明性を高める」という目標そのものに、いつ達成したと言えるか、いつ止めるべきかという条件が最初から含まれていない。条件がない目標に対しては、意志の強弱にかかわらず、個別の施策を止める根拠を持てない。一見良いことに見える施策には反対しづらい、という氏の指摘は、この構造の帰結として読める。

目的だけでは着手できなかった話

Parryの開発でも、近い場面があった。

このブログ（blog-prod-posts）の記事をPRとして送る際、Parryにはdraftとdirectという二つの送信モードがある。2026年8月の頭、「レビュー体験を検証したい」という目的だけでPRを送ろうとしたことがあった。だが、この目的だけではどちらのモードを選ぶべきか決まらない。どちらを選んでも「PRを送った」という事実は作れてしまうからだ。

実際には、directモードで作成したPRはレビュアーへの通知が飛ばない、という挙動が確認されている。通知されなければ、レビュアーが承認タブを自分で開いて気づくまで、そのPRは存在しないのと同じになる。そこで着手前に確認したのは、「どちらのモードなら、実際にレビュアーの承認タブにPRが現れるか」という一点だった。これが、続けるか止めるかを判断する条件になった。

この条件を確認せずに「検証したい」という目的だけで走り出していたら、どちらのモードを選んでも一応の実行結果は得られただろう。ただし、後から「なぜそのモードを選んだのか」と聞かれたとき、答えに詰まっていたはずだ。目的が抽象的なままだと、着手はできても、選択の理由が誰にも説明できなくなる。しんざき氏の記事にあった施策乱立と、規模は違えど同じ形をしている。

ここまでで検証できていないこと

抽象的な目標に、達成条件と停止条件をあらかじめ組み込んでおけば、施策の乱立は防げるのか。それとも、条件を埋め込んだところで、条件自体が形骸化する別の壊れ方をするのか。これはまだ確かめていない。

PRテンプレートのWhy欄が時間とともに空語化していく事例は既に報告されており、Parryが強制する条件がそれと同じ道をたどらない保証はない。「組織の透明性を高めよう」という目標を掲げて似た乱立を経験したことがあれば、それがどの段階で歯止めを失ったのかは、比較材料として知りたいところだ。