サポートで得た知見を製品の品質保証活動にフィードバック
データがある程度そろっていれば
確かに、サポート部門だけじゃなくて、品質保証部門や設計部門までもが問題対応に当たってくれるのであれば、製品のユーザー側から見ればかなり安心感は高いだろう。でも、手厚いサポートもありがたいけど、そもそも製品にトラブルが起きないのが一番ありがたいような……。
「実際には、お客さまからお問い合わせいただいた内容を調査した結果、日立製品の不具合だと判明するケースはごく稀で、操作手順の問題によるものなど、それ以外の原因によるケースが大半を占めます」（梯さん）
へ？ そうなの？ 普通、パッケージ製品のサポートというと、その製品の不具合だという証拠がある程度そろってないと受け付けてくれないようなイメージがあるけど。そもそもサポートって不具合の対応のことかと思ってたけど違うの？
「日立はミッションクリティカルなシステムを多く扱っていることもあって、全社的に、『お客さまが抱えている問題を解決することが第一』という方針が貫かれていますから、自社製品の問題かどうかは二の次なんです。確かに調査の結果、われわれの製品の不具合が判明することもごく稀にありますが、『おかげで短時間で問題が解決できた』とお客さまに感謝されることのほうが実は多く、ありがたいことです。HiRDBを使っていただいているある大手ベンダーの幹部の方から、『あなたたちがいるから、HiRDBを選んでいるんだよ』とおっしゃっていただいたときには、本当にうれしかったですね」
なんでも、HiRDBなどはメインフレーム時代からの顧客が使っていることが多くて、よってもってメインフレーム並みのサービスレベルが求められるのだそうで。で、それにきっちり応えるためには、たとえオープン系パッケージ製品といえども、こうした対応になるんだそうで。
あと、自分とこで製品を開発しているというのも、対応の際の強みになるのでは？ なにせ板谷さんのように、実際にものを作ってる開発者が直接対応に当たるのだから。
「一見、相当に複雑で、システムの奥深いも問題でも、データがある程度そろっていれば大体分かりますね。それに、たとえばOSやハードの側の不具合が根本原因であっても、HiRDBのダンプを手掛かりに追っていけば、ある程度切り分けることができます。日立の中には、OSの中身を解析できる技術者もいっぱいいますからね」（板谷さん）
なんともまあ、「そこまでやるか！」というぐらいの徹底した仕事ぶりですな。でも、品質保証部門としては、ここまでサポート業務に足を突っ込んでいると、本業の品質保証の仕事に支障が出ることはない？
「もちろん、メインの業務は品質保証の仕事ですから、サポート業務とのバランスの取り方には気を遣っていますね。ただ、サポートの仕事を通じて得たナレッジやノウハウを開発プロジェクトにフィードバックすることで、より一層製品の品質を高める効果があるんです。また、現場で得たお客さまの声を、品質保証の業務を通じて製品仕様に反映させることもできます。こうしたフィードバック活動が、品質向上の秘訣の1つなんです」
なるほど。品質保証部門を介して、ユーザーの現場と設計開発部門がつながっているわけか。こういうフィードバックの仕掛けは、確かにあまりほかでは聞いたことがないかも。
