Hebikuzure's Tech Memo

2010年8月2日

バグのトリアージ – それってどういう事?

Filed under: Microsoft Office — hebikuzure @ 10:08 AM

Triaging bugs – what’s that all about?
http://blogs.technet.com/b/office_sustained_engineering/archive/2009/02/12/triaging-bugs-what-s-that-all-about.aspx


この記事は、この Blog の 5/31 の「バグはなぜ無くならないのか – Microsoft Office チームの Blog から」の続きとなる、Office Sustained Engineering Blog の記事「Triaging bugs – what’s that all about?」の私訳です。この続きの記事「What does it mean to be a world class servicing organization?」も時間を見つけて訳して掲載する予定です。Microsoft のバグ修正のプロセスに興味がある方は、ぜひ前の記事と併せてご一読ください。

以下の文章は Office Sustained Engineering の 2009 年 2 月 12 日 の記事 「Triaging bugs – what’s that all about?」 を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation およびマイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


バグのトリアージ – それってどういう事?

Dave B [msft] 12 Feb 2009 1:58 PM

困難な決定を下すということは (覚悟してください) … 困難な作業です。当たり前でしょう! 下す判断のすべてが容易なものであってほしいのですが、私は困難な判断を下すのなら「三人寄れば文殊の知恵」だと信じている人間です。もちろんあまりに多くの人が関わっているのなら、数だけが問題ではありませんから返ってくる声を減らす可能性はあります。これは実に考え方の問題です。より独創的な考え方ができれば、より良い判断ができるようになります。私は悪い判断ではなく良い判断をしたいのです。私の父は常に私には明確なことに対する驚異的な理解力があると言っていました – それは私にとって素敵なことだと思っていました。

以前の投稿で、次期バージョンの Office を出荷する際に行わなければならない困難な決断の性質について述べました。それではそうした決断はどのように行われているのかとお思いなら、この記事が役立つでしょう。私の書き出しでご想像のように、私たちは幅広い視点を含むグループによって行うのが最善だと信じています。

個人的には、トリアージという用語はテレビ番組の “M*A*S*H” で初めて知りました。誰かが見ていた訳ではないですが、正直に言うとこの番組から人生についてより多くの事を学びました。皆さんがご存じのように、トリアージという言葉は典型的には医学の用語で、「多数の患者の診療の順番を決めるため、病人や怪我人に緊急度を割り当てる事」です (私ではなく辞書がそう言っています)。「私たちはいったい何をしたらいいんだ?」という疑問への答えがそれだと私は考えました。

トリアージの考え方にグループ ディスカッションは必然的には含まれませんが、私たちにとってはそれが全てです。繰り返しになりますが、それは単なる数の問題ではありません。洞察力への情熱をもたらすような経験を有する人々が一堂に会するという点が問題なのです。ここに誰をグループに加えるかを考える視点があります。

第一に、機能を開発したチーム – デザイナー、開発者、テスターです。このグループは、その機能に最も努力を注いだ人々です。機能は彼らの言わば子供です。この人たちは機能が完璧である事を願っています。誰も自分の子供が厄介者だとは言われたくないですから。このグループは特に客観的になる事が難しいかもしれませんが、コードと、そのコードの変更に伴う潜在的なトレード オフについて最も広範な知識を持っているグループでもあります。彼らはトリアージで最も上位のメンバーである必要はありませんが、Office の文化において、私たちが新鮮さを失わないようにするためには新人の際立った声が重要です。言うならばこのプロセスにおけるチップクリップ (ポテトチップの袋の口を閉じるクリップ) のようなものです。

次に、カスタマー サポートの専門家 – 私たちの顧客と直に接した仕事をしており、顧客が私たちの製品から何を望んでいるのかしっかりと把握している人たちです。彼らは業界の中で誰よりエンタープライズ ソフトウェアについて理解しており、私たちが顧客のニーズをリストの最上位に保つように気遣っています。その他の専門家も、国際的マーケット、コンテンツ、セキュリティー、アクセシビリティー、その他のいつくかの分野についての特定の問題に対応して、グループに召集されます。

