その「技術的負債」の定義は誰のため？：現場の改善を止める「すれ違い」をほどく

• URL: https://zenn.dev/minipoisson/articles/technical-debt-deception
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 「技術的負債」という言葉が情報システム部門と現場部門の間で異なる基準でカウントされており、それが組織内の不公平な対立を生んでいることを指摘する。現場がExcel/VBAで業務を改善すると情報システム部門はそれを「保守リスクという負債」としてカウントするが、現場にとっては業務システムの機能不足という「確定した負債を返した」行為であり、この基準の非対称性が対立を生む。代替案なしに「VBAは負債だから禁止」とするのは、不確実な将来リスクを回避するために他部門に確定したコストを強制することであり、負債の付け替えに過ぎないと論じる。解決策として「管理された自由」（EUCへのルールと支援のセット）と現場プロトタイプを動く仕様書として敬意を払うことを提案している。

詳細

技術的負債のカウント基準の非対称性

情報システム部門のカウント:

• 業務システムの機能不足（要望未充足）→ 「技術的負債としてカウントしない」（まだシステムがない）
• 機能不足で現場が毎日1〜2時間無駄にしてきた確定的損失 → 「カウントしない」（システムの話ではない）
• 現場がExcel/VBAで開発した機能の将来保守リスク → 「技術的負債としてカウントする」

この構造が「自部門の不都合だけをカウントする不公平な理屈建て」として現場に受け取られる。

負債の付け替えという問題

「統制外EUCの排除に成功した」裏で現場の赤字が膨らんでいれば、組織全体では質の悪い負債の付け替えが起きている。本来の技術的負債管理は「どの負債を抱えるのが組織にとって最も低コストか」という経営判断であるべき。

選択肢の比較:

• 選択肢A: VBAを許容し将来の保守リスクという負債を負う
• 選択肢B: VBAを禁止し毎日の業務遅延とモチベーション低下という負債を負う
• 選択肢C: 必要機能を業務システムに実装するリソースを調達コストとして負う

機会損失という見落とされた負債: 現場が毎日貴重な労働をドブに捨てている状態は「人的資本の浪費」という高い利子を伴う負債。モチベーション低下は複利で組織を蝕む。

3つの解決策

ステップ1「負債の総量で会話する」:

• 現場は「機能がないことで年間〇〇時間の工数が失われている」とコストで訴える
• 情報システム部門は「その機能を業務システムに実装するコストと優先順位」を透明化する

ステップ2「EUCに管理された自由という低利の融資をする」:

• 「放任」でも「全面禁止」でもなく、ルールと支援をセットにした枠組みを作る

ステップ3「現場のプロトタイプを動く仕様書として敬意を払う」:

• 現場のExcel/VBAは「最も優れた動く仕様書」であり業務フローへの適合も実証済み
• 将来的な正規実装へのインプットとして活用する