MF開発質疑応答

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

第24回

MF開発質疑応答


『無能なサル社員どもに設計書を回覧するなど、時間の無駄だ。MF開発は、たらい回しの遅速開発法だ!』(本能寺商会代表取締役/織田信長)

「リリースまでの時間を比べれば、『独裁開発』にかなうものはありません。しかし、後々まで活用されるシステムを目指すなら、社内の合意形成に時間を割くべきです。一般論ですが、実際にデータを入力するのは現場社員、社長はそれを見るだけです。暴君の依頼によって開発されたシステムが、現場の理解を得られず、埃をかぶってしまうことはよくあります。稼働は早いが使われないシステムにするのか、稼働は遅いが使われるシステムにするのか、です。」

『共通表記法のUMLを使わないのはなぜか?』(プログラマ/技術すぐる)

「エンドユーザーには通じないからです。ユーザーは設計書などに興味はなく、出来上がりと、その後の仕事のイメージにしか興味はないのです。共通表記法と言っても、日本人全員がUMLを理解出来る訳ではないので、リリース後の修正はなくならないと思います。ですが、ユースケース図とアクティビティ図については、簡単なので、ユーザーとの仕様確認に有効だと認識しています。」

『参加者が多すぎ、意見がまとまらないのでは?』(課長代理/立背奈伊蔵)

「その可能性はあります。しかし、理想的システムの構築には避けられないことであり、ユーザー代表とSEの腕の見せ所であると言えます。コツは、問題の症状に惑わされることなく、全社的な最適解を目指すこと。大切なのは、課題とコンセプトをメンバーにしっかりと説明し、理解を得ることです。私の経験から言えば、対立はむしろチャンスです。異論を解きほぐすと論点が明らかになります。以外と、深層部分ではつながっていることが多いのです。最も良くないのは、無理やりどちらかに決めつけることと、安易な折衷案です。」

『ドキュメントを作らないなど詭弁だ。実際には、何版もの外部設計書を作っているではないか!』(ITベンダー/マネージャー/弁賀達人)

「無駄なドキュメントをなくそう、と私は言っています。外部設計書と言いながら、開発者ライクで一部の人間にしか理解出来ない『一部設計書』を、まずはやめることです。それに意味のある設計書とは、『WHY』が分かるもののことです。『決断をした時の理由はなんだっけ?』と、後でトレース出来るものが欲しいのです。普通の設計書は、綺麗に完成させることへ重きを置きすぎ、『WHY』が見えなくなりがちです。マニュアルの版を全て保存しておけば、書き込みの文章から、決定までの経緯をトレース出来ます。マニュアルの過去の版は、優れた議事録でもあるのです。」

『MF開発は非常に素晴らしいメソッドだ。私はこの方法論を、世界中に広めなくてはならない。ついては、英語での翻訳出版の予定はあるか?』(シアトル在住日系3世/テクニカルライター/イチロー・ライト・スズキ)

「残念ながらありませんが、逆に私の方から、イチローさんにお願いしたいことがあります。最近知りましたが、『アジャイル・モデリング(AM)』と言う方法論があるそうです。MF開発と同じく、設計までをアジャイルに行うらしいのですが、その日本語訳を早く出版して欲しいのです。長年、ビジネス・ソフトを開発してきた方らしく、私と問題意識がよく似ています。マニュアルでやるかUMLでやるかの違いはありますが、とても興味があります。」

『あ、あの、オラ、はっきりいって、アホなんですけど。オラにわ、NFかいはつなんて、むりでしょか??』(記名なし)

「う〜ん、難しい質問です。私もよく馬鹿とは言われますが、一応、しょっぱい私立大学は出ていますからねえ。ですが、1つ言えることは、強い動機が最も重要だということです。人任せにせず、理想のシステムを作り上げたいという思い。これが大切です。密室で作られたシステムは、使い物になりません。意欲があれば、誰でも設計には参加出来ます。私に言えるのはそれだけです。」

2003.04.19

鈴木正之助

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

スポンサード リンク


 

たまごや

週刊マナー美人

常識ぽてち

女性のためのクルマ読本

週刊節税美人

知って得する労働法

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

四柱推命による人生相談

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

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

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