PFDとは — 開発現場の「よくある問題」を解決する、プロセス設計・改善のための図法
Q.PFD（Process Flow Diagram）プロセスフローダイアグラムとは何ですか？どんな場面で役立つのでしょうか？
A. PFDは、ソフトウェア開発をはじめとしたプロセス（作業の流れ）を成果物との関係とともに図示するための図法です。単なる可視化ツールではなく、プロセスを設計し、改善し続けるための実践的な手段として、特に品質要求の高い製造業・自動車業界の開発現場で広く活用されています。「なぜPFDが必要なのか」という背景から、その本質的な使い方までを本コラムで解説します。
目次
テスト工程になって誰も手を付けていなかった作業が突然発覚する。経験豊富な担当者の退職とともにノウハウが消える。進捗会議で原因不明の遅延が報告される。
こういった出来事に「うちの現場ではよくあること」と感じる方は多いと思います。しかし「よくあること」と諦めて放置するべきではありません。繰り返し同じ問題が起きているのであれば、それは個人の注意不足や運の問題ではなく、構造的な原因がある可能性が高いのです。そしてソフトウェアの規模と複雑さが増し続ける今、この構造的な問題を放置するコストはさらに大きくなっていきます。
作業の抜け漏れ、ノウハウの属人化、予想外の遅延——これらは性質の異なる別々の問題のように見えます。しかしよく考えると、どれも「開発の流れ全体が、チームの共有知識になっていない」という状態から生じています。
誰かが何をすべきかが暗黙のうちに決まっていたり、やり方が特定の人の経験に依存していたり、どの工程に問題があるかを外から観察できる仕組みがなかったり——。こうした状態が続く限り、問題はプロジェクトを変えても形を変えて再発します。
つまり、対処すべきは個々の問題ではなく、「開発プロセスが共有・可視化されていない」という根本原因です。
プロセスを可視化し共有することには、抜け漏れ防止や引き継ぎコストの削減など、すぐに実感できるメリットがあります。一方で、「可視化すること」をゴールにしてしまう、つまり「プロセス＝固定化するもの」と考えることは正しくありません。
現場でよく見られるのが、不具合が出るたびにチェックリストの項目を追加し続けるパターンです。本来ならプロセス自体を見直すべき場面でも、「チェックリストに追加する」というパッチ当てのような対処が繰り返され、実行負荷が高すぎるプロセスが出来上がっていきます。
また、「以前からやっていること」というだけで、なぜその作業が必要なのか誰も説明できなくなっている作業が残り続けることも珍しくありません。これはプロセスが可視化されていても、問い直されないまま固定化されてしまった結果です。
プロセスの可視化は、問題解決の「出発点」であって「終着点」ではありません。
プロセスを本当に価値あるものにするには、「今のやり方を整理して文書化する」だけでなく、それを分析し、問い直し、より良い形に改善し続けることが重要です。そしてこれは、ツールやAIには代替しにくい、人間が担うべき知的な仕事でもあります。
このとき、プロセスが可視化されているかどうかは決定的な差をもたらします。問題がどの工程で起きているか、原因はどこにあるかが特定できれば、根拠ある改善ができます。しかし可視化されていなければ、改善は感覚や経験則に頼らざるを得ず、再現性のない「なんとなくうまくいった」という結果にしかなりません。それでもうまくいくならまだ良いのですが、実際には「部分的には改善されたが全体的には改悪」、「負荷が増えただけで改善になってない」という結果になることが多いのです。
また特定の開発や技術環境において最善だったプロセスが、別のプロジェクトや技術の進化によって最善でなくなることは当然起こります。プロセスとは固定するものではなく、状況に合わせて設計し続けるものなのです。
プロセスの可視化、設計、改善において標準的に用いられる図法がPFD (Process Flow Diagram) です。PFDは「成果物」と「プロセス（作業）」を矢印で繋いでフロー図にしたものであり、「この作業には何のインプットが必要か」「この作業によって何が生み出されるか」を図として表現します。
登場する要素はシンプルで、大きく分けると「成果物（ドキュメントなど）」と「プロセス（作業）」の2種類だけです。成果物は成果物を示すオブジェクト（ドキュメントであれば書類型など）、プロセスは楕円形で表し、矢印でインプット・アウトプットの関係を繋いでいく——それがPFDの基本的な構造です。
例えば要件定義のプロセスであれば、「顧客要望書」や「テンプレート」といった成果物をインプットとして受け取り、「要求の抽出」「仕様のグループ化」「仕様化」といった複数のプロセスを経て、最終的に「要求仕様書」が完成する、という流れを一枚の図で表現できます。PFDを見たことがない人でも、図を眺めるだけで「誰が何をして、何ができあがるか」がおおよそ把握できるのがPFDの大きな特徴です。
ただし、シンプルに見えるPFDも、正しく書くためにはいくつかの簡単なルールと考え方を押さえる必要があります。成果物とプロセスの定義の仕方、粒度の揃え方、プロセス間の繋がりの表現など、書き方の詳細についてはEureka Boxで体系的に学ぶことができます。
AIがコードを書き、テストケースを自動で提案する——そんな時代がすでに始まっています。こうした変化の中で、「実装できる」「テストが書ける」というスキルだけでエンジニアとしての価値を維持することは、以前より難しくなっています。
一方で、「どのようなプロセスで開発を進めるべきか」を考え、設計し、継続的に改善できるエンジニアの価値は、AIの台頭によってむしろ高まっています。AIに任せる部分と人間が担う部分を判断し、全体の流れをデザインできる人材は、AIを活用すればするほど必要とされるからです。
プロセスとは、「縛られるもの」でも「守るもの」でもありません。うまく使いこなせば、開発の質とスピードを同時に上げる強力な手段になります。PFDはその入口に立つための、シンプルで実践的な道具です。
PFDの具体的な書き方や、開発のやり方を改善するための様々な上流工程の知識について、Eureka Boxでぜひ学んでみてください。
