ベテランの一言でシステム仕様が変わる理由｜非公式な影響力を可視化する

要件会議では合意していたのに、ベテラン担当者が「この業務では使えない」と言った途端、仕様が大きく変わることがあります。役職上の決裁者ではなくても、周囲が反対できない状態です。

これは声が大きいという個人特性だけではありません。組織がその人の知識、顧客関係、問題解決力へ依存しているために生まれる影響力です。

権力は役職だけから生まれない

Emersonは、ある人が目標達成のために別の人へ依存し、代替手段が少ないほど、両者の関係に権力が生まれると整理しました。Power-Dependence Relations

業務では、次を一人だけが持つと影響力が強くなります。

• 重要顧客との関係
• 例外処理の知識
• トラブル時の復旧方法
• 経営者との信頼関係
• 過去データの所在
• 取引先や外注先への連絡経路

この人を外して仕様を決めると重要な例外を見落とします。一方、すべての意見を仕様へ入れると複雑化します。

専門性・意見・決定権を分ける

専門性

事実、過去事例、顧客条件、失敗時の影響を提供します。

意見

望ましい対応や優先順位を提案します。

決定権

全体の費用、他部署への影響、将来の保守を含めて選びます。

専門家であることと、全社仕様の最終決定者であることは同じではありません。

「使えない」を実案件へ分解する

• どの案件で使えないのか
• 直近一年で何件あったか
• 対応できないと何が起きるか
• 現在はどう処理しているか
• 全員向けの機能が必要か
• 例外時だけ手動対応できるか

抽象的な反対を、頻度と影響へ変えます。

仕様変更の判断表

項目	確認内容
対象者	誰に必要か
頻度	月・年に何件か
影響	対応しない場合の損失
複雑化	全利用者の操作が増えるか
代替	例外フローで対応できるか
保守	誰が今後変更するか
決裁	最終的に誰が判断するか

ベテランの意見を排除せず、同じ基準で扱います。

異論を安全に出せる順序にする

会議で最初にベテランが発言すると、他の参加者が同調しやすくなります。

1. 各自が事前に懸念を記入する
2. 実案件と頻度を確認する
3. 利用者別の影響を並べる
4. ベテランを含む専門家が意見を出す
5. 決裁者が理由を記録して判断する

誰の意見かより、何を根拠にしたかを残します。

依存を減らしても価値を奪わない

ベテランの役割を、全件処理や最終発言から次へ移します。

• 例外条件の定義
• 品質基準の管理
• 新しい例外の評価
• 後任の育成
• 仕様変更時の専門レビュー

知識が共有された後も専門性が評価される状態を作ります。

まとめ

ベテランの一言で仕様が変わるのは、その人へ組織が依存しているからです。影響力を無視すると業務知識を失い、無条件に従うと全体が複雑になります。

専門性、意見、決定権を分け、「使えない」を実案件、頻度、影響へ変えて判断します。

専門性を残した役割移行は属人化をなくそうとすると反発される理由、決裁方法は会議を重ねてもシステム仕様が決まらない理由で解説しています。