IT記者会Report

IT/ICTのこと、アレヤコレヤ

RFPで垣間見たソフトウェア・エンジニアリングの現実

未来に発生する要求への対応要求など無理難題が

 筆者はここ10年余、IPA/SECや大学(情報科学研究科)でソフトウェア・エンジニアリングに関する調査・研究に従事してきた。今回のその活動の中で、地方自治体など公的な機関による調達仕様書、いわゆるRFPのいくつかに接する機会があった(いずれも公開資料)。そこには筆者の経験してきたある意味で先端的なソフトウェア・エンジニアリング研究とはあまりにも乖離した驚きの世界があった。ここにその一例を紹介し、ひとつの問題提起としたい。

要求仕様書

 この例は、市や町などの5つの医療機関の連合体による総合医療情報システムの開発に関する要求仕様書である。タイトルは「XX連合総合医療情報システム要求仕様書」となっている。そして表紙に大略次の文章がある。(筆者が一部要約)(以下『 』内は当該要求仕様書からの引用。)
 本資料は、事業者がXXX医療情報システムの提案を行うにあたっての参考資料である。
 本資料は、現時点で想定しているXXX医療情報システムへの要求事項を、羅列したものであり、システム化にあたっては受託者による機能の整理・インテグレートが必要である。
受託者は、契約締結後、本資料および提案書をもとに、・・・・(5つの医療機関・病院)とともに、XXX医療情報システム要求定義書を作成するものとする。

 つまり本資料は要求定義書作成作業の調達仕様で、要求定義書の骨格となる対象システムの要求条件を羅列した、と考えられる。この調達を受注しようとする者は、要求定義書作成作業に関する提案とともに、この調達仕様に羅列されている要求条件を整理し、対象システムの要求条件の大略を提案することが求められていると推定される。
 そしてこの調達を受注できたら、顧客(つまり5つの医療機関・病院)と共同作業で、対象システムの要求定義書を作成し納めることになる。
 この要求定義書を納めた企業が、その後その要求定義に基づいたシステム構築の調達に応札できるかどうかは不明である。一般に上下分離(上流工程・下流工程分離)政策をとっている官庁系システムの構築では上流工程受注企業は下流工程、すなわちシステム構築そのものに応札できない。
 この調達仕様書には、対象システムの要求条件について基本的なことが、記述の粗密はあるものの、かなり詳細に示されている。一方、直接の調達対象である要求定義書作成作業の進め方については、冒頭の記述以外何も示していない。目次のおもな項目は下記である。但し、最後の機能要求項目一覧は入手した資料には含まれていなかった。

 1 はじめに
   1.1 背景
   1.2 情報システム導入の目的  
   1.3 情報システムに係る基本的な考え方
 2 基本要件
   2.1 業務範囲等
     2.1.1 導入範囲
     2.1.2 導入する情報システム概要
     2.1.3 業務範囲
    `2.1.4 業務スケジュール
     2.1.5 システム基本要件
      2.1.6 ハードウェア基本要件
     2.1.7 ソフトウェア基本要件
     2.1.8 ネットワーク基本要件
     2.1.9 データ移行要件
     2.1.10 ファシリティ・インフラ要件
     2.1.11 運用支援及び保守要件
 3 ネットワーク
   3.1 概要
   3.2 ネットワーク構築の基本方針
   3.3 基本事項
 4.機能要求項目一覧

要求条件中の無理難題

 以下、その中から筆者にとって驚きの表現をあげてみる。
 2.1.3 業務範囲 本項は、本仕様書における業務の範囲の概要をまとめたものであるが、本情報システムの導入対象範囲は広く、構成する各サブシステムは複雑に連携することから、提案者側において、記載されている業務以外にも、必要とされる業務等がある場合は、発注者側に提案を行うものとする
 また、その他必要となる業務が生じた場合は、受託者の責任において、業務を行うものとする。』
 2.1,3,3 部門システム・外部機関との連携に係る仕様書の作成 既存及び新規に導入予定の部門システムは現在、検討を進めていることから、決定後に既存及び新規に導入予定の部門システム、および外部機関との間で、連携に必要となる要件等の整理を行うこと。※連携に係る部門システム側の経費については、別に見込むものとするが、本調達によって導入される情報システム側で発生する経費については、本調達に含むこと
 2.1,3.4 XXXXの構築に係るデータ連携等 XXXX構築にあたり、既存の部門システムからデータを収集する必要があるものについては、この連携を構築することとするが、連携するシステムの選定は現在検討を進めていることから、決定後に連携を構築する。※連携に係る一切経費を、本調達に含むこと
 2.1.3.5 XXXX支援システムに係るデータ連携等 部門システムと同様に現在、検討を進めていることから、決定後に既存のXXXXシステムと本調達により導入される情報システムとの間で、必要となる連携を構築すること。※連携に係る一切経費を本調達に含むこと
 2.1.5 システム基本要件』
 (1)全般的事項 将来の機能拡張等におけるデータ移行時に特別な費用が発生しないこと
    法改正等のプログラム変更、パッケージのバージョンアップの際には、別途費用が発生しないこと
 (2)業務支援機能 同時処理件数の増加により、レスポンスに影響を与えないよう考慮されていること
    稼働年数の経過等によるデータ量の増加に伴って、レスポンスに影響が出ないように考慮されていること
 2.1.6 ハードウェア基本要件  
  (1)全般的事項 今回導入する情報システムは、マルチベンダ環境での利用を保証すること
 2.1.7 ソフトウェア基本要件
 (1)全般的事項 医療情報システムとして、XXX病院以上の規模・機能の病院において、相当数の安定稼働実績のあるソフトウェアであること
 受注者として、相当数の導入実績と運用保守実績のあるソフトウェアであること。 
 (2)サーバ要件
 データベースサーバ、アプリケーションサーバのOSは、オープン環境下のスタンダードなものを使用すること。また開発途中で陳腐化することがないよう十分な実績があり、かつ将来においてもその発展が見込まれるものであること。 
 2.1.9 データ移行要件
 既存システムに蓄積された必要なデータを安全かつ確実に移行できること。
 2.1.11 運用支援及び保守要件
 (6)ソフトウェア保守 システムに関わる法令改正(診療報酬改正、薬価改定を含む。)が公示された場合は、速やかに対応し、施行前にシステム変更をし、運用に支障をきたさないこと。

想定される課題

 この要求仕様提示からはじまるシステム構築の最終的な要求定義はどんな形になり、その要求定義にもとづく情報システムの調達行為はどんなことになるのだろうか。そして、いったいどんな情報システムが納められることになるのだろうか。
 ぱっと見ただけでいくつかの課題に気づく。
 まず、このシステム構築はすでに医療情報システムとして相当数の実績のあるソフトウェアを使用し、かつその導入実績の豊富な企業でなければ応札できない。
 既存システムとの相互接続やデータ移行を求めている。一方、既存システムの仕様に関する情報がどのように、どの程度与えられるか不明である。本来はこれらの情報が要求定義の中に含まれなければ、見積もりはおろかシステムの実現性も見通せないだろう。
 定義されていない条件によって、未来に発生する経費を見込んだり、あるいは現在は内容は分からないが将来確実に発生する作業を、費用が顕在化しない形で実施するように求めている。
 「マルチベンダ環境での保証」とか、「オープン環境下のスタンダードなもの」、とか、「開発途中で陳腐化することがないよう十分な実績があり、かつ将来においてもその発展が見込まれるものであること」といった極めて難しい条件を、それぞれの概念を定義することなく求めている。

まとめ

 端的に言ってこの要求条件には相当な無理難題が含まれていて、おそらく法務担当が完備し、まともなリスク管理のある一流企業では、こうした要求条件では応札そのものが出来ないだろう。
 実際にはこうしたリスク管理不在の企業が、「何でも出来ます、やります」方式で応札すると想定される。一般に受注側の提案書は、発注側によって様々な視点から評価される。しかし、発注側の調達仕様書の評価はどうなっているのだろう。誰にも評価されることなく、無理難題の羅列が提示され、それが「出来ます、やります」で応札・受注され、調達行為が進んで行くのでは、双方にとって幸せな結果は得られないだろう。ソフトウェア・エンジニアリング以前の話だ。

(謝辞:本調査・研究にあたってご指導頂いた、奈良先端科学技術大学院大学情報科学研究科、ソフトウェア工学講座の関係各位に謝意を表します)