ko31 
先日、Ustreamで配信されたソニックガーデンさん主催のオンライン勉強会「SonicGarden Study #05」を、高崎の非公式パブリックビューイングで見てきました。
今回のテーマは「そのテストは本当に必要ですか。」ということで、ソフトウェア開発におけるテストの考え方について説明するという勉強会です。
勉強会の感想
この配信を見たのは初めてでしたが、まず講師と参加者が SNS 経由でリアルタイムに繋がってる感じって楽しいですね。「みなさん見えてますかー」「あ、札幌からも見てくれてますねえ」みたいな。自分たちがいた高崎絡みのツイートも少しいじってもらえて嬉しかったですｗ
内容ですが、自分はてっきりテストコードを書く意義的な話かと思い込んでいたのですが、もっと広義でのソフトウェア開発におけるテストの位置付けについてが主のテーマでした。
ざっくりと、下記のような流れにそった考え方が紹介されていました。
- すべての欠陥を取り除くことは不可能という大前提
- なので不具合を許容するというスタンスに立つ
- テストを行う目的、コストに見合うテストを考えるべき
- 不具合「0」を目指すよりどれだけ早く直せるかを考える
- 早く対応するためにテストだけで足りない部分は仕組み化していく
これは、ソニックガーデンさんが実践している「納品のない受託開発」の背景にある考え方でもあるようです。
個人的には、上記の中の「不具合を許容する」というメッセージがとても刺さりました。普段現場にいる立場で実感はしていてもなかなか表には出しにくい言葉なので、これを堂々と認めてしまえることがとても爽快であり、認めていいんだという安心感のようなものも感じたり。今後の仕事の取り組み方に少なからず影響が出るかもしれません。
※下記、刺さっているところ。
不具合を許容するという発想が新鮮かつ腑に落ちた感じです #sg_study
— Ko Takagi (@ko31) October 7, 2013
後半に出た「早く対応するための仕組み化」については今回の対象では無かったのですが、この部分に特化した話もなかなか興味深いところですね。
迅速な対応の事例として、以前目にした @jnchito さんの下記エントリがふと浮かんだんですが、ここまでの仕組みが実現できているからこそ、不具合を許容するスタンスを取ることも可能になるんであって、そこは都合が良いところばかり理解ように注意が必要ですね。
テストについて感じていること
自分はいわゆるウォーターフォール型の開発経験が多いのですが、以下はその観点でちょっと感じた余談です。
大手SIerなどと絡んだ仕事をしていると、綿密なテスト計画書を用意して、カバレッジC0・C1を100%満たすとか、ステップ数から換算したバグ摘出目標値を満たすバグを摘出するとか、信頼度成長曲線が理想的なカーブを描いてるかとか・・・。そんな膨大な作業コストをかけてテストを消化したアプリケーションにもかかわらず、いざ運用現場の受入テストに入ったら、今まで気付かなかったバグがあっさり摘出されるというケースを何度か見たことがあります。
開発側は燃え尽きてモチベーションが低下、顧客側は成果物への信頼度が落ちる、あとは仕様書を基準にした仕様通りか否かのせめぎ合いにフェーズが移っていく、お互いにとって幸せでないパターンです。
結局のところ、開発側が実施できるテストというのは、要件定義・基本設計等の工程で拾いきれた要件を満たす機能が100%実現できているかどうかという基準に基いているので、それが本当に顧客の求めたものとイコールかどうかは実際に使ってみるまでは分かりません。
例えば、ソニックガーデンさんが言うその目的やコストに見合う内容のテストをよく考えて実施することで、削減できたコストを顧客受け入れ後のフィードバックに備えておく、といった対策を取ることも可能になるかもしれません。
お互いが幸せになれるように、既成のやり方にとらわれず本当に必要だと思ったことを実践する気持ち・工夫、そんなことを常に心がけていきたいと思います。
パブリックビューイングについて
ところで、高崎のパブリックビューイング参加者は自分を含めて3名でした。自分だけだとプライベートビューイングになりかねなかったので良かったですｗ
講義の後は、参加者同士での会話も盛り上がってなかなか楽しかったです。
また機会があればこういうことやってみたいですねー。
