No.12: 責任所在が曖昧な階層組織の弊害(2)

　前回、官僚的組織の象徴である階層型組織が機能しない事例をお話ししました。今回は、もう一つ私の印象に残っている事例をお話しします。

　私が企業に勤めていたときの、顧客先での製品事故対応の事例です。本来ならもっと短期間で収束できたはずなのに、無駄に長い時間を要し、結果顧客にも長期間ご迷惑をお掛けしてしまったのです。詳しくは申し上げられませんので、一般化して要約します。

　それは、だいぶ前にある顧客の拠点に納入した、データ登録システムです。データは、最終顧客であるユーザがそれぞれブラウザ上で入力し、データ登録システムは夜間のバッチ処理でそれらのデータをチェックし、あるフィルタリングを掛けて抽出したものだけを加工して顧客本社にあるサーバに登録します。本社のサーバは別のベンダが納入したもので、データ登録システムとの間のインターフェイスは明確に決められており、それに従って転送すれば良いものでした。なお、顧客は1〜2年後には本システムを本社システムに統合する計画であり、あと1〜2年で使用を終えることになっていました。

　ある日、顧客から本社サーバへのデータ登録がされていないとの連絡を受けました。システムの担当者が顧客先を訪問して調べると、データ登録システム内に転送できなかったデータが滞留していることが分かりました。

　なぜ、そんなことが起きていたのか？原因を究明すると、実は数ヶ月前に実施した作業で担当者がミスを犯していたことによりデータ送信量が通常時の数倍に達していたということが判明しました。そのために、本社サーバへのデータ登録が夜間のバッチ処理時間枠内に終わっていなかったのです。データ登録システムは当日内にすべてのデータ登録が完了しないと、翌日に全てのデータを最初から登録しようとする(これは当初から設計が良くない部分です)ので、毎日データ登録できないまま数ヶ月経過していたというわけです。

　ミスに至った要因、それをチェックで摘出できなかった要因、そしてそれらを分析したうえでの再発防止策は当然まとめることになりましたが、それはここでフォーカスする部分ではありません。ここで取り上げる問題は、ではデータ登録システムをどの様に処置・改修・対策して顧客に運営していただいたかということです。

　まず、処置として数ヶ月前に作業ミスした部分を正しい内容に戻したうえで、数ヶ月間滞留した本来本社サーバへ登録すべきデータを手作業で登録しました。これで顧客はこれまで通りの運用を再開できることになりました。

　次に、数ヶ月間データが登録できていなかったことに誰も気が付かなかったという問題があります。これはデータ登録システムが異常を検知したときに、直ちに顧客ユーザが気付くようなユーザインターフェイス(UI; ここでは画面と理解いただければ結構です)になっていなかったことによるものです。検知した異常は、画面を何度か操作した先でしか分からず、日々意識して能動的に確認しないと気付けなかったのです。対策として、異常を検出した場合は顧客ユーザの誰もが１日の最初に使用する画面上にそれを表示することとしました。

　事故対策に当たったチームがデータ登録システムそのものに対して適用しようとした改修は以上までです。これとは別に社内向けの原因の深掘り、再発防止策の取りまとめ業務はたくさん残っていますが。。

　これが企業内の品質保証部門等関係部門を含めた対策レビューの場に上がるとどうなったか？前回の事例と同様、企業内の役員以下の階層を―J職―H職－B職―G職―K職というように仮置きします。これは関係部門の階層も混じります。ラインの職制に限らず、上位職はなにかと自分の存在価値を見せようと上書きしたがるものです。

　現場の事故対策チームでは異常表示の改善策を対策として計画を進めていました。事故対策チームの責任者はB職(のはず)で、上位のH職の了承も取っていました。しかし、社内レビューの場で、J職から当初から良くない設計だった、「当日にすべてのデータを登録できなかった場合、翌日に再度はじめからすべてのデータを登録する」という部分にも手を入れないのか、という指摘が入ったのです。

　現場の事故対策チームでは、今回は作業ミスの結果として設計の良くない部分が顕在化してしまったが本来は問題として表出しないものであり、もし今後別な要因として表出したとしても、顧客ユーザが直ちに異常の発生に気づいて連絡していただければ対処できるので、改修により追加の設計と工数を要する本部分は手を入れる必要性がない、と判断したのです。データ登録システムの稼働寿命があと1〜2年ということもあります。

　にもかかわらず、一旦了承したH職も現場の判断をあらためて支持することなく、B職も云われるがまま設計見直しを検討しようということになってしまったのです。結果、顧客先のシステムに最終版が反映され”対策完了”となるまでにさらに1ヶ月以上の期間を要することになりました。顧客の運用にとって必ずしも必要でない機能のためにです。

　システムの動作を一般化、単純化して説明したつもりでしたが、業界外の人にはやや専門的になってしまったでしょうか。責任所在が曖昧な組織では、責任所在をあらかじめ決めたつもりでも、この様な上書き、どんでん返しがよく発生するのではないでしょうか？ あらためて点検が必要な部分だと思われてなりません。

　最新の提言を、メールマガジン(無料)で配信しています。是非ご登録ください。