プログラマの思索

PFD(プロセスフローダイアグラム)についてメモ。

【元ネタ】
オブログ ? アクティビティ図で描くプロセスフロー

PFDによる開発プロセスのモデリング - 千里霧中

PFDの書き方(PDF)

Twitter / akipii: 後で見る RT @hiranabe: "アクティビティ図で書くプロセスフローダイアグラム" http://objectclub.tumblr.com/post/77009751972 …

開発プロセスを設計するという発想: プログラマの思索

【1】PFDが必要な背景

開発プロジェクトを受注して、プロジェクトマネージャがこれから計画を立てようとした時、普通は、MSProjectやExcelを前にして、手が止まってしまう場合がある。
どんな作業が必要なのか、それらの作業全てをすぐに思い浮かべられない時がある。

いわゆるWBS作成作業が必要になってくるが、その洗い出しはかなりあいまい。
そんなあいまいなWBSから詳細見積して、実際に開発してみたら、当初の計画とはかなり違っていた、という話はよく聞く。

そんな問題の背景には、PM・PLクラスの人達が開発プロセスを設計するという意識が薄いのが原因の一つではないか。
WF型開発で開発するといっても、各プロジェクトの成果物もプロセスも、どれも微妙に違うのが普通。
そのわずかな違いを意識せずに、標準プロセスをプロジェクトにそのまま当てはめると、痛い目にあう。

【2】PFDとは

XDDPという派生開発プロセスを提唱している清水吉男さんは、PFDというダイアグラムについて語っている。
PFDは、開発プロセスのDFD(データフローダイアグラム)みたいなもの。
つまり、開発プロジェクトのプロセスと成果物を図式化したもの。

PFDが書けるということは、開発プロジェクトに必要なプロセス(作業)と成果物の全貌が見えていることと同じ。
つまり、PFDを書くことによって、開発プロセスを設計していることになる。

例えば、PFDでプロセスと成果物が結ばれていなければ、それらは必要でないなら除去できるし、逆に見落としているプロセスや成果物を見つけ出すこともできる。
つまり、WBSの漏れをチェックする作業にPFDが使える。

【3】PFDの面白い点

PFDで面白いのは、インプットとなる情報には、要件定義所や設計書などのドキュメント以外に、「○○さんの知識」「○○さんの経験」のような暗黙知となる情報も記載できる点だ。
例えば、リプレース案件において、従来のシステムに熟知した人がいたとすれば、その人の暗黙知を元に、リバースエンジニアリングする作業もあるだろう。

あるいは、要件定義において、顧客からヒヤリングしながら要件をまとめる場合、顧客のヒヤリングが要件定義プロセスのインプットになるだろう。

すなわち、インプットとなる情報は、設計書のように目に見えるモノだけでなく、特定の人の知識・経験・ノウハウという暗黙知も含まれている場合があるのだ。
そういうプロセスは、アウトプットを作るために必要な情報を引き出すのが難しいだろうから、リスクがあり、何らかのリスク対策も必要であると、事前に考えることもできる。

他に注意すべき点は、プロセスが見積可能であること。
例えば「調査する」というプロセスでは、調査対象が未知で不明な場合、あいまいなプロセスになってしまい、見積りしづらく、プロジェクト実施後に大きく工数が狂う危険がある。
その場合、調査項目を抽出するプロセスと調査するプロセスに分けることで、調査項目のボリュームによって調査プロセスの工数を見積しやすくなる。

あるいは、プロセスがループするような図は要注意。
例えば、テストしてバグ修正して、さらにテストするような流れの場合、ループした図を書いてしまいがち。
しかし、実際はテストのプロセスは、バグ発見のプロセスとバグ修正の検証プロセスでは、作業量も作業内容も違う。
ループするプロセスを含むPFDを書いてしまう人は、プロセス設計の細部が見えてない場合が多い。

清水吉男さんが書かれた下記のPDF資料を参考にすると良い。

PFDの書き方(PDF)

【3】PFDの書き方

PFDはDFDみたいなものなので、Excel、PowerPoint、Visioなどで書くことができる。
Enterprise ArchitectでPFDを書くこともできる。

Enterprise Architect：プロセスフロー図(PFD)作成アドインについて

興味深いのは、オブログ ? アクティビティ図で描くプロセスフローにあるように、アクティビティ図でPFDを代用することだ。
そうすれば、UMLの一種として書けるから、astahのようなツールで簡単に書くこともできる。

【4】PFDの意義

PFDが明確に指摘することは、開発プロセスは設計すべき対象であり、各プロジェクトの現状に合うように柔軟であるべきことだ。

日本のSIが持つ標準プロセスは、WF型開発を基本としていて、業務標準化の名のもとに、「プロセスが固定」されている。
マーケットの変化によって、製品開発の内容が変わってしまえば、標準プロセスを一斉に適用するのはすごくリスクがある。

「組織パターン」にあるように、変化の速いマーケットに対応できるように、並行開発やインクリメンタルな開発に対応している組織は、標準プロセスの例外に位置しており、その乖離をプロジェクトマネージャ自身も知っている。
なのに、プロジェクトマネージャは相変わらず、WF型開発に基づいた標準プロセスに合わせて、標準プロセスの範疇にあるように見せたがっている。
自分のプロジェクトは会社標準に従っている、と見せたいのだ。

PFDを使うことで、開発プロジェクトの特徴に合わせて、自由に開発プロセスを設計できるようになれば、WBSに落とし込んで見積しやすくなるだけでない。
プロジェクト後半に、進捗遅延の状況でリカバリー対策を立てる必要がある時、PFDを書いて、開発プロセスを再設計することもできる。
例えば、納期に間に合わせるならば、どのプロセスや成果物を省いたらよいか、どのプロセスを並行に作業させて納期を縮めるか、という発想をPFDが支援することもできる。

色々試してみる。