続マジカのひみつ

マジカを使って若手に実験。なかなか興味深い結果が得られた。前回のマジカのひみつはここ。

実験対象
　　　入社2-4年の若手社員（♂3人）
　　　SEとして分析・設計をやるかたわら、テスターとして試験もやってる
　　　java読み書きはできるが、プログラマではない
　　　予備知識なし (゜Д゜)ハァ? まじかァ? という連中

実験1：マジカなし

マジカの説明なし。ある企業の業務フローをポンと渡し、「明日このヒアリングを顧客とする、という状況で、疑問・質問・ツッコミをピックアップしてね、15分でね」

実験2：マジカ使う

マジカの説明をする。「カード洗い出し→カード並べ」に特化してザクっと解説した後、マジカを使って業務フローからの質問をもう一度考えてね

対象となった業務フローはセミナーでもらったもの。どこの企業にもある「与信業務」「受注業務」に限定して分析を行う。

マジカなしの場合、出てくる質問はさもありなんなものばかりだった。つまり、誰でも思いつく質問だし、回答する方もそれなりな準備がされているものばかり。

• 手続きのフォーマットはありますか?
• 与信の基準となるものはありますか?
• どんな媒体（電話?メール?FAX?）で行っていますか
• 1日に何回の受注業務がありますか?
• 受注業務で作成する帳票のフォーマットを教えてください

マジカを使った場合、ヤバそうな質問が頻出。ヤバそうな質問とは「分析フェーズでスルーされ易く、設計もスルーされ、実装フェーズで露見する仕様の切れ目」のこと。

• 受注の前に営業から「提案」を行っているのでは? その情報を引き継いだり管理したりする業務があるのでは?
• 発注→受注の順番を明確化したい。発注書、請け書が書かれるタイミングは?
• 在庫が無い、納期まで短すぎるなど、発注を請けられない場合があるはず。しかし、そのフローが書いてない
• 受注する人と出荷指示する人は、同じ人なのか? 違うのであれば情報を渡すタイミングと内容を教えて欲しい

あらふしぎ、見違えるほど良い質問になった。ま、かなり誘導可視的なアプローチだけれど、マジカでやりたかったことは彼らに伝わったと思う。

フロー間に埋もれたやるべき作業、誰もトリガーを引いていないのに回りだす仕事、同一人物が担当しているため「見えない」ものとなっている共有情報は、ずっと後になって「気づく」ハメになる。気づいた人がプログラマなら設計バグ化になり易いし、お客さんが気づいたならコンサルの不備とみなされるだろう。

マジカの良さは、お客さんをまきこんで、かつ、システマティックに業務分析できるため、ベテラン／新人のバラツキを減らすことができるところ。さらに、分析する側だけでなく、お客さんの「質問に答えるための気づき」も引き出すことができる。お客さん自身の「気づき」を分析フェーズでできるのは大きい。このありがたみ、酷い目に遭った人なら分かるでショ。