後ろから?前から?

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

第18回

後ろから?前から?


前回までは、分析の進め方を書きました。問題の本質を帰納法で特定し、その解決の為にコンセプトを立てました。ここからは演繹法を中心とした、段階的詳細化作業です。設計、プログラミング、テスト、と流れていきます。

さて、設計の方法ですが……。と、ここまで書いて、手が止まってしまいました。考えてみましたが、「設計とはこうあるべし!」と断言出来ないのです。困ってしまいました。ITボーゲニストの名折れです。

バックナンバー05に、ウォターフォール型と、プロトタイプ型開発について書きました。どちらも一長一短あります。最近はプロトタイプ型が優勢ですが、大規模開発は依然としてウォターフォール型が主流です。まあ、2、3日で終るようなもの、もしくは開発者が1人で使うソフトなどは、さっさとプログラミングに入るべきです。しかし、全社的業務システムになるとちょっと難しい。

ソフト工学の世界は秒進分歩で、まだ発展途上なのです。一体どこまでを設計と呼ぶのかも微妙です。プログラミング(コードを書くコーディング)作業も、設計と呼べるのではないか。コンセプト実現の姿が明確化するのは、打ち合わせにケリがついて、コードを書いたその瞬間になる訳ですからね。その段階までは、暗中模索してる状態、設計段階だと考えることも出来ます。

経験上、開発が終ると設計書は不要です。一応、保存しておきますが、見なくなってしまいます。仕様変更が当然のように発生するので、コードのほうだけ修正し、設計書はほったらかしなのが現実です。コードが最高の設計書とも言えます。私が他人の作ったソフトをメンテする場合、やはりコードを読みます。余分なドキュメントを書かない、持たない点が、プロトタイプ型の長所です。

しかし、いきなりプロトタイピングするのは、やはり怖い。プロトタイプにもユーザーはキチンとした処理を望んでいます。思いつきレベルの要求追加は日常茶飯事、それが翌日にはまた変わる。徐々にシステム全体の整合性が無くなっていき、トラブルが多発。泥沼化していって……。「ちゃんと設計してからやればよかったのに…」と言っても後の祭り。ああ、ホントに難しい。

早くイメージを見たいユーザーはプロトタイプ型を望み、整合性を重視する開発者はウォターフォール型を望む。両者お互いに納得し合える開発の進め方はないものか? 呻吟の末に、とうとうヒラメキました。『マニュアル・ファースト型』開発を提案します。

ソフトの操作マニュアルを設計書がわりに作っておき、プログラミングを後で行う方法です。こんなヘンなこと、多分、私しか言っていないでしょう。ITボーゲニストの面目躍如です。商品開発における『仮想カタログ法』と、最近のシステム開発で言われている『テスト・ファースト』をヒントにしています。

仮想カタログ法は、商品の姿形がない段階でカタログを作ってしまう方法です。技術設計はカタログが出来てから行います。クライスラー社が『ネオン』という車を作る時、採用したそうです。一方のテスト・ファーストは、事前にテストの設計を行い、自分がどんなプログラムを作るべきか熟慮の上、プログラミングに入る考え方です。

マニュアルの作成、テストともに、普通は後半の作業です。どちらかと言うと、鼻歌歌いながらやる作業ですね。この能天気後まわし作業を、最重要作業と位置付けて先に行う。冷静に考えてみると、かなりの利点があるんですよ。

ユーザーの持つ要望を、全て柔軟にプログラムへ反映させる。なおかつ、最小限度のドキュメントで、手戻りの少ない、整合性を保った安全な開発をする。これが目的です。マニュアルが早い段階で用意されていれば、ユーザーには強いイメージが湧いているはず。ワクワクドキドキしながらマイカーの納車を待つように、開発者のプログラミング作業に期待をすることになるでしょう。

「後ろから開発されるのって、なんだか、ドキドキしちゃう。」(次号は詳細)

2003.03.08

鈴木正之助

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

スポンサード リンク


 

たまごや

週刊マナー美人

常識ぽてち

女性のためのクルマ読本

週刊節税美人

知って得する労働法

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

四柱推命による人生相談

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

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

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