アジャイル・マニュアル

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

第20回

アジャイル・マニュアル


私がマニュアル・ファースト開発(MF開発)を提案する理由は、真の『ユーザー指向開発』を実現する為です(ユーザーの要望を全て聞くのではなく、ユーザーの抱える問題点を100%解決する開発)。

プロトタイプ成長型の開発は、ユーザーからの要望を把握しやすいと言われていますが、はっきり言って不十分です。なぜなら、当社のように20名以上のユーザーに使われるシステムはどうすればよいのか? 開発する私のパソコンの周りに皆を呼んで、説明、そして討論しながら改良を進めていくのか? 現実的ではありません。結局は、ユーザー代表の話しだけを聞くことになります。

その代表も、エンドユーザーと意見をすり合わせる術を持っていません。曖昧な口頭でのやりとりで、「こんな感じにするべ」としてるだけです。代表の声が、民意を反映したものになっていないのです。押し付けられたシステムには不満が溜まり、変更要求ひいては人間関係上の軋轢を生み出します。ユーザー代表と開発者が合意を図る以前に、ユーザー内部での合意が必要なのです。

多くのユーザーを抱える大企業の場合、ギャップが生まれるのは仕方のないことでしょう。しかし、当社のような30人程度の会社なら、どうにか出来るはずです。そこで、話しを分かりやすく視覚化してみせる『仮想マニュアル』の出番となるのです。誰もが理解できるマニュアル形式にしてしまえば、広く民の声を聞く、システム開発直接民主制が実現します。

マニュアルの作成は、はっきりいって大変です。しかし、それをするだけの価値はあります。また決して、「1回で完璧なマニュアルを完成させろ」と言うのではありません。マニュアルをアジャイルに成長させていきます。

アジャイル(AGILE)。最近のIT業界でよく使われます。『機敏な』という意味の言葉です。「開発に変更はつきもの。小さなリリースを何回も繰り返し、少しずつ育てるアジャイルな開発をしよう!」などと使います。この小さなリリースを、マニュアル作成(設計)の段階で十分に行い、プログラミング時の戻りを極力減らすのが、MF開発の考え方です。

それでは、やってみます。MF開発では、エンドユーザーまでをプロジェクトメンバーに含めて考えます。紙上で徹底的にユーザーからの意見をもらって混ぜ合わせ、それを知恵のレベルにまで高めていきます。車の開発で、何度も粘土模型を作った後、実車の製造へ入っていくイメージです。プログラマの登場はマニュアルを作った後、そこまではユーザーが主体です。

まずは、パンフレットを作ることから始めます。これは、以前行った分析の結果をまとめたものです。「集まった問題点とその要点、そして設定したコンセプト。システム化の対象業務はここで、会社の仕事はこれからこう変わる!」と明記します。MF開発は基本的に、ユーザー代表とSEが全ての書類を作ります。この2人が皆の気持ちをつかみ、作業を上手くリードしていきます。

そしていよいよマニュアルの作成。まずは、予算、日報などと、業務を分割します。マニュアルは、『業務手順の中に、ソフト操作が含まれている形式』とします。ソフト単独ではなく、業務プロセスの中で考えていく為です。A3用紙の左半分に書き、空白の右側はユーザーの自由記入欄にします。そこには、マニュアルを回覧した際、思いついたことを書き込んでいってもらいます。

マニュアルは何回も編集するので、手書きよりもパソコンで作るほうが良いでしょう。作業のコツは、横並びで少しずつ進めていくこと。業務を1本完全に仕上げてから回覧するのではなく、1本を少し作ったら回して反応を見るような、同時並行多発的に進めていきます。画面のデザインなどは、別の業務をまとめている最中に、前に作ったものを直したくなってくるものなのです。

回覧は大体4回です。1回目は業務手順をまとめた段階で。2回目は画面イメージをまとめ、必要な機能を列挙した段階で。3回目に操作の細部を全て記述し、4回目が全体検証された最終版となります。(アジャイルに次号へ続く)

2003.03.20

鈴木正之助

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

スポンサード リンク


 

たまごや

週刊マナー美人

常識ぽてち

女性のためのクルマ読本

週刊節税美人

知って得する労働法

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

四柱推命による人生相談

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

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

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