野球のルールは難しい

暴言妄言満載の、小さな会社の為の逆説的ギャグ説的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暴言

第4回

野球のルールは難しい


うちの近くの建設会社に入ったSEが、ノイローゼになって会社を辞めました。これからますます激しくなる競争に備えて、情報システムの整備を目的に、中途採用されたSEでした。ご冥福を祈りたいと思います。

いや、ちゃかしている場合ではありません。明日はわが身なんですから。心を病んでしまった原因は、建設業の方々とのコミュニケーションギャップでしょう。あくまでも推測ではありますが、まず間違いありません。

私も痛感してますが、システム開発経験のない方に、開発の難しさを説明するのは至難の技です。以前、一緒に仕事をしたあるSEは、「どうせ理解なんかしてもらえないんだから、開発に必要な時間を、騙してでもいいから、うんと長めに確保することだけさ。」と言っていました。達観していますが、どうも釈然としない。もっといい方法はないのでしょうか。

『うるさい。開発者はもっと謙虚に、おれ達の言うことを聞けばいいんだ!』

いや、業務理解が大切なのは十分承知しております。ですが、このままでは問題は解決しないように思えるのです。開発者側だけの努力ではなく、ユーザーの方々にも、無理を承知の上ではありますが、もう少し頑張っていただきたいと切に希望します。要望事項を明確にし、開発作業にあと少しのご理解を。

多分、コミュニケーションの特効薬など無いでしょう。専門分野の違う人同士ですから。英語しかしゃべれない人と、日本語しかしゃべれない人のコミュニケーションに近いです。どちらかが相手に合わせて言語を切り替えるか、もしくは両者が理解可能な、例えば韓国語やエスペラント語で会話するか……。

開発依頼者向けに、コミュニケーション講座が開催されていました。なんと料金は300万円。また、『ユーザーはUMLの書き方を学べ!』と言っている書籍もありました(UMLはユーザーと開発者の間を取り持つ新しい表記方法)。どれも確かに一理ありますが、おそらく無理でしょう。過酷な条件下で現場仕事をしているユーザーの方に、とてもそんなことは頼めません。

どうしたらよいのかといろいろ考えた末、『やっぱり文章だよなあ…』と結論付けました。非常に古典的ですが、簡単なのでこれなら誰にでも出来ます。野球のルールブックを想像してみて下さい。振り逃げやボークのルールまで、事細かく記載されているはずです。

システム開発の難儀なところは、暗黙の了解をカタチあるルールに定義しなくてはいけない点。なにせ相手が、融通のきかないコンピュータですから。破綻のない綺麗なルールがないと、プログラムにはなりません。業務上の憲法と法律が必要なのです。要するに、それがシステムの設計書であり、文章量が多いということは、それだけ開発時間がかかることになります。

『9人ずつの2チームが、守備側と攻撃側に分かれて戦い、ボールをバットで打ち返して、入った得点の多さを競い合うゲーム。』野球の大ルール(憲法)を書けばこんなところでしょうか。もちろん、これだけでは終らず、振り逃げやボークまで細かく規定した小ルール(法律)があり、この記述まであって初めて、問題なくゲームが行えるのです。

ユーザーの方々は、開発者に簡単な大ルールだけを伝えた時点で、満足してしまう傾向があります。細部の聞き取り調査をして仕様をまとめ上げても、確認を面倒くさがります。これではいけない。開発者側は分かりやすく説明をしなくてはいけませんが、ユーザーも『細かいところは勝手にやってよ!』の考え方から脱却する必要があります。

守備と攻撃のチームがいて野球のゲームが成立するように、ユーザーと開発者が、役割は違えども一緒になって開発する気持ちがないと、プロジェクトは崩壊してしまいます。お互いに理想へ向かって頑張りたいものです。(自戒)

2002.11.26

鈴木正之助

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

スポンサード リンク


 

たまごや

週刊マナー美人

常識ぽてち

女性のためのクルマ読本

週刊節税美人

知って得する労働法

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

四柱推命による人生相談

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

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

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