SEA（ソフトウェア技術者協会）関西・プロセス分科会というやつで、九州工大の秋山義博教授による「PSPとTSPの話」という講演があったので聴きにいった。
恥ずかしながらわたくしは知らなかったが、秋山先生はワッツ・ハンフリーのPSP(Personal Software Process)／TSP(Team Software Process)に関する本の日本語版・「PSPガイドブック」と「TSPガイドブック」の監修をされているようだ。「PSP入門」のほうは何とか読んだけど、「ガイドブック」はあの厚さに恐れをなして手を出してなかったからなあ。
2時間ほどなので、PSP/TSPに関して個別の具体的な内容までは解説されなかったが、まあ要するに色んな事の記録をとって、それをもとに継続的なプロセス改善をエンジニアが自立的にやりましょう、てなことだ。実は別ルートでもTSPの勉強会みたいなものがあって、そこで聴いていたので中身はだいたい知ってるつもりだ。なので、へええそんなことをやるんですか的な驚きはなかったが、TSPそのものよりも、特に品質管理などの周辺の思想との関連みたいな部分を解説されたのがけっこう面白かった。あと、実際にああいうトレーニングを積んでPSPをマスターするのにどれくらいの期間がかかるのか、とか、いったいどこでそんな事をやっているのか、といったようなことについても具体的な情報が得られたのはありがたい。
よく言われることだが、ソフトウェアの欠陥摘出は、前の工程で行うほどコストが安い。PSPではそれをさらに一歩すすめて、そもそも欠陥を作り込まないように前工程でがんばりましょう、という発想になっている。たとえば、テストで出た不具合の改修に必要になるであろうリソースを、レビューやインスペクションに割り当てましょう、とか。そのこと自体は同意できるが、個人的にどうも受け入れ難いのが、コンパイルする前に目視でしっかり確認しましょう、という考え方だ。アジャイル開発の方法論だと、ちょっと書いてみてはやたらとコンパイルして、どんどんとフィードバックが得られるようにしましょう、となる。こっちのほうがしっくり来る。それで結果的に質の高いコードが書けるのならそれで良いじゃないの、と思うのだ。たぶん昔はコンパイルのコストって結構高かったから、コンパイル前にしっかり確認しましょう、ということになってるんじゃないだろうか。本当はそんなあたりも訊いてみたかったのだが会場の関係で時間がなくなってしまいそこまでの議論にはならなかったのが残念。
講演のあとの懇親会は、4月の給料日ということでどこも一杯、大阪第２ビル、第３ビルあたりの地下をさまよった挙句にえらく狭い店に無理矢理潜り込んだ。結構やかましかったので、あまり立ち入った話ができなかったのも惜しいところだ。
