« No news is good newsだった三菱東京UFJ銀行システム統合 | トップページ | Responsiveness »

2008年12月17日

トラブルシューティング中に責任逃れと思われないために

トラブルシューティングというものに対する理解の齟齬が要因で、顧客の心証を害することがある。

製品の不具合が発現するためには「引き金」が必要である。「引き金」は特定の操作や操作、周辺システムの環境、もしくはそれらの組み合わせなどだ。たとえばある値より長いデータのpingにより起きるping of death。ping自体は正常な処理だが、受信したオペレーティングシステムの不具合を誘発してシステムがダウンする。トラブルシューティングで最初に行うのは、この「引き金」を見つけることである。「引き金」を早期に発見することには次の意義がある。

  • 「引き金」を引かないような運用(いわゆる回避策)をお客様にお願いすることで、不具合の発現を抑止できる。
  • 意図的に作り出せる「引き金」であれば、再現環境を構築し、根本的な不具合の発見と修正をより効率的・迅速に行える。

「引き金」を見つけるには、ログを解析する、設定を確認するなど様々な手法を駆使し、まず仮説を立てる。次にその仮説を検証するために、「引き金」と思われる設定を変更したり操作を意図的に行うなどする。もし仮説が外れていた場合は、別の仮説を立てて検証する。このサイクルを繰り返す。

以上のようなトラブルシューティング基本手順をよく理解していない人は、「引き金」を見つけようという行為を「他者に原因を押しつけて責任逃れしようとしている」と感じたり、仮説・検証サイクルを「行き当たりばったりのモグラたたきをしている」と誤解することがあるようだ。

こういった誤解を避けるためには、手順を体系立ててきちんと説明する、つまり原因追及のプランや流れを説明することはもちろん、言葉の選び方に留意する必要がある。ある設定や環境が引き金ではないかと疑っていてその変更や調査を依頼する場合は、「○○が問題を引き起こす要素(要因、引き金)でないかと考える」と表現するのがよい。このとき「○○に問題があるのではないか」と表現すると、責任逃れと取られかねない。

回避策を提示すると、「バグがある状態では怖くて使えない」「ほかにも何か致命的なバグがあるのでは?」と言ってくることがある。極論すれば、すべてのハードウェアやソフトウェアは怖くて使えないと言っているのに等しい。バグがあるという前提で、うまく付き合っていく必要がある。これがIT業界の現実である。

|

« No news is good newsだった三菱東京UFJ銀行システム統合 | トップページ | Responsiveness »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« No news is good newsだった三菱東京UFJ銀行システム統合 | トップページ | Responsiveness »