内部の話し

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

第23回

内部の話し


マニュアル・ファースト開発(MF開発)も、いよいよプログラミングです。前回まで作った仮想操作マニュアル。ソフト開発の教科書的な呼び方をすれば、『外部設計書』と言います。『開発者以外の外部の人間にも理解できるもの』だからです。通常は、ここから内部設計が始まります。開発者以外には理解できない『内部設計書』を作ります。

まず、外部、内部と区別した言い方が、非常にイヤですね。開発作業を行うSEとプログラマは『内部』で、実際に出来上がったシステムを使うユーザーは『外部』なのです。この排他的感覚が、非常に良くないような気がします。

外部設計書とは『WHAT(何を開発)』についてまとめたもののはず。内部設計書は『HOW(どう開発)』についてまとめたもの。それぞれ、『WHAT設計書』、『HOW設計書』と言い換えたほうがピンと来るのでは、と思います。ついでに言えば、パンフレットは『WHY(なぜ開発)』が重要です。

さて、いざプログラミングです。が、その前に、1つやることがあります。せっかく作った『WHAT設計書』ですが、残念ながら、十分ではありません。それは、『エラー対応』が抜け落ちているからです。マニュアルには、『こうしたら、こう動く』とは書かれていますが、間違った操作の防止策を書いていません。その点を、ユーザーとSEが協議して決める必要があります。

『数量×単価=金額』であること、等々、業務によって色々あります。エラーチェックだけでかなりの量になりますが、マニュアルの余白へ書き込んでいって下さい。間違ったデータがデータベースへ格納されてしまう前に、つまりは、入力時点でキチンとはじいてしまうことです。腐ったミカンを、箱の内部へ入れてしまってはダメです。

まあ、このような点が、ユーザーからは想像しにくいところなんだと思います。だから、『内部設計』なんて言ってしまうんでしょうね。実際にプログラミングへ入る前は、データベース設計などの準備作業が、かなりあります。やはりここから先は、『餅は餅屋』へ任せることになるでしょう。プログラムをカリカリと書いて、それをチェックして。そして、いよいよテストです。

このMF開発の利点は、無駄なドキュメントが殆んど出ないことです。マニュアル上には、テストケース(画面の絵)が既にあります。その通りにテストを進め、テスト時の画面のキャプチャを、マニュアルの絵と差し替えていきます。テストの終了と同時に、操作マニュアルも完成してしまうのです! 

当然、エラーチェックなどの基本的テストは、正確に行われている必要があります。しかし、プログラマからはなかなかイメージしにくい、重要機能のテストについては、あらかじめ設計されている訳です。その部分を通したら、証拠として画面の絵を貼り付ける。管理する上でも非常に便利です。マニュアルは、A3用紙の右余白を切れば完成です。まさに一石二鳥。

それと、丁寧な内部設計書は書きません。開発者同士が分かれば、メモで十分です。『どう開発するか』の内部設計書は、システム内部にある情報、『どう開発したか』を見れば分かります。最近は、便利なドキュメント作成ツールもあります(内部情報から出力されるので内部設計書なんですね)。最低限の約束事(コーディング規約など)を、キチンと文書化しておけば十分でしょう。

さらにもっと有難い点は、システムの導入が楽になることです。ユーザーへの操作説明は、半分、終っているようなもの。既にマニュアルを読み、その設計にも、一部、関わっていた人達ですから。イメージは十分過ぎるほどあります。

以上、前半は難儀でも、後半に楽が待っているMF開発。いかがでしたか? メンバー同士の合意形成を重んじた、プロジェクトの進め方です。もう内部も外部もありません。ユーザー代表もエンドユーザーも、SEもプログラマも、皆が1つです。サイコーです。まあ、あまり良いことばかり書くと眉唾的印象を持たれてしまいますので、次回は危惧される点などについても書く予定です。

2003.04.12

鈴木正之助

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

スポンサード リンク


 

たまごや

週刊マナー美人

常識ぽてち

女性のためのクルマ読本

週刊節税美人

知って得する労働法

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

四柱推命による人生相談

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

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

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