プロセスフロー図を描いてみる

20210410

プロセスフロー図を描いてみる

昨年末くらいから要件・仕様をどう決めて、どう残していくかということについて本を読んだりしていたんだけど、そのつながりで PFD (Process Flow Diagram: プロセスフロー図) の存在を知った。

本来はどう使う、とか難しい話はおいといて、マインドマップのような思考ツールとして使っても効果があるように思う。

目次[非表示]

PFDの描き方

描くにあたっては、4つの記号と2つのルールを気にするだけでいい。
道具はパワポでもノートでもホワイトボードでも何でもよく、自分の思考の腰を折らないテンポ感がありさえすればOK(自分はPlantUMLを使っている)。
とにかく描くことが大事。

PFDってこんな感じ

食べるラーメンお箸満腹ラーメンをつくるカップ麺卵熱湯カップ麺を選ぶ今日の気分ストックお湯を沸かす水電気ポット

出オチというか、ぱっと見ておおよそPFDが何なのか検討がつくんじゃないかと。

  • 右端にある「満腹」が最終的に欲しい成果
  • 丸は左にある必要なものから何かをつくる(する)作業
  • 四角は必要になる材料
  • 雲型は形ある材料ではないけど、必要なもの
  • 矢印で 必要なもの→作業→できたもの がつながる

これだけ。使う記号は4つだけなので、すぐに覚えられるはず。

描くにあたってのルール

1. 四角(雲型)どうし、丸どうしを矢印でつなぐべからず

上のPFDから、一番基本的な部分を抜き出すとこんな感じ。

やること必要なもの1必要なもの2成果

つまり、やることとは、「必要なものを使って成果を作り出すこと」になる。
別の言い方をすると、やることには必ず1つ以上の必要なものと1つ以上の成果が存在しなければならない。
よって、やることとやることを直接つなぐことはできない。

やること1やること2これは禁止！！

同じことが必要なものと成果にも言える。
元のラーメンの図を見ると分かるように、あるやることの成果は、他のやることの必要なものになっている。
要は、一番端っこに存在する最初に必要なものと最後の成果以外はすべて中間成果だ。
やることを通らずに中間成果が別物になることはあり得ないので、これらも直接つなぐことはできない。

中間成果必要なものこれも禁止！！

2. 最終成果から順に描くべし

ここまで、必要なもの→やること→成果はこの順に描いていたが、実際に考えるべき順番は以下の通り。

やること必要なもの1必要なもの2成果1. 最初に「何が欲しいか」を考える2. 次に「何が必要か」を考える3. 最後に「何をするかの名前」を考える

つまり、PFDを描くにあたって最初に考えるべきは、求める最終成果となる。
ここから始めて、順にそのために必要なものを考えていくことになる。

ルールがもたらすご利益

1. 「やること」を始めるための条件が明確になる

やることを開始するには、必要なものがすべて揃っている必要がある。
逆に、どこかの時点で状況により必要なものが揃わないことが分かった場合、条件を変えて別の必要なものを考えることができる。

例えば箸がまだ洗い桶に入ったままだとしたら、それを洗うか、フォークで食べることを考える必要があるかもしれない。

食べるラーメンお箸満腹

あるいは、場所がキャンプ場であったなら、お湯を沸かすのに電気ポットを使うことはできず、枯れ木を拾って割って薪にし、火をおこす必要があるだろう。
水も「そこにある」ということは無いかもしれない。

お湯を沸かす水電気ポット熱湯

いずれの場合も、最初に考えていたものとは異なる必要なものを見つけるか、やること(および別の必要なもの)を追加する必要がある。

普段我々は、成果を得るために「お湯を沸かしてラーメン作って・・・」というやることベースで分解して道筋を考えることに慣れている。
しかし、実際にはやることにはそれを完了するために必要なものが存在する。
やることベースで考えてしまうと、そこを考え落としてしまい、

  • やることを始めたはいいが、必要なものが足りず成果を出すことができない
  • いざ必要になってから必要なものを準備するのに時間を取られる

