ソフトウェア開発におけるQCDを達成するために、それぞれのプロジェクトに合ったプロセスを定義して順守することは有効な手段と言えます。しかし、いざプロセスを定義しようとしても、何をどう決めて良いのか迷う事も多いのではないでしょうか。ここでは、シンプルで理解しやすいプロセスの表現方法として多くの企業で活用されているPFD（プロセス・フロー・ダイアグラム）を活用しつつ、効果的にプロセスを定義する方法について説明します。

PFDはDFD（データ・フロー・ダイアグラム）を改良したプロセスの表現方法であり、「プロセス」と「成果物」の連鎖を「フロー」でつないで表現します。3つの要素で構成され、手軽に作成できるため、最近では多くの企業で活用されています。プロセスには「プロセス定義書」、成果物には「成果物定義書」を作成し、曖昧さを取り除くことができます。

PFDを作ることにより、プロセスと成果物が明らかになることで、関係者間で開発の進め方について合意することができます。また、ムダなプロセスや作業範囲が見えるようになり、より良いプロセスを検討できるようになります。すなわち、開発の状況に合わせて、より良いプロセスに変化させていくことが可能になるのです。

しかし、ただPFDを書けば、開発の問題が解決されるわけではありません。PFDを書くことで、新たに発生する問題もあります。

実際の開発現場で、PFDを適用した際、問題になりがちなことをいくつか紹介します。

開発現場では、プロジェクトの要件が暗黙のまま進められていることが良くあります。PFDとプロジェクト要件の関係が希薄な状況ではPFDの正しさを確認することが難しくなります。例えば、開発期間が短いため、既存の成果物を極力使うようにする場合と、既存成果物の品質も向上することを目的とする場合では、プロセスは大きく異なります。

成果物の観点では、入力と出力の成果物は明確ですが、中間成果物は曖昧な状態のままプロセスを設計することがあります。このような状態でもPFDの正しさを確認することが難しくなります。

多くの開発現場では、これまでの経験を元にガントチャートが先に作られ、タスクと成果物の関係が後になってつながっていないことが判明して手戻りになることもあります。これはPFDとプロジェクト要件からスケジュールに落としていないことが問題です。

PFDだけでは、PFD内で表現した成果物間の関係がわからなかったり、成果物の要素間のトレーサビリティがわからないなどの問題があります。また、最終的に完成する仕様書の体系がわかりにくいといった問題もあります。

これらの問題を解決するには、プロセス・成果物を複数の視点（関心事）で定義し、正しさを確認する必要があります。そこで、「プロセス・アーキテクチャ」という考え方が役に立ちます。

「プロセス・アーキテクチャ」では、プロセス・成果物の関心事を５Wの観点で以下のように5つの成果物を定義します。そのうち、「プロセスの要件」は他の4つのすべてに関係することから、プロセス・アーキテクチャ「４＋１ビュー」となります。これにより、プロセスや計画の正しさが確認できるだけでなく、成果物間のトレーサビリティも確保できるようになります。

プロセスを定義する前に、まずは、プロジェクト自体の要件を明らかにする必要があります。これは、開発のすべての活動のゴールを決めるための要件になります。プロジェクト要件が明確になっていないと、プロセスが定義できないだけでなく、プロジェクトが本来目指すべき方向を見誤って、やり直しが必要になったり、プロジェクトが混乱してしまいます。プロジェクト要件の書き方は、特に決まりはありませんが、下図のようにリスト化するのが一般的です。USDMに精通していればUSDMで書くことで、より正確に記述できます。

このプロジェクトで何をするか"What"を定義する際に、プロセス側面で作成するのがPFD（プロセス・フロー・ダイアグラム）です。どのようなインプットに対して、何をして、その結果どんな成果物が作成されるのか、というつながりを明確にした図です。プロセスは階層表現が可能で、全体から詳細を表現できます。

プロジェクトで作成する成果物の論理的な単位、成果物の属性、成果物間の関係を記載するものが成果物関係図です。それぞれの成果物のつながりを関係として記載したもので、成果物のトレーサビリティが明らかになります。どの成果物が、他のどの成果物に影響を与えるのかを知ることができます。

成果物間の静的な関係を表現する図を使う事が一般的で、オブジェクト図やクラス図、ER図などで表現します。

作成する成果物が、公式ドキュメントとしてどこ"Where"に配置されるかを記載するのが公式ドキュメント配置図です。プロジェクトの要件において、必要とされる公式ドキュメントに対して、成果物を割り当てます。このプロジェクトが終了した後、成果物を保守していく上でも、この情報が役に立ちます。

包含関係を表現するために、パッケージ図を使い、成果物関係図で示した成果物が、公式ドキュメントを示すパッケージのどれに包含されるかを記載します。

PFDでプロセスを明らかにしたら、プロジェクトの要件とあわせて、具体的にプロジェクト計画を作ります。これで、実際にプロジェクトを進めるための具体的なプランができます。

プロジェクト計画は、日程とタスク、それを実施する人が明確になっていることが必要です。ガントチャートが一般的です。

プロセス・アーキテクチャを定義するためのPFDは以下のようになります。

既存のプロセスを見直したり、新たな開発のプロセスを明らかにするときは、プロセスの正しさ、成果物間の関係の正しさが作業効率や成果物品質を左右します。プロセス・アーキテクチャの考え方を身に付けてプロセスを自由にデザインし、効率的でムダのない開発プロセスを手に入れましょう。

既存のプロセスを調査し、As-Isプロセスを表現したPFDを作成します。別途、ヒアリングにより得られたTo-Beプロセスを表現したPFDを作成し、As-Isプロセスの課題とその解決方法を提示します。

プロセス・アーキテクチャを導入するための教育やサンプルづくり、レビュー等を組合せ、プロジェクトや組織にフィットするプロセスにしていくための支援をします。