先だってのセミナーも含めて、以前からソフトウェアに対して、軽めの品質管理やテストをどう考えたらいいか思いをめぐらしてた。技術的な考えは後日にでも記載するけど、今日は、アナロジーとして的確と思えるのを見つけた／考えついたので紹介する。
自分自身が少し体育会系なので、以下の「陸上競技ルールブック2012」。（年度でタイトル変わってるかもしれない。）
http://www.jaaf.or.jp/athlete/rule/
ここに”第3部 トラック競技”と”第9部 クロスカントリー競走”があり、さらっと対比してみると良い。そもそもページ数が、38ページと4ページ。トラック競技だとmm単位の記述。クロスカントリーはシーズンだって”冬期期間に行われるべき”とか、”魅力的な”や”おおよそ”なんていう非常に曖昧な表現などが目に付く。
自分でも正確に知らなかったけど、トラック競技での風速測定は定められてて、100m競技だとスタートから10秒間。スタート前の計測でもないし、全員ゴールまでの時間でもない。当然だけど、スタートの記載は”スターターの信号器の発射（閃光／煙）”。
クロスカントリー競走は大抵芝生の所で開催されているけど、ルールブック上は”可能な限り草で覆われた”との表現。自分が事前に想定してたよりも、遙かに記載がアバウトだった。
でソフトウェアの世界では、ここでの例の、クロスカントリーの競技のくせにトラック競技のルールブックで話す愚行を行ってるケースがあまりに多い気がする。
そもそも、競技種目に相当するユーザや必要とされる使われ方が異なるのに、つい同じ土壌（例だと陸上競技）で括ってしまう。それなりの素地（元々のメンバーの能力とか今までの信頼性）があった上で厳密な手法などを話すのならいざ知らず、より高度な技法の説明に終始することもある。せっかくクロスカントリー競技で競う／楽しもうとしてるのに、妙にトラック競技のmmの話を持ち出されて興ざめするようなシーンに近いだろうか。
背景としていろんな手法や技法を知っておくのは良い（悪くない）が、組織体内の議論やセミナーでのグループ討議のための情報では、その組織体やグループに応じた手法や技法を元に議論すべきと考える。
