森を見て木も見る

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

第22回

森を見て木も見る


マニュアル・ファースト開発(MF開発)を続けます。第3版では、いわゆる『操作マニュアル』のカタチにします。第2版では列挙していただけだった機能を、細部まで詳しくまとめます。書店のパソコン書籍コーナーで売られているような、操作を丁寧に解説したものが理想です。『絵が主、文が従』です。

まずは、『日報を入力する』などのタイトル。それに、初期状態の画面イメージがあり、入力する箇所とその入力例が書かれていて、実行されるとどのように変わるかを描きます。『(入力前)→(入力例)→(実行後)』です。横に別欄を設け、補足的な文章説明を加えるのがオススメです。

システムの規模によっては、かなりの厚さになります。ですが、「面倒だな〜」と言わずに、作業してほしいところです。『ソウ言イエバ式』の発見が沢山あります。見た目や操作性などの標準化が図れ、部品の共通化につながります。

設計中、類似した『パターン』と呼べるものに必ず出会います。例えば、実行ボタンの位置、画面からの問い合わせ要求を出した際の入力のさせ方、など。「前にも似たような絵を描いたな」と気付いたら、全てパターンに合わせて標準化します。見た目と操作性がそろっていると、ソフトは使いやすくなります。

部品の共通化に関しては、『類似した機能をいくつも作るのはやめよう』ということです。これは、WINDOWS上での操作を考えれば分かります。EXCELやWORDのメニューから、『保存』を選んでみて下さい。どちらも、『名前を付けて保存』が表示されます。ソフトは別でありながら、同じダイアログです。これは、『保存する』という機能を使いまわししているからです。

例えて言えば『外注』という考え方です。自分のメインではないが、必要不可欠な分野を、スペシャリストにお任せしてしまおうということです。会社の仕事で言えば、社員旅行の手配などですね。このケースでは、ファイルの保存に関することを、その道一筋のプロ『名前を付けて保存』に外注しているのです。

当社の例ですが、予算や日報の入力中に、その工事の請負金額などを知りたい時があります。その際、ボタン1つで『工事情報』が表示されれば便利ですが、工事情報に他の情報まで付随していると、使いまわしが難しくなります。

するとどうなるか? 各画面がどんどん肥大化していきます。「予算や日報の作業中にも、工事情報は見たい。ソレジャ、予算と日報の画面内にも、工事情報をつけてしまおう」。その結果、もしも工事情報に何らかの修正を加えなくてはいけなくなった時、多くの箇所を修正する羽目になります。

この保守における泥沼化を防ぐのが、機能別外注方式による設計です。再利用を考え、共通部品化を進めて保守コストを減らす。これを『オブジェクト指向』の考え方と言います。年に1回の社員旅行の為に、スペシャリストを会社で雇っていたら非効率ですよね。旅行代理店にお願いしてしまえば良いし、旅行代理店は色々な会社から仕事を受注すれば良い。それと同じです。

設計のコツは、小さくシンプルにすること。似たような機能はないか、使いまわし出来そうなところはないか、と考えることです。すると必ず気付きます。私はこれを、『ソウ言エバ式オブジェクト指向設計』と呼んでます。(注:完全なやり方ではありません。『指向』しているだけです。)

さて、第4版で全体検証をして設計は終わりです。これからいよいよプログラミングへと入りますが、ここでしっかり検証して下さい。問題の解決に本当に役立っているのか、設定したコンセプトがきちんと具体化されているのか?

私の経験では、設計書以上のものが出来上がることは、まずありません。プログラミングに入ってからも『ソウ言エバ式』の発見と改良は続きますが、それはあくまでも部分的なもの。ボトムアップ的な開発アプローチには、限界があります。目的をしっかり持ち、全体を見渡しつつ、各部分へと落とし込んでいく。『森を見て木も見る』ような心構えが、システム開発には必要なのです。

2003.04.05

鈴木正之助

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

スポンサード リンク


 

たまごや

週刊マナー美人

常識ぽてち

女性のためのクルマ読本

週刊節税美人

知って得する労働法

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

四柱推命による人生相談

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

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

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