トラブルかスペックか

予め障害も文書化しておけばスペックになると言われる。実際に製品の障害とされることも、調べてみたらスペックでしたということはよくある話である。だからと言って、スペックかどうかがすぐに判別できるかというと、実のところそうでもない。あらゆるシステムの動作がスペックとして文書化され定義されているとも限らないし、そもそもがそれはスペックのエラーじゃないか、と思うこともままあるので、話はややこしい。結局のところ、障害に見えるものは障害だという主張と、想定どおりの動作を実現しているという主張の間における、せめぎ合いの中で現象毎に判断せざるを得ない。まあ、滅多にこういう状況には陥らないのであるが、このジレンマが発生すると、僕ら製品企画部門は何らかの形で巻き込まれることになる。

どちらかに組する判断が行なわれると、当然他方に対して不具合解決のために何らかのアプローチを行なうことになる。だからこのあたりの判断をするのは結構難しい。判断したつもりになっていても、他方からの反発を招く可能性も十分にある。全てをユーザーの視点に立つと、会社として無理難題を背負い込むことになるし、会社の視点だけに目を向けると、お客様の反発が来ることは必至である。理詰めの判断がなされれば両者納得できるかと言うと、事は単純ではなく、大抵どこかに理屈を超えた、一見グレー・ゾーンが残されている。そこまで見えてきた時にどう判断するか、最終的なさじ加減はきっと50-50よりも一歩だけユーザーに歩み寄るのが正解ではないだろうかと思う。

製品としての障害対応はここまでとさせていただきたい旨お客様に話をする、といった具合に引導を渡さざるを得ないこともたまにある。お客様にとって面白い話ではないので、僕らにとってもあまり楽しくはない。だからこれまでに必要な調査を行なったのか、製品の動作として妥当との判断に理論的な矛盾や無理はないのか、といったあたりを予め入念にチェックすることが前提になる。そのあたりを説明しながら、これ以上の対応は障害対応ではなく別のタイプの、お客様が希望するならば有償サービスとして対応することを述べることになる。お客様側の反応もまちまちで、それも仕方ないとコメントされる人から、障害に見えたのだから断じて障害であるとの立場を貫こうとされる人までいる。結局は理詰めでいくことになるのだけれど。

それにしてもこの手の話は精神的に疲れるし、正解がどこにあるのか手探りになるために時間もかかる。会社とお客様とが合意できるような、解決の方向性が見えると一段落である。やっとここまで来たかという思いを持って、帰社することになる。ほっと一息ついた気分がするが、結構忍耐力勝負だったりするので、同時に何件も抱え込みたくはないものだ。