＜ITへの的外れな期待＞

「仕事を誰にでもできるようにする」

　もちろん、うまく行くケースもある。いくつかあげてみよう。

• 製品ごと、事業所ごと、顧客ごとにさまざまなやり方をしていた仕事を標準化する取り組み。仕事の仕方を標準化することにより、他の人が手伝ったり代わったりできるようになる。
• 操作を分かりやすくし、アルバイトやパートでもできるようにする。場合によっては、顧客が自らできるようにする。

　さまざまな例外事項にプログラムで対応しようとする試みが引き起こす問題点が3つある。順に紹介する。

（１）コストがかかる

　これは言うまでもないが、プログラムの開発にコストがかかる問題がある。件数の80％を処理する1行も、件数の0.01%を処理する1行も、基本的にプログラムを設計し、作成するコストは同じである。当然、件数の80%を処理する1行は経済的だが、件数の0.01%を処理する1行は不経済である。
　さらにデータを多様に分類するプログラムは複雑になる。データを5種類に分類するプログラムに対し、分類がもう一次元増えてそこにも5種類があると、5×5=25種類の2次元マトリックスになる。さらにもう1次元増えてそこに4種類あると、5×5×4=100種類の3次元マトリックスになる。テストデータは種類の数だけ必要なので、テストのコストは2次元のとき5倍、3次元になると20倍である。

（２）データの信頼性が落ちる

　プログラムが複雑になると、データの信頼性が落ちることも言うまでもないだろう。複雑なプログラムを、高い信頼性で作成すること自体が、難しいことである。その複雑なプログラムも、制度が変わったり環境が変わると変更しなければならなくなる。変更すると、何らかの間違いが起こる。また、変更後のテストも複雑である。それが信頼性を落とす。
　さらに悪いことに、複雑なプログラムほど変更が多い。例外的なケースへの対応はしばしば変更される。例外にきめ細かく対応するほど、変更が増えてしまうのだ。
　もう一つ、データの信頼性を著しく損なうケースが起こる。それは、例外処理を本来の対象でないところで適用してしまうケースだ。処理が複雑になるほど、そういうことが起こりやすくなるが、本来の対象でないケースに例外処理を適用していることをテストで発見することは難しい。

（３）利用部門の管理者の能力が落ちる

　通常、プログラムが例外に対応していない場合は例外処理は人間が行う。その件数は少ないので、業務の生産性には大きな影響はない。例外の対応は、担当者が規則や過去の事例などから対応方法を調べて、それを管理者に確認して実行される。
　プログラムが多くの例外処理を担うとき、担当者はプログラムを使って例外処理をこなす。管理者に相談・確認することがないので、それらの処理の存在を直接の担当者だけが認識する。
　その結果、担当者はますます専門化し、管理者の業務処理能力は落ちていく。｢誰にでもできるように」を目指していたにもかかわらず、逆の結果を招いてしまうのだ。

前のレポート

次のレポート