こんにちは、SWETの伊藤(@akito0107)です。

SWETが所属する品質管理部では開発プロセスや検証プロセスなどの業務をProcess Flow Diagram（PFD）を使って可視化し、チーム全体の認識合わせや業務効率化に活用しています。

この記事ではPFDそのものやPFDを用いた業務可視化の実例を紹介します。その後、SWETで開発しているPFDを記述するためのツール、PFD Draw Toolを紹介します。

PFD（Process Flow Diagram）とは

PFDとは清水吉男氏がDFD（Data Flow Diagram）を基にして、人が行う作業に使えるようにアレンジしたものです[1]。

PFDでは開発プロセスや検証プロセスなどの業務プロセスを、成果物とプロセス（1つ以上の成果物を受け取って異なる成果物へ変換する操作）に注目して可視化します。

ここでは具体例を用いつつ、PFDの書き方と構成要素について説明をします。

注：ここからの説明は、DeNAの品質管理部で用いているPFDの説明になります。オリジナルのものとは一部表現が異なっています。

下にソフトウェア開発のプロセスの例をPFDで記述しました[2]。このPFDでは、初期成果物の要求（=ソフトウェアで実現したいこと）から始まり、仕様策定、設計、実装を経て最終成果物のソフトウェアまで至る様子が表現されています。

図1: 開発プロセスのPFDの例

PFDの構成要素の説明をします。図1を見て分かるとおり、PFDには次の4つの構成要素があります。

要素	画像	説明
成果物	成果物	プロセスの入力または出力となる具体的なものを表し、四角で示します。成果物ごとに一意のIDが付与されます。
プロセス	プロセス	入力を出力に変換する作業または操作を表し、丸で示します。作業は手動で行われることもあるし、自動で実行されることもあります。プロセスごとに一意のIDが付与されます。入出力がないプロセスは存在しません。
矢印	矢印	成果物とプロセスの依存関係を表現します。
点線矢印	点線矢印	初回の実行では入力がないことを示し、成果物からプロセスに向けて使用されます。

PFDでは成果物やプロセスの依存関係を矢印で表現します。たとえば、図1のP3はA2、A3に依存していますし、A3はP2に依存しています。これはP3を開始するためにはA2、A3の成果物が揃っていることが前提条件となることを表しています。

また、品質管理部では、メインとなる図に加え、成果物・プロセスそれぞれに要素表を用意しています[3]。要素表とはPFDに書き切れない詳細な説明を記載する表で、たとえば図1のPFDに対応する成果物の要素表は下のようになります。

ID	名前	概要
A1	要求	PRDとして企画側から提供されるもの
A2	仕様	画面の動作イメージおよび制約事項などが記載されているドキュメント
A3	設計ドキュメント	API定義、シーケンス図、状態遷移図、DB設計を含んだドキュメント
A4	ソフトウェア	ビルド済みで実行可能な状態のソフトウェア。スモークテストを完了させておく。
A5	実装中に見つかった設計のミス	実装の過程で見つかった設計のミスもしくは改善点。ドキュメントに反映させ、その後実装を修正する。

成果物の定義を詳細に書き下すことにより、成果物についての認識のずれが発生していないかを確かめることができます。たとえば、A3はAPI定義、シーケンス図、状態遷移図、DB設計を含んだドキュメント と定義しています。今回は例示のため簡単に書いていますが、定義や成果物の完了条件などをあらかじめ明確にして作業者間で認識をそろえておくことにより、いざ実際に開発を進めた際にドキュメントの作成漏れや作業の漏れを防ぐことができます（なお、プロセスについても同様に要素表を作成します）。

より詳細なPFDの記述方法に興味がある方は[¹]等を参照してください。

PFDのメリット

さて、PFDの大まかなルールと記法がわかったところで、PFDのメリットを考えてみましょう。

業務プロセスを可視化すること自体の有用性はさまざまな場所で語られていますが、改めて整理します。特に次の2つが挙げられます。

業務の流れを誰でも把握できるようにする。
業務改善の土台になる。

たとえば、1については新任者がチームに入ってきたときの立ち上がりや、チーム内で認識を揃えるのに必要な要素です。 2について、それぞれの作業がどう繋がってるのかを観察することにより、業務の冗長性を排除したり、品質に問題がある作業をあぶり出して改善作業を行うことができます。

業務プロセスの可視化は、PFD以外にフローチャートやバリューストリームマッピングなど、さまざまな手法が存在しています。それらに比べると、PFDは成果物に注目する、という特徴があります。

たとえばフローチャートでは業務の手続きに注目し、それらのアウトプットである「成果物」は省略して記述されます。上の図1をフローチャートで書くと次のようになります。

PFDで書く場合に比べ、簡潔に記述できてはいますが、作業の順番は理解できてもそれらの関連性についての情報は希薄になっています。

