矢口竜二のブログ

今はIT関係で、色々な事に手を出しているが、その中から
新たな事が出来ないか模索も考えているのが本音である。
前にもブログに書いたが、若い頃からシステムを手掛けている時に
私は人の行動や、物の動きなどを観察して、システム的に
使えないかと言う好奇心が強かった。

それは人や物の動きの中に、色々な動作があるが、
システムを作る側は、相手からの要望だけで、決められた範囲しか
システム化しない。
それは企業の要望であるが、システムは人が使うので、
人ぞれぞれに能力的な違いがあるのが、トラブルとなる事が多い。

そのトラブルを避ける為には、人が使う事や物の動きを
取り入れる事のより、色々な工夫がシステムに挿入されていると
システムが生きると言うのが、私の考えであるから、
その様な行動を良く行っていた。

私のシステムはプログラマー泣かせであると書いた事があるが
それはシステム分析を行う場合は、必ず現場の仕事をやらせて貰い
人や物の動きに対して観察してからシステム設計を行っていた。

それは人がシステムに合わせるのでは無く、システムが人やる事に
合わせる考え方を私は持っていたので、その様なシステム設計を
行っていたからである。

人を見る場合は、特に能力の面や考え方を見て判断しないと
問題が起きた場合などに対処出来ないし、人それぞれに能力的に
違いがあるので、その面を考慮しなければ、良いシステムとは
言えないと考えている。

だから、システム面では複雑化するのでプログラマーは
時間が掛るのと、論理的な面で複雑になるので苦労させた。
酷い時にはシステム設計書にプログラム言語で複雑な部分を
書いてプログラマーに渡していた事もある。

それはプログラムが複雑になるので、納期までに出来ない事が
多くなり、それでは問題が出るので、複雑なルーチンを書いて
渡していたのである。

それでもシステムは必ずバグが出るし、論理的な問題は起きる。
私の場合は事務処理系から生産までシステムを作ったが、
前にも書いたが、元々は事務系の仕事をしていたので内容が分かり
問題が起こりやすい部分も分かるので、企業側は喜んだ。

私の若い頃は、システムは技術系の人が、企業から内容を聞いて
システムを作る人が多かったので、企業の言う範囲しか設計出来ない。
それで問題が起きる、それは、システム側は相手の言うがままに作るが
そこには問題が起きそうな部分が省かれてしまうし、同時に相手側は
コンピュータの利点が分からないので、言いたい事を言うのである。

そうなるとコンピュータに出来ない部分も出てくるが、
作る側は聞いた事をシステム化するが、メモリーや記憶媒体が
現在のように大きくないので無理がある場合も出てくる。

ましてや技術系の方は、処理内容が分からないので、問題点を
理解出来ないままにシステムを組む事になるが、私の場合は
処理内容が分かるので、問題点をこちらから提案出来る事が
出来たのと、相手側の能力ではチェック機能を増やす事も
当たり前に行った。

チェック機能によって、相手の入力ミスを防ぐ事を重点に考え
それはデータの入力ミスが、プログラム上では通るが、最終的に
問題が起こる原因であり、データ入力がコンピュータの
生命線であり、そこでミスると取り返しの付かない事になる事を
私も経験していたので、その部分はチェック機能が厳しいシステムを
作っていたのである。

基本的に相手の能力を判断してシステムを作らなければ
機能的な事だけ考えたシステムは、最終的に使われなくなるし
マニュアルでは、能力的な問題は解決出来ない事が分かっている。