日本情報システム・ユーザー協会（JUAS、河野俊二会長）が策定する透明性の高い「要求仕様書」は、2003年度（04年3月期）から積み上げた研究の総仕上げになる。研究成果を組み合わせたり、手法を援用・発展させることで、IT投資の最適化やIT人材の育成につなげていく。今回のプロジェクトにより、「システムの開発や保守・運用のプロセスが透明化され、発注側と受注側の食い違いが回避される」（細川泰秀専務理事）と自信を見せる。（佃均（ジャーナリスト）●取材／文）

赤字プロジェクトの元凶　要求仕様めぐるトラブル回避へ

開発、運用のプロセスを透明化

　ここ数年の間、ユーザー企業の情報システムは脱メインフレームとオープン化やウェブアプリケーション化を指向し、コスト圧縮が最優先に掲げられる傾向が強かった。機能や性能への要求が厳しく、システムの複雑さが増したにもかかわらず、短納期で低予算な情報システムを開発する力が求められている。その結果、赤字プロジェクトを多数抱えて業績不振に陥る大手SIベンダーが相次いでいる。

　ユーザー企業でも当初に計画した性能が得られないとして、システム開発を断念したり、納期を急いだため運用開始後に大きなトラブルが発生するケースが目立っている。受注するSIベンダーは「要件定義があいまい」とユーザー企業（発注者）の問題点を指摘し、ユーザー企業は「SIベンダーに提案力がない」と受注側の力不足を非難している。しかし、この認識の違いは、結果として両者とも利益を失っているのが現状である（図1）。

　ユーザー企業には、情報システム開発の問題で「5・5・3の法則」があるという。 これは「工期は半分遅れ、予算は半分オーバーし、品質の3割は不満」という状況を指す。細川専務理事は「こうした問題の要因は、『要求仕様書』でSIベンダーとユーザー企業が正しく合意していないことに起因している」という。

　このため、要求仕様書→設計→設計変更を通じて仕様の変化を一貫して管理できる様式を開発することで、両者の認識のズレを解消することを目指す（図2）。

■SRMに経営戦略や評価盛り込む

　JUASでは03年度から、情報システムの開発や保守・運用、IT人材の育成にかかわる計20の専門分科会を順次発足させてきた。個々の分科会の成果をSRM（システム・リファレンス・マニュアル）委員会（委員長＝木野戸裕・キリンビール情報企画部長）が整理して、会員にレビューする作業を通じて、ユーザー企業の立場に立ったSRMの策定を目指すとしている。

　JUAS版SRMは、経営課題や組織運営、資源配置など、ビジネスモデルの検証・策定からスタートするのが特徴で、経営戦略とCIO（最高情報責任者）やIT組織の役割分担、情報システム構築における主体機能の設定、IT人材の特性、投資対効果や外注先（情報システム子会社や海外オフショアを含む）の評価など広範囲に及んでいる。

　このため、SIベンダーの多くが採用している「V字型」の開発プロセス・モデルではなく、IT戦略立案から保守・運用までトータルな「システム・ライフサイクル・プロセス（SLCP）」を視野に入れた「U字型」の開発モデルに軸足を置いているのが特徴だ（図3）。

　このうち「要求仕様書」については、「システム技術文書ガイド」「ビジネスシステム定義」「オブジェクト設計ガイド」、基本設計書についても「ユーザビリティ1～ペーパー・プロトタイプ～」などの手法を策定し、会員の有志企業において実プロジェクトへの適用評価を進めている。

　こうしたなかから、投入資源（納期、予算、人員）やバグ発生率の相関関係、工数積算の指標、リスク管理の目安などを明らかにしており、「これを援用・発展させればシステム開発・保守・運用のプロセスが透明化され、発注者と受注者の間の食い違いが回避される」（JUASの細川専務理事）と見ている。

開発作業の役割と責任を明確化　共通認識のもと「契約モデル」へ

■提案力不足の「たらい回し」なくす

　具体的には、新たに構築するシステムにユーザー企業が業務の実際を反映した要求（期待）機能、性能を「見積照会仕様書」としてツリー構造で記述し、それを用語やデータ定義のリポジトリと対照させ、最終的に「プログラム・モジュール」や「プログラム・ユニット」に落とし込む。こうすることで、大規模で複雑なシステムでも機能ごとに細分化され、システム全体での位置づけが明確になる。また、ツリー構造で記述したドキュメントをたどることでメンテナンスが容易になる。

　一方、現場のエンドユーザーが利用するアプリケーション画面の設計や展開では、住宅の間取り平面図に家具を配置していくように、紙の上に入力フォームや表示機能などを記入する。エンドユーザー部門や現業管理部門、IT管理担当部門、システム開発部門など関係者が参加するチームを編成して、要件定義や詳細設計に誤解がないかをチェックしていく。

　またプログラム作成においては、「モジュールまたはユニット単位でテストを完了させ、初歩的なバグを解決しておくのが有効」（細川専務理事）という。

　ちなみに、JUAS有志会員企業における実プロジェクトへの適用評価で得られた主要なエンピリカル（経験則的）なメジャメント（測定基準）は次の通りだ。



■要求内容を数値化し目標設定

　今年度からスタートするプロジェクトは、以上のような成果をもとに、「気づかせる」ことに主眼を置く。ひとつはITの専門知識を持っていない人でも「要求仕様書」が記述できるようにすることだ。「在庫を減らしたいと考えても、生産現場から倉庫、取引先への配送の仕組みが分からなければ仕様が固まらない。そこで生産拠点や倉庫の場所、配送の手段などを具体的に記述すると、情報システムの問題でないことが分かるかもしれない」と細川専務理事は語る。

　情報システムの改善または新規構築が必要と判断した場合でも、「在庫をどれほど減らしたいのか、数量なのか金額なのか」などを具体的に考えることができる。要求を数値化することがシステム化に欠かせないが、これまで現場のエンドユーザーや経営者は、漠然とした要求をIT部門や委託先に伝えるだけだった。これを数値化し、さらに業務処理プロセスを可視化する。

　こんな統計もある。JUASがまとめたメジャメントに従い、「ソフト開発を500万円につき1個以下の潜在欠陥まで抑えて納入すれば、発注する」との条件を付けて、実際にSIベンダーへ提案したところ、4割は条件通りのソフトをつくることができたという。さらに、客観的なメジャメントがあれば、SIベンダーは「工期を標準より、3割短縮すると、要件定義の費用は1割高くなる」など理論的に説明しやすくなる。客観的なデータ指標がないから、価格設定も曖昧で、両者間の不満がくすぶっていると捉えている。また、JUASが策定した仕様書の記述レベルが上がるほど、情報システムの構築費を削減できるというのだ（図4）。

　また、これらを基に、ユーザーの要求をSIベンダーがどのように実装していくか、開発作業の役割と責任の分担、達成目標（機能・性能、バグ発生率など）を明確化していこうとしている。具体的な数値を基に全体の設計図をビジュアルに展開することで、ユーザーとSIベンダーがシステム要件について共通の認識をもつことができる。これにより、最終的には両者が合意できる「契約モデル」につながっていく。

　4月にNTTデータや富士通など大手SIベンダー6社が合意した「ユーザーにも分かりやすい要求仕様の記述方法」の検討に、JUAS案が盛り込まれていく可能性もある。JUASでは、大手SIベンダーが開始した研究協力について「ユーザー企業側とは、基本的に発想が違う。しかし、ベンチマークなどには協力する」（細川専務理事）と、協力を示唆している。

　情報システムの評価に一定のメジャメントを確定することができれば、情報サービス会社にとっても大きなメリットといえる。