インターネット個人史

今日でウェブが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 への寄稿記事を若干加筆修正したものです。

ソフトウェアの品質ってなんだろう

 　このブログの主な読者層は「品質保証部」やそれに類する組織に属しておられることと思います。「品質保証部」です。「品質」を「保証」する「部門」です。「品質」を…  クドいですね。しかし、みなさんご自身は「品質」、特にソフトウェアにおけるそれを適切に説明することができるでしょうか。そこで今回は、僕自身もソフトウェアテストという仕事にはじめて触れた時に抱いたギモンである「ソフトウェアの品質って何？」について現時点での解を示してみたいと思います。

歴史にあたろう

　このような大きな概念を知るときは歴史にあたるのが王道です。きっと僕が疑問に思うよりはるか昔から、比べ物にならないぐらいの膨大な時間を掛けて、賢人たちが議論して辿り着いた解が既に存在すると考えるべきです。ただし、広くそれを伝えるために抽象化されているので、明日から現場で使えるほどの具体性を期待するのは筋違いでしょう。ラストワンマイル、現場への適用は常に自らの手で試行錯誤する必要があります。

　閑話休題、それでは賢人たちにおける「ソフトウェア品質の定義」について歴史を振り返ってみましょう。ほぼ時系列に並べましたが、いくつか年代不明であったため掲載していないものがあります。

• ソフトウェアを完全に停止させたり、容認できないような結果を出す欠陥が全くないこと(Capers Jones:恐らく70年代)
• 要件に対する適合(Philip B Crosby:1980)
• 「狭義の品質」と「広義の品質」(石川馨:1981)  
  　狭義の品質:製品の品質
  　広義の品質:仕事、サービス、情報、工程、部門、人、
  　システム、会社の全てを含めた質
