ソフトウェア

Windows開発チームのバグ管理にまつわる裏話を勤続25年以上のベテランが語る


MicrosoftのWindows開発チームによるバグ管理の歴史は、MS-DOSWindows 1.0までさかのぼります。25年以上にわたってWindowsの開発に携わるレイモンド・チェン氏は、自身のブログでWindows 1.0からWindows 10に至るまでのバグ管理システムにまつわる裏話を語っています。

We called it RAID because it kills bugs dead | The Old New Thing
https://devblogs.microsoft.com/oldnewthing/20200317-00/?p=103566

Windows 1.01がリリースされた頃、Windows開発チームのアプリ部門によってバグを管理するためのデータベースが構築されました。データベースの名称はチーム内での投票の結果、「RAID」に決定。RAIDという名称は「Raid」という殺虫剤のブランド名に由来するもので、「Kills bugs dead.(虫を殺す)」というキャッチコピーが使われていたことから選ばれたそうです。プログラムのアイコンには殺虫剤スプレーの缶を模したデザインが採用され、ファイルの拡張子は「RAID Query(クエリー)」の略で「.rdq」が採用されました。


チェン氏によると、RAIDが誕生して数年後、どういうわけかRAIDという名称の由来は殺虫剤ではなく「Reporting And Incidents Database」の頭文字を省略したものとして定着したそうです。しかし誰もその原因を知らず、気にも留めていなかったとのこと。

RAIDを運用していた頃は「プロジェクトのバグをRAIDデータベースに登録する」ことを「RAID a bug」と呼んでおり、RAIDは言葉としてもチーム内で定着していきました。 また、拡張子の.rdqも、「明日レビューするバグの.rdqを送ってもらえますか?」という風に、クエリーファイルを指す独自の略称として定着しました。


RAIDは16ビットアーキテクチャが主流の時代に生まれ、開発当初は3万2767個までバグを登録することができました。当時は十分な容量でしたが、技術が進歩し、Windowsがアップデートしていくにつれて容量が足りなくなり、新しいデータベースに移行しなければなりませんでした。新しく作成されたデータベースに、古いデータベースに残っていた未修正のバグもコピーされ、古いデータベースは読み取り専用で保存されました。

新しいデータベースへの移行で、古いデータベースからコピーしたバグの管理番号がずれてしまったことから、移行した直後はチーム内で混乱が生じたとのこと。例えば、ソースコードの中に「バグ3141の修正」というコメントがあっても、その番号がどのバグを指しているのか分からなくなることがあったそうです。


その後も、Windows 95のサポート期間中に3回、データベースの移行が行われました。RAIDの開発者たちは、自分たちが作った小さなバグ管理データベースが約20年も使われるツールになるとは考えもしなかったようで、実際に開発者の1人は「そんなに長持ちするようには作ってなかった。ごめん!」とチェン氏に謝罪したそうです。

数年がたち、Windows XPの開発プロジェクトが順調に進んでいる頃、社内で同時にRAIDにアクセスするユーザーが多すぎて、サーバーが新しい接続の受け入れを停止してしまうという事態が何度も発生しました。そのため、ミーティングなどでプロジェクトの状況を確認する際など、参加者全員がデータベースに接続できるように、他の社員の接続をいくつか切断するようにお願いすることもあったとのこと。

こういった背景から、Windows開発チームがバグ管理データベースに求めるものがRAIDの限界を超えてしまったため、ようやく新しいバグ管理データベース「Product Studio」が開発されました。Product StudioはRAIDのように登録できるバグの上限はなく、信頼性と柔軟性を向上させるために3層アーキテクチャを採用し、ファイルの添付もサポートしていました。

Product StudioはRAIDに変わるバグ管理データベースとして機能しました。しかし、突然アプリが応答しなくなり、「中間層への接続中にエラーが発生しました」と表示されるバグが頻繁に発生するようになりました。あまりにも同じバグが続くので、チェン氏はよく「中間層は取り除くべきだ」と同僚に冗談を言っていたそうです。


Product StudioはWindows 8が登場する頃まで使用されました。Product Studio以降のバグ管理システムは、バグ管理を含めたプロジェクト管理ツールである「Team Foundation Services」に切り替わりました。Windows 10が登場する頃には「Visual Studio Online」へと移行しています。その後、Visual Studio Onlineは名称が変わり、2020年3月時点では「Azure DevOps Services」に変更されています。

チェン氏によると、Azure DevOps Servicesも、Windows開発におけるすべてのタスクを管理するのに十分な大きさではないようです。古いプロジェクトは定期的にアーカイブされるのですが、残念ながらアーカイブされたプロジェクトは管理番号が変更されてしまいます。しかし、元の管理番号はタイトルとして保存されるため、「コードの中に『バグ3141の修正』と書かれていても、問題なく古いタスクを見つけることができます」とチェン氏は語っています。

この記事のタイトルとURLをコピーする

・関連記事
ボーイングの有人宇宙船「スターライナー」は打ち上げられた後に重大なソフトウェアのバグが発見されていた - GIGAZINE

Googleのお抱えハッカーがWindowsのバグを発見、深刻度は低いがサービス拒否状態に陥る恐れあり - GIGAZINE

「偽のバグを大量に埋め込む」ことでソフトウェアのセキュリティがアップすると研究者が指摘 - GIGAZINE

スプレッドシートに時限式のバグを混入させて仕事を失わないようにしたエンジニアに有罪判決が下る - GIGAZINE

SIerとなって悪のシステムバグと戦い、エンジニアの壮絶なる業務内容を体感できるゲーム「SIerクエスト」 - GIGAZINE

in ソフトウェア, Posted by darkhorse_log

You can read the machine translated English article here.