【感情会計】善意と悪意のバランスシート

善と悪の差し引き感情=幸福度

【システム雑談】中間まとめ

開発費を高騰させる「システムエンジニアへの誤解」というタイトルで【システム雑談】というものを続けていますが、もう少し続きそうなのでいったん整理します。

 

blog.dbmschool.net

 

blog.dbmschool.net

 

「SEへの理解」と「システムへの理解」

「システムエンジニアへの誤解」という観点で書いていますので、一見すると「職場の人間関係の見直し」みたいな印象もありますが、それが主旨ではありません。

 

たくさん金を食うからという理由で特別扱いされ、働きが悪くても認められる不思議なポジションを、なぜか「システム」というものが占めている。

 

blog.dbmschool.net

 

システムを政治利用するユーザーとシステムに利用されるユーザーの違い

そのシステムに振り回されるわりに、賃金のほうはシステムとのトレードオフのように実質的には下がっていく業務現場のメンバーたち。

 

使えないシステムでも、それを ”作った” という実績が評価される一部の人間がいる一方、それを ”使わされる” 側の多数の現場従業員が、上がらない生産性を悪く評価されて賃金も上がらず、ことによっては人員整理されてしまう。

 

blog.dbmschool.net

 

みすみすルサンチマンを増やして強化する機能を持つシステムなんて嫌だ。

 

 

実務を離れて要件定義は存在しない

、、と、現場側メンバーの一人ながら、システムとは少し特殊な付き合い方をしてきた経験をもとに書いています。

 

何度も述べていますが、基幹システムはもともと現場業務に寄り添う目的で作られています。

 

blog.dbmschool.net

 

しかし、システムにさせる事柄が増え、内容が複雑さを増していくと、開発の難易度が上がる。

 

要件定義が難しい理由

世上「要件定義が難しい」とよく言われますが、本当に難しいのは使えないシステムを投げ込まれた現場の運営です。

 

本当は先ず何よりも「現在の業務の掌握度」が高くないとシステム要件の明確化ができませんし、それをエンジニアに伝えることもできません。

 

blog.dbmschool.net

 

とにかく、システムはいったん作ってしまうと運用の責任の一端が実務者に分散されることも多く、何かを決めるにも文字どおり「決め手を欠く」ことになって身動きが重くなりがち。

 

その主要な要因が「ちょっと変えるにもやたらとカネがかかる」である以上、問題の解決は上流(開発にカネがかかる)にある。

 

「高価」であることが、扱いが難しい原因になっている

ということで・・

偉くなってしまえば勝ちだ、みたいな図式を打ち砕くには「高すぎる開発費」という足かせを外してしまわなくてはなりません。

 

 そのためにユーザーはエンジニアと手をたずさえて、できる限り安くて効率的なシステムを模索していくのが良いと思うし、実際に私はそうしてきました。

 

blog.dbmschool.net

 

もちろん、システムを作るより業務のスキームを変更してしまう、というのもその一つです。

 

その安くて使い勝手の良いシステム作りの第一歩として、とにかくお付き合いが深くなるシステムエンジニアに対するある種の誤解をピックアップしている状態です

(あくまでも私の経験則に基づいた私見ですので、そのつもりでお付き合い願えれば幸いです)