[テクニカルサポートとの付き合い方]

2009年9月30日(水)諸角 昌宏

　品質向上の取り組みで中心となるのは、ユーザーと製品開発の中間に位置するテクニカルサポートであり、製品品質の向上はユーザーとテクニカルサポートの協調関係の上に成り立つものである。ここでは、製品の品質をあげるためのアプローチ方法について述べるともに、テクニカルサポートの質をあげるためのアプローチ方法に関しても述べていく。

　製品の品質およびテクニカルサポートの質自体を、ユーザー側から改善していける機会は以下の2つである。

リアクティブにアプローチする方法

これは、問い合わせした問題が解決した後、今後同じような問題が起こらないように対策を求める場合の方法である。実際には、どのような問題が発生していたかによるのだが、一般的には以下の3点について対策を求めていく。

（1）製品の品質を維持する体制の見直し及び改善

簡単に言えば、テスト体制の見直しおよび改善である。「テストは十分だったのか」「テスト自体のカバレッジは十分なのか」など、発生した問題がなぜ製品の出荷前の段階で見つからなかったのかという点に関して、見直しおよび改善策を求めていく。

特に、一度解決した問題が再発したような場合には、このテスト体制の改善を強く求める必要がある。

（2）既知の問題の事前連絡の方法の確立

これは、同様の問題が既に他のユーザーで発生して報告されているにも関わらず、その問題が発生した場合の対策である。ユーザーは、重要な情報やバグの情報は、できる限り事前に連絡してほしいと考えている。もし、事前に知らされていれば、その問題を避けて使用することが可能な場合が多い。そこで、このような問題の発生をきっかけとして、既知の問題に対する事前連絡の方法の確立をテクニカルサポートに求めていく。テクニカルサポートにとって、様々なユーザーで発生した問題をすべて把握することはかなり難しいことではある。だが、どこまでの範囲の情報が入手でき、ユーザーに事前連絡できるのかを明確にし、そのための体制を確立することを求めていきたい。

（3）迅速な問題解決のためのテクニカルサポートの体制改善

これは、発生した問題に対するテクニカルサポートの対応について見直しおよび改善を求めていくことである。可能であれば、対応について時系列で整理し、問題がどこにあったのかを明確にした上で改善方法の提示を求めていきたい。また、次に問題が起こった場合に迅速に対応できる体制の明確化も求めていきたい。

プロアクティブにアプローチする方法

これは、実際に問題が発生する前に製品の品質を高めたり、テクニカルサポートの障害時の対応を迅速に進めるために、どのようにアプローチしていけばよいかということである。このための方法として、製品品質およびテクニカルサポート対応に対する「マニフェスト化」を提案したい。

マニフェスト化というとなんだか政治家のようであるが、ここでは、製品選定（RFPなど）の段階で、製品品質やテクニカルサポート対応に対する要求項目を取り入れていくためのマニフェストと考えていただきたい。製品選定は、とかく機能比較のみになりがちだが、製品品質やテクニカルサポート対応をきちんと取り込んでいくことにより、実際に運用を始めてからの問題の発生をできるだけ少なくできる。そのためには、マニフェスト化が必要であると考える。

それでは、どのような内容をマニフェスト化すべきであろうか。以下に9点のマニフェスト項目をあげる。

（1）バグ累積グラフの提供

これは、リリース前に見つかったバグの累積数を時系列にしたがって表したグラフである。開発段階ではよく用いられるグラフだ。このグラフが右肩上りの状況では、製品品質が安定していない（まだまだバグが多い）状況であり、この状況でリリースされた製品を使用するのは危険である。グラフが水平に近い状態になると品質が安定してきたことになるので、ある程度安心して使用できる。したがって、このグラフを提供してもらうことにより、品質の安定度をある程度把握可能だ。また、リリースごとのグラフを提供してもらって比較することで、新しいリリースにおいて品質が改善されているのかどうかを見ることができる。

（2）残存バグリストの提供

すべての残存バグリストを提供することは、メーカーにとっては難しいことであるが、クリティカルな残存バグのリストと修正・改善時期の情報に関しては提供を求めたい。残存バグの情報は、ある機能を使用するかどうかの判断材料として利用できる。なおテクニカルサポートでは、クリティカルかどうかの判断としてショーストッパー（Show Stopper）という言い方を用いることがあるので、この用語も覚えておきたい。

（3）テストカバレッジ

テスト仕様書、あるいはテスト項目表とその結果について情報提供してもらいたいところだが、それをメーカーに求めるのはかなり難しい。したがって、テストをどういった方針で実施しているかという情報を提供してもらいたい。1つは、フルセットのテストをどのタイミングでどのくらいの頻度で実施しているか、またパッチ・セットやワンオフ・パッチのテストをどのように実施しているかという情報である。もう1つは、開発段階で実施するテストのほかに、出荷前にフィールド・テストなどを実施しているかどうかの情報の提供を求めたい。これにより、テストカバレッジの状態がわかり、品質が高いかどうかの判断ができるようになる。

（4）エラーメッセージ表の提供

