プロセスを表現して、問題の構造を見抜く

こんにちは、プロセスデザインエージェントの芝本秀徳です。

前回は、「HOW」ばかり考えていては、問題の真因を解決することはできないということ、そして、真因をあぶり出すためには「プロセス」を知ることが有効だというお話をしました。

問題の真因を理解するためには、「問題がどのような構造で発生しているのか」を知らなければなりません。そのうえで、「問題そのものが発生しないように、どうするのか」を考えなければならないのです。現象を抑え込むのではなく、問題を生み出す原因そのものに働きかけることが大切です。そのためには「プロセスを表現する」ことが必要になります。つまり、プロセスを「見える化」するのです。

なぜ、プロセスを表現する必要があるのか。それは、表現されていないものは変えようがないからです。問題を解決しようとして陥りがちな間違いは、現状がどうなっているのかがあいまいなまま、「空中戦」でなんとかしようとすることです。これは、家の図面なしに、リフォームするようなもので、いびつな家ができてしまいます。問題個所を特定し、変えるためには、まず現状のプロセスを「目に見える」カタチに表現しなければなりません。

そのプロセスを表現するための方法の一つとして「プロセスフローダイアグラム（PFD）」があります。この表現技法は、（株）システムクリエイツの清水吉男氏が、成果物とプロセスを表現する技法として、構造化設計手法のDFD（データフローダイアグラム）をヒントに開発されたものです。

下の図は「要件定義プロセス」を例に描いたプロセスフローです。

表記方法は、誰にでも理解できるものです。サークルはプロセスを、フォルダは成果物を表しています。表記方法にはある程度の自由度があり、ここでは雲として表現している「ノウハウ」などの無形成果物は、その性質にふさわしい表現を使うことが認められています。

PFDはソフトウェアプロセスのために開発されたものですが、ソフトウェアにかぎらず、すべてのビジネスプロセスで有効です。私のコンサルティングでは、ビジネスプロセスでも使えるよう、少しカスタマイズして活用しています。

PFDは、プロジェクトのライフサイクルを「プロセス」と「成果物の入力と出力」で繋いで表現する技法です。プロジェクトの手順を表現する方法として「ワークブレークダウンストラクチャー（WBS）」がありますが、WBSはワークパッケージと成果物の関連と、実施の順番を考慮しますが、成果物の入力／出力は考慮されていません。PFDはこの点を補ってくれます。

プロセスフローダイアグラムを作成するときのポイントは、
・プロセスは「◯○を△△する」という「名詞＋他動詞」で表現する
・プロセスには必ずインプット成果物、アウトプット成果物を伴わせる
・最終成果物から逆算する
の３つです。

実際に描いてみるとわかりますが、簡単そうに見えて、かなりの思考力を必要とします。セミナーなどで、参加者に描いていただくときも、ほとんどの方が苦労されます。それは、日ごろの仕事を「プロセス」の視点で見たことがないからです。何をインプットとして、何をアウトプットしているのか、あいまいなまま仕事をしているのです。プロセスフローを描くことで、仕事の仕方を見直さざるを得なくなります。

問題が発生したときは、どのプロセスで「現象」が発生し、その問題がどのように発生していったのかが、プロセスをたどることでわかります。レビューをしていなかったのなら、それが計画プロセスや、見積もりプロセスなど、上流ですでに問題が発生していたことがわかるのです。

仕事やプロジェクトを、プロセスの視点で見直すことで、「問題の構造」が見えてきます。目の前の現象にとらわれるのではなく、構造に働きかけることが可能になります。