いざ実行してみると、作業のゴールイメージがずれていたり、成果物不足で作業同士がつながらなかったりといったことがよくあります。プログラマーの方でしたらプロセスの『型』を明記する、といった方が伝わりやすいかもしれませんが、 PFDではプロセスだけではなく成果物に注目することにより作業の目的とそれらの関係をより明確にでき、プロセスの実行時の不確実性の排除やチーム内外との認識齟齬を防ぐのに役立ちます。

PFDのSWETでの活用方法

PFDの一般的な説明をしたところで、SWETで活用しているPFDの具体例をいくつか紹介しようと思います。

例1: レビュープロセス

SWETの業務として、プロダクトコードのレビューがあります。ここでのコードレビューの目的は、不具合の可能性を早期に発見するということももちろんあるのですが、 SWETメンバーのテストや対象のプログラミング言語についてのノウハウをレビューを通じて、実装者（レビュイー）に対して伝達することにあります。

SWETで行われるレビューのプロセスは次のようになります。

図2: レビュープロセスのPFD

ここで注目するのは、成果物としてA4, A5のノウハウといった不定形のものや人間の脳内にしかないものを扱っているという点です。「成果物」と書くとドキュメントやソースコードなど、具体的なものをイメージしがちですが、PFDではこのような抽象的な対象についても扱うことを許容しています。

例2: 外部勉強会の運営プロセス

それではさらに複雑な例を見てみましょう。 SWETではTest Nightなど、外部の方々を招いた勉強会を主催しています。その際の開催や運営のプロセスを可視化したものになります。実際のものからはかなり省略・簡略化したものになりますが、関係各所との調整や、何をどの順番で実行しなければいけないかが明確になっています。

図3: 外部勉強会の運営プロセスのPFD

このような複雑な業務プロセスでもPFDを活用することでプロセスを明確に表現でき、特にチームで作業する際には共通の理解を促進するのに役立ちます。

PFD Draw Toolについて

PFDについてその概要・メリット・具体的な事例を紹介してきました。ですが、PFDの弱点として、その記述やメンテナンスが難しいという問題点があります。

成果物・プロセスそれぞれにつける一意なIDの付与や要素表の作成がその代表的なもので、成果物やプロセスを生成するたびにIDを編集したり、表と図の対応をそろえたりと、とにかく人力でPFDを整合性が保たれている状態に維持するのはかなりの労力を費やします。

そこでSWETではPFDの記述をサポートするツールを作成しました。ツールはWebベースのアプリとして実装されていて、社内の人であれば誰でもアクセスできるようにしています。

ちなみに、この記事に掲載してあるPFD（図1 ~ 3）はすべてこのツールで記述しています。

PFD Draw Toolの機能

いくつか機能があるのですが、ここでは主要な機能を3つ紹介します。

ID自動採番

成果物、プロセス生成時に自動で連番のIDを付与します。また、ここで付与されたIDは後で自然な順序（PFDのグラフ構造の始端が若く、終端に向かうにつれ番号が増えていく）に自動で振り直すこともできます。

要素表自動作成

成果物、プロセスを作成時に自動で要素表にも追加します。図の方で値を修正すると、要素表に自動反映します。またその逆も自動で行います。

PFDのルールのチェック

PFDには、記述上のルールがいくつか存在します。たとえば成果物と成果物は矢印で繋げない（プロセス同士についても同様）、成果物はひとつのプロセスからしか生成されない、などです。それらのルールに反したPFDをそもそも書けないようにする仕組みが実装されています。

PFD Draw Toolの技術スタック

簡単に実装に用いた技術スタックを紹介します。

実装にはReactをベースに状態管理ライブラリとしてRedux、Canvas上のコンポーネントライブラリとしてKonvaを使っています。

Reduxを用いることにより、この手のエディターの基本機能であるUndo / Redoや、ファイルへの書き出しの実装を簡易に実装できています。

まとめ

この記事ではPFDの紹介とSWETでの活用事例、SWETで開発したPFD Draw Toolについて紹介しました。 PFDは成果物にも注目して業務プロセスを可視化することにより、それぞれのプロセスの関係を明確にし、実行時の不確実性を抑制し、作業者間での認識齟齬を防ぐのに役に立ちます。

SWETではこのPFDを用いて各種業務の可視化や効率化に活用し、さらにPFDの記述やメンテナンスを簡易にするツールを実装しました。

今回はPFDを用いた業務の改善・効率化については触れませんでしたが、また機会がありましたら紹介させていただこうと思います。

注釈

[1]: 梶本和博、派生開発推進協議会T21研究会著『プロセスを自在に設計するーPFDを使いこなそうー』八木将計、八木香織（編集）、NextPublishing Authors Press、2021年5月29日
[2]: ここではPFDの説明のために簡略化した開発プロセスを記述しています。実際の開発はここに検証の工程が追加されたり、「仕様を決める」というプロセスの中にも何工程も含まれたり、かなり複雑なものとなります。
[3]: オリジナルのPFDでは要素表ではなく、それぞれの成果物・プロセスに定義書を記述します。