技術の進歩は「螺旋」である。 @t_wada さん社内講演

先週、新卒技術研修の一環として @t_wadaさん にご講演を頂きました。
題して「この先生きのこるためには」*1。

第一線のエンジニアとして素晴らしい薫陶の数々を授けて下さいましたので、渋谷や六本木の会社さんもオファーしてみたほうがいいですよ。ホント。

エンジニアはアーティストとしての側面も持つので、ファーストクラスの方の考え方に早いうちから触れておくことは、数年先の彼らの在り方に少なからず良い影響を与えるはずだ、という考え*2に基づくおふたりめの社外講師です。おひとりめは当時非公開でしたが、時効になってましたら教えてください。

新卒研修とはいうものの、社食のカフェテリアを全開放した形で既存社員にも受講してもらいました。正直、私も含めた既存社員のほうがよっぽど直接の教育効果は高かったんじゃないかと思いましたが、それはそれとして。ご講演の中でのいくつかの気づきを共有します。

技術の進歩は「螺旋」である

今回最も衝撃を受けて、かつ個人的なブレークスルーになったのがこちらのトピックでした。この業界、基本的に後発有利でして、純粋な実装の能力に関しては、技術が洗練されていく点、学ぶ環境が整備されていく点において若いほうが有利です。年代的にちょうど若者とおっさんの中間地点におりまして、職制はラインマネージャ、職種はQAでありながら純粋実装技術でもそうそう劣りたくないワガママな身としてかなり焦っていたのですが、ようやく戦うすべを得られました。

外から見ると「振り子」

中央集権システムと分散システムの例が最もわかりやすいかと思います。1980年代に全盛を誇ったメインフレームとシンクライアントの関係は、その後のパーソナルコンピューティングへの流れを経て、再度「クラウド」という言葉で揺り戻って来ています。ソフトウェアエンジニアの外からみれば「それ30年前にあったやん」と思えるかもしれませんが「ホストコンピュータ＆シンクライアント」と「クラウドコンピューティング」の間には、wwwの台頭によるHTTPベースのプロトコルの整備やリッチクライアント(もはやこれも懐かしい)、ソーシャルストリームによる情報の即時共有といった大きな技術要素がいくつも積み重ねられています。

つまり「振り子」ではなく、一周して返ってくる間に少し登っている「螺旋」である。と。

これらの差分を加味した上で、なぜこちら側に戻ってきたのか？そして次はどの方向にいくのか？を考えぬくことで、この歴史を知らない人(若者に限らずボーっとしてたおっさん含む)に較べて遥かに有利に個人的な技術戦略を採ることが可能になるのです。なんということでしょう。わーい。

もちろん、エンジニアである以上、技術の大局的な方向性には以前から強い関心をもって眺めていたのですが、これからはこの”少し登っている”部分に注目してより深い洞察を心がけようと思いました。こういうとき「螺旋」のイメージを持っていることで (一見同じに見えて何か増えているはず) という前提を持てることは意外に大事な気がします。

正しい技術が生き残るわけではない

前述の「螺旋」とも繋がるのですが、技術は技術的に正しいものが生き残ってきたわけではなく、使う人だったり、環境であったり、さまざまな要因で決まる、と。

例として、Linuxについてのリーナスとタネンバウムの議論 や、Worse Is Better というエッセーを挙げた上で「大抵は汚くても*3 劣っていてもシンプルなものが生き残る」との見解を示されていました。

技術にもレイヤがあり、例えば初期のFacebookのコードはそれはそれは汚かったそうですが、それが後日世界を席巻したことなどが想起されました。「螺旋」の「差分」を洞察する上で「正しいから生き残った」というバイアスを外すことができるという点で非常に重要な気づきを頂いたと思います。また、+1で「当時技術的に正しかったもの」は何らかの技術のDNAとして一部、あるいはそのまま戻ってくる可能性があるのではないかなと考えるに、何らかの自分が信じた技術にその浮き沈みに関係なく投資をしておくと後日莫大なリターンを貰えそうな気もします。当時まじめにJavaScriptやってた人とか。

エンジニアと企業の関係性が否応なく変わる

ほぼt_wadaさんのお話のまんま、かつ、研修を設計しておいてなんですが、今後「社内だけ」で技術力を一線に保つことは、加速度的に難しくなっていくでしょう。おそらくこれは技術者以外もです。「社外」に対して何らかの看板を建てることでその人に玉石混交の情報が集まり、それをキュレーションして価値にして発信することでまた更に情報があつまる、というポジティブフィードバックの形成を、企業自体が支援していくことが、人材だけが資産であるソフトウェア企業にはMUSTとして求められます。

