実運用システムの仕様決定技法については、ＩＴ業界ではＲＡＤ(Rapid Application Development)からはじまり アジャイルソフトウェア開発（短期反復型を特徴とするソフトウェア開発の一手法）など が取り沙汰されてきたが、実際は、調達仕様と、その解釈、詳細化 といった極めて泥臭いプロセスで進んでいるのが多数派ではなかろうか？ ここでは、目新しい技法の話ではなく、この要件定義の泥臭い話の留意点について 書き記したい。

明文化されている仕様とされていない仕様

システム開発の調達には、必ず仕様書があるが、これには、 明文化されている仕様とされていない仕様が存在する。 とはいえ、仕様は開発の範囲を定義するものであり、 これが書き方により大きく変わるというのはあってはならない。 この２つの仕様とは、言い方を変えると、『詳細かつ具体的に記述した仕様』と、 『やや抽象的な表現により、開発範囲は規定するが、それ以上は 発注者と開発業者が詳細設計時に協議し、定義していく仕様』があるということである

このような仕様記述の抽象度の相違は、同じ調達の中の部分にもより異なるし、 総合評価や価格入札といった、調達方式によっても異なる。 例えば、提案を重視するような総合評価方式の仕様書は、より抽象度の高い記述になる傾向にある。 また仕様記述の抽象度は、パッケージをベースにするのか、スクラッチで開発するのかにも依存する。 つまり、パッケージを前提にするのであれば、詳細な仕様記述はともすると パッケージ調達の制約になりかねず、これを控える傾向となる。

要件定義を円滑に行うために

いうまでもなく、システム開発が大規模であればあるほど、 システムの設計から開発・検証までのプロジェクト管理が重要である。 プロジェクトの管理の手法としては、PMBOK(PMI(Project Management Institute) が体系化したプロジェクト管理手法）などがあるが、会議体を定め合意形成のプロセスやドキュメントを明文化し 何よりもその形式を逸脱しないことが重要である。

パッケージベースのシステムであれば、まず第一に考えるべきことは、 『どこまで既存のシステムと同様な仕様にするのか？』、 『業務をシステム（パッケージ）に合わせることはできないか？』 という視点である。 本来これは、発注前に決めておくべきことではあるが、 発注段階では、調達されるパッケージが必ずしも特定できないので 設計時に決めていくことになる。 しかし、開発方針とその工数を大きく左右するものであり 早期に、ある程度の方針を決める必要がある。

詳細な要件定義を円滑に行うために、筆者が最も重要と考えることは、 利用者のイメージできる言葉および画面、イメージで議論することである。 ＵＭＬ(Unified Modeling Language)のユースケースは、利用の主体と客体を図示した極めて分かりやすい表現である。 また、ＥＡ(Enterprise Architecture)ドキュメントのＷＦＡ(Work Flow Architecture)は、システムを用いた業務フロー定義の基本である。 しかし、これらは、要件定義の第一歩にすぎず、結局は、画面、帳票、データそれぞれの インプット／アウトプットをイメージできなければ要件定義は終わらない。

この意味で、画面と帳票とデータの具体的要件が重要であるが、 順番としては、詳細なＷＦＡの定義が先で、それを検証する形で 画面や帳票の定義を確認していくことになる。 幹を先枝葉は後にという、この順番を間違えると、結局手戻りが発生することになる。 ＷＦＡについては、パッケージをベースにするのであれば、 パッケージの想定するＷＦＡと、要件としてのＷＦＡの相違を 詳細に捕らえておく必要がある。 この部分を、発注者と受注者で念入りに意識合わせしておかなければ 画面、帳票、データといったさらに詳細かつ具体的な仕様についての 齟齬が大きくなってしまう。

つまるところお互いの歩み寄りが必要

以上は、筆者の実体験に基づく留意点であるが、 ＩＴシステムの要件定義に関しては、 「超上流から攻めるIT化の原理原則17ヶ条」IPA/SEC に、より体系的にまとめられているので参照されたい。

上記のような点に留意し、しっかりしとしたプロジェクト管理のプロセスを踏むのはもちろんであるが、 システムは、発注者と受注者、利用者と開発者の共創の産物である。 開発プロジェクトの開始当初から、発注者意識、受注者意識を超え、 お互いを理解し、歩み寄る姿勢が、結果的に良いシステムを産み出すのである。