現場で嫌われる「バッタモン要件定義」の話です
私が考える基幹システムの存在とは『働く人の味方』
なぜなら、起業した経営者が当初は自分でしなければならなかった各種作業を機械化するところに端を発しているからです。（⇩こちらにもそんなことを書いています）
基幹システムの成り立ち
もちろん創業した初期の頃にできる機械化といってもたかが知れていますので、その時点では「基幹システム」なんてレベルにはならないでしょう。
ですが事業が軌道に乗り、雇った部下たちに作業をエンパワーメントできるようになると話は変わってきます。
業務体制の組み方を機能的に考えざるを得なくなる。
この頃から「システム」というものをリアルに考え始めるでしょう。
そして、その時に考えた範囲のレベルでシステムを組むことになろうかと思います。
ということは、本来は実務に沿って走る性質のもので、そこに社内政治などは関係しないはずです。
経営陣への「やってますアピール」として機能するシステム
当初は純然たる「業務の機械化」としての存在意義を持っていた基幹システムですが、時とともに妙なノイズが入ってくることがある。
システムを改編したこと自体が ”成果” として扱われるのはどこも一緒だと思います。
ですが、実際の効果が現れるのには時間がかかるのが普通です。
なぜなら「システムに起因した現場の改善と業績アップ」は、出来上がったシステムがある程度の期間稼働した後でないと正確に測定できないので、システム開発との因果関係が証明できない。
まあ仕方がないですね。
なので、システム完成の指揮を執ったプロジェクトマネージャーに対する評価は「スケジュールの進捗度」や「コストの予実管理」そして「改編を成し得たこと」で済ませざるを得ない。
こうなると「作文」とか「ポーズ」でのアピールさえうまければ、結構な評価を得ることも可能になってくる。
要件定義の「機能」
要件定義をやったと見せかければ仕事は終わる。
その後機能不足が露見して追加予算が必要になっても、とりあえず言い繕って現場を黙らせてしまえばよい。
そのままカットオーバーまでやり過ごせばプロジェクトは終了する。
事前説明とは全然違うと現場からクレームが上がっても、それは現場のコンセンサス形成が甘いのだとか、新体制への取り組みが噛み合っていないからだとか、そもそも業務改善の工夫が足りないからだなど、いくらでも他人の責任にできる。
システムへの無関心層が増えれば増えるほど、「システム改編プロジェクト」というものに口を出してくるユーザーは少なくなるので、己のキャリアに箔をつけるだけのきな臭い思惑は、意外と平和的に通ってしまう。
なんだか「選挙にいかない人間が増えるほど、既得権者がやりたい放題になる」に似てますね。
それと「予算さえ獲得して自分の実績さえ積めれば、後は野となれ山となれ」と考えるエリート官僚の構図にも似ている。
なるほど、要件定義して作ったシステムが理想的に稼働するのが難しい理由が、なんとなく見えてくるぞ・・（あくまでも私見です）
＜雑談は続く＞
