サービス仕様という存在

顧客が既に提供しているサービスがあり、そのサービスを実現しているシステムのリプレースを行う、というタイプの案件があります。このような場合、RFPや顧客からの要求仕様だけを見ていると「なぜそのような要求があるのか？」という理由に当たる部分が分からないことがあります。質問やヒアリングを通して理解しようとしても、何か全体が整理されていない気がすると感じるのです。何が足りないのだろうと悩んでいる時に、サービス仕様というものが存在をたどり着きました。

サービス仕様が業務要件の前提になっている。

RFPや顧客からの要求仕様にも、システムの背景、データ、業務要件が記載されています。しかし、その内容は、実は（考えてみれば当然なのですが）顧客が提供しているサービスの理解が前提になっています。サービスが複雑ではない場合、画面とデータ、そして業務の流れから、「なぜそのような要求があるのか？」ということが分かります。このようなケースの方が多いでしょう。なので普段は特に問題を感じません。しかし、サービスが非常に複雑な場合には、そのサービス仕様を理解しなければ、データや業務要件が繋がってきません。業務とはサービスを提供するために行う仕事であり、サービスそのものではないのです。

RFP、要求仕様ではサービスに関連する情報は頻出するが、体系的には説明されない。

なぜこの問題に気づかないのか？というと、サービス仕様には、サービスとその意味、サービスを構成する要素の意味や関連性などがあるのですが、RFPや要求仕様にはサービス名や構成要素の名前、データ帳票といった断片情報が頻繁に出てくるため、全く知らないわけではないのです。ですが、その理解は「なんとなく」なものであり、この中途半端な理解が、サービスの目的や関連性なども含めて体系的サービス仕様を理解する必要性に気づかなくさせるのです。

サービス仕様は誰が定義するものか。

このサービス仕様は開発する側が定義するものではなく、顧客の責務として仕様化するものです。なので、サービス仕様がなければ全体を理解できない、要件定義、基本設計ができないという場合は、顧客に教えてもらうフェーズを必ず持つ必要があります。顧客は業務のプロ、開発する側はシステム開発のプロなわけですから、恥じることなくサービス仕様について説明を受け、その詳細が理解できるまで教えてもらうことが要件定義、基本設計を成功させる非常に重要な要因となります。