一方、エンジニアが社外において価値を認められれば認められるほど、企業を移ることが容易になります。経営者にとってはさぞかし辛い時代ではありますが、全力でエンジニアの社内外での成長を支援しつつ、人材自体の流動性を高いレベルで維持する、そのために、社内外に対しいかに自社が魅力的な環境であるかをアピールしつづける、ことが現時点での最善手ではないかと思います。引き続きがんばっていきましょう。

参考(手前味噌):

Wacate2013 s bpp_session from Shinsuke Matsuki

ご講演のあと。アウトプット重要。

受講していただいた新卒社員には「これ社外に向けてどこかに書いてね」とお願いしてあります。ここに挙げた以外にも数々の実践的、観念的両面からの素晴らしい教えを頂いたので、そのうちのいくつかは彼等の何らかの社外への出力でカバーされることでしょう。t_wadaさん、本当にありがとうございました！

本日は株式会社 ACCESS 様にて講演させて頂きました。お聞きくださった皆様、ありがとうございました！ (@ 株式会社ACCESS 幕張研究開発センター) http://t.co/5301MdAAGg

— Takuto Wada (@t_wada) 2014, 4月 24

*1:"せんせい きのこる" が正しい読み方です

*2:別にそれが当社に対するもので無くて良い

*3:誤認。ご指摘により訂正

ソフトウェア品質保証プロセスのモジュール化

ソフトウェアQAテスティングギャザリング というフリーダムな試みがありまして。これはソフトウェア品質保証に関連するアクティビティのアトムを集めて、カードゲームみたいにするとプロセスデザインが楽になるかなと考えて試しにやってみた。ものです。

届ける先自体の変化の速度が速いので、プロセス自体もころころ作り変える必要があり、プロセスを変化させるための仕組みとしてはPFDが著名ですが、似たようなものをソフトウェア品質保証に限ることでより簡単に出来ないかなと思います。

現時点において「方法」は大別してふたつ。

• 作り方を担保するか：これを本ブログではプロセスQAと呼称しています。
• 作ったものを担保するか：これを本ブログではテスティング/テストと呼称しています。

V&Vですね。まんま。プロセスQAは作っている様子をどのように捉えるか。テスティングはどのように知るかがキモになるのですが、どちらでもスタート地点は届けたい価値における品質面/ビジネス面/その他の何かのモデルにすると、とりあえず説明責任は果たせるのかなと考えています。

インターネット個人史

今日でウェブが25周年。その70%をリアルタイムで見てきた世代のひとりとして、極めてパーソナルなウェブ≒インターネット史をまとめてみたいと思います。

Yahoo! Japan

インターネットを買った*1のと同時期にはじまったのがYahoo!Japanでした。当時はクレジットカードなどという危険物は持ち合わせておらず「月々いくら」かかり続けるなんだかよくわからないモノを親に頼むのにはかなり勇気が要りましたが、ナゼかあっさり承諾をもらえて僕のインターネットがはじまりました。いろんな投資をしてもらいましたが、費用対効果をかんがみてこれは会心の一撃だったのではないかと思います。おかげさまでむっちゃ食えてます！ちなみにサービス開始直後のYahoo! Japanはこんなかんじでした。

それしか無かったので名前はついていませんでしたが、後年「ディレクトリ型」と呼ばれる、人力でよさげなページをカテゴリに分けて登録していくタイプです。創業者のジェリー・ヤンは相撲が好きで、最初の検索エンジンのサーバ名がkonishikiだったとのこと。

ジオシティーズ

僕の知る限り日本最初の「誰でもホームページが作れる」サービス。ジャンルごとに街角の名前がついていて(例えば本に関するページならbookland)そのページを訪れた人が何かしらのコメントを残せる「ゲストブック」という仕組みがミソでした。自由に使える素材がどれもこれもケバく、どこをどう頑張っても今で言う「90年代のウェブサイト」にしかならなかったのが郷愁をそそります。

2ちゃんねる

バイト仲間から「おもしろいページがあるよ」というものすごくザックリしたリコメンドをもらって覗いてみたけどぜんぜんわからなくてめったにアクセスしていませんでした。まとめサイトはよく見るくせに未だにネイティブたる2ちゃんねるのほうはあまり見ていません。立てたスレもこの十数年で「Delphiで作られた有名ソフトって何があるの？」ぐらいです。

