早くバグフィックスさせる方法（第6回）

「バグを早く直して欲しい」。これは、顧客から見れば常に期待することだろう。そもそもバグを作り出したのはメーカーなのだから、すぐに直すべきだというのは普通の考え方だ。しかしながら、これにも優先順位があること、また、修正版を適用することによる副作用（サイドエフェクト）など、きちんと考慮すべきところもある。ここでは、バグに対する対処法を述べるとともに、その中でできるだけ早くバグフィックスさせる方法について述べていく。

まず始めに、バグ発生から修正版提供までにどのような登場人物がいるのかという点から述べていく。これは、以下のようなエスカレーションフローに基づく登場人物ということになる。

図1　バグ発生から修正版提供までに登場する人物

上記の登場人物に対して、バグという観点からそれぞれの役割を以下に記述する。なお、ここで述べていることはあくまで一般的なもので、会社ごとに多少違った形態やエスカレーションフローを使用していることをあらかじめ理解しておいていただきたい。

1.Tier1

Tier1では、ユーザーから問い合わせの合った障害（ここではバグに関して記述しているため、問い合わせの内容を「障害」という呼び方にする）に対して、既知の障害であるかどうかを確認する。既知の障害だった場合、その情報をユーザーに連絡する。連絡する内容は、パッチなどの修正版がすでに公開されている場合にはその情報の提供、ワークアラウンドなどの回避策が示されている場合にはその内容、また、今後のリリースにおいて修正される場合にはその時期や内容である。

既知の障害でなかった場合には、Tier2にエスカレーションし、詳細調査、技術的な調査を依頼する。

2.Tier2

Tier2では、Tier1からエスカレーションした情報を元に、詳細調査を行う。必要であれば、再現環境の構築を行い、どのような条件で発生するかなどを調査する。このTier2における調査や再現環境の構築が、この後のエスカレーションにおける重要な情報となる。

Tier2での詳細調査の結果、障害が製品のバグである可能性が高い場合には、上記の情報を元にTier3にエスカレーションする。また、Tier2での詳細調査にもかかわらず障害の状況が把握できない場合にも同様にTier3にエスカレーションする。この場合には、Tier3での詳細調査の依頼やTier2においてより詳細な調査を行うための支援を仰ぐということになる。

詳細調査の結果を元に、可能であればワークアラウンドなどの暫定対処の方法を見つけユーザーに連絡する。これにより、ユーザーはとりあえず当面の障害を回避できる。

3.Tier3

Tier3では、Tier2からの情報を元に、テクニカルサポートとして最終確認する。また、Tier2では調査し切れなかった障害を調査する。Tier3においてバグの可能性が高いと判断した場合に、次の「サステイニング」（後述）にエスカレーションされる。Tier3は、テクニカルサポートとしての最終的な技術責任を持つとともに、サステイニングと協力して障害対応あたることになる。

4.サステイニング

サステイニングと次のコア開発は、今回初めて出てきたものである。これらは、開発部隊に属し、それぞれ以下の役割を果たす。

• サステイニング：　製品出荷後のメンテナンスやバグフィックスをする
• コア開発：　製品の新機能を開発する

サステイニングを明確に別のグループにしているか、あくまでこの機能をコア開発に持たせるかは会社によって違う。ある程度の規模の会社になると、製品の新機能開発とメンテナンスを分業することによって効率的に開発を進めるためにサステイニングを持っている。

さて、Tier3からエスカレーションした障害を修正するのがサステイニングである。ここでは、リリース後のソースコードをメンテナンスしている。障害に対しては、ソースコード・レベルでの障害調査を実施し、ソースコード上の問題点を見つけ出し、修正し、パッチや修正版を作成してユーザーに提供する。いわゆるバグフィックス部隊である。

5.コア開発

コア開発では、特にバグフィックスを行うわけではないが、バグフィックスのためにサステイニングと協調することがある。製品の機能やインプリメンテーションに関しては一番分っているところであるので、バグフィックス時のサステイニングとコア開発の協力は重要である。