ことが起きてしまう。

ラーメンの例で言えば、

食べるラーメンお箸満腹ラーメンをつくるカップ麺卵熱湯カップ麺を選ぶ今日の気分ストックお湯を沸かす水電気ポット

何事も起こらなければ

  • 箸と卵を準備して(2min)
  • お湯を沸かしながらカップ麺を選んで(3min)
  • 卵を落としつつお湯を注いで3分待ち(3-4min)
  • 食べる！(10min)

の20min弱で成果が得られることを期待できるが、キャンプ場の例でいけば40minではきかないだろう。
最初に考えたやること自体は間違っていなかったにも関わらずだ。

2. 「最終成果」に必要のないことを考えなくて済む

現在の状況から最終成果までに至る道筋は、それこそ無数に存在する。
しかも、途中で最終成果に至らないルートを枝切りしながら考えなければならない。
我々の思考力や想像力に限界はないかも知れないが(*)、それでもほとんどのケースで時間的な制約は存在する。
また考えるだけではなく、実際に成果を得るためにやることをこなす必要がある。当然、これにも時間がかかる。

よって、まず最終成果を得るところから考え始め、そこへ至るために必要なものとやること、そのつながりを見出すことに思考力や想像力を動員した方がよい。
なぜなら、最終成果が得られることが保証されているからだ。
また多くの場合、繰り返し何度も考えることで、より必要なものとやることの精度を高めることができる。

(*)個人的には、時間的な制約だけでなく「考え続けること」にも限界があると思っている。
考えることはタダかも知れないが、ドラクエのMPのように何らかのリソースを消費しているように感じられる。

その他のご利益

手順でなく、関係が明確になる

手順では「なぜそうなのか」の理解が難しく、状況に合わせた改善が難しい。
PFDの場合、「ラーメンを作るためには熱湯が必要」である依存関係からくる順番が明確になる一方で、「カップ麺を選ぶ」ことと「お湯を沸かす」ことに強い順序はなく、同時に行うことも可能であることがわかる。

影響範囲が明確になる

キャンプの例で見たように、仮に必要なものが揃わなかった場合、全体のどの部分に影響が出るかをすぐに理解することができる。
影響が大きければ、予めそれが起こらないように対策を取る、または起こったとしても代替手段を考えておくことができる。

理解しやすい

これはPFDに限った話ではないが、図示することは他人とのコミュニケーションにとって大きなプラスになる。
特に相手にとって未知の事柄を説明する場合、全体像を見せた上でピンポイントの話もすることができる。
色々と忘れてしまった未来の自分も他人と大差がない。
必要なことをパッと思い出すためにも、ルールが単純な図示は力を発揮すると期待できる。

参考

PFDの考え方、PlantUMLでの書き方は以下を参考にさせていただいた。

  • PFDによる開発プロセスのモデリング
    • PFDのメリットや使い所が大変完結にまとめられています。おすすめ。
  • PFDってなに？
    • 何のために書くのか、どのように書くのかがまとまっている。
  • 誰も教えてくれない 計画するスキル
    • PFDを使って、計画時点で必要なもの・やること・成果からなるプロセスの質をできるだけ上げておくことの重要性が書かれています。おすすめ。
  • PFD(Process Flow Diagram)の書き方
    • 考案者である清水氏による説明資料。
    • 「プロセスを固定」するのではなく、「安定」させることが重要であると説かれている。
  • 35号：PFDの使い方
    • 清水氏の「PFDは作業者本人が自分の“プロセスの設計”に使うもの。」という考え方が紹介されている。
    • 「自分の“プロセスの設計”=日々、自分の仕事を振り返り、明日の仕事の進め方をシミュレーションすること。」という考え方は、作業を「決まったプロセスに則っているので自分は正しく仕事をしている」という態度から、ぐっと自分事に引き寄せるもののように思える。
  • 会議を爆速にする、Visual Studio Code 超便利スニペット集
    • VSCode/markdownで効率よくPFDを書くためのテンプレートがある。

