35号：PFDの使い方

≣ 概要

PFD（Process Flow Diagram）とは、故 清水吉男さん（1949年4月18日〜2017年11月22日）が定義したダイアグラムです。

PFDの書き方については清水吉男さん本人が作成された文書が以前はウェブ（「硬派のホームページ」というタイトルのブログ）で公開されていたため簡単に学習することができました。

「PFDは簡単に描ける」とはいっても、初めてPFDを描く方は、「要件リスト」など、多くのプロセスが参照し更新する【成果物】について線がゴチャゴチャになり、もつれた毛糸のようになってしまうかもしれません。

でも、その辺りの問題については、慣れの要素が大きいですし、先輩が描いたPFDから学ぶことによってクリアすることができます。近くにPFDを使っている先輩がいない場合は勉強会に参加して、休憩時間などに、具体例をもとに講師にコッソリ質問するのが早道です。

実は、私はPFDの記法（ノーテーション）についてはあまり興味がありません。個人的には、PFDでなく、DFDを使うことの方が多いですし、他の人への説明のためには、PFDもどきをUMLのアクティビティ図で描くことが多いからです。興味があるのは、今回のタイトルに書いた通り「PFDの使い方」です。そこで、このnoteではPFDへの情報のリンクとともに「使い方」について書きます。

≣ PFDを学ぶには

PFDを全くご存じない人もいらっしゃるかもしれませんので、まずは、PFDを自学習する方法について書きます。

PFDを学ぶ最良の方法は「派生開発推進協議会」に入会して、会員向けの資料を読むことです。清水さんが書いたものもあります。「派生開発推進協議会」の研究会に入るのもよいですね。

ウェブで公開されている資料に、とても良いものがあります。梶本 和博氏によるAFFORDD カンファレンス2014のチュートリアル資料である「PFDってなに？」は、清水さんが公開されていた内容をほぼ網羅し、かつ、分かりやすい内容になっています。まずは、この資料を読まれることをお勧めします。

他にも、みずのりさんのコンパクトにまとまったテクニカルで実践的な良い資料や、いせりんさんのすてきな考察が公開されていますので、気になる方はさがしてみましょう。

≣ PFDの使い方を知りたかったわけ

私が清水吉男さんと会話するようになったのは、2009年のことです。前年度から、SQiP研究会の第5分科会「ソフトウェアテスト」を高橋寿一さんから引き継いで担当していたのですが、2009年に新しく第6分科会「派生開発」が誕生し、清水吉男さんがアドバイザーとしてやってきたのです。通常、アドバイザーはあまり分科会に参加されない方が多いのですが、清水さんは毎回参加されて、ご指導されていたように思います。

その後、清水さんは、2010年には副主査、2011年に主査を担当されました。（私が委員長になったときに、本当に恐縮だったのですが主査を引き受けてもらいました）。
それで、機会を作っては清水さんに、PFDの使い方を聞いていたのです。（先日、連続ツイートした通りです）

そして、想像していたPFDの使い方と全く違っていて、だから「納期遅れや品質問題を起こしたことが無い」と自慢できたのか！ と、清水さんをますます尊敬したのでした。

≣ PFDの使い方

先に紹介した梶本 和博氏の資料の51ページにあるとおり、PFDを作る目的は「プロセスを設計する」ことです。梶本 和博氏の資料では10ページもかけて「プロセスを設計する」ことについて解説しています。
PFDを上手く使っている人はみんな「プロセスを設計する」ことを話します。テスト関係でいえば、てったん（河野哲也さん）がPFDマスターと思います。てったんに「どこでその極意を習得したの？」っていつか聞いてみようかなあ。

≣ プロセスを設計する

「プロセスを設計する」というと、「全社標準の開発プロセスをプロジェクトに合わせてテーラリングすること」を想像されるかもしれません。多くの場合、テーラリングは「全部ありの重い全社標準プロセスから不要な作業を引き算して作る」イメージだと思います。

