こんにちは。デベロップメントテクノロジーセンターのいとけんです。
本記事では、ある案件での悩みの解決に PFD (Process Flow Diagram) を使った経験を報告します。
PFD 未経験者ばかりでしたが、プロセスが可視化された結果、想定以上に活発な議論ができました。
本当に短時間で参加者間の共通認識を作れるので、みなさんも PFD を活用してはどうでしょうか？
目次
PFDとはどんなものか馴染みが薄いと思いますので簡単に紹介します。
PFDとは、データフローダイアグラム (DFD) を改良して作られたプロセス設計記法で、
表記法がシンプルであるため扱いやすく、汎用性が高いのが特徴です。
下にPFDの記載例を示します。
直感的に「リーダーの経験値」が品質のバラツキの要因になってヤバそうだ。。。と気付きますよね。
詳細なPFDの書き方はネットで検索すれば出てくるので割愛しますが、以下のような特徴があります。
- 簡単に理解できる、共通認識を作れる
表記法がシンプルなため、直感的に理解しやすい。
初見でも分かるため、色々なステークホルダと簡単に共通認識を持つことが出来ます。 - ムダな作業を見つけられる
現状を可視化すると、InputとOutputが同じ(実は何もしていない)プロセスが見えたりする。
あるべき姿を書くときは、達成したい内容(ゴール)から書くので、要らない作業は入り込まない。 - 暗黙知を書ける
プロセスに対するInput/Outputに人知(無形成果物:暗黙知)を記載することが出来ます。
個人の能力依存になっている箇所を見つけられるので、ノウハウ伝承などの改善を取りやすい。
とある案件で「課題解決に関するプロセスの問題を抱えている…」という話を同僚から聞き、
「プロセスの問題ならPFDを使ってみよう！」ということでワークショップ開催を検討しました。
また、どんな状況なのかを現場にヒアリングした結果、以下のような事が分かりました。
- この案件は複数プロジェクトが同時に走っている
- 各プロジェクトのマネジャーが独自に課題管理している
- 課題は拾っているが、
放置され対応時間が取れないものがある
まとめると、
マネジャーの力量に任されていて、課題解決が出来てたり出来てなかったりする。
という状況だったので、
- 各自の現状のやり方を可視化する
- チームとしてどうすべきか案を出す
と、２段階で進めることとしました。
そして、コロナ禍なのでオンラインで実施することにしました。
ちなみに、ワークショップ参加メンバーは、PFD初心者1名＋単語を初めて聞いた方3名です。
初回は、目的の共有とPFDの記法説明を30分ほど行った後、各個人が行っている課題解決のやり方をPFDに落としてもらい、その後みんなでディスカッションしました。
できあがったPFDは以下になります。
みごとに書いている内容がバラバラです。笑
(でもAさんとYさんのが似ていて、KさんとTさんのが本質的に同じものって気づきましたか？)
ここからが、PFDの本領発揮でした。
ワークショップ主催側（わたし）の想定をはるかに超えて議論が盛り上がってしまい、
第2部のPFDをブラッシュアップさせる工程を無くし、議論を尽くすことにしました。
例えば、、、
- この会議なに？どんな事をやっているの？
- ヒアリングって何に注意してやってる？
- アジェンダに載せる基準ってなに？
- 思った以上に課題を出す場は有るね。。。けっこう、みんなやってたんだね！
- ビジネスパートナーさんが意見を言える場が少なくないか？
そこから今後に向けて以下２つの方針が出てきました。
- チームを跨いで課題を１箇所に集約する(既存のチケットシステムへ)
- みんなのPFD(出来ているところ)を繋げることで仕組みにする
2回目はグループワークで「課題を１箇所に集約する」仕組み作りです。
散在している課題書き込みの場を１つずつ精査して、どうチケットシステムに誘導するか検討した結果、以下のようなPFDができました。
チケットシステムに誘導するもの、自分たちの手で登録するもの、ランク別に整理されました。
ついでに、各会議体の位置づけや目的が曖昧であることに気付いたり、
その会議の進め方の改善にまで議論は及びました。
また、課題をしっかり登録する文化を根付かせようと、以下の方針も決まりました。
- 即座に起票 – 必須項目を減らして迅速に入力可能に
- 何でも起票 – この課題何だっけ？は一旦置いておく
本当は2回のワークショップの計画だったのですが、「課題を１箇所に集約する」だけじゃ片手落ち、
解決まで追えるようにしよう！となり、第3回の実施です。
チケットシステムに乗っかった課題…となると、ついステータスがどーだとか入力フィールドがどーだとかなりがちです。
しかし今回は、「乗っかった課題が放置されないようにする」に集中し、どんな課題が起こり得るか、どう対応すべきかの検討を行っていたのが印象的でした。
PFDを導入したから「課題が放置されない」に集中できたのかどうかは謎ですが、
可視化されたことによって、より本質にフォーカスできた…という効果が有ったのかもしれません。
（そうだとうれしいな。。。）
そして、出来上がったものがこちらです。
まず、参加者からは多くのポジティブな感想をいただいて純粋に嬉しかったです。
代表的なものを幾つかを紹介しますと、、、
- ルールが⾮常にシンプルなので、⼊りやすい
- 認識合わせ、ディスカッションのネタとして使いやすい
- 改善検討は成果物を⾒ながら検討できる
狙った通り！と言った感じで、ほくそ笑んでしまいます。。。
逆にネガティブ(?)な感想としては以下のようなものが有りました。
- PFDでまとめるスキルの習熟に時間がかかる
- 複雑な業務や他システムとの連携があった場合は煩雑になりそう
2つともご指摘の通りです。
1. については、PFDは読むのはすぐに出来ても、書くのは多少の習熟は必要になります。それでも可視化は出来てしまうところが、PFDの凄さなのかなと思います。
2. については、PFDはアクターが多数(≒複雑)になると「誰が何を」が見づらくなってしまいます。ここは、スイムレーン（担当者毎に水平に線で区切ること）を導入したりして回避する必要がありそうです。
私自身、自分のためにPFDを使っていましたが、PFDを使って議論をしたことは有りませんでした。
しかし、実際に議論で使った結果、お互いの活動(ノウハウ)を共有し、結合できたのはPFDの力だと感じました。
これからも、色んな使い方をしてみたいと改めて思いました。
顧客が社内とはいえ、初めてのワークショップ講師、しかもオンライン開催ということで、きちんと価値を届けられるか不安で緊張しました。しかし、蓋を開けてみれば活発な議論が繰り広げられ、狙った通りの効果が出せて一安心しました。
そんななかで、参加者から以下のような意見もいただきました。
- ベーススキルとしてファシリテーションも必要そう
今回のワークショップでは「PFDの書き方の習得そのもの」よりも、「PFDを使うことの価値」を感じてもらおうと思ったために、議論の内容を議論の最中に私自身が PFD に反映してしまったのが大きかったのかな？と思います。
結果として、参加者からの「スキルの習熟に時間がかかる」という意見にも繋がっていると思います。
ここは、今後どのようにファシリテートしていくか・ワークショップの目的を明確化するかの課題だと感じました。
- 演習に使ったツール類は会話に対して描画が追い付かず進みが鈍くなった
自分自身でリハーサルをしたときは耐えられるかな？と思っていたのですが、想定以上にストレスになってしまったようです。
また新たなツールを試したり、経験者の意見を参考にブラッシュアップしたいと思います。
今回は、プロセス改善案を作成するところまでの内容になりますが、実際にプロセスを適用すると新たな問題が発生するはずです。
どんなダイアグラムを使っても同じですが、初めから完璧なプロセスは出来ませんし、時代や環境変化に伴って常に変更は必要です。
今後、適用後のプロセス改善サイクルを回すところまで追いかけていければ…また新たな知見を紹介できるかなと思っています。