メーリングリスト

何でも、みんなで集まって好きなテーマで話せる仕組みがあるらしいと聞いて。今も昔もゲーム好きだったので、ゲームについて語るメーリングリストに入っていろいろお話していました。ちなみにここで知り合って仲良くなってよく遊ぶようになって好きになってふられたHさんはその後ポケモンを出す寸前のゲームフリークに入社し、企画やデザインを担当、後日説明書でまんま名前を見てびっくりしました。DSが出た時に「何かアイデアないー？」と久々にメールをもらったのが最後かも。あの頃にGmailが無くて本当に良かった*2です。

テレホーダイとWorlds Chat/J

23時～翌朝8時までつなぎ放題！(56Kbpsでな)というテレホーダイ。このネーミング凄いと思います。もともと接続料金は定額のAT&Tだったので、この時間に限れば本当にページを見放題！IT系に夜型が多いのはこれに原因の一端が無いとは言わせないです。これもバイト先の友達から教えてもらった、当時、、というか今でも画期的だと思う3D空間をペラペラの平面アバターが自由に動き回り、近くにいる人とリアルタイムでお話できる、Worlds Chat/J(略称はWC/J) というソフトにどんはまりしました。雰囲気としてはこんな感じ。いろんな部屋や、隠し通路、裏技があって、それを教え合うのも主要なコミュニケーションで、ベテラン同士になると「神社ね」とかで通じる感じがまたなんとも。画像検索で見つけた時は少しグッときました。

ICQ

アッオーです。僕のICQナンバーは25638612です。"I seek you"のアルファベットよみで”ICQ”。当時はページャーとか呼ばれてた、インスタントメッセージングソフトです。メーリングリストでもWC/Jでも、仲良くなったらとりあえずICQナンバーを交換、というまんま今で言うTwitterアカウント的な存在でした。登録されている友達がいまオンラインかどうかわかる機能の草分けではなかったでしょうか。テレホーダイと同時期に普及したため、23時になると一斉に友達リストがオンラインに変わっていく様子に「いつもの場所に集まっている」という不思議な感覚を覚えました。

Lycos