コメント

コメントを投稿

このブログの人気の投稿

Cっぽいコードでgoogle testとgoogle mockを使ってみる

Cっぽいコードでgtestとgmockを使ってみる クラスとか使っていないコードでgtest, ついでにgmockを使うことができないか試してみたのでメモ。 参考にした情報 以下の情報を参考にさせていただきました。ありがとうございます。 ブログ sioaji2012のブログ - 組込C言語でUnitTest 5 GoogleMock 書籍 モダンC言語プログラミング 元のコード 我ながらCだかC++だか分からないコードですが・・・ capsule.h # include <iostream> # include <stdint.h> # ifndef CAPSULE_H_ # define CAPSULE_H_ // Prototype for public function void publicMethod ( const uint8_t input , uint8_t & output ) ; # endif // CAPSULE_H_ capsule.cpp # include "capsule.h" // Prototype for private function static void privateMethod01 ( const uint8_t input , uint8_t & output ) ; // Implement for public function void publicMethod ( const uint8_t input , uint8_t & output ) { std :: cout << "publicMethod called." << std :: endl ; // call private function privateMethod01 ( input , output ) ; return ; } // Implement for private function static void privateMethod01 ( con...
続きを読む

Cっぽいコードでgtestとgmockを使ってみる その2

Cっぽいコードでgtestとgmockを使ってみる その2 前回 Cっぽいコードのフリー関数に対してgtest, gmockを使った試験ができそうだ、というところまで進めることができましたが、やはり既存のソースコードに手が入ってしまうことが気になっていました。 今回は、そこを改良できないか試してみます。 参考にした情報 以下の情報を参考にさせていただきました。ありがとうございます。 (自分で思いつくのは無理です・・・) ブログ C言語のテストでスタブ関数を使うためのアイデア googlemockでグローバル変数のモックオブジェクトを作れるか 方針を検討する 前回のコード 前回の試験対象関数が書かれたコードはこんな感じでした。 関数名 説明 publicMethod 試験対象の関数。内部で面倒な処理を行う privateMethod01 を呼び出している。 privateMethod01 面倒な処理をしている関数。 publicMethod と結合して試験はしたくない。 # include "capsule.h" # ifdef GTEST // add "_impl" suffix to private function # define FUNC(func_name) func_name ## _impl # else // not to change # define FUNC(func_name) func_name # endif // TEST // Prototype for private function static void FUNC ( privateMethod01 ) ( const uint8_t input , uint8_t & output ) ; # ifdef GTEST // To use mock, replace function call to pointer void ( * privateMethod01 ) ( const uint8_t input , uint8_t & output ) = FUNC ( privateMetho...
続きを読む

WSLにgoogle testを入れてみる

WSLにgoogle testを入れてみる ふと思い立って試してみたので、メモとして残しておきます。 インストール ソースコードをDL&展開 wget https://github.com/google/googletest/archive/release-1.8.0.tar.gz tar zxvf release-1.8.0.tar.gz cd googletest ビルド cmake が必要なので、インストールします。 sudo apt install cmake mkdir build cd build cmake .. sudo make && sudo make install 成功していれば、 ls /usr/local/lib とした際に libgtest.a libgtest_main.a が表示されるはずです。 使ってみる 適当なコードを用意 サンプルとして超適当なコードを用意します。 gtest_sample.cpp # include <iostream> # include "gtest_sample.h" bool sample_function ( const uint8_t input , uint8_t & output ) { std :: cout << "called sample_function" << std :: endl ; output = input ; return true ; } int main ( ) { uint8_t input = 16 ; uint8_t output = 0 ; bool ret = sample_function ( input , output ) ; std :: cout << "output: " << static_cast < uint16_t > ( output ) << std :: endl ; std ::...
続きを読む