あまり注目されない部分だが、エラーメッセージに対する情報が充実しているかどうかは、製品品質の観点から非常に重要である。それぞれのエラーメッセージに対して、問題の内容や重要度、エラー発生時の後処理についてきちんと書かれている表の提供を求めたい。また、エラーメッセージのリストから、どの程度エラーがカバーされているかを明確にできる。エラーのカバレッジの低い製品は、障害時に的確なエラーメッセージが出なかったり、的確な処理がされない場合があるため、メンテナンスが後々大変になる。

（5）セキュリティ対策状況の提供

近年、セキュリティが確保されているかどうかは非常に重要である。そこで、製品の脆弱性テストの実施状況がどのようになっているかの情報の提供を求めたい。可能であれば、クレジットカード業界が導入する情報セキュリティ基準であるPCI DSSなどのコンプライアンスに準拠したセキュリティ対策が取られているかについても明確にしたい。

また、セキュリティパッチがどのように提供されるかの情報も重要である。セキュリティパッチは緊急性が高く、迅速に適用することが必要となる。そのため、製品導入時ほどテストの期間を取ることができない。セキュリティパッチの品質をどのように確保しているかの情報の提供も求めていきたい。

（6）フォールトトレランス状況の提供

セキュリティ対策と並んで、フォールトトレランスをどのように実現しているかを確認したい。ハードウェアにおける故障、ソフトウェアにおけるバグは避けられない。問題が起こった場合に、どのようにして稼働状況を維持できるかという情報の提供を求めたい。フォールトトレランスがないと、例えばハードウェアの故障時に、その判定のために数日を要してしまったり、ソフトウェアのバグの原因解析のために数日を要してしまうことがある。技術的にフォールトトレランスを実現している場合もあるし、障害時にテクニカルサポートが緊急対応することで対応しているところもある。どのようにフォールトトレランスに対応しているかを明確にしたい。

（7）障害発生時の切り分け手順の提供

あらゆる障害に対する完全な切り分け手順を作ることはできないとしても、想定される障害とその場合の切り分け手順のガイドラインの提供を求めたい。これにより、障害時の迅速な対応が可能になり、解決までのある程度の目安を明確にできる。また、このガイドラインが提供されるかどうかにより、どこまで障害を想定した対応の準備ができているかを把握できるようになる。

（8）テクニカルサポートホットラインの設置状況の提供

テクニカルサポートからなかなか回答がこない、あるいはなかなか進捗が見えず、解決できるのかどうか不安な状況が発生した場合に対する対策として、ホットライン的なものを設置しているかどうかの情報の提供を求めたい。テクニカルサポートのマネージャやメーカーの上層部に直接連絡が行くなど、方法はいろいろある。

（9）テクニカルサポートのビジネス継続性対策状況の提供

テクニカルサポートが使用するシステム(電話やメール、問い合わせ管理データベースなど)が故障した場合、どのようなバックアップ体制が取られているか、また、災害によりテクニカルサポートが使用するオフィスやシステム全体が使用できなくなった場合、どのような方法で業務継続ができるのかに関する情報の提供を求めたい。また、最近問題となっているパンデミックへの対策として、テクニカルサポートの要員をどのように確保し、どのような形で業務を遂行できるかに関する情報の提供を求めたい。特に、24時間連続稼働しているミッションクリティカルなシステムにおいては、障害時にテクニカルサポートと連絡が取れないとビジネスに大きな影響を与える。したがって、ビジネス継続性への対応状況に関しては特に注意したい。

以上は、典型的なマニフェストの項目となるものだが、すべてをマニフェスト化する必要はない。ユーザーにとって重要となる項目のみを使用すればよい。また、ユーザー側で苦労した点や経験した問題点などが他にもあるはずなので、それらのマニフェスト化も検討していただきたい。

以上、製品の品質およびテクニカルサポートの質の向上に関して、リアクティブ・プロアクティブの両方の観点から述べてきた。これらを進めていくことで、日本人が期待する品質の実現に向けてのアプローチをテクニカルサポートを通して実現できるものと考えている。

さて、今回を最後に本シリーズを終了する。本シリーズを始めるにあたってまず考えていたのは、「IT業界のエッジで働く人々を明るくしたい」ということである。そのためのアプローチとしてはいろいろあると思うが、ここでは、ユーザーやパートナーの人々と、その反対側に位置するメーカーのテクニカルサポートという両方のエッジで働く人々に焦点をあててみた。

その上で、「製品を提供しているいわゆるメーカーのテクニカルサポートと、製品を利用しているユーザーならびに製品を導入・支援・管理しているパートナーとの間の関係を、敵対関係から協調関係に導く」という観点から、テクニカルサポートとのやり取りやコミュニケーションをどのように進めていくべきかについて述べてきた。これにより、本来の目的に近づくための1つの切り口が示すことができたのではないかと考えている。

最後になるが、「愚者は経験から学び、賢者は歴史から学ぶ」という格言があり、これを座右の銘としている人も多い。IT業界が、この格言のように歴史から学ぶことができていたならば、もっと違った世界を生み出せていたかもしれない。歴史から学ぶということは、歴史が証明しているように相当難しいことのようである。一方、歴史から学ぶことができなくても、歴史の一部を作り出すことはできるはずである。ほんのわずかではあるが、1人の人間が生きてきた足跡は間違いなく歴史の一端である。本シリーズで述べてきたことは、ほとんどすべて経験に基づくものであるが、多少なりとも今後歴史から学ぶことのできる人々の一助となってくれれば幸いである。