私も当初、PFDのことを「テーラリングして作った自プロジェクトのプロセスの見える化のためのツール」だと思っていました。でも、それは間違いでした。清水さんは「プロセスの定義からプロセスの設計へ」と言います。この辺、分かりにくかったので何度も聞いてしまいました。

すると、「“プロセスの定義”というと“立派なプロセスを最初に作って守っていく”イメージになるけれど、PFDを描く目的はそこではありません。」と教えてくれました。
「そうじゃなくて、どうしたらたくさん抱えている作業を上手く進め、納期を守るかなんだ」と熱く語ってくださいました。（懐かしい）

そもそも、清水さんが、開発期間の長い汎用機のソフト開発と、短納期のオフコンのソフト開発を同時に複数抱えてしまったときに、「この複数の仕事を混乱させずに対応していくにはどうしたら良いだろう？」と考えて編み出したダイアログがPFDだそうです（正確には、初めのうちは、清水さんもDFDを使っていたそうです。そのうち、DFDだと、"ソフトウェアが実行する関数"を"人の作業"に対応させるのは良いけど、DFDだとデータの要素とデータのストアの定義が曖昧で読みにくいのでPFDを考案したとのことです）。

PFDを使う背景としては、
　・　品質を落とさない
　　　（プロセス改善とは「混乱した状態を鎮めて品質を向上させる」こと）
　・　自分の作業に必要なものが無いかもしれない
　　　（他の人の仕事遅れによってインプットが変化する）
　・　作業を中断するタイミングを間違えると効率が落ちる
　　　（切りの良いところまで進めてその日を終わりにしたい）
の３つがあります。
この3つを前提としながら仕事を上手くやるためにPFDを使ってプロセス設計を実施するわけです。

上手くやるためには、
　・　ゴールを先に決める
　　　（仕事が完了したときの状態や最終成果物を決定する）
　・　PFDのプロセスはとても細かい
　　　（作業レベルとする）
　・　PFDを描いて何度もシミュレーションする
　　　（何が起こってもあわてず代案が出せる）
が有効な施策となります。
具体的には、明日、自分が行う作業（中断すると効率が大幅に落ちるレベルの詳細な作業）の粒度でPFDのプロセスを描き、各プロセスに投入されるものの状況が変わることを何度も頭の中でシミュレーションするということです。

例えば、「もしも【コーディング作業】というプロセスに必要な【設計書】（コーディング作業のインプットの一つ）ができていなかったら誰の頭の中に設計書に書かれるべき情報があるんだ！？」といったことを事前に隅から隅までシミュレーションして、【設計書】ができてなかった時にも慌てないで、速やかに次善の行動（代案）を実行するということを行うというのがPFDの使い方です。

≣ 清水さんとの対話

清水さんとの対話（多分、呑みながら）を思い出して、書いてみます。
対話で使うPFDとしてキャッチイメージを再掲します。

