障害管理のお仕事をしていて気分が悪くなったので（なぜ障害の原因が不明なのか、を説明すると丸一日になる。１時間目は「UNIXの誕生」、２時間目は「UNIXにおけるプロセスという概念（汎用機におけるジョブ・タスクとの違い）」、休み時間の体操「RAIDのIはinexpensiveのI」、３時間目は「UNIXにおけるプロセス管理」、４時間目は「プロセスの生成と消滅」、５時間目は「MS-DOSの誕生」・・・）ちょっとうさばらしをしたくなりました。コンピュータネタ、目次へやり玉に挙がるのはVisual Studioの開発現場から（第2回）ね。
さて、マイクロソフトというバグがいっぱいの製品を出す会社。どうしてあんなにバグが多いのでしょう。表だって死者こそ出ていませんが、三菱自動車の社員は「なんでうちがリコール隠しでぶつぶつ言われるのに、マイクロソフトは平気なんだ」と多少は思っている事と存じます。私も「なんで皆様の机の上のMS-Windowsが止まっても何もないのに、あたしがたまたま知っているMS-Windowsのサーバが青くなると私が文句言われるんだと思います。
普通に考えると、彼らは出荷前に何もテストをしていないと思いますが、この記事を読む限りではきちんとテストをしているようです。不思議です。多分VisualStudioだけテストをやってMS-Windowsはやっていないという事情があると想像されます。しかし、そこは同じMicrosoft、やはりVisualStudioのテストチームもどこかでテストを忘れているにちがいありません。ここはもう一度じっくり読み返してみましょう。
テスト・チームが最終的に承認しなければ，その製品の出荷はできないのです。ですって。日立ソフトウェアエンジニアリングはテストチームが出荷停止権限を持っていることでトム＝デマルコ氏にも高く評価されています。マイクロソフトも同じレベルとは初めて知りました。すばらしい。なのにどうして製品にバグが多いのでしょうか。やはりテストのどこかに欠陥がありそうです。もう少し読み進めてみましょう。テスト・チームの作業は，多岐にわたります。以下に主なものを3つに分けてまとめてみました。なんとなく推測できます。この人たちはテストの計画を立ててからテストの仕様を作成しています。これは逆ではないのでしょうか。テスト項目を洗い出すなどしてテストの仕様を作成してから、それを期日内に消化できるようにテストの計画を立てるのが普通のように思います。
（1）テストの計画を立てる
（a）テスト計画書を作成する
（b）テスト仕様書を作成する
（c）品質基準の策定に参加する
（2）テストを実行する
（a）テスト手順を作成し，それを保守する
（b）テスト自動化の仕組みを開発する
（c）テスト支援ツールを開発する
（d）ビルドしてできた生成物に対して定期的にテスト手順を実行する
（3）テストの結果を報告する
（a）バグを報告し，その修正状況を追跡する
（b）報告したバグが修正されていることを確認する
（c）各機能の品質基準への達成度を報告するさらにその後に「品質基準の策定に参加する」とあります。普通は品質基準が決まってからテスト仕様ができるのが当然なのでしょうがマイクロソフトでは違うようです。素直に読むと出荷日にあわせてテスト計画を立てる→計画（露骨に言うとテスト日数）にあわせてテスト仕様を決める。→テスト仕様をクリアできるように品質基準を定める。という開発をしていることになります。これでは、バグがつぶしきれないはずです。
項番(2)において「テスト手順を保守する」というのが理解不能な言い回しが出ています。これは私が無知だからかもしれないので何も言いません。でもテスト自動化の仕組みを開発するというフェーズが入るのは・・・あとを読むとテストが自動化されているということだから・・・素直に考えると、JUnitみたいなツールをそのたびに開発すると言うことでしょうか。す、すごすぎる。テストツールのテストをどうやっているかみたい。テストツールこそ実績のある、安定したモノを使うべきでしょうに。そういえば昔あった「Microsoft Test」という製品、いつの間にか無くなりましたね。やはりその都度ツールをプログラミングしているようです（後で出てくるがVisualBasicなどで作っているそうだ）。
項番(3)テストの結果を報告する、の(b)もちょっとクラっと来ますね。修正の確認って・・・再テストじゃないの？つまり普通は項番(3)の(b)の代わりに「品質基準が達成されるまで上記(2)(3)を繰り返す」とあって、項番(4)を作って(3)-cの「各機能の品質基準への達成度を報告する」を入れませんか。つまりマイクロソフトでは「原則テストを１度しか回転させない」。もちろんこれは文章表現だけの問題かもしれません。しかしもし、構造化プログラムを学んだ経験のあるプログラマであれば、私のような表現を使うはずです。つまりこいつらプログラミングの基本３構造を知らない。
マイクロソフトではプロジェクトの初期段階からテスト作業も開始し，プログラム・マネージャ（マイクロソフト社内ではPMと呼ばれている）による設計作業や，プログラマ（マイクロソフト社内ではDevと呼ばれている）による実装作業とほぼ並行して進める体制を採っています。なるほど、eXtremeProgramingで提唱されている方法に近いことをやっているのか。ならばテストの順序に多少のずれが出てくる事はあり得るでしょう。（それでもテスト計画がテスト仕様の前に来ることはありえんぞ。）しかし、ここで大きな疑問が湧いてきます。マイクロソフトが日本でやっているのは、要するに合衆国製ソフトの日本語化だろ。つまり普通の意味での開発とはちがうだろ。途中では日本語と英語の混在環境になるだろ。大丈夫？
つまり、テストの位置づけに対する考え方からして間違っている可能性がある。
作業が主にローカライズであるとするならば、合衆国本社のテスト仕様を持ってきて、言語にとらわれない部分と、言語固有の部分に分けるなどしてから、どのテストを行うか／行わないか、日本固有の部分として何を行うか（たとえば禁則処理）を検討するという作業が入るだろうが。んでもって必要なモノについてテストツールの日本語化をやって、、、そんな感じで進むんだろうが。多分、そうしているのだろう。傍証ながら裏打ちする事実はある。日本独自の製品であると考えられる「はがきスタジオ」、極めて品質が悪い。この会社にはテストを１からデザインできる人材がいないからこうなるのだ。普通は合衆国本社のテストをローカライズする作業しかやっていないからこうなるのだ。
とすると、このWindowsコラム、何を説明しているんだろうね。多分合衆国のテスト説明を日本語化してそのまま書いているということか。でも出来れば合衆国の製品をローカライズする事に特化したテスト技法なんかを書いてほしかったなあ。実はそれが大事なのだ。
そんなことを言うのは、これが「派生開発」のよいモデルケースになるかもしれないからだ。
システムクリエイツの清水吉男さんによると、コンサルタントとして多くの会社を回って開発標準を見てきたが《「標準」と呼ばれるものの中に、「新規開発」のパターン以外は見たことが》ないそうです。実際には既存のシステムを元に修正する「派生開発」の方が多いというのに。
たしかに、開発というと新規開発の方が、派手だしかっこいいし、新規開発手順を手直しすれば派生開発にも適用できそうだし、標準手順は新規開発をモデルに作りたくなるものです。しかし、派生開発の標準を作ることも大事でしょう。が、やっぱり政治的につくりにくいんだよね。ならマイクロソフトの日本法人という派生開発ばかりやっていると堂々と言えるところの開発プロセスを参考にしてみたいな、とか思うわけだ。が、その辺がおくびにも出てこないと言うことは・・・この会社、開発プロセスが・・・ない。CMMIで言うとレベル１だわ。コラムの最後にこんなのがあった。
◆会社紹介◆ 「マイクロソフト プロダクト ディベロップメント リミテッド」は，日本のマイクロソフトの中で研究開発を担当する会社。日本のマイクロソフトの組織は，3つの会社で成り立っており，ほかにマーケティングや営業を担当している「マイクロソフト株式会社」，サポート業務や製品の製造・流通を担当している「マイクロソフト アジア リミテッド」がある。つまり「がんばれゲイツ君No.136」で紹介されている「弊社（マイクロソフト株式会社）はソフトウェア使用権の許諾等を重な業務にしており」という文言、実は妥当だったのです。なおこのコラム、実は続き物だそうです（全部で10回もあるそうだ。楽しみ楽しみ）。で、第１回を見ると、マイクロソフト製品の品質が悪い実にもっともな理由が分かります。
・プランニング：私はここに属しています。開発ツール以外の製品にはあまり見られない例外的な部署です。主な仕事は製品の改善要求を出すことです。 ・・・（中略）・・・ このような製品品質の低下を開発内部で事前に防ぐため，開発工程の全体を開発の当事者から一歩引いたところで監視するのが私の仕事です。おい。製品品質の低下を防ぐための監視を行う部署が開発ツール以外には存在しないと言っているのか？君の会社は。インハウスの開発ならいいかもしれない。ユーザーの受け入れテストという圧力があるからね。でも、シェリンクラップでしょ。放っておくと品質は下がり放題になるよ。
教訓：テスト部門は営業の都合で動くものであってはいけない。製品品質の低下を防ぐという意味で独立した権限をもたなくてはならない。