散々いろんなとこで語り尽くされている感はあるけど。デスマ中に QA との様々なやりとりからも、ウォーターファール的なやり方*1はもう限界だよなぁ、と感じている。
少し前のデスマで QA とこんなやり取りがあった。
「（渡されたアプリケーションを見て）事前の情報を遥かに超える規模のアプリケーションなので予定してテスト工数では足りない。話が違う、もっと機能少なかったんじゃないの？」
「完成度が低すぎる機能がある。QA の意味が無いので一時テスト作業を凍結する（もう要員割り当てちゃったよ。どうしてくれるんだ的な意味で）」
これらはテスト期間と要員の見直しが急激かつ大きく必要になるので QA からしたらたまったものではないだろう。QA は他プロジェクトの開発スケジュールと合わせてにらめっこしながら一つのプロジェクトのテスト期間と要員を割り振る。そのため、一つのプロジェクトにリソースをふりすぎると他すべての QA に影響が出てしまうので、本当にイヤなことなのだろう。*2
これは、まぁ…プログラマーが悪いというか、ごめんなさいのサインを早めに出さなかったマネージャが悪いといえば悪いし、元を辿れば最初っからムリくさいスケジュールをゴリ押しして下さったエライさんが悪いといえば悪い。
誰かに悪者を押し付けるのはカンタンなんだよね。作業工程が分離してるから尚のこと責任のありかを決めやすい。でも、それってなんかオカシイと思うんだよね…。各工程でがんばってない人なんて居ないと思うのですよ。*3
ちょっと話がズレた。
各工程間で降ってくる成果物が大きいと、予定してたのと違う大きさのモノが降ってきたときに対応におおわらわになってしまう。アジャイルなやり方はソフトウェア開発に携わる者すべてにとって福音になりうると思う。もちろん QA にとっても。
その理由は方々で散々語り尽くされているように、フィードバックループが小さくなるから。前述の QA とのやり取りもフィードバックがたくさん得られることによりかなり軽減されると思う。
「（渡されたアプリケーションを見て）事前の情報を遥かに超える規模のアプリケーションなので予定してテスト工数では足りない。話が違う、もっと機能少なかったんじゃないの？」
↓
各イテレーションの開発スピードを睨みながら QA リソースの割り当てを短い単位で見直すことができる。
「完成度が低すぎる機能がある。QA の意味が無いので一時テスト作業を凍結する（もう要員割り当てちゃったよ。どうしてくれるんだ的な意味で）」
↓
あるイテレーションで完成しない機能が出た場合、浮いてしまう QA リソースは最小限の期間に抑えられる。
また、QA は単なるテストだけでなく、仕様上の問題点やユーザ視点からの意見を出すことができる。それらを反映することは顧客の利益につながる可能性が極めて高いが、ウォーターフォールではテスト工程の「バグ修正」名目でやるしかない。修正のチャンスが一度きりではどうしても尻込みしてしまう。
しかし、コードは書かれたばかりなら比較的手を入れやすい*4。書いたコードが即評価されてフィードバックが得られるなら QA の要望は実現しやすくなる。これは QA にとって大きなメリットではないだろうか。
数々の文献が指摘するように、やはりカギはフィードバック間隔を短くすることにあると思う。
これらは俺自身が実践した内容ではないから、脳内の都合のいいシナリオでしかない。ただ、ドカンと一気に成果物渡してテストしてネ、では QA が不幸になるばかりだ…とデスマを終えた今、強く感じている。
追記
ブクマコメで指摘されたんで *4 について。これ、書き方が悪いね orz。というかこのエントリ自体妄想全開で書いちゃったからちと恥ずかしくなってきた…。
これは「3 日立てば他人のコード」ってヤツです。ウォーターフォールだと書いたコードはテスト工程で文句言われるまで一回動いたら基本放置。で、修正依頼が来るころには何でこんなコード書いたかサッパリ忘れちまって、思い出すのにやたら時間がかかってしょうがない、てなヤツです。
逆にアプリケーションそのものに対する理解は日を追うごとに増していくんで、その観点から見るとコードの理解度は高まっていくと思います。
つっても意外と書いたコードって覚えてるもんなんだけどね。擬似コードや手書きの図とかのイメージが残ってるとなんでこんなコードになったのかすぐ思い出せちゃったりする。変り種だと「あーこのコードは紗々食いまくりながら書いたヤツだぁ」とか。