「ライコスのほうがたくさんヒットするよ」。Yahooのディレクトリもほとんど片っ端から見てしまい、ホームページにもそろそろ飽きてきた頃に耳にするようになった言葉です。当時としては珍しいロボット型の検索エンジンで、Yahooでは探せないあんなページやこんなページが出るわ出るわ。「あるとわかっているページはYahooで。あるかどうかわからないページはLycosで」というのが当時の僕のネットサーフィンスタイル(ﾄﾞﾔ でした。いま思えば「普段の生活に役立つページ」ってほとんど無かったような。どうでしょう。

i-mode

衝撃でした。いままで↑こんなにワクワクしてきたインターネットがいつでもどこでも出来る。本当に鳥肌がたちました。AT&Tはなんと当時からウェブメールを提供しており、メールがどこでも読める！という意味不明の万能感を得たのをよく覚えています。会社の人はご存知かもですが、僕の返信が異様に速いのはたぶんこの頃の逆トラウマです。加えてまさかその数年後に”そのソフト作ってる”会社で働いてるとは夢にも思いませんでした。画像は最初に使ったP501iHYPER。あんた、ホントにハイパーだったぜ。…まんなかのレバーが痛かったけど。

テキストサイトとReadme!

最初のうちは面白がっていたロボット型検索も、たいがいの言葉を探してしまってさてどうしよう？と焦りだした頃に一世を風靡したのがこの「テキストサイト」というジャンルでした。テキストのフォントでフレーズに強弱をつけて、空白でテンポをつけて日常やニュースを何倍も面白く伝えるスタイルは「侍魂」がパイオニアだったと思います。そういえば「ウェブサイト」って言葉もこの辺から定着しだしたように思います。恐らく「トップページ」と「おしながき」という構造が一般化してきたため「ページ」という表現がそぐわなくなってきたのではないかと。「侍魂」を皮切りに雨後の竹の子のように増殖したテキストサイトをまとめていたサービスが「Readme!」です。友達のサイトもけっこうここでいいランクに居たと思います。

BIGLOBEとCGI

AT&Tでも2MBという十分なホームページ容量がついてきていたので、そこで自分なりの静的なページをつくっていたのですが、コミュニケーションが発達していくにつれ、どーーーしても掲示板を置きたい。しかし、AT&TではCGIが使えない！ということで当時かなり限られていたCGIが使えるプロパイダであるBIGLOBEに乗り換え。当時運営していた個人サイトには常連さんが10人ぐらい来てくれていたので、定期的にオフ会を開催していました。オフ会！うわあ！相互リンクが友情の証で、いくつかのサイトさんと合同のオフ会なんかも。オフ会！うわあ！

ちょうど友達もウェブサイト開設真っ盛り。その友達のひとりに自分のサイトで自作のmidi(うわあ！)を公開している人がいて、ダウンロードしてきたzipを解凍すると、中にはその楽曲に対する思いや制作ノートを綴った readme.txt が付属していました。なぜか当時はこの readme.txt をものすごく羨ましく感じて「僕もreadmeが書きたい！」(でも音楽とか作れない)「…よし、フリーソフトを作ってそこにreadmeを入れよう！」という今考えても本当に意味がわからない動機でソフトウェア制作*3を覚えました。3本目ぐらいの作品が窓の杜とかに載って、月に10冊ぐらいCD付きの雑誌が送られてくるというはじめての体験もこの辺です。

Google

「Lycosより”いい感じに”ヒットする検索エンジンがあるよ」という顧みて実に的を射たリコメンドをもらって使っていたのがGoogleです。ちなみに初めてGoogleを見た時の印象は「検索するとこが横にながーい」です。今でも思います。しばらくしてIT系の会社に入った(まだ居る)のですが、その当時は「ホームページ(この頃は既にブラウザの設定名)にGoogleを指定するのがオシャレ」という謎の風潮がありました。

mixi

このへんからもう「イマドキのウェブ」ではないかなと思います。職種に「ウェブ系」というジャンルが出てきたのもこの辺でしょうか。けっこう初期に登録していてユーザIDが4万台です。自分のサイトを更新するより日記のほうが反応が多いのが嬉しくてしばらくはこちらを更新していましたが、mixiの友達は90%ぐらい非IT系にも関わらず技術的な話が多いのがちょっと申し訳なく、そういう話ははてなダイアリーに移して、いまこちらになってます。

---

リアルの思い出はだいたいその時々の流行歌と紐づくのですが、ネットの思い出が紐付かないのはたぶん「文字を読んでる」からかな、とふと思いました。おかげさまで人生が500倍(当社比)ぐらいおもしろくなったインターネットへ感謝をこめて。

*1:誤用ですが感覚としてはこれが近い

*2:残るから

*3:最初は"上手に"作ろうとかいう発想自体無かったので正しく制作だと思います

プラクティカルクオリティモデルのメモ

けっこうな数の運用を経て型が出来てきたのでメモ。

何がうれしいの？

品質保証の活動(主にテストとプロセスQA)について

• なぜそれで充分と言えるのか？
• なぜその活動が大事なのか？

が自分の意見で説明できるようになります。字面で見ると響かないかもですが、現場の品質保証活動の最上流から自律的にブレイクダウンできると手を動かす場面へのトレーサビリティが確保できて、結果として周りを動かす大きな力になります。

成果物は品質特性をコンテキストにあわせて狭めたもの

品質特性は非常に数が多くその全てを適用した品質保証体制を敷くことは出来ず、ステークホルダー全員がわかる何らかの基準なり思想にそって削ぎ落とす必要があります。戦略とは戦いを略すと書くとおり、品質特性全てに向かって戦うのは上策ではありません。略すのはいいけどその課程には筋を通したい、そのためのメソッドがこのそぎ落とし方のモデルです。

そぎ落とし方のモデル

このそぎ落とし方のパターンを適用して、そのプロジェクト、ビジネスにとって最適な量のモデルに作り変えたものをプラクティカルクオリティモデル、とよびます。造語です。クオリティモデルのままだと、公的に定義されているものと見分けが付かないからです。Practical は 「(理論上ではなく)実際の, 実践的な, 現実的な」とかいう意味です。なぜメソッドではなくモデルなのかというと、このフィルタ自体も構造を持つことが多かったからです。

具体的にはどんなモデルがあるの？

ビジネスリスクベースド

いま一番熱いそぎ落とし方。ステークホルダーの納得度が違う。
これはサービス開発向けのモデルが確立できてきたところ。
向かうビジネスにとって何ができなければヤバいか？を優先付けする。
サービス開発の現場では変更性＝CIをかなり高くおいてみている。

ドメインベースド

これが出来ると仕事がかなり楽になるので頑張りたい。
多業種多ドメイン垂涎。
モバイル、ウェブ、組み込み、などドメインにとって
当たり前に期待される部分と自分たちが表現したい品質を
モデル化する。

ゲーミフィケーション

DevQUTで紹介した方法。機能を含めた品質をボスに見立て、
プロセスをマップに見立て、各種特性のHPをゼロにしたらDONE!ってやつで、
とっても楽しいです。

プロジェクトオリエンテッド

最初のモデルはこれ。すさまじくアタマをつかう。でも、プロジェクトメンバーの意識を品質というボードに乗せて同期できるところは非常に良かった。

RedmineのREST APIで特定プロジェクトの全チケットを取得しようとして失敗する

出来そうで出来ない、かゆいところにいつもあと1センチ届かない、RedmineのREST APIの振り回されメモ。

基本形

チケットの情報を取るときはRedmineのApplication Rootから issues.xml にパラメータ渡してGETが基本的な形(issues.jsonでも可)。API_ACCESS_KEY は個人設定のページで各自発行できます。

https://redmine.server.com/redmine/issues.xml?key=API_ACCESS_KEY&project_id=PROJECT_ID&limit=100&page=1

この時limitを指定しないと先頭から25件しか取得できないことに注意。
チケットが100件以上あるプロジェクトでも、一度に取得できるのは100件まで。

で、前述のリクエストを投げるとこんなのがルート要素として返ってきます。

<issues total_count="471" offset="0" limit="100" type="array">

この total_count を limit で割った数(+1)だけ page があります。よって、この例では先頭のリクエストの page パラメータを 1〜5 までカウントアップしながら、5回リクエストを投げないと「全てのチケット」は取得出来ない、ということです。面倒ですね。

ページ数分リクエストする

考え方としてはざっくり↓こんな感じ。(リクエスト1回多いですが、やってることわかり易く。

request_url = "https://redmine.server.com/redmine/issues.xml?key=API_ACCESS_KEY&project_id=PROJECT_ID&limit=100&page=1"
response = http.request(request_url) #https対応のclient作っておく
xml = Nokogiri::HTML.parse(response.body, nil, "UTF-8")
total_count = xml.css("issues").attribute("total_count").value
limit = xml.css("issues").attribute("limit").value
pages = total_count.to_i / limit.to_i + 1 #何ページ(=何回)リクエストするのか計算

pages.times do |page_number|
  request_url = "https://redmine.server.com/redmine/issues.xml??status_id=*&key=API_ACCESS_KEY&project_id=PROJECT_ID&limit=100&page=#{page_number + 1}"
  response = http.request(request_url) 
  full_xml << response.body
end

ところがどっこい

とりあえずこれで full_xml に「そのプロジェクトのチケット全部」が入る、、、ハズだったのが、なんと status_id=*(OpenとClosedを両方とる) が効かずにOpenしか取ってこれていないことが判明(Redmine 2.3.1.stable)。燃え尽きたよとっつぁん。

落ち込んだりもしたけれど

いまは CSV Export で元気です。たぶん。

追記

status_id=* はURLエンコードしてあげないとダメっぽいです。status_id=%2a。で、これで全部取れたとしても5個のxmlなりjsonなりを結合してからFull Parseという手数が待ってますので、CSV Export から二次元配列をゴニョゴニョしたほうが早く感じるのはトシなんですかね…。

「北の国から」の初期、なぜ純と五郎さんは敬語で会話しているのか？

スペシャル版の断片だけ観ていていつも疑問に思っていたのですが、テレビドラマ版(全24話)を初めて通して観ていたところ第8話で、純と蛍が通う中ノ沢分校の教師、涼子先生(原田美枝子)からズバリ訊かれていました。

涼子先生「ひとつだけ伺っていいですか？」
五郎さん「なんすか？」
涼子先生「黒板さん、どうして純君に対して丁寧な言葉でしゃべるんですか？」

桃井かおりを彷彿とさせる気だるい雰囲気でテレビドラマ当時の登場人物の中でも異彩を放つこの涼子先生、事実上の最終回となる 2002・遺言 で再登場し、純と結が出会うきっかけを作ります。

涼子先生「蛍ちゃんには普通のしゃべり方するでしょ。 …前から不思議に思ってたんですね。あれ、何か理由があるんですか？」

はい。視聴者も本当に気になってました。これをうけて

五郎さん「…。 …いえ」
涼子先生「…」
涼子先生「…余計なこと言ってごめんなさい」
五郎さん「…。 とんでもないす」
涼子先生「…」
五郎さん「…」
涼子先生「じゃ、良いお年を」
五郎さん「良いお年を」

…ええええええ。「理由があるんですか？」との問いに対してそのまま「いえ、特に」ということと思いますが、視聴者生殺しです。

お話は続き、この第8話のラストシーン、正吉の家に紅白を観に行ったはずの純と蛍が、笠松家の家族団らんに入りきれず、自宅に戻ってきたところで五郎さんが「富良野の街の灯を観に行こう」と誘い出します。富良野の夜景を見下ろしながら今年一年の子供たちの労をねぎらい、五郎さんは純に語りかけます。

五郎さん「純」
純「はい」
五郎さん「父さん、これまで君に丁寧な言葉を使ってきた。…そういうつもりは無かったが… いつからか、そういう習慣ができちまってた。でも、もうやめる。今からやめる。…だから、おまえもやめろ」
純「…はい」

五郎さんは言葉少なではあるものの、自らの言動を改める旨を純に伝えます。結論として、作中で理由が明確に述べられることは無いようです。

富良野に引き取るまでの間、子育てをほとんど奥さんに任せっきりにしていた引け目と、長男である純を一個の男性としてきちんと扱いたいという相克が不器用な五郎さんの性格と相まってこのような接し方として現れていたところで、先ずもって親子の信頼関係を築く必要がある、ということに五郎さんは直感的に気付いたのではないかと想像しました。

「北の国から」タイトルからは想像も付かないぐらい、どろどろの人間ドラマ(しかも20年越し！)ですので、大自然と純朴な住民たち、みたいな先入観で敬遠されていましたら、是非観てみてください。途方に暮れると思います。回想シーンが多いため、意外とスペシャル版のどこから観てもすんなり入れます。

北の国から スペシャルドラマ版8巻（DVD12枚）セット　 (マーケットプレイス DVDセット商品)

これまでテスト設計をしてこなかった組織がテスト設計をはじめると、なぜ一時的にバグが出せなくなるのか？

　わかります。これまったく同じ体験を7年ぐらい前にしました。もちろん「テスト設計」と自信を持っていえるような大層なものでは無かったのですが、それでも一応考えて、こうかな？こうかな？と仕上げたものでいざテストを実行！するとまあこれが出ない。びっくりするほどバグが出なくなり、自分の方針は間違っていたのかと懊悩したことがあります。もしかしたら同じ境遇にいるかもしれない新米テストマネージャのみなさまへ、そのカラクリをお届けいたします。

　端的には

1.テストを作る、行為自体が既にテストになっている
2.人間が書かれていることしかやらなくなった

からです。ほぼショートアンサーの裏返しですが、この現象が起こる現場はおそらく下記のような前提にあるはずです。

1.これまでテストケースが事前に準備されたことが無い
2.歩く製品知識かつ、ものすごく頭のいい、または観察力のあるテスターがいる

詳しく見て行きましょう。

1.これまでテストケースが事前に準備されたことが無い

　特別なテスト技法を活用しなくても、例えCPM (コピー・アンド・ペースト・アンド・モディファイ：要するに仕様書から仕様をコピーして、語尾を「〜すること」に変更するだけ) 法オンリーであったとしても、仕様書を別の文書で表す課程で「この仕様はあの仕様と衝突しないだろうか？」「この仕様記述は明らかにｘｘという標準や規約に違反している」という気付きが生まれます。この気付きを開発チームに確認するとその時点で誤りに気づき、ソフトウェアが正しく実装されます。このとき、テスト仕様書を変更せずにそのままテストを実行すると件のテストケースの結果は概ねPASSEDとなるはずです。バグ、出ませんね。

　ただ、これでさえ課題管理システムが整備されていない組織であれば、うっかり修正するのを忘れていたというどうしようもないミステイクを検出することができますが、ともあれ仕様書のレベルが低ければ低いほど、テストを準備するだけで多数のバグが発見されるはずです。これは、品質コストの概念からすると凄まじいコスト対効果となります。なりますが、どう考えてもレベルが低すぎるところで活躍している、いうなればレベル10の勇者がスライムの群れを相手に無双している状態に過ぎません。このような状況にあるテストチームはテストを作るより仕様書の質の改善を手伝ったほうが大局的にはそのグループのためになると思われます。

仕様書 というとどうしても大仰なドキュメントを想像しがちですが、チラシの裏に書かれたログインフロー、ホワイトボードに殴り書かれた権限仕様、プロジェクトマネージャがよく覚えている機能仕様 すべて含みます。

　開発チームの成熟度が向上してくると、やはりまた検出率は落ちてくることでしょう。その時こそ、さまざまな網羅の方式を提供してくれるテスト技法や、ターンアラウンドタイムの速度を上げるテスト自動化、はたまたテスト分析の方式自体を変えてみる、など自分たちの方の技術を向上、拡大させることで、また検出率を向上させる。それに応じて開発チームがまた技術力を上げてくる、という正のスパイラルが起こるようになると、あとは放っておいても素晴らしいチームが出来上がると思います。楽しいですね。

2.歩く製品知識かつ、ものすごく頭のいい、または観察力のあるテスターがいる

　ソフトウェアテストの数ある(ありすぎ)分類方法の中に「スクリプトテスト」と「探索的テスト」という分け方があります。前者は(スクリプト：台本を)予め用意してからコトにあたる方針で、後者はテスターが頭の中でテスト設計を随時行う前提でいきなりテストを実行する方針をさします。どちらの方針もテスト分析だけは予め行なっておく事が多いようです。

　「探索的テスト」はテスト対象のリアクションを見ながら次にどんなデータを、あるいはどんな観点をあてて見ようかと考えながらテストを実行していくため、膨大な製品知識はもちろんのこと、そもそもそのソフトウェアがどのような前提で動作しているのか、という下回りの知識、ともすればセキュリティやユーザビリティなどといった非機能要件に列挙される分野の知識も要求される、非常に高度なスキルです。準備するコストがゼロに見えるので一見夢の様なテストと思われがちですが、テストマネジメントの観点から見ると「最初のひとつめのバグを見つける速度は最速だが、どこまで網羅したのか分からない」というレポートを書くときに困る性質を持っています。これをマネジメントする方法もいくつかあるのですがそれはまた別の話。

　閑話休題。なぜ掲題のような性質をもつテスターがいる状態ではじめてテスト設計をすると検出率が落ちるのでしょう。おそらく、テストを準備するという施策を打ち出す前は、製品をポンと渡して「少し見てくれない？」といったオーダーに対し、そのテスターは無意識に前述のような「探索的テスト」を行なっていたはずです。製品がポンと渡される、状況であればテスト分析など夢のまた夢、ということは探索する範囲も「基本的に無限」であったはずで、それこそ縦横無尽に製品を駆け回り、バグの匂いを天性の勘で嗅ぎつけ、それを検出していたことでしょう。こういうテスターに”順番に実行していく”タイプのテストを行わせると、これまで無制限に発揮されていた想像力がまさしく「台本」によって制限され、どうしても課された定量的なタスクをこなす方向に意識が行ってしまいます。

　ではどうすれば良いのでしょう。実はこのようなテスターはたとえどれだけスクリプトテストの技術が発達しても得がたい特性を持っていますので、そのまま「少し見てくれない？」型のテストを実行してもらったほうがテストチームにとっても幸せな結果となります。とはいえひたすら「少し見る」では飽きるはずですので、ついでに「なぜここを見ようと思ったか」「なぜそのようなデータを入れようと思ったか」という思考のリバースエンジニアリングとも呼べる課程を文書に起こしてもらい、それをスクリプトテストを開発する際の重要な資料として利用すると良いでしょう。また、その瞬発力を最大限活用できるよう、複数の製品を担当してもらう、のも有益かもしれません。

以上「なぜテスト設計をすると一時的にバグが出せなくなるのか？」の種明かしでした。後者の天然探索的テスターはどうしようもありませんが、前者は明らかに組織のレベルの低さに起因しており、気に入ったのでもう一度言いますが、レベル10の勇者がスライムの群れを相手に無双している状態です。まずは相手を育てて、心からゲームを楽しめるようにしたいところです。

本記事が、新たにテストマネージャになった方への何かのヒントになれば幸いです。

---

本記事は Software Testing ManiaX Vol.8 への寄稿記事を若干加筆修正したものです。