「これバグでしょ？」 vs. 「それは仕様です！」（前編）：失敗しない「外資系」パッケージソフトとの付き合い方（2/2 ページ）

[吉丸新一郎（日本ヒューレット・パッカード），ITmedia]

「仕様」には2つの意味がある

　その理由は、Aさんの言葉にある「5分以下には設定できないよう、制御されており」という部分が示しています。これは、ソフトウェア設計者が明確に意図した処理（コーディング）だと考えられ、5分以下の設定では動かせない（または動かしたくない）理由があることを意味します。

　これは性能に起因するものかもしれませんし、後続のプロセスとの整合性によるものかもしれません。いずれにせよ、設計書にそのような記述があり、プログラム担当者がそれに従ってコーディングしたのであれば、それは明確に「仕様」といえるでしょう。しかし、開発時に問題があり、ユーザーインタフェース（設定画面）上では、ユーザーが任意に値を入力できるようになっていたわけです。

　一方、ユーザー側はそのような設計の経緯は知りえません。本来であれば、ソフトウェアの設計に従って入力が制限されるべきところが、ユーザーに見えているのは、その設計に適さない入力画面だけ。しかも、そちらが自分にとって都合がよい場合、なおさら「それはバグだ、修正してほしい」という話になるわけです。

今回取り上げたケースをまとめるとこのようになります。事象は1つでも、立場や動機によって、物事のとらえ方は180度変わることが分かるでしょう

　このように、メーカー側は設計に従った動作を「仕様」と言い、ユーザーは自分にとって望ましい動作が「仕様」で、そうでない場合はバグに見える――というすれ違いが生じます。

　ユーザー側が主張する仕様も「要求仕様」という立派な仕様なのですが、それは製品の選定、または要件定義のフェーズで提示すべきものであって、運用の段階になって提示しても、サポート窓口の担当者は、その要求を聞いて設計するのが役割ではないため、会話が成立しないという残念な結果に終わってしまいます。

仕様は仕様でも、「製品仕様」と「要求仕様」は違います。*の部分ですが、もしスクラッチ開発で、ユーザーが「1分間隔でも動作すること」と要求していたら、製品仕様は違ったものになるでしょう

自分が使った「仕様」の意味を理解しているか

　今回の話はあくまで一例ですが、「パッケージソフトウェアなのだから、SIのようにがっちりと要件を定義しなくても、自分たちがやりたいことと製品のコンセプトや機能が一致していれば、ささいなことは確認しなくても何とかなるだろう」と思う方もいると思います。確かにせっかく既製品を使うのだから、細かいところまで確認、定義していてはスピードという利点を損ないかねません。

　しかし、今回の例であれば、Bさんの言う「間隔を1分に設定しないと、弊社がお客さまに提供するサービスとの整合性が取れない」というのは、製品を使う上でクリティカルな部分です。これをアーキテクチャ設計の用語で「ユースケース」、または「品質特性シナリオ」と呼びます。

　その評価や設計には客観的な手法が存在しますが、それはまた別の機会に扱うとして、ここでは「仕様」という言葉について、ユーザーが言う「要求としての仕様」と、メーカーが言う「設計、実装としての仕様」では、意味合いが異なるということを理解していただければと思います。それが会話が平行線になるのを防ぐ第一歩です。

　さて、一度矛を収めたように見えるBさんですが、この会話には続きがあるのです。その内容は後編で。

著者紹介：吉丸新一郎

　日本ヒューレット・パッカード株式会社 プロフェッショナルサービス コンサルタント / シニアアーキテクト。自社のエンタープライズ向けソフトウェア、特にハイブリッドクラウド管理、データセンター運用自動化製品を専門とした導入コンサルティングを担当。

　製造業システム子会社でのデータセンター事業企画・運用、ベンチャー企業での新規事業開発および運用を経て、ソフトウェア利用者の立場をサプライヤーの立場に変え現業に従事、現在に至る。

　趣味は音楽鑑賞（ジャズやクラシック）や歌舞伎やオペラの観劇など。旅行が好きで、食べ歩きが得意ジャンル。