レポートNaITEスタッフの岡野です。3/28(日)に大森にて開催された勉強会の内容ご紹介をしてまいります。お付き合いくださると幸いです。3/8-9に開催されましたシンポジウムの一部のセッションの紹介をしました。そのシンポジウムは、こちらから参照できます。レポートこの中から、3本のご紹介です。ーテスト設計コンテスト決勝それぞれのご紹介は、下記の資料を参照いただけますと幸いです。Ujitawww.slideshare.net最後の質問コーナーでは、下記の2点が挙げられていました。:アンケートからの流れだった。参加者の半分以上が「管理者」。何か改善するのにいい手はないか?ということが目的で参加しているので、こういう質問が出たと考えられる。:開発者でもやっていけそうな人が対象という意味。発表者の中でも認識のずれがあった。自分の所感として・・・WACATEという宿泊型勉強会があり、自分も冬(2016/1開催分)に参加しました。夜から「分科会」という形で、参加者が持ち寄った議題・お題でディスカッションをする枠が設けられています。そこでも、このJaSSTのパネルディスカッションで話された内容が議論になっていて、行き着く先・考える先は、みな同じだからこそ、こういうシンポジウムでの注目度は高いのだなぁと感じました。参考:WACATEwacate.jp---------------------------------------------------------------------------------------------次は、勉強会のメインテーマでもあります、PFDのセッションです。PFDワークショップはじめにPFD概要の説明、そのあとに、ワークショップが行われました。Ujitawww.slideshare.net概要説明時の主だった内容を上げると、次のような感じです。PFDは、作業の見える化/等を目的としている。単なる図ではなく、思考の道具。開発プロセスを変化させ、安定させるために使う。全体が見通せるようになるので安心感が生まれる。一度作ったPFDで「固定」するのではなく、変更や検証することで「安定」させていく。PFDは階層化できる。個々のPFDをより上位のPFDで表現する。(プロセスは二重線で表す)子供のプロセスは、親の番号をつき継いで、X.1・・・とするとよい。(親はX)可読性を上げるために複製表示というやり方もとることができる。書き方は流れの方向は自由でよい。上下左右、わかればOK。DFDを拡張した図法である成果物から書いていくと書きやすい。「人のノウハウ」のような形の無いモノでもOKで、必ずしも電子データである必要はない。参考:PFDの生みの親、清水吉男さんの資料はこちら。http://homepage3.nifty.com/koha_hp/process/PFDform3.pdf-------------------------------------簡単に概要の紹介があった後に、ワークショップ開始。お題は、「今朝、家を出るまでにやったこと」。やったことを列挙してみました。私には子供がおります。小さい子もいるので、自分のことと子供のことが対象として入ってきます。出発!ひとつづつ、PFDを書いていき、成果物からほかのプロセスにつながるものがあれば、つなげる・・・ということを実施してみました。他人と見せ合ったりして、成果物の状態の持ち方がそれぞれで異なっていたのが印象に残りました。具体的にひとつあげてみましょう。最後の「出発(家を出る)」というプロセスの成果物に、いろんな意見がありました。「家の外に出た自分」ここの理解では、プロセスの主人公はあくまでも自分であって、「誰もいない家」の主人公は「家」であるから、成果物としては少し違うのではないか、という意見が上がりました。「持参必須なものをもった自分」というのは、概要説明でも言われていた「成果物から書いていく」という点を踏襲しており、これが妥当なんだろうなぁ、と思いました。上記にあげた、ワタシの例でいきますと、インプットは、下記になるかなと考えました。・・・が考えられるかな、と振り返って考えました。このPFDの考えを元に、自分の子供がいつ何をすべきで、それは何のために?ということを一緒にやると、忘れ物がなくなったり、「何のためにこれはやるんだろう?」という思考するプロセスが身につくかな、なんて親として打算的なことを考えてしまった次第です・・・。------------------------------------さて!もう一つ、お題が出ました。「本を出版する」これも上記と同じように実施してみましたが、なかなか難しかったです。PFDの例の一つとして、参考になるものが、これです。itpro.nikkeibp.co.jp-----------------------------上記演習二つを実施したあとのまとめです。PFDを書く時の順序。成果物・作業(行動)を洗い出す。思いつくものや、すでにあるもの等とにかく書き出す。そのあと一気に俯瞰してみる。それらを”関係”でつなぐ全体のMECEを見る全体を調整する他人と認識を合わせるきれいにしてみる記述するときの諸注意。成果物と成果物をつなげない。書く順序→ボトムアップかトップダウンか。階層化するのは書きなが分けてもいいのではないか人をインプットとして書くと動詞が自分だけで書ける。自分のロールの視点で書くと、同じ立場の人は困らない。別の関係者が見るときは、別の階層になる。関係者を成果物として書き出すことによって、その成果物の状態(中間・最終等)が見えるようになる。PFDができたら、「誰がどのタイミングで」という計画に落とす。計画に縛られてPFDを書くと図に出てこない成果物が発生する。自分のバイアスがかかってしまう。全部洗い出してから、MECEに書いてみることが大事。プロセスには時系列を持たない。順序性を表現するための図ではない。PFDをかいてわかること開発プロセスのPFDを作るときには関係者で合意をとる必要がある。する際にスケジュールやWBSの概念が入ってくる。クリティカルルートも見えてくる。目的で使うツールは変えるべき。PFDは成果物とプロセスがあるので、WBSが書ける。