顧客が本当に必要だったもの

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

第59回

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


『IT暴言』は、今回でおしまいです。約2年間、どうもありがとうございました。後半は、発行のペースを乱してしまい、大変に申し訳ありませんでした。プレリリースや他マガジンへの提供分なども含めると、書いた本数は全60本。少しでも皆様のお役にたてたのであれば、嬉しいです。

全体を通して振り返ってみると、字数を多く割いているところは、『問題解決』と『コミュニケーション』についてです。特にコミュニケーションは、企業内の業務システムの開発で最も大事なことだと、私は思っています。プログラミングなどの技術力と共に、『システム開発の両輪』であると言えますね。

ところで、『顧客が本当に必要だったもの』というタイトルの風刺絵があるのをご存知ですか? 私は今年の春に知りました。開発者の間では、かなりメジャーな存在となっていますが、これほど的確に、システム開発の実情を表現しているものはないと思います。御存知ない方は、まずはこの絵をご覧下さい。(http://www.dashiblog.com/blog/archives/project_comedy_l.gif

コミュニケーションは難しいと語りかけるこの絵、面白さが分かりますか? 苦笑いしてしまった方は、過去に苦労されたことがある方でしょう。え、私ですか? 私の場合は、あまりにも身につまされて、泣けてきました…。

顧客が本当に必要だったものは、古タイヤをロープで吊っただけのブランコ。それで十分だったのに、既に説明の段階から間違いが始まっていて、途中でアナリストやプログラマが、輪を掛けてヘンなことをやらかして…。なぜ一発で、『古タイヤのブランコ』が作れないのか? この絵を知人の建築関係者に見せたら、「ウチの業界も同じだよ…」と嘆いてました。

なぜでしょう? あまりにも色んな要因がありすぎ、到底一言では語り尽くせませんが、「創造とはかように難しいもの」であり、また一般論になりますが、「会社勤めしている人は創造的作業(プロジェクトワーク)に慣れていない」ということは言えると思います。大半の人が普段行っているのは、定型的作業(ルーチンワーク)なので、慣れていなくても当然と言えば当然ですが…。

開発のし易さから言えば、1番楽なのは『開発した当人だけが使うシステム』です。2番目は『1人のユーザーだけが使うシステム』。ユーザーと開発者のコミュニケーションが、1対1のやり取りだけで済みますからね。最も難しいのは、『立場の違う複数のユーザーに使われるシステム』です。企業の業務システムの開発は、この3番目のケースに含まれます。

昔、先輩のSEから教わったのは、「要望の又聞きをするな」ということと、「ユーザーからの要望を聞く際、上司と部下は別々にヒヤリングせよ」ということでした。要するに、同じユーザー同士でも、全く違うことを言ってきたりするのですね。「ほんとはオレ、この機能なんか要らないけど、部長が必要だって言うからさあ…」などと。

大切なのは、ユーザー全員と開発者で、『開発のビジョン(方針)』をしっかりと共有することです。さもないと、プロジェクトメンバーのベクトルが揃わず、皆が勝手なことを言い始めます。まずは、『確固たる方針』を持つこと!

しかし困ったことに、最近の情報活用系システムは、より一層、開発が難しくなってきています。これまでの、集計作業の省力化を目的としたシステムとは違い、一体何を作ったらいいか誰も明確には語れないのです。不確かなユーザーからの要望を元に、具体的な設計へとまとめていく力。これは簡単に言えば、『発明家』の仕事ですね。プログラミング能力とは、あまり関係ありません。

例えば、「自動車はどうあるべきか」とゼロから考えて、『再発明』することが出来るか? タイヤは4本、ボディーは四角などと、既存の姿に囚われた発想ではなく、お手本のないモノを考え出す力が必要なのです。ユーザーのアイディアや思いつきを元に、それを全体的に統合してコンセプトを立てて、細部を決めていく力――難しいのですよ、本当の意味での設計は。 

私が当社のシステムを設計する際、考えるヒントにしたのは、「資本主義と社会主義の比較」でした。『情報』は、人に活用されて初めて『情報』となります。人間と経営のことを知らないと、情報活用系システムの設計は出来ないな、と痛感しました。それが、当コラムを書く一つのキッカケでもありました。

開発に慣れていない会社は、あまり欲張ったIT投資をしないほうが安全です。既存の安いITサービスを、いかに活用していくか考えた方がいいでしょう。しかし、複合的な業務システムを、どうしても開発しなければいけない場合は、『古タイヤのブランコ』が見えてくるまで、きちんと設計してからにすべきです。決して焦らずに。プログラミングに入るのは、それからです。

では、最後にお別れの一言。話し合いを重んじ、よりよいシステムの開発と活用を目指して頑張りましょう! ユーザーから望まれる必要にして十分なシステム、『古タイヤのブランコ』を目指しましょう! (完・合掌)

2004.11.11

鈴木正之助

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

スポンサード リンク


 

たまごや

週刊マナー美人

常識ぽてち

女性のためのクルマ読本

週刊節税美人

知って得する労働法

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

四柱推命による人生相談

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

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

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