秋山「清水さん、PFDについて教えてください。」
清水さん「いいよ。なに？」
秋山「PFDの〇のなかにプロセスを書きますが、その粒度がわからなくて。」
清水さん「粒度というと？」
秋山「【テスト設計をする】とか【テスト自動スクリプトを書く】とか、そのくらいの粒度でよいのでしょうか？」
清水さん「他部門の人向けの説明資料ならそういう粒度にすることもあるけど、【テスト設計をする】というような粗い粒度なら、ワークフローやアローダイアグラムでタスクの流れだけを表現したほうが良いんじゃない？　成果物とスケジュールも表したいならWBSの方が良いだろうし。」
秋山「なるほどです。ワークフロー、アローダイアグラム、WBSといったものと、PFDとの使い分けは、どうするのですか？」
清水さん「ワークフロー、アローダイアグラム、WBSは、“プロセスの定義”で使い、PFDは“プロセスの設計”で使う。」
秋山「定義と設計ですか。違いがよく分からないです。」
清水さん「仕事全体の流れ、各作業に必要な時間と担当者、作業と作業との関係、作業と（中間）成果物の関係、等々を大まかに明らかにして、そのプロジェクトのSLCP（ソフトウェアライフサイクルプロセス）を決めること。これが“プロセスの定義”。」
秋山（心の声）『ふむふむ。確かに計画書にワークフローやWBSを書きます。あれはプロセスを定義していたのか。』
清水さん「それに対して、PFDは作業者本人が自分の“プロセスの設計”に使うもの。」
秋山「自分の？」
清水さん「自分の。」
秋山「自分の“プロセスの設計”って何ですか？」
清水さん「日々、自分の仕事を振り返り、明日の仕事の進め方をシミュレーションすること。」
秋山「そのためのツールがPFDだということですね。」
清水さん「そう。」
秋山「実際に清水さんがPFDをやられたときの様子を教えてください。」
清水さん「当時、納期や開発期間が異なる大小たくさんのプロジェクトを抱えていて、並行に仕事をすすめる必要があった。」
秋山「いくつくらい？」
清水さん「大きなプロジェクトが1つと、小さなプロジェクトが1つから3つ。」
秋山「それは大変でしたね。」
清水さん「すべてのプロジェクトを成功させることが私への期待であり、それに応える。」
秋山「すごい。」
清水さん「当たり前。でも、頭の中だけで作業を進めていると、だんだん混乱してくる。」
秋山「そりゃそうです。」
清水さん「だからPFD（当時はDFD）を使って自分の仕事を描きだした。」
秋山「PFDの始まりですね。」
清水さん「それは束になった。」
秋山「1枚じゃないんですね。」
清水さん「プロジェクトが複数あったし、階層もあるから束。」
秋山「束のPFDを見たことないです。」
清水さん「仕事を終えて、家に帰るとPFDをテーブルに広げる。」
秋山「PFDは手書きですか？」
清水さん「もちろん。で、今日の仕事が昨日したシミュレーション通りにできたかどうかを確認する。できていないところについて、PFDを描きなおす。（赤入れする）」
秋山「終わったところも直すのですか？」
清水さん「そうしないと、シミュレーションの予測精度が悪くなる。」
秋山「そうか。そうですね。まだプロジェクトが終わったわけではないし。」
清水さん「そうしないと、プロジェクトが終わったときに振り返りもできない。今日の仕事の反省が終わったら、次は、明日の仕事のシミュレーションをする」
秋山「シミュレーション？」
清水さん「PFD（上の図を参照）に、ある作業（１）が成果物A（正確には投入物Aと呼ぶ）と成果物Bをインプットとして、A+Bよりも価値のある成果物Cを作ると描いてあったとする。」
秋山「清水さんのプロセスの定義は“投入物を成果物に変換する行為／仕掛け”でしたね。投入物をより価値ある成果物に変換することをプロセスと呼んでいましたね。」
清水さん「でも、このとき、成果物AとBが必ず存在するとは限らない。」
秋山「そこ、疑いますか。」
清水さん「疑うのではなく、最悪な事態を【想定】して、イザとなっても慌てないように準備する。ひとの責任にしません。」
秋山「リスク管理のようなものですね。」
清水さん「プロセス1を始めるときに、成果物Bができていなかった時はどうしよう？ 、と考える。成果物Bがなくても、成果物Bを作るプロセスXはあるはずで、そのプロセスXへの投入物を使えないか？ 、と考える。それもだめなら、誰に聞いたら良い？ 、と考えておく。これがシミュレーション。様々なケースを想定して何度も対応方法をシミュレーションすることが大事。」
秋山「なんのためにシミュレーションをするのですか？」
清水さん「変化に対して、自分の仕事を安定させるため。」
秋山「自分の仕事の品質と生産性を安定させるのですね。」

≣ 終わりに

今回は、（書く書く詐欺にならないように、）「ASTERセミナー標準テキスト」の解説をお休みしてPFDについて書きました。まだ書き足りないことがたくさんあるのですが、私の筆力では書いても伝わらない（ワークショップとかしないと無理な）ので以上とします。
来週から、テキスト解説に戻ります。