RFPで垣間見たソフトウェア・エンジニアリングの現実2014-06-12RFPで垣間見たソフトウェア・エンジニアリングの現実エッセイ未来に発生する要求への対応要求など無理難題が筆者はここ10年余、IPA/SECや大学(情報科学研究科)でソフトウェア・エンジニアリングに関する調査・研究に従事してきた。今回のその活動の中で、地方自治体など公的な機関による調達仕様書、いわゆるRFPのいくつかに接する機会があった(いずれも公開資料)。そこには筆者の経験してきたある意味で先端的なソフトウェア・エンジニアリング研究とはあまりにも乖離した驚きの世界があった。ここにその一例を紹介し、ひとつの問題提起としたい。要求仕様書この例は、市や町などの5つの医療機関の連合体による総合医療情報システムの開発に関する要求仕様書である。タイトルは「XX連合総合医療情報システム要求仕様書」となっている。表紙に大略次の文章がある。』内は当該要求仕様書からの引用。)本資料は、事業者がXXX医療情報システムの提案を行うにあたっての参考資料である。本資料は、現時点で想定しているXXX医療情報システムへの要求事項を、羅列したものであり、システム化にあたっては受託者による機能の整理・インテグレートが必要である。提案書をもとに、・・・・(5つの医療機関・病院)とともに、XXX医療情報システム要求定義書を作成するものとする。調達仕様で、要求定義書の骨格となる対象システムの要求条件を羅列した、と考えられる。関する提案とともに、この調達仕様に羅列されている要求条件を整理し、対象システムの要求条件の大略を提案することが求められていると推定される。この調達を受注できたら、顧客(つまり5つの医療機関・病院)と共同作業で、対象システムの要求定義書を作成し納めることになる。この要求定義書を納めた企業が、その後その要求定義に基づいたシステム構築の調達に応札できるかどうかは不明である。)政策をとっている官庁系システムの構築では上流工程受注企業は下流工程、すなわちシステム構築そのものに応札できない。この調達仕様書には、対象システムの要求条件について基本的なことが、記述の粗密はあるものの、かなり詳細に示されている。進め方については、冒頭の記述以外何も示していない。目次のおもな項目は下記である。最後の機能要求項目一覧は入手した資料には含まれていなかった。以下、その中から筆者にとって驚きの表現をあげてみる。本項は、本仕様書における業務の範囲の概要をまとめたものであるが、本情報システムの導入対象範囲は広く、構成する各サブシステムは複雑に連携することから、提案者側において、記載されている業務以外にも、必要とされる業務等がある場合は、発注者側に提案を行うものとする。その他必要となる業務が生じた場合は、受託者の責任において、業務を行うものとする。既存及び新規に導入予定の部門システムは現在、検討を進めていることから、決定後に既存及び新規に導入予定の部門システム、および外部機関との間で、連携に必要となる要件等の整理を行うこと。※連携に係る部門システム側の経費については、別に見込むものとするが、本調達によって導入される情報システム側で発生する経費については、本調達に含むこと。XXXX構築にあたり、既存の部門システムからデータを収集する必要があるものについては、この連携を構築することとするが、連携するシステムの選定は現在検討を進めていることから、決定後に連携を構築する。※連携に係る一切経費を、本調達に含むこと。部門システムと同様に現在、検討を進めていることから、決定後に既存のXXXXシステムと本調達により導入される情報システムとの間で、必要となる連携を構築すること。※連携に係る一切経費を本調達に含むこと。将来の機能拡張等におけるデータ移行時に特別な費用が発生しないこと。法改正等のプログラム変更、パッケージのバージョンアップの際には、別途費用が発生しないこと。同時処理件数の増加により、レスポンスに影響を与えないよう考慮されていること。稼働年数の経過等によるデータ量の増加に伴って、レスポンスに影響が出ないように考慮されていること。今回導入する情報システムは、マルチベンダ環境での利用を保証すること。医療情報システムとして、XXX病院以上の規模・機能の病院において、相当数の安定稼働実績のあるソフトウェアであること。受注者として、相当数の導入実績と運用保守実績のあるソフトウェアであること。(2)サーバ要件データベースサーバ、アプリケーションサーバのOSは、オープン環境下のスタンダードなものを使用すること。開発途中で陳腐化することがないよう十分な実績があり、かつ将来においてもその発展が見込まれるものであること。既存システムに蓄積された必要なデータを安全かつ確実に移行できること。)が公示された場合は、速やかに対応し、施行前にシステム変更をし、運用に支障をきたさないこと。想定される課題この要求仕様提示からはじまるシステム構築の最終的な要求定義はどんな形になり、その要求定義にもとづく情報システムの調達行為はどんなことになるのだろうか。どんな情報システムが納められることになるのだろうか。見ただけでいくつかの課題に気づく。このシステム構築はすでに医療情報システムとして相当数の実績のあるソフトウェアを使用し、かつその導入実績の豊富な企業でなければ応札できない。既存システムとの相互接続やデータ移行を求めている。既存システムの仕様に関する情報がどのように、どの程度与えられるか不明である。本来はこれらの情報が要求定義の中に含まれなければ、見積もりはおろかシステムの実現性も見通せないだろう。定義されていない条件によって、未来に発生する経費を見込んだり、あるいは現在は内容は分からないが将来確実に発生する作業を、費用が顕在化しない形で実施するように求めている。「マルチベンダ環境での保証」とか、「オープン環境下のスタンダードなもの」、とか、「開発途中で陳腐化することがないよう十分な実績があり、かつ将来においてもその発展が見込まれるものであること」といった極めて難しい条件を、それぞれの概念を定義することなく求めている。まとめ端的に言ってこの要求条件には相当な無理難題が含まれていて、おそらく法務担当が完備し、まともなリスク管理のある一流企業では、こうした要求条件では応札そのものが出来ないだろう。実際にはこうしたリスク管理不在の企業が、「何でも出来ます、やります」方式で応札すると想定される。一般に受注側の提案書は、発注側によって様々な視点から評価される。発注側の調達仕様書の評価はどうなっているのだろう。誰にも評価されることなく、無理難題の羅列が提示され、それが「出来ます、やります」で応札・受注され、調達行為が進んで行くのでは、双方にとって幸せな結果は得られないだろう。ソフトウェア・エンジニアリング以前の話だ。2024年7月観測レポートリンクhttp://blog.livedoor.jp/itkisyakai/はてなブログをはじめよう!itkisyakaiさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。