第1回から第3回まで、私たちは次のような現象を見てきました。
•「業務は変えていない。システムを入れただけ」という自己欺瞞
•「現場の抵抗が強い」という便利な責任転嫁
•「次はAIを入れれば解決する」という技術万能論
これらはすべて、別々の問題に見えますが、根は同じです。
「設計すべきものを、設計していない。」
▶見えていなかった設計対象―影響システム
ここで、ようやく言葉にしましょう。
情報システムが導入されるとき、必ず同時に変わるものがあります。
•誰が、いつ、何を判断するのか
•誰の権限が強まり、誰の裁量が失われるのか
•失敗したとき、誰が説明責任を負うのか
この「人と組織の振る舞いの仕組み」を、ここでは影響システムと呼びます。
これまで多くの改革が失敗してきた理由は単純です。
「情報システムは設計したが、影響システムは放置した。」からです。
▶「そうか、影響システムが大事なのか」という次の罠
ここまで読んだ読者の中には、こう思った人もいられるでしょう。
「なるほど。では次は、影響システムもちゃんと考えなければならないのだな」
ここまでは、正しい。
しかし、その直後にこう続くとしたらどうでしょう。
「では、ITベンダーさんにお願いしよう」
残念ながら、ここで改革は再び道を誤ってしまいます。
▶影響システムは「設計できる」が「外注できない」
影響システムとは何でしょう。
それは、権限と責任の再配分です。
•誰が決めるのか
•誰が責任を負うのか
•誰が評価されるのか
これは、経営やマネジメントの核心であり、外部に丸投げできる性質のものではありません。
もちろん、外部の専門家が、論点を整理し、可視化し、設計を支援することはできます。
しかし、決めること自体を代行することはできません。
それを引き受けてしまうITベンダーがいるとすれば、それは善意ではなく、無理解でしょう。
▶安請け合いと「それっぽい改革」
現実には、こうした会話が交わされています。
「業務改革も含めて支援できます」
「組織面も考慮した設計を行います」
でも、その中身をよく見ると、ヒアリング結果を画面設計やワークフローに落とし込む。
それだけで終わっているケースが多いのです。
影響システムは、UIや操作手順ではありません。
にもかかわらず、それをシステムの設定項目に矮小化してしまいます。
これでは、影響システムを理解しているとは言えません。
▶最低最悪・極悪非道―本当にやってはいけないこと
そして、最も罪深いのがこのパターンです。
•先に情報システムの構造を決め
•その制約に合わせて
•権限・承認・役割を再定義する
一見すると、合理的に見えるかもしれませんが、これは本末転倒です。
情報システムに、影響システムを合わせる。
これは改革ではなく、システム都合による組織の歪曲です。
このとき、組織では何が起きるでしょう。
•判断権限が形骸化する
•責任の所在が不自然にねじれる
•調整役が切り捨てられる
•現場は「従うだけ」の存在になる
これを、改革と呼んではいけません。
▶なぜ、こんなことが起きるのか
理由は明確です。
影響システムを理解できない場合ほど、情報システムで影響システムを作ろうとするからです。
なぜなら、情報システムは
•目に見える
•図に描ける
•外注できる
一方、影響システムは、
•抽象的
•不都合な真実を含む
•内部の覚悟を要求される
だから、避けられるのです。
▶本当の設計順序
最後に、改めて確認しておきましょう。
改革における設計順序は、以下の通りです。
1.影響システム（誰が決め、誰が責任を負うのか）
2.業務プロセス（その判断をどう流すのか）
3.情報システム（それをどう支えるのか）
この順序を逆にした瞬間、改革は必ず歪んでしまいます。
▶結びに代えて
情報システムは、組織を良くも悪くもできます。
しかし、それはあくまで影響システムをどう設計するか次第です。
システムを作ったつもりで、組織を設計してしまっていないか。
そして、その設計を、本来自分たちが引き受けるべき責任から逃げるために、他者に押し付けていないか。
この問いから目を逸らす限り、どれだけ新しい技術を導入しても、改革はうまくいかないでしょう。
合同会社タッチコア 小西一有
期末の今、話して、課題を整理してみませんか？
▶情報システムと影響システムー正しいITが壊すもの（全4回）◀
第1回：ある一言が改革を失敗させる(1/19）
第2回：「現場の抵抗が強くて…」は本当か？(1/26)
第3回：「次はAIを入れれば解決する」―技術が問題を増幅させる(2/2）
第4回：第4回：情報システムに影響システムを合わせる極悪非道（2/9）
