運用設計の手抜きがもたらす悪循環に気づかない管理職のお話し

いつもながら友人のグチにお付き合い頂けるとすれば、今回はシステム運用のお話。まあ、今回のグチには一理あると思うので、ぜひご一読を。


新しい情報システムを導入するとき、本番稼働するまでのプロジェクト体制や導入手順は一生懸命考えるのだが、本稼働した後の運用設計をサボっていることが多すぎるという件。

たしかにプロジェクトというのは期間を決めて、大量のリソースを一気に投入するものなので、期限どおりに終わらないと直近のコスト増の要因になる。

なので短期的な費用に気を取られがちな管理者たちは、本番稼働の納期を厳守しようとするあまり、本番稼働後の運用がいかに費用がかからない効率的なものになっているかの設計を、おそろかにしがちだという。

その結果、プロジェクトとしてはほぼ納期内に完了し、無事本番稼働を迎え、プロジェクト関係者は評価されるのだが、運用設計がおそろかになった部分はすべて、運用部隊の負荷増として、運用部隊に責任が押し付けられる。

そのようなプロジェクトが複数つづくと、運用設計が悪いせいで、運用部隊の負荷が増える一方になる。

管理職たちは、もともと運用の効率化に関心がなく、プロジェクトという社内で目立つ活動を期限どおりに終わらせることに関心が向くので、運用負荷が増えて、運用部隊の動きが悪くなると、それを運用部隊のせいにする。

たとえば、運用部隊はやらなくていいことまでやろうとしているとか、そもそも運用部隊の業務の進め方の効率が悪い等々。

しかし実際には、そもそも運用設計を真剣にやっておらず、そのツケを運用部隊にまわしているだけなのだ。

それどころか、本番稼働後に見つかったシステム設計上の問題の「尻ぬぐい」さえ、運用部隊に丸投げしてしまう。するとますます運用部隊の負荷が増える一方になる。

結果、運用部隊が自らの業務を改善する時間的、人員的な余裕さえなくなった場合、運用部隊は慢性的に仕事が回らない状態になる。

運用設計の重要性をわかっていない管理職たちは、これを運用部隊の問題として解決しようとする。たとえば人を追加するとか、新たな運用ツールを導入するとか、最悪の場合は「そもそもあいつらの作業効率が悪いだけだ」と考えて何の対策もとらない。

運用部隊にツケを回しつづけると、確実の情報システムの稼働状況が悪化し、利用者部門にじっさいの影響が出てくる。

同じような不具合が何度も発生するとか、使えるんだけれど動作がものすごく遅いとか、利用者が問題解決までに何日も待たされる等々。

そういった利用者部門の不満は、情報システム部門の管理者たちの気づかないうちに、「声なき声」として少しずつ蓄積されていき、情報システム部門全体に対する悪評につながる。

表立って文句を言ってくれれば、情報システム部門としては逆にありがたいのだが、最悪のケースは利用者部門が情報システム部門に対して「あきらめ」の気持ちを持ち始めることだ。

情報システム部門に何を言っても仕方ないので、自分たちで何とかしよう。

システムの利用者部門がそう思い始めると、社内の情報システムの統治(ガバナンス)自体の危機になる。

利用者部門の面従腹背は、次に新しいシステムを導入するプロジェクトを立ち上げたとき、十分に利用者部門の協力が得られないという現象となってあらわれる。

十分に利用者部門の協力が得られないと、今度は導入プロジェクト自体の品質が下がり、納期までに完了しなかったり、ますます運用設計に無関心になったりする。

こうして情報システムの導入と運用について、「悪循環」が始まる。

最初に運用設計をきっちりやっておけば良かったのに、運用設計をおそろかにしたせいで、利用者部門の声にならない不満を引き起こし、次の新しいプロジェクトの成果物の品質が下がり、さらに運用部隊の負荷が増え、さらに利用者部門の不満を大きくし…といった悪循環だ。

このように考えると、運用設計をしっかりやって、運用部隊の負荷を下げることがいかに重要かが分かるだ。

ところが、情報システム部門の管理職の中には、自分たちのやっている仕事全体がぐるぐると循環するPDCAサイクルになっているという自覚のない人が意外に多い。

そのため、プロジェクトをやりきったその都度の達成感と評価だけで、次の仕事に取り掛かってしまうことが多い。


以上が友人のグチの内容だ。まあ、一般の民間企業の管理職に、そこまでの頭の良さや賢明さを求めること自体、ムリな話だと筆者は思う。

定時後の飲み会や、休日のゴルフに労力をムダに費やすという、「ザ・昭和」の仕事のやり方に何の疑問ももたない管理職に、頭の良さや賢明さを期待するだけムダというものだ。

所詮サラリーマンなんてそんなレベルである。