システムの最もシンプルな効果は「加速」
しかしその加速は、作業そのものだけではなく、作業に付随するあらゆるものに作用する。
「作業だけ加速させたいんだ」というのは甘い期待で、システム周りに存在する社内の各種問題をも加速させる。
上の記事で書きましたが、問題の規模が大きくなっても耐えられる体質にしておくか、そうでなければあらかじめ問題そのものを解決しておくというのは、要件定義前に ”ユーザー側” が済ませておかなければならない大切な条件です。
あくまでもこれはシステム開発を依頼する ”ユーザー側” の仕事であり、システム開発の技術的な役割を担当する ”エンジニア側” が果たすべき条件ではないことを、我々は肝に銘じておかなければなりません。⇐ここ重要！
本音を言わない要件定義の打ち合わせ
上に示した過去記事で「負の要素のほうは美点と違って当人自身が見ないようにしていることもあり、急な加速に対して無防備に肥大してしまう」と書きましたが、要件定義の打ち合わせではこの ”見ないようにしていること” が議題にあがらない。
「見たくないし、そんなことはシステムが入れば解決するだろう」
とか、
「それをするのがシステムだろ！」
といった感じでしょうか。
なにやら「そこをなんとかするのがお前たちエンジニアの仕事だ」とブラック感を漂わせる危険なフレーズがテーブルの下に漂っている気がします。
私の知り合いのシステムエンジニアに
「要件定義の会議、中々まとまりがつかないのでは？」
と聞いて
「いや、割と問題なく進みますよ」
と返されて驚いたことがありますが、上記で言うテーブルの下の闇が、テーブルの上ではまったく存在しないことになっているからだと、私はひそかに思っています。
「人間関係改善システム」をプログラミングで作れるか？
あるクライアントのプロジェクトリーダーと、アウトソースの業務体系整備に関する会話をしたことがあります。
そこでは同時にシステムの大幅改修が行われていました。
かなり予算もしっかり取ったと思われる物々しさが感じられる。
私自身はシステム周りの話に参加できないので、進捗に関する情報はリーダーから聞くばかりとなりますが、そのリーダーさんは明らかに現場との人間関係が上手くいっていない。
そんな立場にある中では、システムが陳腐化した分だけ、それをカバーするために人間関係が濃くなってしまい、そのことがかなりのストレスになっている模様・・
ちょっとしたやり取りからもそれが濃厚にうかがえる。
会話のストロークが、急に逃げ腰になることが何度もあるのです。
そしてそれは毎回「実務担当者とのコミュニケーション」が話題になったときでした。
部外者である私に対して「だからそのへんをなんとかしてほしい」のニュアンスで多数のストロークが交わされる結果となり、なんとなくその組織のフォルムがイメージできました。
＜雑談は続く＞
