PFD勉強会で夜景を楽しむホワイトデー

　3/14は、ホワイトボックスのテストデータ作成作業、通称「ホワイトデー」でしたが、みなさまにおかれましては如何なるホワイトボックステストをお楽しみでしたか。
　実はその日、大崎のNHN Japan カフェにて、『初心者向けPFD勉強会』が催されました。

　WACATE2011夏の経験から、PFD勉強会をしたい！と思い立ったもとやまさんがtwitterでつぶやいたところ、

PFD 勉強会。。。できないかしら？！

— zunko motoyamaさん (@motozun) 2月 11, 2012

@koyaman2 @gen519 @goyoki @noriyukimizuno 了解しました～！宜しくお願いします。

— zunko motoyamaさん (@motozun) 2月 11, 2012

　7時間後に開催が決まっていた・・。
　ソーシャル！ソーシャル！

　会場は、いかにも景気がいいぜって感じのピカピカ★の高層ビル。スーツじゃない人たちがカフェスタイルな空間で打ち合わせをしつつ、壁には忍者が埋まっているというシュールさでした。

当日の流れ

　当日の流れは以下の通り。

勉強会開催までの流れ説明: もとやまさん PFDの概要説明: みずのりさん 演習ワーク*3: グループにて 解説: みずのりさん PFDの歴史とアドバイス: 清水吉男さん 閉会挨拶&ナチュラルな自社アッピール: 村上さん

　・・・そう。この勉強会には、PFDの考案者ご自身にお越しいただいているのですね・・・！

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

 　(3)の演習の際にも、具体的なアドバイスをいただきました。といいますか、著書・『要求を仕様化する技術・表現する技術』にサインをいただきましたｗ　ありがとうございます！

PFDとは何か

　PFD(Process Flow Diagram)は、プロセスと成果物の関係を明確するために、DFD(Data Flow Diagram)を派生させたものです。
　清水さんご自身による『PFDの書き方』という資料が公開されており、本来ならこの記事も、資料を熟読のうえで書くべきですが・・・今回は勉強会の参加報告ということで許してください。

　今回学んだ範囲だけでいうと、まずPFDはものすごくシンプルで、とっつきやすい。
　それは書く方、読む方双方に言えることで、みずのりさんによると、PFDを他の人に見せて、「何コレ？」と聞かれたことが一度もないそうです。そのくらい直感的な図。

　とりあえず出てくるのは、「成果物」と「プロセス」。ある成果物をINPUTとして、何らかのプロセスを実行すると、OUTPUTとしての成果物が生まれる。この成果物がまた新たなINPUTとなり・・・というフローを描いていきます。
　これで何が嬉しいか。みずのりさんによると、

全体の作業が見えやすくなる 作業分担が明確になる 作業を分解して考えるクセがつく 進捗が把握しやすくなる などなど

とのこと。なるほど。

実際に書いてみる

　ワークとして、以下の業務プロセスをPFDに落としこんでみました。
　簡単そうに見えて、意外に、行き詰まります。

客先からの変更要求をトリガにアプリケーション改修作業を開始します。 以下の手順で回収作業を実施します。 改修仕様書を作成した後、ソースコードの変更点を明確化します。 ソースコード変更点について、レビューを実施したのち、ソースコードの改修を実施します。 改修完了後には、改修仕様書記載の内容を、アプリケーション要求仕様書へ反映する作業を実施します。

　とりあえず、本文中の「成果物っぽいもの」と「プロセスっぽいもの」にマーキングして、それを並べてみます。
　そもそも実際に作るときは、こんな明文化自体されていないのですから、本来はまず「自分たちってどんな作業やってるんだっけ」というところの洗い出しから入るのかも知れません。

　てなわけで作ったのが、以下のPFDです。
　ちょっとわかりづらいですが、赤い線は、正解例を見て書き加えたもの。
　つまり、たくさん間違っています。

　よくなかったのは、以下のような点です。

(1)改修仕様書を、変更要求だけから作成

(2)ソースコード変更点を、ソースコードなしに作成

　変更内容だけでなく、変更する対象もないと、作業できませんね。
　わたしのやりがちな典型的な考え漏れが、コレです。

(3)レビューの結果が、ソースコード変更点だけ

　実際には、レビュー自体の成果物「指摘シート」があって、これを「反映する」プロセスの結果、ソースコード変更点が修正されます。

(4)レビューのインプットとして、改修仕様書が漏れている

　そのまんまです。

(5)更新される成果物の扱い

　ちょっとPMBOK的な発想で、「ソースを改修したら改修済みソース」、といった発想をしていました。
　正解例では、「ソースコード改修」と「ソースコード」の間は両矢印で「更新」となっていました。「アプリ要求仕様書」と、改修後の「アプリ要求仕様書へ反映」も同様です。

(6)前後関係について

　「改修完了後には」という文言から、どうも時間の前後関係、因果関係を表現したくなるのですが、それはしないそうです。あくまで、IN/OUTとプロセスの、静的な関係を描くことが目的ということでしょう。

清水さんの教え

　今回の初心者向けアドバイスとして、

成果物には番号を振っておくと、議論しやすい。 最後の成果物から考えると、そこにたどり着く最短のプロセスが見つけやすい 「3時間経過」という事象はプロセスとみなして、「時計」で表現してもいい

という教えていただきました。

　またPFDを描くご利益として、プロセスが明確になっていると、工程が行き詰まった時に対応策を練りやすいと教えていただきました。聞いたことを絵で表現したみたのが、下の図です。イメージなのでプロセスの○は省略しています。

　このように、成果物Aの後で作るBが遅延し、Cを作れないとき・・・。
　それぞれの成果物のIn/Outを分解してみる。すると成果物間の実態の関係は、こうかも知れない。

　Bの中ではB1→B2→B3の順に作っているけど、実はB2は、成果物Cに影響を与えていないかも知れない。であればB3に先に着手すればいい。また、もしA2→B3→C2と作られていくなら、もしかするとA2から直接C2を作ることも考えられるかも知れない。

　このように、流れさえわかっていれば、改善策が生まれやすい。というのがお話でした。

PFDを描いてみて

　上でも書きましたが、まず、とっつきやすい。前提となる知識がほとんどなく、たとえば「ループさせたい場合は？」のように、必要に応じて新しいルールを習得していけばいいというのが大きなメリットです。
　みずのりさんがおっしゃっていたように、自分たちの作業の流れを整理し、見直すこともできます。

　もともとの用途は、「自分の仕事のプロセス」ではなく、「ソフトウェアの対象となる業務プロセス」を整理するものではありますが、まずは自分の理解しているところで絵を描いてみて、徐々にソフトウェア設計で使っていく、というのがよさそうです。

　以上、勉強会の参加報告です。
　主催者のみなさん、清水さん、どうもありがとうございました。
　そして、NHNに入社しよう！（宣伝）