• 魅力的品質と当たり前品質/狩野モデル (狩野紀昭:1984)
• 製品またはサービスが、明示してあるか、あるいは暗黙の要望を満たす能力として持っている特性の総称(ISO 8402: 1986)
• システムが本稼働するとき、どこまで真のビジネス(ユーザ)ニーズにあっているかということ(James Martin:1994)
• 品質は誰かにとっての価値である(G.M.Weinberg:1994)
• プロダクトの特性が顧客のニーズに応えることで満足を提供する &不備(障害や誤り)から免れる(Joseph M. Juran:1998)
• 指定された特定の条件で利用する場合の、明示的または暗示的なニーズを満たすソフトウェア製品の能力(ISO 25000:2005)
• 機能及び性能に関する明示的な要求事項、明確に文書化された開発標準、および職業的に開発が行われた全てのソフトウェアに期待される暗黙の特性に対する適合(Roger S. Pressman:200

バグが無いこと？

　1970年代では「バグが無いこと」と定義されていました。海外での変遷は大雑把には「バグが無いこと→要求を満たしていること→暗黙の要求もあるよ→ビジネスニーズもあるよ→もう、何だかわからない(ワインバーグ) →悟りの世界(プレスマン)」という流れです。ワインバーグの言はわかったようなわからないような印象を受けますが、実は品質の相対性という重要なポイントを初めて示しています。筆者の俗な想像ですが、「品質って何ですか？」と訊かれまくった賢人たち、ワインバーグはキレてぶっきらぼうに言い放ち、プレスマンはムキになって説明した、のではないでしょうか。特にプレスマンの言は「それでわかるなら定義なんか調べないよ！」と言いたくなるようなヒステリックさです。

　これだけ品質の定義について幅自体がブレてきたのは、ソフトウェアシステムの社会における存在感、価値の占めるその割合の増加と密接な関係があるのではないでしょうか。掲載した限り最も古い言及であるCapers Jonesの時代にはB2Cなどというドメインすら無かったはずで、社会におけるソフトウェアの役割も小さく「最悪動かなくても手でやるよ！」という牧歌的な頃であったかと思います。時代を経るにつれ、ソフトウェアの利用は効果的、もはや無くては立ち行かないもの、水道や電気と同じぐらい、あるいはそれ以上に重要かつクリティカルなインフラ、とその重要さを増すたびに、人間がシステムに持つ期待がどんどん膨らんでいき、今現在においてもその膨張はとどまることを知らないように見えます。 

Column:

　80年代における日本とアメリカの品質認識の違いはとても興味深いものがあります。「品質」の定義を異様に広くとっている日本に対し、アメリカのそれは「先立つ何かがあり、十全にそれに従えていること」とされています。これは、アメリカのソフトウェア産業が主に軍からの厳密な発注と契約に基づいて発展してきたのに対し、日本はお客様の望む以上のものを提供する、という工業製品における思想に範を置いてきたためと考えられます。「プロセス保証」と「テスト」という軸を並列に置いた時日本では前者が、海外では後者に重きが置かれているように感じるのもこの歴史的経緯とは無関係ではないはずです。  

　日本の定義はさすがお客様第一主義らしく、最初から幅が広く、著名な狩野モデルでは製品自体の品質とユーザの満足度を相対的に表すモデルが84年の時点で既に提唱されています。魅力的品質なんて今でも定量化が難しいのに30年以上前からその端緒をつけるあたり、品質大国ニッポンは伊達ではないです。日本の定義はシステムに限った話ではないのですが、伝統的に工業製品の製造過程を見習ってきたため、ソフトウェア産業においても同様の定義が使われてきたと考えて良さそうです。海外からすると「ニホンすげえよ、奥が深いよ！(でも具体的に何したらいいのかわからないよ)」で、日本からすると「海外の方法論はスゴいけど、お客様が語らないんだよねえ」という印象をお互いに持っていたのではないでしょうか。

"ソフトウェア"品質モデル

　一方、品質を一意に定義する、ことはどうやら難しいと悟った別の賢人達はソフトウェアに限ってその抽象度を一段下げ「ソフトウェア品質モデル」を提唱しはじめます。こちらも時系列に沿っていくつかの例を挙げます。

• Boehm’s Quality Model (Boehm: 1976)
• McCall’s Quality Model (McCall: 1977)
• FURPS (Hewlett-Packard:70年代後半) *のちに+
• ISO/IEC 9126 (1991)
• ISO/IEC 25000 シリーズ SQuaRE (2005) 

　このどれもが今でも使えるものばかりなのは驚愕です。余談ですが、最初に触るものとしてはFURPS+が特性の数が少ないのでオススメです。特徴的なのはFURPS(+)を除きそのどれもがツリー構造を採用している点です。BoehmとMcCalのそれは親特性と子特性が交差しあうN:Nの関係を持っていたのに対し、ISO9126以降では1:Nの構造が遵守されているのは、恐らく普及のためにある程度の単純化が図られたからではないかと予想されます。

　特に有名なISO/IEC 9126は、前述のお互いへのリスペクトが、海外の具体的な計測法と日本の品質の幅を広くとる思想の両方をソフトウェアという分野に限って標準化できた幸福な例と言えると思います。さきほど、人間が持つシステムへの期待は今も膨張していると述べましたが、それはISO/IEC9126から25010への改訂時に主特性が6個から8個に。利用時の品質も主特性が1つ増加し、副特性が正式に定められたことからも伺えます。9126だけでも大変だったのに、更に増えてこの先どうしたらいいのだろうとこの記事を書いている今も頭を抱えています。人間がある程度諦めてくれれば特性も減るのでしょうが、それを言ったら負けな気もするので頑張りたいと思います。

いまいまの解

　気を取り直して。ここまで「品質」自体の定義の例とソフトウェアに限って「品質」を一段具体化した「品質モデル」の例を見てきました。冒頭の質問に立ち返ってみましょう。「ソフトウェア品質って何ですか」。これらの考察を踏まえて解答するなら、現時点では

　「定義自体は以上のような変遷を経て未だに定まり切れていないが、ソフトウェアに限定してモデル化されたものがいくつかある。その中でも網羅性を求めるならISO/IEC9126(→25010)を、使用性を求めるならFURPS+が良さそう。9126は品質モデルの定義と内部/外部品質と利用時品質に分かれており、モデルは6つの主特性と27の副特性から構成され…」

　といった形になり、このあと対象の製品にまでスコープが及べば数時間は話せますが、相手が寝てしまうと思うので、少なくともソフトウェア企業の品質保証部という実戦部隊としての短い答えは、

「既存の品質モデルを製品にテーラリングして良し悪しを語れるようにした概念」

　となります。そこから、その良し悪しを良い方向に導いたり計測したりするための、今現在最も効果的な、パズルのような、”知る”技術として、ソフトウェアテストがあるのだなと理解しています。もちろんみなさんがいまおかれているコンテクストにおいて異論は多々あるでしょうし、僕自身、もっと良い解答を得られる事もこの先あると思いますが、先ず議論自体が行えるように、自分なりの解を用意しておくことも大事かなと思います。

BOKがあるよ。

　なお、本記事の定義はほぼ下記書籍を参考にしています。「ソフトウェア品質保証ってどうやって勉強したらいいですか？」と訊かれた時に脊髄反射で「はいどうぞー！」と渡せる本で、必読です。
 

ソフトウェア品質知識体系ガイド―SQuBOK Guide

---

本記事は WACATE MAGAZINE Vol.46 への寄稿記事を若干加筆修正したものです。

「通り過ぎ症候群」について

造語です。僕自身かつて経験した状態で「え、こんなことが人様の気付きになるのか！？」とびっくりしました。今でもたまにあります。定義は、

「いま自分が学んでいる地点を世間の平均的な知見と捉え、かつて自分がいた時点に今いる人に対して、価値ある情報など持っていないと思い込んでしまう状態」

とし。出力して価値を届けられる状態をスルーしてしまうので「通り過ぎ」と表現しています。学べば学ぶほど謙虚になるため、真面目な人ほど陥りやすいように思えます。学んで、少しでも自分の血肉になっているならそれはものすごい価値のあることなので、あとはマトメ方、構造化や伝えたいことのミニファイだけ気をつけてバシバシ発信してほしいなと思います。

これは

「情報発信者は価値を決めることができない」- 情報論1999 *1  

という原理を学びの課程に置き換えたものでもあります。例えば、今日何を食べた〜 という一見どうでもいい情報でも100万人、1000万人規模、あるいをそれが断続的でも数年に亘って続いた場合、前者はトレンドを作り出し、後者はその人の因果関係を想像できる(例えば健康状態)貴重な情報になります。情報に対して価値を創造するのは常に受け手側ですので、こうかな？と思ったことは躊躇せず発信してみていただきたいなと思います。

*1:Update  https://twitter.com/Shukuguchi/status/405997537145790464