前回のエントリーが尾を引いているのですが.
ここ何事も10人10色で、全員が納得する仕組みや使い勝手は存在しません。国や制度なら尚更です。
システム作りも政治も、その面では同じです。20%が不満でも80%が満足するか、90%の人が少しの不満をもつか、どちらが良いかなどは、判断できるものではありません。人の価値観で異なるし、時代背景にもよるでしょう。
幸福度の高い人を多く作るか、適度な不幸を皆で共有するかも、意見の分かれるところです。
私は、どちらの世界も有って良いと思いますし、住民が自分の意思で選択か引っ越しができる仕組みがあれば良いなと考えるのです。
システムも、経営者にとっての使い勝手と、実務担当者にとっての使い勝手とは違います。
実務担当者にとっての必要項目も、経営的には不要な項目もあります。近視眼的に必要と思われている項目も実は不要だったということも多くあります。その判断は、システム屋が出来るものでは有りません。上意下達なら、直訴できるだろうし、相手担当者に実権があるときは、従うしかないでしょう。
使い勝手は、使う人の慣れ具合も左右されるので、相手の経験にも依存されまます。
正論な論理だけでは構築できないのが業務システムの難しさです。OSやコンパイラは、実装技術的には高度なスキルを要しますが、理論がはっきりしていて、作る仕組みが固定化されるので、その面ではスッキリして、作り易いとも言えます。(作り易い/難しいの比較は無意味なんですが)
一言で言ってしまえば、業務システムは、入力データの集計仕事に集約されてしまうので、答えが確定するだけに簡単そうに見えますが、多システムとの複合した仕組みだと、トランザクション管理すら自由になりません。 MS系で、Active_DirectoryとRDBを同期をとって動作させるのも、難しいものがあります。ましてや、他のOSと連携させるとなると尚更です。
他の仕組みとの連携保証を高めると、使い勝手が犠牲になりがちです。トレードオフになります。
経理システムとの連動は、金と物との流れと矛盾が付きもので、落とし処を見付けるのを要求されても困るだけです。
新人や知識不足の技術者だけて作れるものではありませんし、作れるとは誰も言わないでしょう。経験を積む必要があるので、自然と淘汰されます。
個々のプログラム開発は護送船団方式であっても、システム開発は押さえるところは押さえている筈です。
ただ、予算と期間という壁があるので、100%満足できるモノは作れないので、どこかで納得の上で妥協する必要が有ります。PMやリーダーの腕の見せ所です。
#ダメPMによる火災も起こりますけどね.www