新鮮

頑張らないために頑張る

使われないシステムが生まれる原因?

 

先日に引き続き、約10年携わっていた「社内システムエンジニア」についてツラツラと書いてみようと思う。

このエントリでは主に SIer さんや PG さんに参考になる話ができればと思う。みなさんの仕事の上流で何が行われて、その上流の人々の関心事が何かを共有することで、お互いにハッピーになれる部分があるのではないかと考えている。またそれ以外の方にも世の中にはそんな仕事があるのだと知ってもらえれば嬉しい。

 

今回は「使われないシステムが生まれる原因?」である。

 

再掲、良いシステムとは使われるシステムである

先日、良いシステムとは使われるシステムであるというエントリを挙げた。SIer さん、とりわけインフラチームの方々には「アホなことぬかすな、クズが!」と思う方も多いだろうが、ここは百歩譲って頂き、まずは仮置きさせて頂きたい。

www.hiizumix.net

 

では「使われる」ためにはどうしたらいいのだろうか。

 

逆に考えたほうがいいかもしれない。

「なぜ使われないのか?」

使われない原因が分かれば対策を講じることができるし、デスマーチした甲斐もあるのではないだろうか。・・・それは絶対ないか(笑)

 

なぜ使われないのか?

では「使われない原因は?」と訊かれたとき、あなたは何が浮かぶだろうか。

  • 必要な機能が足りない
  • システムの使い勝手が悪い
  • システムの性能が出ない
  • 障害が頻発している

このあたりだろうか。

 

もちろんこれらは満たしておきたい要件だが、使われない原因ではない。

  • 必要な機能がなくても、使う必要があれば使う
  • 使い勝手が悪くても、使う必要があれば使う
  • 性能が出なくても、使う必要があれば使う
  • 障害が頻発していても、使う必要があれば使う

なんだよそれ!と思うかもしれない。実は、機能・使い勝手・性能・品質などとは独立したところに「使われない原因」がある。

それは何なのだろうか?

ケースバイケースだが、大半のケースはユーザが使いたくないからである。

 

ユーザが使いたくない?

全く意味がわからない。使いたいから発注したんじゃないの?このブログの筆者は救いようのない馬鹿じゃないのか?と思うだろうが、ここは一度、システムを利用するユーザの視点で考えてみたいと思う。新しいシステムが導入されるとユーザはどう思うだろうか。「業務が楽になって嬉しい!」と思うのだろうか。

実はそうではない。

いままでのやり方で出来ていたのに、やり方を変えなければならない。新しいシステムの使い方を学ばなければならない。今まで作ってきた業務マニュアルを破棄して新しく作り直さなければならない。場合によっては取引先に業務変更を説明しなければならない。変に効率化すると一緒に仕事をしてきた人を減らさなければならない。場合によっては自分の職がなくなるかもしれない。ユーザにとってこれは恐怖以外の何物でもない。

 

ではユーザ部署の部長はどう思うだろうか。

部長のミッションは自部署を大きくすることなのに、業務が効率化すると部署を縮小しなければならない。部署を縮小すると自分の権限が減るし、部下が離反するかもしれない。さらに部署を縮小なんてしたら自分の評価に影響するかもしれない。いままで社内政治で勝ち上がってきたのにここで負ける訳にはいかない。俺にはこれからも養っていくべき愛する家族がいるんだ。ユーザ部署の部長にとってこれは想像を絶する恐怖である。

 

最悪のケースは部署間連携だ。

システム化により全体最適を目指すと必ずいずれかの部署が割を食らう。総論賛成、各論反対、絶対反対。なんで他部署の効率化のために自部署の稼働を増やさなければならないのか。利益を生み出しているのは花形である自部署なのに、なんでコストセンターのシステム部門ごときの都合にあわせるのか。組織力学的に理不尽ではないのか。

 

そう、稼働が減ることは恐怖であり、稼働が増えることは理不尽なのだ。つまり、死んでも変えたくない。システム導入を建前では歓迎しつつも本音では否定している。それがユーザの想いであり、使われないシステムが生まれる最大の原因なのである。

もう一度言おう。

機能・使い勝手・性能・品質などとは独立したところに「使われない原因」がある。

 

するとどうなるか

会社方針なので建前としてはシステム部門に従わざるを得ないが、本音では絶対に変えたくない、死んでも変えたくない。すると些細な事に注文をつけはじめる。

 

「これからは印鑑は不要になり、電子署名になります」

「取引先の都合上それは認められない。印鑑"でも"使えるようにしろ。」

 

「エクセルではなくWEB画面になります」

「ここに色がつかないと業務にならない。色を付けるようにしろ。緑だ。」

 

「後続フロー簡素化のため、○○を追加で入力してもらいます」

「それはできない」

 

万事許せないのである。小言を言うことで、システム構築に積極的に協力しているアピールができる。そしてシステムを使わない理由はシステムが業務実態にあっていないからだと理由を作ることができる。そして使わないのはシステム部門の責任だと転嫁することができる。建前と本音が両立できる。自分たちの恐怖や理不尽が解消できる。

 

で、社内システムエンジニアはこの小言をうけてどうするか。

「仕様変更」である。

あなたをデスマーチに追い込む「仕様変更」のトリガーはここにあるのだ。

 

使われない原因、それから派生して仕様変更の原因、それはシステム利用企業の組織力学から生じてくるのが分かった。ではどういう対策をすれば使われるのか、仕様変更を減らせるのか。あなたは家に帰れるのか。

長くなったので別エントリでお話したいと思う。

 

おわり