元ネタ:ユーザ目線のシステム作り：
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=42918&forum=40「画期的なシステム開発手法云々が可能か等」が語られています。ここでの発言者の意見に大方賛同していますので、改めてエントリーするのは憚られるのですが、一家言ありましたので、書いてみます。<- 素直に書きたかったと言えないのかオイ。
ユーザー要求を即システムに反映できて、開発技術者の意思が入りこまないシステムを目指しているようにかんじました。
耳当りの好い言葉なんですが、「ユーザー要求が正しい」という前提が保障されないと砂上の楼閣に過ぎません。
当の会議室で発言があるように、開発者は業務要件をシステム化しているに過ぎず、業務シナリオを考えているのではありません。
開発者はマクロな業務知識は必要だとは思いますが、個々の法人の業務知識は一過性のものと考えます。
開発者の役割の一つに、業務シナリオとシステム操作に矛盾が生じない設計をすることがあります。
ノン開発者システムの怖さはここにあります。(言われるままに作る似非開発者は除きます。)
例を挙げると。
販売管理システムで日次/月次〆処理済みの伝票にミスが見つかったとき、どうします。
普通のシステムなら、修正不可で赤黒処理するように作ります。これは製造工数も増加するし、操作する人も面倒に感じます。これを操作し難いと感じて、直接変更可能にしたい変更要望がでた時、ユーザー目線のシステムだと歯止めが効かず、変更される。もしくは始めから修正可能なシステムになっているかもしれません。 当期内の変更なら追試すればいいのかも知れませんが、前期以前の伝票を操作すると、粉飾行為になりかねません。(一部のERPはこれが可能だと噂かありますが。)
UIを使い易くつくるのは当然ですが、UI以外の訂正/削除などのデータ操作はある程度の制約を加えるのがシステムです。
20日〆の翌月末支払いとか1円未満切捨てとか単純なルールは実装できます。しかし、当月内の買い上げ額がxxx円以上の顧客に対しては時価不定の商品を1つプレゼント....というルールは実装できても、経営的に成立するのかシステムは判断できません。システムは意思決定"支援"システムであって、意思決定はできません。その意味では業務システムは未熟と言えるのかも知れまんが、これが役割だと思うのです。
業務ルールを構築するのは脳内作業であってシステムではありまん。業務ルール策定者がIT技術者で自らシステムを作るのがベストですが、そうもいかないので我々IT屋が成り立っています。
4GLとかユーザー定義言語は昔からあります。いずれも限界があり大輪に至りません。
ユーザー層にとっての使いやすさと所属会社にとっての業務との整合性を意識している人は少数です。
社会保険庁の職員の行った反システム的な行為をみれば明らかなように、操作に歯止めをかけるのもシステムの重要な用件です。ユーザー目線では実現しにくい項目だとおもうのです。悲しいですが。
業務ルール策定者以外のユーザー目線のシステム構築というのが、引っかかって書いてみました。