読者です 読者をやめる 読者になる 読者になる

PFDによる開発プロセスのモデリング

 組み込みで認知が広がっている開発手法にXDDPというものがあります。このXDDPは色々示唆に富む手法で、実際XDDPを構成するプラクティスを活用してきました。その中で早期から気軽に使っているプラクティスにPFD(Process Flow Diagram)というものがあります。

 PFDはDFDをベースに作られたもので、主に開発プロセスモデリングに用います。
 記法が単純&明快なのと、後述しますがアクティビティ図やフローチャート等によるモデリングと比べて異なるメリットを持っているので、自分も色々な場面で活用しています。今回はそのPFDの概要を紹介したいと思います。

 なおPFD自体は提唱者による詳細な資料が既にウェブに公開されているので、詳細はそちらを読んで頂ければと思います。
http://homepage3.nifty.com/koha_hp/process/PFDform3.pdf


PFDとは

 PFDモデリングの基本ルールは簡単です。主に以下が基本ルールです。

  • 開発プロセス上の成果物(ドキュメントやソースコード、データ、情報等)を、四角や書類マークで囲って書く
  • 開発プロセス上のプロセス(作業)を、○で囲って書く
  • 矢印のフローで、成果物とプロセスをつなげる。

 具体的には以下のような感じになります。
f:id:goyoki:20120822023340j:plain
f:id:goyoki:20120822025613j:plain
f:id:goyoki:20120822025612j:plain

 プロセスが、成果物のインプットを受けて、成果物のアウトプットを出すという流れを図示したイメージです。フローは並列で書いても構いません。
 注意点として以下があります。

  • プロセスとプロセスを直接つなげてはいけない。成果物と成果物を直接つなげてもいけない。プロセスと成果物のつながりで表現する。
  • 作業や成果物の依存関係の明示化に努める
    • 条件分けは考えない。
    • スケジュールは考えない。実行順序もなるべく考えない

(他にも細かい記法やルールがありますが、それらについては前述の提唱者資料を見て頂ければと思います)

 なお気付いた方もいるかもしれませんが、前述の通りPFDはDFDのサブセットです。業務系開発ではDFDを業務フローの分析に使用することがありますが、PFDはそれにいくつかサブセットルールを加えて開発プロセスの分析に特化させたものになります。


PFDのメリット

 PFDは、順序や条件分けにこだわらず、成果物やプロセスの依存関係の明示にフォーカスすることから、一般的なフローチャートやアクティビティ図と異なったメリットを持ちます。いくつか紹介します。

本質的な依存関係の明示

 PFDはプロセスの本質的な依存関係が明示されます。
 例えばフローチャートではしばしば以下のような記述がされます。
f:id:goyoki:20120822025614j:plain
 しかしPFDで書くと、以下のように本来の成果物や作業の依存関係を細かく明示できることがあります。
f:id:goyoki:20120822025615j:plain

 こうした特徴は次のようなメリットを生みだします。


並列化可能なフローが割り出される。

 本来の依存関係を明示することで、並列実施な作業が割り出せることがあります。例えば上図では「じゃがいもを切る」「スープを作る」「にんじんを加工して炒める」といった作業が並列可能なことが一目瞭然になります。
 これにより、担当分けや納期短縮の検討を進められることがあります。


クリティカルパスが明確になる。

 また並列化可能なフローが割り出されることで、クリティカルパスが分かりやすくなります。
 例えば上図で各プロセスの必要工数を明確にすることで、「にんじんを加工して炒めるのが一番工数が必要」といったことを評価可能になります。


成果物が明快になる

 PFDではプロセスのインプットとアウトプットが「成果物」という形で具体的に明示されます。これはPFDを手軽にするのに役立っていますが、それ以外にも以下のようなメリットも生み出しています。


依存する成果物を把握しやすくなる

 PFDではインプット・アウトプットの成果物を明確化することで、作業が何に依存しているかを簡単に把握可能になります。
 例えば以下のフローチャートで作業「C」を行いたい場合、前段階「A」「B」その他前工程すべてのタスクが全て完了しないと作業「C」を進められないような印象を持ちます。
f:id:goyoki:20120822025616j:plain

 しかし以下のようにPFDで書くと、最低限「1」「2」「3」がそろえば、全段階の状況がどうなっているのであれ、作業「3」を進められることが把握可能になります。
f:id:goyoki:20120822025617j:plain

 また後工程についてもモデリングすれば、作業「C」の結果、最低限何を更新しなければいけないかも明示されます。


進捗状況を明示しやすい

 PFDでは、作業の進行は「フレームワークの調査を行った」「設計仕様を考えた」といった作業の終了でなく、「調査レポート」「設計仕様書」といった具体的な成果物の作成有無で判断されます。これは作業がどの段階まで進んだか細かく把握するのに有効です。


ズームイン・ズームアウトが容易

 またPFDはDFDと同じく、柔軟なズームイン・ズームアウトの分析がやりやすくなっています。
 例えば以下のような開発プロセスを考えます。
f:id:goyoki:20120822025618j:plain

 PFDでは、ズームインしてそれぞれのプロセスの詳細なPFDを簡単に書けるようになっています。
f:id:goyoki:20120822025619j:plain

 これにより、開発プロセス全体から細部の作業フローまで、様々な場面でPFDのメリットを活かせるようになります。


PFDの用途

 PFDは、本家の提唱する開発プロセスの設計やテーラリング、管理で使われます。またその他、既存の開発プロセスのリバースモデリングによる分析も一般的な用途です。
 自分も計画づくりでのスケジューリング前の分析や、新しい環境に入った際のプロセスの明示化、プロセス改善のツールとして活用しています。
 単純明快で効果もあるので、フローチャート等による分析に加えて、とりあえず使ってみるのも良いと思います。