Why doesn’t Office just fix all of the bugs before they ship it
http://blogs.technet.com/b/office_sustained_engineering/archive/2008/12/12/why-doesn-t-office-just-fix-all-of-the-bugs-before-they-ship-it.aspx
以前にもどこかで紹介したような気がするが、Office Sustained Engineering という Office 開発チームのブログで (ずいぶん以前の記事なのだけど) どうして Office 製品のバグが出荷前に無くせないのかについて論じたとても興味深い記事がある。この記事「Why doesn’t Office just fix all of the bugs before they ship it」を訳してみた。
以下の文章は Office Sustained Engineering の 2008 年 12 月 12 日 の記事 「Why doesn’t Office just fix all of the bugs before they ship it」 を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation およびマイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。
なぜ Office は出荷前にすべてのバグが修正されないのか
この記事は、我々が次期バージョンの Office をどのように開発し公開するのかに関する良く寄せられる質問について説明する、関連した 3 つのブログ記事の最初のものです。特に、以下の話題について説明する予定です。
- なぜ Office は出荷前にすべてのバグが修正されないのか ?
- ‘トリアージ’ の プロセス (どのバグを修正するのかを決定するために行われます) はどのように機能しているのか ?
- Office を製品として維持するために今のようなやり方が選択されているのは何故か ?
パート1: なぜ Office は出荷前にすべてのバグが修正されないのか ?
まず明確な事から始めましょう。我々は全てのバグを見つけてはいません。私は周囲に比べて最も聡明ではありませんがそう認識していますし、皆さんにとってもそれは大きな驚きではないでしょう。しかしそれは何故でしょうか。我々の努力が足りないからでない事は保証できます。またバグを見つけるためのプロセスに問題があるからでない事も確かです。我々の開発プロセスではその初日に開発者とテスターが組み合わされ、バグの発見と修正はプロセス全体を通じて他の何よりも優先されます。
実際、根性のあるバグ潰し屋の誰にたずねても、バグを見つけるのは困難だと言うでしょう。幸い我々のテスターはことのほか聡明です。彼らは “簡単な” バグのほとんどすべてを見つけ、さらに “難しい” バグの大部分も見つけ出します。開発チームが予期しないような機能の使い方が必要であるようなバグでさえ白日の下に晒します。しかし何百万人もの利用者が自分の仕事を達成するため想像もつかないような幅広いオプションを設定して Office を利用しています。その結果、我々の製品は、我々が想像もつかないような使い方をされるのです。たとえば我々は新しいスマートなハンマーを作ったつもりだとしても、利用者は結局それを配膳道具のように使い、我々にどうしてこんなフォークを設計したのかと尋ねるのです。シナリオは無限にあり、それを一つずつすべて予測するのはまったく不可能です。これはどんなに優れたテスターがいても同じです。
これに関連して、ソフトウェアのバグは世の中のその他の物に比べて確認しにくいという問題もあります。あるユーザーにとって欠陥のある動作と思える動作が、別のユーザーにとっては完璧で期待通りの動作になります。そのため実際の動作が “意図されたもの” であるかどうかについて開発チームのメンバー間で数えきれないような議論が戦わされることになります。それぞれに観点が異なるための意見の相違もよくあります。我々は、以前のバージョンやベータ バージョン、数多くのユーザー訪問から得られるデータを使い、私たちの見解が最も一般的な利用者の見方となるよう最善を尽くしています。結局の所、そうした視点の表明は気まぐれなもので (心理的に誰かにとっての至宝が別の人にはゴミであるように)、我々の結論も常に正しいとは限りません。
最終的に、すべてのバグは生き残るための巧妙な手口を持っているというのが真実でしょう。バグを潰しても、復活する方法を見つけ出すのです。さらに悪いことに、彼らは異なった、より面倒なバグに変化するのです。ソフトウェアの開発チームでは、これをリグレッションと呼んでいます。バグを修正するにはコードの変更が必須です (私はこの点について明確に理解しています)。コードの変更は別のシナリオでの新しいバグの潜在的な原因になります。リグレッションによっては修正した元のバグより性質が悪い場合もあります。これは ‘アリが良いか、シロアリが良いか’ という問題に似ています。一方は不愉快な邪魔者ですが、もう一方は災厄の原因です。一般的に言えば、災厄を避ける方が良いでしょう。
災厄を避けるようにするということが、我々の製品がバグのある状態で出荷されるもう一つ理由です。これは直感に反するように思えますが、ありていに言って、リグレッションの現実の結果、もし我々がすべてのバグを修正しようとすれば、永久に出荷できないでしょう。これは災厄と言えるでしょう。このように我々は常にこの現実に直面しており、我々が高い品質の製品を期日通りに出荷しようとすると、非常に困難な決断が必要となるのです。
例えば、仮に (実際にはそうではありませんが) 我々がすべてのバグを修正できるとして、それは我々が行うべき最も重要なことでしょうか? またそれは利用者にとって、新機能のメリットを享受できるのが 20 年に一度になるのより重要でしょうか? OEM や ISV やその他の関係者が我々の出荷予定日を計算できるのより重要でしょうか? 競争力のある機能に適切なタイミングで対応することより重要でしょうか? 常に考慮が必要な多数のトレードオフが存在しているのです。
いくつかのトレードオフは明確で、例えば全体的な品質は出荷予定日より重要です。品質に問題があれば、出荷日を引き延ばすでしょう。これは以前にあったことです (覚えていらっしゃるでしょう)。しかし決定しなければならないことの大部分はそれほど明白ではありません。一見明確ではないバグの修正と予定通りの出荷のトレードオフは、告知済みの出荷日が近づくにつれて決断が難しくなります。
こうしたプロセスの実例はこの問題を示すのに役立つでしょう。Office 2007 のリリース後、あるユーザーが多数の問題 (“ゴミ” であり、“お宝” ではありません) を見つけました。特に、Excel ファイルへの複数のリンクを含む PowerPoint プレゼンテーションを開く際、それぞれのリンクを更新する新しい方式 (より多くのメタデータを追跡しています) が原因で、非常に長い時間が掛かることが分かりました。一般的に言えば、これは多数の人に影響を与えるものではありませんが、このユーザーのプレゼンテーションの特性上、これは大きな問題でした。彼らはこのバグを hotfix として修正するようリクエストしました。我々はその修正をしたのですが、少し後になって、そのバグを修正すると外部リンクを含むプレゼンテーションで VBA コードを実行する際にクラッシュしてしまうという新しいバグが発生することが分かりました。このバグは非常に性質が悪く、一つの修正により他のより多くのシナリオが危険にさらされるため、我々は元の修正を破棄し、ユーザーにはパフォーマンスの問題で適切な回避策を取れるよう協力しました。
我々の目標は個々のどの問題についても、可変的な要素に留意しつつ最良の決断を行うことです。こうした目標を達成するため、すべてのバグについて修正をするのとしないのとどちらが最善かを決める ‘トリアージ’ を行っています。この決定を、一貫性をもってうまく行っていくのはいかにも複雑なプロセスです。これにはどのような変更についても賛成または反対の立場から議論を重ねている、多数の経験豊富な開発チーム メンバーの洞察力が必要とされます。多くのの場合、私たちは正しい選択をしています。しかし時に間違いを犯し、一つのバグを修正することでより悪い – 検知できないかもしれない – バグを招いてしまうこともあります。場合により我々はバグの本質を真に捉えているユーザーのシナリオを正しく理解できず、本来修正すべきバグを修正しないと決めてしまうこともあります。このように確かに完全とは言えませんが、トリアージのプロセスは優れたものであり、このブログのシリーズのパート 2 のトピックになるでしょう。
まとめると以下のようになります。我々は品質に問題があれば出荷日を変更しますが、告知済みの出荷日に間に合うようにできる限りの努力をします。また我々はどの Office のリリースでも顕著なユーザーへの影響があるバグはないことを期待しています。しかし残念ながら我々はユーザーが見つけられるバグのすべてを見つけることができず、また一部のバグについて実際にはユーザーに多大な問題を引き起こすものであるのに軽視するという、誤ったトリアージをしてしまうこともあります。これら二つの現実の結果、我々は世界規模の ‘アフター サービス’ 組織となり、過去にリリースした製品に必要なアップデートを提供するため懸命に働いています。こうした努力により、ユーザーに最良の価値ある提案が提供できることを望んでいます。この続きをお待ちください…
投稿: Friday, December 12, 2008 11:09 PM by Dave B [msft]
Hebikuzure's Tech Memo 
コメントを残す