過剰な人たち

暴言妄言満載の、小さな会社の為の逆説的ギャグ説的IT活用コラム。マニュアル・ファースト開発とは?会社の情報活用力とは?零細建設業の社内SEにして世界唯一無二のITボーゲニストが、今日も考えます。

IT暴言
鈴木正之助

IT暴言

はっぱ 発行部数を見る

はっぱ

鈴木正之助自己紹介
はっぱ 鈴木正之助おススメ本
はっぱ 鈴木正之助にメールする

コラム

59

顧客が本当に必要だったもの〜少し長めのあとがき

58 IT嫌いがIT推進役の条件?
57 壁の壊し方(下)
56 壁の壊し方(中)
55 壁の壊し方(上)
54 ABどっち?
53 見せれば花
52 組織の方程式『P=SΣ』
51 組織と集団
50 いい按配の丼勘定
49 サルでも分かるTOC
48 情報の使い方
47 EとAのあいだ
46 ELSEの男
45 解決方法あれこれ
44 技材よりも人材
43 デザイン・トラウマティック
42 過剰な人たち
41 ニューヨーカーに風鈴を!
40 『自由からの逃走』
39 コーモリとケータイ
38 間接部門と呼ばれる理由
37 フライは誰が捕る?
36 コンピュータは人である!
35 スパゲッティに至る旅路
34 プログラマとオペレータ
33 静かな会議
32 CODE・IS・TATTOO
31 立って座って酒飲んで
30 BEHIND・THE・MASK
29 HOWの賞味期限
28 『頑張らない』
27 考えてる人、頭のいい人。
26 正確という烈しい病
25 振り返る、の巻。
24 MF開発質疑応答
23 内部の話し
22 森を見て木も見る
21 ソウ言エバ式進化論
20 アジャイル・マニュアル
19 <緊急暴言>やってくれるぜNEC!
18 後ろから?前から?
17 ミタイナの翼
16 感動したらゴミ箱へ
15 ナゼ×5=?
14 問題なんて……。
13 とりあえずバイアグラ
12 砂時計にサヨウナラ
11 『 2:8 = 8:2 』(開発コストを1/5にする方法?)
10 手書きのチカラ
09 脱税の出来るシステムとは?
08 ソリューションはイリュージョン(解決策など幻想)
07 帳票はセルフサービスで
06 パンツ、ズボン、コート
05 いつまでたってもプロトタイプ
04 野球のルールは難しい
03 機械なんて至らないもの
02 ブラジャー選びに要求定義を学ぶ
01 建売住宅にカラオケルームは付くか?
00

Tことわざ・システム屋システム持たず

 
 

IT暴言

第42回

過剰な人たち


開発コストを、大幅に削減させる秘策があります。それは、エラーチェックを行わないこと。入力の間違いは入力者の責任であると、割り切ることです。

細部の2割が作業時間の8割を占める、とずっと前に書きました。ちなみに、エラーチェックがどれほどの行数書かれているのかと言えば、たまたま手元にあった『品目データ登録』という約200行のプログラムは、約40%の80行でした。条件によってこの数字は変わってきますが、結構な作業の量です。

ある時、ユーザーが趣味的に開発したプログラムを見る機会がありましたが、ビックラこきました。なんと、エラーチェックがほとんど入っていない。「もし、ヘンな入力をしたらどうするの?」と私が聞くと、「常識があれば、そんなことはしない!」と涼しい顔をした答え。自作の、自分だけしか使わないソフトなら、シビアなチェックは要らないのですね。

チェックは処理の主体ではありません。データの入力された後の方が大事です。もちろん、システム異常につながる危険な入力は、はじかなくてはいけません。が、開発コストを考えれば、端折れるところは端折ってしまった方が良い。

例えば、『工事名称の未入力チェック』。名無しの工事などあるはずもなく、うっかり入れ忘れてしまう事など、普通は考えられない。仮に、空白で入力されたとしても、普通は誰かが気付く。その段階で、「失礼しました」と一声発して修正すれば良いだけだが、さて、ここから話しは急展開する。

「入力するの忘れないように、チェックしてくれヨ。便利になるだろ。」

念の為に繰り返しますが、絶対に必要なチェックもあります。しかし、明らかに過剰と思えるケースが、ある……。と、ここまで書いてきて、これは普遍的な問題であることに気が付きました。日本中のいたるところで起きている話しであって、しかも、原因と結果が循環するので始末が悪い。

これは『遊泳禁止』の看板と同じです。常識があれば、危険な場所では泳がない。判断レベルの低い人に対するお知らせのようにも思えますが、これは、突っ込まれた時に備えての『予防線』。意味ないんです。そんな看板を立てておくから、国民の判断力も低くなる。日本は、親切過剰な国なのでした。

会社内も予防線の宝庫です。例えば、馬鹿丁寧な資料作り。突っ込まれないようにと、見た目に凝り始めるのですね。するとまた、「センスねえな」と、突っ込まれる。「今度こそ」と、誰も見やしない表を添付したり、枚数が増える。

システムのチェック。「あの人たちが使うんだから」と、開発者はチェックを増やす。考えることなく使えて便利になる。しかしある時、「入力できちゃったヨ」と、これまで想定してなかったデータが網の目を潜り抜ける。慌てふためいて、データの後始末とチェックの追加を行う。親切と気配りの名のもとに、サービス提供側の作業増大とクライアント側の白痴化が、同時進行するのです。

簡素化すべき部分と親切にすべき部分、2つにわけられるんじゃないでしょうか。この不幸な過剰連鎖反応を、どこかで断ち切りましょう。サービスしなくちゃいけないのは、社外のお客さんに対してです。社内の立派な大人に対しては、過剰な親切と防衛は不要です。子供じゃないんでちゅよ。

レベルの低い人には、教育を施すのが正しい対応。ここは親切に。何でもやってあげる式の甘やかしは、間違ったアプローチです。多極分散ネットワーク型社会など、『自律と信頼』が前提条件。「社内LANがあるからOK!」なんて、単純な話しではありません。まずはリーダーが『過剰作業見直し令』を発し、メンバーも心がける。『自律と信頼』を胸に、合理化へ舵をきりましょう。

見習うべきはマイクロソフトです。あの、セキュリティーホールだらけのインターネットエクスプローラーを見よ! 「ユーザーに悪い人はいない」と、全面的に信頼しているから出来ることなんですね、きっと。

2003.09.08

鈴木正之助

※記述が古い場合があります。自己責任にてご利用ください。

スポンサード リンク


 

たまごや

週刊マナー美人

常識ぽてち

女性のためのクルマ読本

週刊節税美人

知って得する労働法

ファミレス様、覚悟せよ!

四柱推命による人生相談

小口輸入支援・販路ドットビズ

あなたもライターになれる
お問合せ

創刊:2002.10.20
更新:2013.06.06
IT暴言
デジタルたまごやトップ