恐らくこの記事を目にする方であればだれでも読んだことがあるであろう、IT系専門誌をいくつも出している大手出版社。
先日そちらの記事で、「要求仕様書の作成の「王道」を学ぼう！」的な宣伝を目にしました。
その出版社とどこかのコンサルタントが共催でセミナーをするので、その宣伝ということなのですが、宣伝記事はいいとして、さも、「仕様書作成に正解がある」かのような書きぶりにはホント困ってしまいます。
世の中には、
・要求定義と要件定義の違いとは？
・要件定義のやり方
・発注者側で最低限このくらいは仕様書を作れ！
などの意見が氾濫していて、「そういうふうにしなければいけないのかな？」と思わず信じてしまうかも知れません。
でも、それは全部間違いです。
要求仕様を含む、発注者側が提示する「仕様」に、正解はありません。
世界中どこを探してもありません。
日本人が大好きな、米国や英国の政府の一部の機関が作成した標準書にも、正解はありません。
何故でしょうか？
それは、「仕様書」は「契約」の一部だからです。（要求仕様書は、仕様書の一部ですね。）
「契約」は、発注者側と受注者側とで、義務・リスク・費用分担の境界線を定義するものです。
システムの規模や内容、発注者や受注者の力関係、契約に至る事情などは千差万別であり、一つとして全く同一の契約などあり得ません。
似たような団体、似たような業務だからといって、同じ仕様書（＝契約）で良い、という訳ではないのです。
ちなみに私自身も、コンサルタントとして様々な仕様書（契約書）を作成したこともありますし、
受注者として、仕様書の無いシステム開発を受注することもあります。
例を幾つかあげたいと思います。
先ほど挙げたセミナーでは、業務仕様や業務フローの定義や書き方に力をいれているらしいですが、これは、「PKGが利用できない業務で、かつ、現行業務の改善程度の改修で済む場合、かつ、システム開発にプロジェクトの主眼が置かれている場合」にしか使えません。
PKGの適合度が比較的高い業務分野、例えば、自治体の基幹業務などにおいては、PKGの機能評価を時間を掛けて行ってから、自庁の業務とどうしても相容れない部分だけ、カスタマイズの仕様を作成したほうが、遥かに良い物が安く手に入ります。
下手に独自の業務定義を行うと、（得られる業務効率化の成果は大して変わらないのに）カスタマイズばかり増えてコスト増をまねきます。
また、PKGを使用しないシステムにおいても、現行業務から劇的に変化をさせたい、と思っているのであれば、そもそも自社の社員だけで業務やシステム処理のデザインをするのは無理があります。
外部から、知見やアイデアのある設計者やコンサルタントを呼んで、新しい技術や新しい使い方を用いて業務変革ができないかを検討しなければなりません。
（ここ、弊社の宣伝です）
この場合、自社でコンサルタントを用いて業務要件を定義する場合もあれば、プロトタイピングを用いて、業務仕様を殆ど記述せずにシステムのあり方を模索する場合もあるでしょう。
更には、仕様書の作成、というと、どうしても要求仕様書の作成＝業務の仕様を作成する、という方向にいきがちです。
実際、先ほどのセミナーもそうですし、他の本や記事などもそういう方向に持って行こうとしています。
ですが、仕様書はあくまで契約の一部です。
契約条件を整えることを置き去りにして、業務の仕様ばかりを整えても、プロジェクトの成功にはあまり寄与しないものなんですが、契約条件の重要性に触れている媒体には殆どお目にかかったことがありません。
このあたりについては、次回の記事でご紹介したいと思います。
追記：弊社のこれまでのコンサルティング経験をまとめた、「公共団体のための情報システム調達ガイド」を作成しました。
システムの全てのフェーズで、リスクをコントロールし、マネジメントを行う手法をまとめています。