以上、バグが発生してから修正版が提供されるまでの全体的な流れや役割に関して説明してきた。次に、障害に対して取るメーカー側の対応方法に関して述べていく。通常、以下の３つの方法のいずれかで対応することになる。

ワンオフパッチの提供

いわゆる個別パッチを提供する方法である。障害によるユーザー業務への影響度が高く、ワークアラウンドなどの暫定策が取れない場合に提供する。

ワンオフパッチ自体は、その障害の修正だけを含むものである。修正確認はするが、製品のリリース時のような完全なテストはしない。サステイニングによる簡単なテストの後に提供されるものである。したがって、パッチ適用後に副作用として別の問題（サイドエフェクト）を引き起こしてしまう可能性がある。もちろん、サステイニングでは、ソースコードレベルで慎重に確認した上でこのパッチを作成する。だが、どうしてもカバーし切れないケースが発生する可能性は否定できない。したがって、適用にあたっては、ワークアラウンドなどの代替策がないかどうかを詳細に吟味する必要がある。

パッチセット・リリースでの提供

定期的に提供されるパッチの集まりのことをパッチセットという。メーカーによっては他の名前を付けている場合があるので、それに関してはメーカーに確認していただきたい。パッチセット自体は、提供前に一通りのテストを行うため、適用に当たってのサイド・エフェクトの可能性は少ない。したがって、パッチセットがリリースされたときには、速やかに適用するように計画を立てるのが良い。なお、パッチセットのテストは、製品のリリース時と同様の完全なテスト（フルQAと呼ぶ）を行う場合もあるし、一部のテスト（サブQAと呼ぶ）のみを行う場合もある。サブQAの場合には、多少サイドエフェクトの可能性が出てくる。しかし、サブQAに関しては、メーカー側で吟味したテスト項目であるので、それほど心配する必要はないだろう。

次期リリースでの提供

パッチあるいはパッチセットとして提供しない場合には、次期あるいは将来のリリースにおいて修正を盛り込むことになる。比較的軽微な障害やワークアラウンドが明確な場合には、この方法を取ることが多い。障害に対する対応がこの方法になった場合には、いつ、どのリリースで提供するのかを抑えておく必要がある。このリリース次期に基づいて、リリース版の適用やバージョンアップを計画し、速やかに進められるようにしておく必要がある。

この3つの提供方法を見てわかるのは、障害が発生した場合でも、何が何でもパッチを提供するものではないということである。明確なワークアラウンドがある場合や、障害自体が軽微でユーザーの使用においてあまり問題にならない場合には、次期あるいは将来のリリースにおいて修正を盛り込むことになる。ユーザーの立場からすると、どんな小さな問題であれ、バグはすぐに修正されるべき、つまり、パッチが提供されるべきと思われるかもしれないが、必ずしもそうではないという認識を持つ必要がある。

これは、1つにはメーカー側の開発効率の観点から、ユーザーに対して影響の少ない問題の修正は後回しにしたいという理由があるわけだが、一番大きな理由は、上にも書いたように、パッチに関しては完全なテストが行われないため、サイドエフェクトが発生する可能性を否定できないためである。したがって、多少不自由になるかもしれないが、安全であるワークアラウンドの適用という方法を暫定的かつ早急な解決策として取ることを考えたい。

さて、それでは最後に、早くバグフィックスするにはどうすべきかに関して述べる。以下、2点に注意して進めていただきたい。

1. 障害に関して、その影響度を明確にしておく。その障害により、使えなくなる機能が出てくるか、あるいは、システムに影響が出る（たとえば、ネットワークを止めてしまうなど）のかどうかなどを洗い出し、その影響度、重要度を明確にして整理しておくのが良い。これにより、ワンオフパッチが必要になるかどうかが分り、テクニカルサポートにワンオフパッチを依頼する場合の影響度が明確になる。また、パッチセットのリリースを待てるかどうかの判断材料になる。
2. 第2回、第3回で述べてきたように、テクニカルサポートができるだけ速やかにエスカレーションできるように進めていく。障害は、緊急度が高い場合が多く、原因調査を速やかに進められるかどうかが重要になってくる。また、原因調査が速やかに進み、エスカレーションが進めばパッチも速やかに提供されることになる。