最後に、ソフトウェアの出荷についての広範な経験を持つマネージャーのグループです。彼らは何度も高品質な製品をタイムリーに出荷した体験を有してして、トレードオフについて理解する際に豊富な経験をもたらしてくれます。トリアージ チームはOffice のすべての製品のマネージャーと上級エンジニアで構成されており、一部の人は 20 年以上も Office についての仕事をしています。彼らはこのプロセスに貴重な、円熟した視点をもたらします。

間違いが無いように言っておくと、異なった視点とは異なった意見を意味します。トリアージ ミーティングは、皆が元気になるクンバヤ (訳註 : Kumbaya、歌の名前) を歌うためにキャンプファイヤーの周りに集い、友達同士が抱き合うような大人数のグループとはまったく違う事を保証できます。どちらかと言えば、それは (準備はいいですか?) 自分の見方が正しいと信じている情熱的で博識な人々を魅了する、言葉による格闘試合のようなものです。あなたと違い私はそうした罠におちてしまいそうですが…。結果として、ほぼ間違いなく見解の不一致が生じます。見解の不一致は議論を生じさせ (白熱した論争とも言えますが)、時には議論が激しくなり時間もかかるため、全体のプロセスに価値があるのか疑問に思われるかもしれません。毎回毎回トリアージのプロセスにどれだけの意味があるのか、私たちは気にかけています。複数の考え方は良い決定を下すのに必要であり、よい決定は製品をより良く完成させるのに必要です。大抵の場合、このプロセスは良い議論を 1 回か 2 回 (か、100 回) 行いますが、プロセスの最後では製品の品質に帰結するそうした議論がどれだけ貴重であったか、皆が理解する事になるのです。

トリアージでの決定に魔法の公式はありません。そこには問題の深刻度や、問題の発生するシナリオがどの位出現するのかなど考慮すべき多数の事柄がありますが、これらを一つの公式に還元しようとしてもそれは機能しません。どの問題も特定の顧客のシナリオがその背後にあり、それは人手をかけて問題を評価し決定を行う事が必要な、意思決定のレベルに関係しています。公式に依るのではなく、最良の判断では常に性急な対応に飛びつく前に、優れた質問が得られるまで議論を煮詰めているのです。出荷が近づくと、トリアージ グループは全ての問題と提案されている変更について注目し、最も基本的でかつ重要な問いかけをするのです。「それには意味があるのだろうか?」 私の 9 歳の息子ももっとこの疑問を持つと良いのですが….

毎回のトリアージの議論/論争で舞い上がった埃が治まると、結論はいつも同じになっています。トリアージを行ったグループは「私たちはいったい何をしたらいいんだ?」という疑問に答える際、最終結論が最も理に叶っているものだと信じているでしょう。それは、個々のトリアージのメンバーは、他のメンバーの考え方が特定の問題に対してより有効だと信じるであろう事を意味しています。本当の話、これはなかなかに困難な事なのですが、しかしトリアージ グループは私たちが私たち自身とその考え方について見通す手助けをしてくれます。それは愉快な課題である必要はありませんが、疑い無く必要な課題なのです。

トリアージのプロセスは常に正しい決定を保証してくれるのでしょうか? いいえ、そうではありません。しかし正しい決定を行う確率を劇的に向上する事は保証できます。私たちは、どの決定の一つをとってもそれが数百万の顧客に影響を与えるという事を知っているので、どのリリースの過程においてもトリアージに多大な工数を費やすでしょう。それには間違いなくその価値がありますが、私はそれを毎回毎回そうしなくても良い事を嬉しく思っています。おや、ちょっと待ってください。

製品が出荷されると、トリアージは日常当たり前の事になります。実際、顧客が評価できるプレ リリース版への変更ではなく顧客が利用している、市場に出回っている製品への変更になりますから、意思決定にはより熱心に取り込みます。顧客の実装している手法がバグの存在を前提としており、バグが起きないとうまく動作しないため、問題を修正すると顧客の手法を失敗させてしまうという事例を見てきました。そうした事情もあるので、私たちは世界でも第一級のアフター サービス組織になる事に尽力しています。その理由と方法が私の次回のブログの題材です。引き続きご注目ください。

広告

コメントする »

まだコメントはありません。

RSS feed for comments on this post. TrackBack URI

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

WordPress.com で無料サイトやブログを作成.

%d人のブロガーが「いいね」をつけました。