PFD(プロセスフローダイアグラム)で開発プロセスを設計する
PFD(プロセスフローダイアグラム)についてメモ。
【元ネタ】
オブログ ? アクティビティ図で描くプロセスフロー
【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資料を参考にすると良い。
【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が支援することもできる。
色々試してみる。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「ソフトウェア工学」カテゴリの記事
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- 「ゲームをテストする バグのないゲームを支える知識と手法」の感想(2023.06.10)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
「astahによるUMLモデリング」カテゴリの記事
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
- 統計学の考え方をastahでまとめた(2023.05.28)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- 第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方(2023.05.13)
- 令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた(2023.04.15)
コメント