いつまでたってもプロトタイプ

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

第5回

いつまでたってもプロトタイプ


前回は、ついついSEストレス嘆き節のような内容になってしまいました。ITボーゲニストの私も、日々、開発現場で格闘を続けている1人のSEでありますので、どうか大目に見てやって下さい。

『文章化がシステム開発の第一歩』と書きました。この文章化(図表も用いるとなお良い)という作業は、とても大切なものです。プロはいきなりプログラミングに入らず、まず設計書をきちんと書きます。ここは絶対に端折れません。もし、いきなり始めてしまうSEがいたら、その人は『なんちゃってSE』である可能性が高いです。

「でも、最近はプロトタイプ(試作品)を造って、さっさと開発するんでしょ。」

そうです。ですがはっきり言って、このプロトタイプ方式は曲者なのです。開発に使うツール(ACCESSなど)が進化したおかげ(せい?)で、行き当たりばったりな開発が増えてしまいました。プロトタイプでイメージを共有し完成品に結びつけるはずが、いつまでたってもプロトタイプのまんまという、泥沼のエンドレス開発を生み出しています。

プロトタイプ方式は、従来型のウォターフォール方式へのアンチテーゼとして現れました。約10年前までは、簡単に修正の出来る便利なツールなど無く、システム開発には長大な作業時間が必要でした。それは要求定義、設計、プログラミング、テストという流れであり、あたかも滝が上流から下流へ逆流することなく流れていくスタイルの開発でした。(ゆえにウォターフォール方式)

それはしかし――せっかく開発者に要望を伝えても、さんざん待たせた挙句、全く違うものが出来上がってくる――という不満をユーザーに抱かせます。ユーザーは、要求を出した翌日からでも使ってみたいのですね。設計の段階で要望事項を凍結し、それから数ヶ月も経ってからようやく出来ましたでは話しにならない訳です。開発者の誤解もあれば、ユーザーの心変わりもあります。

そこに登場したプロトタイプ方式。考えながら開発するスタイルに、時代は変わってしまったのでした。しかし皮肉なことに、修正作業量が増大してしまったのです。一言で言えばあきらめが悪くなった。ボールペンで書いていた手紙を、ワープロで書くようになったと思って下さい。

住宅建築で考えてみます。壁紙などは比較的簡単に変えることが出来ますね。しかし、柱や基礎の部分のやり直しは出来ません。システム開発でも、入力フォームの背景色などは簡単に修正出来ますが、基礎に当たるデータベース部分のやり直しは容易ではありません。うかつなプロトタイプ方式は、この基礎部分の修正ばっかりになってしまいます。

建築の場合は、柱や基礎が大切であることは誰にでも分かります(ド素人の私にも分かる)。しかし、システム開発作業は内容がなかなか見えずらい。どの部分が簡単で、どの部分が難しいのかの判断が、ユーザーには出来ない。その結果、あちらこちらで泥沼開発プロジェクトが散見されるようになりました。

『上流工程の1時間は下流工程の10時間』。新米だったころ、よく先輩から聞かされたものでした。要求定義や設計でヘマをすると、プログラミングやテストの段階で、10倍の時間をロスしてしまうということです。曰く金言。プロトタイプ方式は大規模開発(複数人が使用、複数業務が連携するようなシステム)には向きません。まずは文章および図表で、しっかりとした設計を!

プロトタイプ方式と同義語なのが、スパイラルアップという言葉です。修正を繰り返し施し、徐々に良くしていくスタイルです。泥沼化(スパイラルダウン)を防ぐ為、回数を事前にしっかりと決めてから行いましょう。人間、家を3回建てるとようやく理想の家が建つと言います。3回程度のスパイラルがお勧め、それで到達しない場合は技術面より構想に問題あり、と私は考えています。

2002.12.01

鈴木正之助

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

スポンサード リンク


 

たまごや

週刊マナー美人

常識ぽてち

女性のためのクルマ読本

週刊節税美人

知って得する労働法

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

四柱推命による人生相談

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

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

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