はじめに
昨日（2019/1/19）、AFFORDDが開催するPFD勉強会が大阪でありました。それに関する感想です。興味深い話、PFDの演習、いろいろな方との交流ととても刺激的な時間を過ごさせていただきました。
www.kokuchpro.com
タイムテーブル
13:15 受付開始
13:30 PFD講習
16:45 PFD演習（年賀状のPFD作成）
18:45 終了
21:30 懇親会
プロセスとは
プロセスとは入力を出力に変換する行為。
開発のプロセスは常に状況に応じて変化させていく必要がある。しかし、組み込み開発現場では変わっていない。これは80,90年代に人海戦術で成功した体験によるため。
PFD(Process Flow Diagram)とは
プロセスと成果物をつないで表現した対話のための図。
こちらの記事も非常に参考になります。
PFDによる開発プロセスのモデリング - 千里霧中
ルール
1. プロセスは目的語-述語で書く
2. 成果物は名詞で書く
3. プロセスとプロセスをつないではいけない
4. プロセスには番号をつける
4-1. 番号は実行の順序ではない
4-2. 番号が飛んでもよい
ヒント
1. １シートにプロセスは「7±2」程度*1
2. プロセスの妥当性は、やることの入力/出力を書き出すことで判断できそう
3. PFDは最初につくって、適宜修正が必要なもの
4. ゴールから考える（引っ越しのイメージ）
日本の組み込み製品への要求の歴史
デバッグのPFD
PFDの利用方法のまとめ
| 作成 | 利用目的 | 作成例 |
|---|---|---|
| 個人 | 自身の作業理解 | デバッグプロセスの可視化 |
| 個人 | 上司との対話（日程計画すり合わせ） | 開発プロセスの可視化 |
| チーム | プロジェクト全体像の認識合わせ | 開発プロセスの可視化 |
上手くまとまっていませんね。。。作成を個人またはチームで 行うか、作成目的が何かを意識すること、で得ようとする効果が異なることを意識しておきたくて作成しました。
おわりに
PFDをどのように使うか、現場に取り入れるか、ということを悩んでおり、今回勉強会に参加させていただきました。PFDで表現する対象とその粒度を明確にすることが大切だと感じました。そして、チームでの運用においては、心理的安全性の構築も並行して行う必要があると思いました。個人の運用ならすぐにできます。しかし、本質は他者とのコミュニケーションツールであり、PFDを用いて本音の議論をし、勇気あるプロセス変更を実行していくことだと考えています。
直近では、日程計画をした業務があるので、その業務のPFDを個人作成します。あと、部内勉強会の進め方をその参加者とともにPFDにしてみようと思います。
AFFORDD主催のPFD勉強会参加。PFDによるコミュニケーションの可能性を感じた。演習により、チームでPFDを描くというのは良いのかもしれない。いかに問題定義するか、場作りするか、が大切かな。 pic.twitter.com/deUOl9ukqk
— YU2TA7KA (@UGKGbrothers) 2019年1月19日
*1:増えるときは下位層をつくる、プロセス定義書、成果物定義書を作成する
