方法論とは当然のことを整理して説明する方法

1992年頃，ある会社に勤めていたとき，
アメリカの本社で業務分析のツールがあった。


分析対象の業務の担当者を特定し，
各担当者に詳細な作業方法を聞いて，
ツールに入力するだけで、
業務フローが完成する。


業務全体で，帳票名や画面名（入力情報名と出力情報名）を統一する。


各担当者に業務処理の詳細を聞き，ツールに入力する。
作業開始の切っ掛け、
入力画面や帳票が誰から来るのか，
各項目に何を入力するのか，ない場合にはどうするのか，
作業終了で誰にどの結果を渡すのか，
など詳細に聞き取る必要がある。


全ての聞き取り・処理終了後，
入力された業務処理の情報をツールがつなげて，
業務フローが出来上がる。


これは、帳票名が統一されているので，
前の業務の出力が次の業務の入力として、
業務がつなっがていく。


ばらばらに入力した業務処理がプロセスとしてつながる。
非常に面白いツールであった。


アメリカでは新入社員がお客の業務を理解するためのツールとして使われていた。


全く業務を知らない新入社員でも，
お客から詳細に処理を聞き取り，
これをツールに入力するだけで、
連続した業務ふろーになる。


何にも知らない新入社員が業務プロセスを理解するためには，良いツールのようだ。


日本でも，
顧客の業務プロセス概要を確認し，
各作業担当者に聞きまわって，
業務フローを作り上げた。


分析プロジェクトのメンバーが終わったと言うので，
プロジェクト・ルームへ行くと，
業務フローが壁いっぱいの大きな紙に印刷されていた。


しかし，結果に問題があった。
このツールは業務フローを書くだけで，
ツールで作成した図は問題点，改善方法が判らなかった。
結果をどうお客へ説明すれば良いのか判らない。


一人のメンバーが，図のある部分を指して，
ここが花火のようなんですよね，
と言ったのが切っ掛けだった。


何故，図で花火のように見えるかというと，
ある業務に沢山の情報が集中しているのだ。
だから作業が複雑化していて、
作業としては単純化しての改善の可能性がある
と言う、当たり前の話だった。


これを切っ掛けに，6つほどの分析の方法を開発した。
業務フロー図を見て，
改善の可能性をピックアップする方法を開発し，
業務分析方法論として作り上げた。


方法論としてドキュメント化することは、かなり大変な作業だった。


花火のようだと言ったメンバーに方法論としてまとめさせ，
出来上がったドキュメントを何回もレビューし，
書き直しを指示し，
こうなるはずだとの意見も入れて，
方法論として完成させた。


米国ではツールを開発しただけではなく，
業務分析論があるんだ，
問題の可能性の抽出方法、改善の方法案は、
などと、顧客に説明して、受け入れられた。



業務分析と言っていながら、
業務フローを書き出すだけではダメで
問題点の指摘、改善案の例などを提示し、
改善後の業務プロセスを提示できないと
業務分析とは言えないだろう。



米国本社でも方法論として採用してもらおうと何回も説明に行ったが，
彼らのツール利用目的が違ったために，受け入れてもらえなかった。
これが残念だった。



方法論は当たり前のことを，
１つの手法としてまとめ上げることだと理解できた。


この仕事も楽しい一時期であった。


・作成：2011/5/10　更新：2011/5/26、2012/3/24 QuietWriteから移動