.NETで作る!

.NETに関するあれこれ(C#、VB.NET)

業務設計入門

前置き

最近、久しぶりに上流工程(業務設計)を担当することがあり、今後はそちら方面の仕事が増えそうでしたので一度自分における「業務設計」というものを振り返ってみたいと思います。

今回はプログラミングについての話題はありませんのでご了承ください。 なお、業務設計とは上流工程の一種であり、現状業務の分析、業務改善の提案、新業務の設計を指すものだとします。

下流工程と業務設計

下流工程(詳細設計やプログラム)の場合、事前ないし事後に技術的な課題が判明しており、それをいかに解決するかというスキルが求めらます。課題は普遍的なものが多く、ネットを漁れば類似する課題に直面している人が見つかったり、解決するためのヒント、場合によっては回答そのものが見つかることも少なくないです。

一方、業務設計の場合、そもそも「今何をやっているのか?」、「何が課題なのか?」という点から始まるので、いかにユーザーの真意を読み解くかというスキルが求められます。課題は特徴的なものが多く、「ネットに聞くんじゃなくて本人に聞け」というものが多いです。で、本人に聞く訳ですが、相手は人間ですから思い込みであったり、矛盾していたり、漏れがあったりと、下流工程とは全く違うアプローチで解決しなければなりません。

業務設計に求められるスキル

結論から言えば、

  • 現業務の理解と課題の提示
  • 新業務の提示

を行う資料作成スキルが必要です。*1

資料作成スキル

どういう資料が作れるかということになりますが、先人たちがいろいろと図の表記法を発明してくれているのでそれに倣うのがよいです。以下に表記法と欠点を紹介します。

フローチャート

フローチャート - Wikipedia

書式は言うまでもありませんね。

この書式では業務手順は理解できますが、細かすぎて全体が見えません。 というより、業務相関を示すための資料ではないので不適切です。

アクティビティ図

アクティビティ図 - Wikipedia

UMLの一種。フローチャートパーティション(スイムレーン)を付けることで作業者の相関や、時系列の送還を示せるようになっています。

フローチャートよりは業務理解しやすいですが、粒度はフローチャートと同じなので細かすぎです。 初期の時点でこれを行うと、枝葉末節にとらわれる可能性があり適切とは言い難いです。 初期はもっと大きな粒度(手順ではなく業務)でやりましょう。

DFD(データフローダイアグラム)

データフロー図 - Wikipedia

Wikipediaの表記を引用してはみましたが、私的には渡辺幸三氏が提案するDFDの表記が好みです。有用だと思うのですがネットに表記法が載っていないのが残念。表記法が載っている本はありますのでご紹介。

 

私は10年近く上記の書式を使用して業務設計しておりますので、実戦に耐えうる書式であると思っています。

ですが、上記書式で業務設計はできるのは間違いないのですが、課題分析であったり、漏れの確認、業務改善をすることにはあまり適していない気がします。*2*3

お待たせしました。次が私の中の本命です。

物と情報の流れ図(バリューストリームマップ、VSM)

www.itmedia.co.jp

バリューストリームマップで検索すると「DevOps」の記事がヒットしたりしますが、もともとは上記サイトにあるとおり、

もともとはトヨタ生産方式における手法 (中略) バリューストリーム・マップを作成することによって、諸工程の中で顧客に対する付加価値を生み出している活動とそうでない活動が顕在化されるので、非付加価値活動に潜むムダを排除し、リードタイム短縮や中間在庫削減を目指す。

であり、DevOpsの用語ではなく、現状課題把握、業務改善に用いられる図式です。まさに業務設計にぴったりの図式ですね。

さっそく書式を…と行きたいところですが、私も独学で学んで使い始めたばかりなので人に語れるようなことはありません^^;  よって今回は書式の紹介というところで終わらせていただきたいと思います。

後日どうやって学んでどこに躓いたかなどの体験記を書く予定です。

*1:対人スキルも必要ですが、ヒアリングする内容の方向性(資料を作成するための情報収集)が間違っていなければどのようなアプローチでも構わないと思いますので省略します。

*2:図式の力ではなく、設計者の業務設計力に依るところが多い気がします。業務設計百戦錬磨ならこれでいけるとは思います。

*3:後述するVSMと似ています。大きな違いはモノと情報の流れを区別して表記するかどうかぐらい?

. .