SWETグループのmad_pです。SWETグループではTest Nightシリーズなどの勉強会を開催しています。勉強会開催にはノウハウが多くあり、なんとなくいつも同じ人が回している、ということになりがちです。SWETでは数年前から勉強会運営プロセスをPFD （Process Flow Diagram）を使って記述しており、ノウハウの蓄積と再利用がしやすくなりました。本記事では、勉強会開催に使ってみてわかった、PFDの利点・弱点を共有します。
勉強会開催について
SWETグループではTest Nightシリーズ、Test Online、Lint Nightなど、いくつかの勉強会を開催しています。各回、だいたいSWETメンバー3人くらいで企画・準備し、当日は他のSWETメンバー、DeNAの技術広報メンバーにも手伝っていただいて12人くらいのスタッフで開催しています。イベント規模は、おおむね会場60名程度、オンライン100名程度のハイブリッド開催としています。
勉強会を開催するには、シリーズのどのイベントを実施するか、誰に登壇していただくかなどを企画し、会場を予約、connpassやXで告知、とやることがいろいろあります。また、イベント日時が決まらないと告知もできないなど、作業間には依存関係があり、実行順序に影響します。この開催・運営プロセスを以前は前任者の経験に頼って回していました。2022年ごろ、PFDを使って勉強会の開催までのプロセスをモデル化しました。それ以降の開催では、このPFDを見ながら作業しています。属人性の高かったコツやノウハウが共有されるようになり、反省をプロセス改善につなげることができるようになりました。
おさらい: PFD （Process Flow Diagram）
SWETグループでは2020年くらいから、PFD （Process Flow Diagram）を業務プロセスの分析に活用しています。PFDでは、業務プロセスを成果物とプロセスに注目して可視化します。PFDおよびSWETで開発したドローツールについて、別記事で解説しているので参考にしてください。この記事で例示しているPFDは、すべてそのドローツールで作成しました。
- PFDとPFD Draw Toolの紹介
かんたんなプロセスを例として、PFDの表記法を見てみましょう。成果物（記号Aと四角で表記）を入力としてプロセス（Pと丸）を実行し、出力として別の成果物を得る、ということを矢印でつないで次のように表記します。
この図の他に成果物要素表とプロセス要素表を用意し、各要素の説明や詳細を記述しています。ドローツールでは要素を右クリックして詳細を入力すると、自動的に要素表で管理してくれます。
勉強会運営プロセス全体図
勉強会運営プロセスの全体を見ていただこうと思ったのですが、大きすぎたので簡略版を作りました。
この簡略版で各プロセスの概要を説明します。勉強会運営には次のような要素があります。
- イベント企画（紫）
- どんなイベントにしたいか、誰に登壇していただくかなどを決め、日程調整をして会場を予約する
- 告知・参加者管理（水色）
- connpassのイベントページを作成し、案内文を作文する
- connpassのメッセージや予告ブログで告知する
- 開催準備（クリーム色）
- 開催当日のためのタイムライン（進行表）や司会用スライドを準備する
- 必要に応じてリハーサルを行う
- 懇親会がある場合には予算管理しつつ飲食物を手配する
- イベント開催
- 当日はタイムラインにそってイベントを進める
- レポート・配信（ピンク）
- 配信の録画を編集して公開、ツイートをposfieでまとめる、登壇資料をconnpassに登録など、イベント後の情報公開をする
- 振り返り（緑）
- アンケートを集計し、登壇者にフィードバックする
- スタッフのKPTやアンケートを振り返り、プロセス改善につなげる。必要に応じてPFD自体を更新する
PFDではこれらのプロセスをすべて、入力（成果物）→プロセス→出力（成果物）としてモデリングします。成果物は「A9：参加者/非参加者のSWETへの認知」のような抽象的な概念でもよいです。前のプロセスの出力が次のプロセスの入力として使われることで、依存関係が記述されます。
これらのプロセスを詳細化した全体図がこちらです。
すごく大きいので、詳細に見たい場合はブラウザの別タブで表示し拡大してください。
5つのエリアの色は簡略版に合わせています。成果物は簡略版と全体図では必ずしも対応するわけではないですが、おおむね合っているかと思います。
PFDの作り方として、最初に大まかなプロセスを描き、大きなプロセスを別のPFDで詳細化するという手法がよいとされています。今回は逆で、先に詳細な全体図があって、あとからこの記事での説明のために簡略図を作成しました。余談になりますが、全体図はドローツール登場以前に作られたため、ArtifactのAの代わりに、DeliverablesのDを使っています。
実際のプロセス例
全体図の一部を拡大してもう少し見てみましょう。イベント告知の一部を切り取ったものです。
中央付近にあるP37「開催予告メール送信」に注目します。開催予告メールを送信するには、D87の開催予告メール文面を作成しなければなりません。D86の過去の文面を参考にしつつ、P36で作成します。P36にはもうひとつの入力、D35のconnpassイベントページがありますが、これは、メッセージ送信にconnpassメッセージを利用しているため、先にイベントページができている必要があるということを意味しているのでしょう。P37に戻ると、もうひとつの入力にD28開催予告ブログがあります。予告メールはブログが公開されてから送出したいというタイミングの事情が反映されていると考えられます。P37が完了すると、成果物D88として「送信された開催予告メール」ができます。参加者のみなさんはD88予告メールやD26ブログのツイートを見て登録してくださるというわけです。
下半分のP24、X広告購入の近くを見ると、P21の広告文面作成から3つの成果物、D29X広告文面、D30フォロワーターゲット、D31キーワードターゲットが作成されています。ひとつのプロセスから複数の成果物が作成される例となっています。P24は複数の成果物を入力とする例でもあり、これら3つを入力とします。
PFDでは、ひとつのプロセスが複数の入出力を持てるのに対して、ひとつの成果物が複数のプロセスの成果物として生成されることはありません。どちらのプロセスの責務かがわかりにくくなってしまいます。このような場合には、それぞれのプロセスからは中間成果物を生成し、後段に中間成果物をマージして成果物を作るプロセスを置くとよいです。一般的なドローツールで作図するときには気をつける必要があります（SWET製のPFDドローツールでは成果物に対して複数の生成プロセスを設定できないようにしています）。
ここではプロセスに注目してPFDのプロセス記述を説明しました。PFDを作成するときは、最終成果物から逆算して、それを生成するにはどんなプロセスが必要か、そして入力としてどんな成果物が必要か、と考えるのがよいです。プロセスも大事ですが、特に成果物に注目して「何を作るのか」を考えるとよいかもしれません。
PFDを使った勉強会運営
このように作ったPFDを活用して勉強会運営をしています。基本的にはプロセスにしたがって、左から順に進めていけば抜け・漏れなく作業を進められます。PFDを参照することで、勉強会運営を経験していないメンバーも、全体の流れや成果物の今後の使われ方なども把握しやすくなります。進捗や担当を管理したくなるので、ドローツールにはラベル機能をつけてもらいました。
ひとつのPFDを使って複数の勉強会を実施するので、ラベルが混乱しないよう、毎回勉強会ごとに全体をコピーして使っています。複数のイベント開催が並行して走ることもあります。
勉強会運営では告知文や登壇依頼文など、作文をする機会が多くあります。プロセスの入力成果物として「過去に使った文面」を置いておくことで、前回どう書いたっけ、を参考にすることを明示できます。ドローツールの機能で要素にリンクを書いておくことができ、右クリックしてすぐ参照できるので便利です。
PFDの要素表は、Googleスプレッドシートをひとつ作りました。要素表は勉強会ごとにコピーするのではなく、成果物ごとにタブを作って、勉強会ごとに行を追加する形式で記録しています。ドローツールの成果物のリンク欄に、スプレッドシートのタブまたはセルへのリンクを書いておきます。記録を一元管理することで、過去の成果物も参照しやすく、重宝しています。
実際の運用例
この記事を書くにあたって、2025年10月23日に実施した「CI/CD Test Night #8」でのPFD活用をふり返ってみました。この勉強会の運営PFDは、9/14にテンプレからコピーして作成し、10/31に振り返りを完了するまで、1か月半活用しました。
勉強会運営にPFDを使ってよかったと感じた点には次のようなものがありました。
- 依存関係を持ったTODOリストとして活用でき、次に何をすべきか明確になった
- ラベルを使って進捗・担当者管理ができた
- 過去の成果物を参照して、成果物の作成が楽になった
- connpass、zoom、URL短縮ツールの使い方など、忘れやすいことをプロセスの詳細に記述しておいたのでわかりやすかった
- 不要な作業は「スキップ」ラベルをつけ、今回は実施しないことを明確にできた
- 今回はX広告を使わないので、広告費の予算管理も含めてスキップ、など
- プロセス改善をPFDに反映できた
- 社内発表者の資料公開プロセスを追加
- 最初にPFDをテンプレからコピーし、振り返りをテンプレに反映する、というプロセスを追加
- 運営中に気づいた点をすぐ記録できるように、KPTシートは最初に作成する
逆に、PFDをうまく使えなくて失敗した部分もありました。
- 当日のイベント開催中はPFDを見るためのPCが不足した。スタッフも登壇していたため、参加者に見えないようにこっそりPFDを見ることができなかった
- 当日はPFDを見なくても作業できるようにすべき
- 当日のタイムライン作成をスキップしたところ、当日やり忘れたことが出てきた
- 過去の司会用スライドを元に作成したとき、TwitterをXと修正するのを忘れてしまった
- ドローツールでPFDをGoogleドライブに保存していたため、同時編集できなかった
- 保存形式はJSONなので、GitHubに入れるのも一案かもしれない
PFDを活用した勉強会運営にも慣れてきて、捗るようになりました。逆に「慣れてきたから省略しよう」と省略したところで問題が発生したので、そこに要素として存在する価値があることも実感できました。特にタイムラインに当日向けのノウハウが多く入っていたので、印刷しておくなり、スマホで確認できる程度のチェックリストにするなり、工夫の余地があるとわかりました。
PFDの利点・弱点
くり返しになりますが、PFDの利点についてまとめます。
- 業務の流れを誰でも把握できるようにする
- プロセスの漏れ、やり忘れがなくなる
- 成果物に注目した分析で、作業の依存関係が分かる
- 業務改善の土台になる
- 不要なプロセス、やらない仕事が明確になる
逆に、勉強会運営から感じた、PFDの弱点についても考えてみます。
- プロセスの粒度がまちまち
- 成果物を中心としてプロセスを組み立てるので、ひとつのプロセス（丸）に必要な時間が大きくばらつく
- ソフトウェア開発のように、プロセスが大きくなると粒度がそろっていないことが全体の見通しを悪くするかもしれない
- 工程管理に使いにくい
- プロセスごとの工数や人員を管理し、デッドラインやマイルストンまでの進捗管理・工程計画をするには向いていない
- PFDからWBSやガントチャートを生成するのがよさそうに思える
- 勉強会運営くらいの規模であれば、ラベルで担当者・完了だけ管理する程度が有用そう
- 階層的な詳細化は、活用できればうれしいが難しい
- ドローツールにもサブプロセス詳細化の機能を用意したが、成果物をサブ成果物として管理する機能も必要なことがわかり、活用できるまでには至っていない
- 別のPFDとして管理するくらいの割り切りが適していそう
- くり返し作業の記述（ループ）ができない
- くり返しの単位をサブプロセスとするなどの工夫が必要
- PFDは不要なくり返しを洗い出して減らす方向に活用するのがよさそう
まとめ
SWETでPFDをプロセス分析に活用するようになって5年程度です。プロジェクトの計画やQA作業のプロセス分析など、幅広く活用できています。その中で、勉強会運営は短いサイクルでくり返し実施してきたため、いちばんノウハウが蓄積され、また改善も続けられてきたものです。PFD化で過去の成果物を組織的に記録し、再利用できるようになりました。
余談になりますが、最近とある小さめのWebシステムを作ったときも、コンポーネントの動作を最初にPFDでモデル化しました。SWETのドローツールは保存形式がJSONなので、PFDのJSONをそのままAIに渡すことで、コンポーネントの依存関係を把握してくれて助かりました。ソフトウェア開発にはもっと厳密なUMLなどを使いたくなると思いますが、生成AIを使ったコーディングの前段としての要件分析、仕様分析には、PFD程度の粒度のものが合っているかもしれません。
参考文献
- 梶本 和博、派生開発推進協議会T21研究会 著 『プロセスを自在に設計するーPFDを使いこなそうー』 八木 将計、八木 香織（編集）、NextPublishing Authors Press、2021年5月29日
