その理由は、Aさんの言葉にある「5分以下には設定できないよう、制御されており」という部分が示しています。これは、ソフトウェア設計者が明確に意図した処理(コーディング)だと考えられ、5分以下の設定では動かせない(または動かしたくない)理由があることを意味します。
これは性能に起因するものかもしれませんし、後続のプロセスとの整合性によるものかもしれません。いずれにせよ、設計書にそのような記述があり、プログラム担当者がそれに従ってコーディングしたのであれば、それは明確に「仕様」といえるでしょう。しかし、開発時に問題があり、ユーザーインタフェース(設定画面)上では、ユーザーが任意に値を入力できるようになっていたわけです。
一方、ユーザー側はそのような設計の経緯は知りえません。本来であれば、ソフトウェアの設計に従って入力が制限されるべきところが、ユーザーに見えているのは、その設計に適さない入力画面だけ。しかも、そちらが自分にとって都合がよい場合、なおさら「それはバグだ、修正してほしい」という話になるわけです。
このように、メーカー側は設計に従った動作を「仕様」と言い、ユーザーは自分にとって望ましい動作が「仕様」で、そうでない場合はバグに見える――というすれ違いが生じます。
ユーザー側が主張する仕様も「要求仕様」という立派な仕様なのですが、それは製品の選定、または要件定義のフェーズで提示すべきものであって、運用の段階になって提示しても、サポート窓口の担当者は、その要求を聞いて設計するのが役割ではないため、会話が成立しないという残念な結果に終わってしまいます。
今回の話はあくまで一例ですが、「パッケージソフトウェアなのだから、SIのようにがっちりと要件を定義しなくても、自分たちがやりたいことと製品のコンセプトや機能が一致していれば、ささいなことは確認しなくても何とかなるだろう」と思う方もいると思います。確かにせっかく既製品を使うのだから、細かいところまで確認、定義していてはスピードという利点を損ないかねません。
しかし、今回の例であれば、Bさんの言う「間隔を1分に設定しないと、弊社がお客さまに提供するサービスとの整合性が取れない」というのは、製品を使う上でクリティカルな部分です。これをアーキテクチャ設計の用語で「ユースケース」、または「品質特性シナリオ」と呼びます。
その評価や設計には客観的な手法が存在しますが、それはまた別の機会に扱うとして、ここでは「仕様」という言葉について、ユーザーが言う「要求としての仕様」と、メーカーが言う「設計、実装としての仕様」では、意味合いが異なるということを理解していただければと思います。それが会話が平行線になるのを防ぐ第一歩です。
さて、一度矛を収めたように見えるBさんですが、この会話には続きがあるのです。その内容は後編で。
Copyright © ITmedia, Inc. All Rights Reserved.