中国オフショア開発：亜才株式会社

是澤さんは嘆いていた。
あぁ、おれはなんて馬鹿な事をしていたんだ・・・。
日本側のPMの要求とはいえ、BTSとエクセルでの二重管理なんてあまりに効率が悪いではないか。
ムラ、ムリ、ムダを省くのが改善の基本だが、この二重管理はまさにムラではないか。
なのに、これまでまったく改善してなかった。。

「是澤さん、是澤さん、BTSとバグ一覧表でバグの状況が違います！」
という開発側のマネージャーの劉さんの再三の指摘を受けて、
是澤さんはバグ管理をBTSで一本化する道を模索し始めた。

BTSには、エクセルにはない利点が多くある。
一つのバグを一つのトピックで管理するので、バグ修正の経過が見やすい、というのがその1つだ。
同じようなバグが見つかれば、「そういえば以前同じようなバグがあったから、検索して参考にしよう。」ということが簡単にできるし、設計書に同じような仕様があったときには、「この仕様はあのときのバグの対処を参考にして、あらかじめ使用を追加して開発側に渡そう。」ということができる。

バグの現在の状況をリアルタイムに把握できるのも大きな利点だろう。
オフショア開発では普通の開発とは違い、翻訳、というフェーズが入る。
バグ修正では、テスト担当者、翻訳担当者、修正担当者、という風に、担当者が頻繁に入れ替わる。
場合によっては設計チームとのやり取りも必要なため、バグの現在の状況をはっきりさせないと、
「是澤さん、是澤さん、ID23のバグの再テストは終わりましたか？」
「え！？一覧ではまだ翻訳依頼を出したばかりということになってますけど？」
「辣腕翻訳家の羅さんが数分で翻訳しちゃいました。
バグの修正も終わりましたよ。」
「えー！？
すぐに再テストします！！」
ということになりかねない。

一覧表の管理で起こりうるこのような状況も、BTSを使うと簡単に回避できる。
バグに、再テスト中、翻訳中、修正中、などのステータスをつけることもできるし、
現在の担当者の名前を付けることもできる。
また、担当者が変わった際には担当者にメールが送付されるため、
「え！？今、自分が担当者だったの？？？」
なんていうミスを防ぐことができる。

さらに、エクセルでの管理は、コミュニケーション上不都合があることも確かだ。
バグ一覧は各担当者が同時進行で修正を加えるため、
「翻訳担当の羅さん、バグ一覧を更新しましたので翻訳お願いします！」
「・・・是澤さん、私も今更新したばかりなんで、是澤さんの一覧と内容が違うんですけど。。。」
「えー！？でもそのバグ急いで修正しないといけないから、そっちで修正してもらえませんか・・・」
「・・・わかりました。。。」
ということになり、羅さんは泣く泣く修正するはめになる。

つまり、翻訳者がバグ一覧に翻訳内容を記述している最中に、テストチームがバグ一覧に新たなバグの内容を記述してしまったため、
テストチームが新しく上げたバグ一覧に、翻訳の内容を記述しなおす、という統合の作業が必要になる。
バグ一覧での管理には、ある人が更新した内容と、別の人が更新した内容が異なるため、
一方の人が更新したバグ一覧の上に、他方の人が更新内容を書きなおす、という作業が必要な場合があるのだ。

だが、BTSの場合、このようなことは起こらない。
一つのトピックに次々にレスを投稿していけばよいからだ。
一つのバグは一つのトピックで管理されるため、ほかのバグの更新に影響されることもない。

BTSには、一覧形式にエクスポートできるものも多い。
私たちが使っているBTSでも、CSV形式とPDF形式でエクスポートが可能だ。
見やすさという面ではエクセルの一覧表に劣るが、
バグの原因や修正内容、担当者などが一覧で確認できるという点は変わらない。