「WACATE 2012 冬」参加レポート（その2）――よい仕事がよい人生を作る
こんにちは、第3バイオリンです。
新年あけましておめでとうございます。今年もよろしくお願いいたします。
さて、前年からの続きとなりますが、「WACATE 2012 冬」参加レポート第2弾、さっそく参りたいと思います。今回は、1日目のイブニングセッションとディナーセッション、夜の分科会の様子をお届けします。
■イブニングセッション「PFDの真価 〜あの遅れはどこへ消えた？〜」
システムクリエイツの清水 吉男さんのセッションです。
清水さんは、「多くの人は『品質』を確保する方法を持っていない」と切り出しました。自分のプロセスを自分で設計する、ということを実践している人がどれだけいるのでしょうか。「そんなのはリーダーの仕事だし、自分がリーダーを任されるようになってからやれば……」と思う方もいるかもしれません。しかし、「今日から君がリーダーだ」と言われても、昨日まで何もやっていなかった人がいきなりできるようになるのでしょうか。
清水さんはプロセスを設計するための方法として「PFD（プロセスフロー図）」を紹介しました。
PFDは、成果物とプロセスの「関係」を表したものです。成果物に何を書けばいいのか、作成した成果物が後の工程でどのように使われるのかを図示することでプロセスの全体像を見ることができるようになります。
例えば、料理を作るときでも、必ず後工程（できあがったときの見た目、味など）を考えながら作ります。行き当たりばったり、適当に材料を切り刻んで調味料を放り込んで、とやっていたらろくなものになりません。
清水さんは、PFDを使うことでプロセスのシミュレーションも行うことができる、と語りました。ようは机上演習と同じで、いろいろな場面を想定することができるので、できるだけ「想定外」を減らし、実作業中も慌てないようにすることが可能です。
さらに、作業中にプロセスを変更する必要が出てきた場合にも、自分が作成したプロセスであればすぐに対応することができます。スタートとゴールさえわかっていれば、途中のプロセスを省略したり別のプロセスで代替したりしても成果物に影響しない「代案」を考えやすくなるのです。それにより、1週間の遅れも挽回することもできる、と清水さんは語りました。
最後に清水さんは「PFDはあらゆる作業のプロセスに使うことができます。PFDを使うことで、無計画な上司の対応に振り回されることがなくなり、無茶をしなくなります。それは優れた技術者の健康、ひいては生命を守ることにもなるのです。皆さんが健康に、よい人生を送れるようにPFDを活用してほしいのです。」と締めくくりました。
清水さんとは「WACATE 2009 冬」のときにお会いして、私が実行委員長を務めるソフトウェアテストシンポジウム「JaSST’12 Niigata」でも基調講演をお願いしたことがあります。清水さんのお話のなかで一貫しているテーマが「仕事の取り組み方、仕事への向き合い方がその人の人生を作る」です。今回も、よい仕事をしてよい人生を作るヒントをいただくことができました。そして、PFDをもっと知りたいと思いました。
■ディナーセッション
1日目のセッションのあとは、温泉に入ってディナーセッションです。おいしいお酒と、名物のマグロをいただきながら、他の参加者と交流をはかれる時間です。
途中、実行委員の方が、参加者が申し込み時に寄せたコメントを紹介したり、歌やダンスを披露したりする場面や、いろいろな書籍やグッズが当たる抽選会といったお楽しみもあります。今回は、参加者が少なめということもあって、全員がプレゼントをもらえるという珍しいことがありました。ちなみに、わたしにはカレンダーとメモ帳が当たりました。今、机の上に置いて使わせてもらっています。
■夜の分科会
ディナーセッションの後は夜の分科会です。いくつかのテーマが設けられ、参加者は各自が好きなテーマのグループに加わって議論します。
わたしが選んだのは以下のテーマでした。
「ポジションペーパーに書いたことを議論しよう」
ポジションペーパーセッションでは語りきれなかったことを、この場でもっと話し合ってみようという主旨のもとで10数人が集まりました。
ポジションペーパーに「今後の進路についての悩み」を書いたわたしは、「この先、スキルを高めてテストエンジニアを極めるか、それともマネジメントや後進の指導といった方向に進むか、迷っている」と切り出しました。
すると他のメンバーから「そもそも『テストエンジニアを極める』ってどういうことだろう。どうなれば『極めた』ことになるのかな」という意見が出ました。それを考えるために、まず「みんなの職場に『この人、凄いテストエンジニアだな』と思う人はいるか。いるとして、その人のどういうところが凄いと思うのか」を出してみることになりました。
意見を出し合って、「凄いテストエンジニア」はおおまかにいって以下の2種類に分類できるのではないかという結論に至りました。
- 自動化スペシャリスト
- ドメインスペシャリスト
自動化スペシャリストとは、その名のとおりテスト自動化に精通したテストエンジニアのことです。一方、ドメインスペシャリストとは、特定のドメイン、つまりテスト対象となる製品やシステムの仕様に精通しているテストエンジニアのことです。よく、ベテランのテスト担当者が「なんとなくここが怪しいかも」と適当に触ってみて、みごとにバグ（それもかなり深刻なもの）を出す、ということがありますが、これもドメインスペシャリストの範疇に含まれます。
ここまできて、参加者のひとりが「確かに、自分の職場でも熟練テスターが一番バグを出している。その人のスキルはもはや職人技だ。これってエンジニアリングが職人技に負けているということなのではないか」とつぶやきました。すると別の参加者から「エンジニアリングというなら、そもそも、テスト設計って本当に『設計』と呼べるものなんだろうか。単にどのテスト技法を使うか、という話なら、プログラミングでいうと『ソートの処理にはクイックソートアルゴリズムを使おう』というレベルと同じではないのか。そのレベルで『設計』というのは違うと思う」という意見も飛び出しました。
となると、テストエンジニアが技術的スキルを極めるなら自動化スペシャリストしかないのでしょうか。なんだかよくわからなくなってしまいました。しかし、「テストエンジニアが技術的スキルを高めるとはどういうことなのか」という、ある意味、素朴な疑問について深く考える機会を持てたのはよかったと思います。
分科会が終わった後もみんな語りたいことは尽きず、他のグループの参加者も一緒になって部屋に戻って議論を繰り広げていました。わたしも仲間に加わりたかったのですが、眠気と疲労が限界だったので早めに自室に戻って寝てしまいました。残念ながら、体力は若手ではなくなりつつあることを実感してしまいました。
今回のレポートは以上です。次回は2日目の様子をお届けします。