コラム


第2回 プログラマー残酷物語


2.設計図のない建物や・・・

(3) 今も尾を引くソフトウェア業界の事情

ところでオフィスコンピュータと呼ばれる事務処理を中心とするコンピュータの時代を経て、昔の大型機より性能の高いパソコン（パーソナルコンピュータ）が、10万円そこそこで手に入る時代となった現在でも､ソフトウエア業務の初期の事情が尾を引いているように思われます。


性能が高くなることは、複雑な業務を、コンピュータに行なわせることが出来るようになったことを意味します。複雑な業務ほど､事前に詳細な聞き取りを行い、充分な分析が必要となってきます。それにもかかわらず各システムの価格が、そのような聞き取り、分析の前に決まってしまうのです。システムエンジニアは、作業を行う前から使える時間が決められてしまっているのです。


今だにコンピュータの営業の中にハード中心の考え方が残っており、見積り段階でユーザー業務分析なんぞに時間をかけていられるかといった風潮が見られます｡値段が決まってから設計が始まるのです。家やビルでそんなことは許されません。電化製品でもユーザーの使い方を検討するまえに値段が決まることはないはずです。コンピュータの事務系ソフトの業界だけに今でも残っている憎むべき習慣です。


そんな中で仕事をするシステムエンジニアは、金額の範囲内に原価（プログラマー人件費）を押さえることを要求されます。現場でおこる様々な状況がどのような建前で動いているかだけではなく、例外事項にみえる現象が、実際にはどのような事情で発生しているかを見極めないと、本当に現場で使えるシステムの構築は出来ないのに、そんな事を聞き取り分析する余裕がないのです。


コンピュータでは、原始記録の記入ミスとともに、コンピュータへの入力ミスという新らたな問題が発生します。記入ミスについては、入力できないようにするか､警告のメッセージを表示してあげることにより、入力ミスも同時に一定程度防げるのですが､記入ミスの発生原因を分析し､様々な事態を想定しないとそのロジックは組めません。とても時間がないとあきらめてしまいます。システムエンジニアの中にもそんな状況を憂い､少しでも現場に近いシステムを作ろうという気持ちを維持している人もいます。しかし大半は違う考えになってしまっています。


まず、システムの中に建前以外の現場の事情をいれないようにする。そのことよって例外事項はメモやノートという形で現場作業の中に残りますが､現場の人が最も望んでいる合理化にはなるべく目をつぶる。記入ミスや入力ミスはユーザーの責任ということにして、チェックロジックは最小限にする。現場からのクレームにそなえる為、責任限定を明確にすることを目的とした記録を残し、後々のクレームに対して準備をしておく。


そんな事に重点を置いた設計が優れた設計だとされ、社内でも評価されます。採算の取れるシステムエンジニアという扱いです。さらにそんな考えかたが価値観になってしまうと、もう救いようがありません。そんな環境をあたり前だと受け入れた人たちに、「現場の側に立った設計が大切だ」と話していても、理解されないのは悲しいことです。「現場の業務なんてある程度知っていれば良いことだ」というセリフを、コンピュータの営業やシステムエンジニアから、意識的にせよ無意識にせよ聞かされると怒りすら覚えます。


事務系のソフトウエアであっても、コンピュータのソフトウエアを作ることは、一つの作品を作り出すことです。その時､実際にコンピュータを操作する人だけでなく、そのシステムに関連するすべての人のことを考えるというあたり前の自覚が、希薄になってしまっているのです。「こんな事が許されるのは、コンピュータのソフトウエア業界ぐらいだよ」と言ってみても､きょとんとされては言葉が続かなくなってしまいます。


個別設計のシステムでみられるこれらの傾向が、パッケージソフトになるともっとひどいことになります。


目次