ソフトウェア・シンポジウム2018 in 札幌

問題提起：提案依頼書（RFP）に含まれる「無理難題」を話題にして
神谷 芳樹
みたに先端研ymitani@computer.org

門田 暁人
岡山大学
monden@okayama-u.ac.jp

要旨えられる．この調達を受注しようとする者は，要求定義書作成作業に関する提案とともに，この調達仕様に羅列されている要

ここ 10 年余，IPA/SEC や大学の情報科学研究科でソフト求条件を整理し，対象システムの要求条件の大略を提案する

ウェア・エンジニアリングに関する調査・研究に従事しことが求められていると推定される．てきた．その中で，地方自治体など公的な機関による IT

そしてこの調達を受注できたら，顧客（つまり５つの医療機システム構築に関する提案依頼書（RFP）のいくつか（公関・病院）と共同作業で，対象システムの要求定義書を作成し開資料）に接し，詳細に評価する機会があった．そこには納めることになる．

筆者らの経験してきた先端的なソフトウェア・エンジニ

そして実際にはこの要求定義書を納めた企業が，引き続きアリング研究とはあまりにも乖離した驚きの世界があっ当該要求定義に基づいたシステム構築を実施する．

た．
そこではじめに一つの典型的な要求仕様書を紹介しながこの調達仕様書には，対象システムの要求条件について基ら問題提起の一文を Web サイトに寄稿し[1]，次いで，複本的なことが，記述の粗密はあるものの，かなり詳細に示され数の提案依頼書を評価し，ジャーナル論文として寄稿したている．一方，直接の調達対象である要求定義書作成作業の[2]．

進め方については，冒頭の記述以外何も示していない．目次

本論ではその経緯をあらためて整理し，その後の推移とのおもな項目は下記である．但し，最後の機能要求項目一覧あわせて若干の考察を示した．

1.

は実際には資料には含まれていない．

問題提起のきかっけ：最初の寄稿『1 はじめに（背景，情報システム導入の目的，基本的な考え方）

ひとつの典型的な要求仕様書を紹介しながら，そこに含ま2 基本要件れている「無理難題」をあぶり出し，問題提起とした[1]．

（業務範囲等，業務スケジュール，システム基本要件，ハードウェア／ソフトウェア／ネットワーク基本要件，データ移行要（１） 要求仕様書の概要

件，ファシリティ・インフラ／運用支援及び保守要件）
3 ネットワーク

紹介例は，市や町などの 5 つの医療機関の連合体による（ネットワーク構築の基本方針）

総 合 医 療 情 報 システムの開 発 に関 する要 求仕様書である

4.機能要求項目一覧（160 ページ）．タイトルは「○○連合総合医療情報システム要（実際には含まれていない）』

求仕様書」，表紙に大略次の文章がある（筆者が一部要約）．
（以下『 』内は当該要求仕様書からの引用．）（２） 要求条件中の「無理難題」『本資料は，事業者が○○○医療情報システムの提案を行

本仕様書には次のような驚きの表現がある．

うにあたっての参考資料である．
本資料は，現時点で想定している○○○医療情報システム『業務範囲：への要求事項を，羅列したものであり，システム化にあたって本項は，本仕様書における業務の範囲の概要をまとめたもは受託者による機能の整理・インテグレートが必要である．のであるが，本情報システムの導入対象範囲は広く，構成する

受 託 者 は ，契 約 締 結 後 ，本資料および提案書をもと各サブシステムは複雑に連携することから，提案者側において，に，・・・・（5 つの医療機関・病院）とともに，○○○医療情報シ記載されている業務以外にも，必要とされる業務等がある場合ステム要求定義書を作成するものとする．』

は，発注者側に提案を行うものとする．
また，その他必要となる業務が生じた場合は，受託者の責つまり本資料は要求定義書作成作業の調達仕様で，要求任において，業務を行うものとする．』

定義書の骨格となる対象システムの要求条件を羅列した，と考

125

SEA

ソフトウェア・シンポジウム2018 in 札幌『受注者として，相当数の導入実績と運用保守実績のある『部門システム・外部機関との連携に係る仕様書の作成：ソフトウェアであること．』

既存及び新規に導入予定の部門システムは現在，検討を進めていることから，決定後に既存及び新規に導入予定の部
門システム，および外部機関との間で，連携に必要となる要件『（２）サーバ要件』

等の整理を行うこと．

『データベースサーバ，アプリケーションサーバのＯＳは，オ※連携に係る部門システム側の経費については，別に見込ープン環境下のスタンダードなものを使用すること．また開発むものとするが，本調達によって導入される情報システム側で途中で陳腐化することがないよう十分な実績があり，かつ将来発生する経費については，本調達に含むこと．』においてもその発展が見込まれるものであること．』『○○○○の構築に係るデータ連携等：『データ移行要件』○○○○構築にあたり，既存の部門システムからデータを『既存システムに蓄積された必要なデータを安全かつ確実に移行できること．』

収集する必要があるものについては，この連携を構築することとするが，連携するシステムの選定は現在検討を進めているこ『運用支援及び保守要件』とから，決定後に連携を構築する．

『（６）ソフトウェア保守』※連携に係る一切経費を，本調達に含むこと．』『システムに関わる法令改正（診療報酬改正，薬価改定を『○○○○支援システムに係るデータ連携等：含む．）が公示された場合は，速やかに対応し，施行前にシス部門システムと同様に現在，検討を進めていることから，決テム変更をし，運用に支障をきたさないこと．』定後に既存の○○○○システムと本調達により導入される情（３） 想定される課題

報システムとの間で，必要となる連携を構築すること．
※連携に係る一切経費を本調達に含むこと．』

まず，このシステム構築はすでに医療情報システムとして相『システム基本要件』

当数の実績のあるソフトウェアを使用し，かつその導入実績の『（１）全般的事項』

豊富な企業でなければ応札できない．
次に，既存システムとの相互接続やデータ移行を求めてい『将来の機能拡張等におけるデータ移行時に特別な費用る．一方，既存システムの仕様に関する情報がどの程度与えらが発生しないこと．』れるか不明である．本来はこれらの情報が要求定義の中に含『法改正等のプログラム変更，パッケージのバージョンアッ

まれなければ，見積もりはおろかシステムの実現性も見通せなプの際には，別途費用が発生しないこと．』いだろう．
さらに，定義されていない条件によって，未来に発生する経『（２）業務支援機能』費を見込んだり，あるいは現在は内容は分からないが将来確『同時処理件数の増加により，レスポンスに影響を与えない実に発生する作業を，費用が顕在化しない形で実施するようよう考慮されていること．に求めている．

稼働年数の経過等によるデータ量の増加に伴って，レスポそして「マルチベンダ環境での保証」や，「オープン環境下ンスに影響が出ないように考慮されていること．』のスタンダードなもの」，さらには，「開発途中で陳腐化すること『ハードウェア基本要件』がないよう十分な実績があり，かつ将来においてもその発展が『（１）全般的事項』見込まれるものであること」といった現実には不可能な条件を，『今回導入する情報システムは，マルチベンダ環境での利それぞれの概念を定義することなく求めている．

用を保証すること．』

2. 事例集積による論考の深化と論文寄稿『ソフトウェア基本要件』
筆者らは上記の問題提起につづいて，典型的な 5 つの提『（１）全般的事項』『医療情報システムとして，○○○病院以上の規模・機能の案依頼書を評価し，「提案依頼書に含まれる無理難題の分病院において，相当数の安定稼働実績のあるソフトウェアであ類」として，事例紹介とともにジャーナル論文に寄稿した[2]．
そこでは「無理難題」を（1）実績を求める要求，（2）技術的にること．』

126

SEA

ソフトウェア・シンポジウム2018 in 札幌

実現が難しい要求，（3）仕様の分からない既存システムの移行，連携を求める要求，（4）将来の課題への対応を求める要求，

4. 一つの考察，調達と製品・サービス提供に関する組織活動の非対称性に分類した．
また事態改善に向けて，それぞれの項目に対する現実的な類推ではあるが，こうした「無理難題」の背景の一つに組織対策を例示した．

活動に於ける調達（発注）と供給（受注）に関する非対称性が（1）実績を求める要求に関しては，「…○○の実績を有するこあると考えられる．多くの企業・組織体では発注と受注，つまりと．○○に関する直接的な実績がない場合には，類似する実調達と製品やサービス提供の活動は拮抗する．組織体はある

績や技術についてのエビデンスにより，○○の実施に支障がときは発注側，あるときは受注側として振る舞う．しかしながら，ないことを示すこと．」売り手市場の販売対象を持つ企業や医療，行政サービスなど（2）技術的に実現が難しい要求に対しては，稼働率や稼働品の場合，受注側の活動は競争も少なく穏やかで，一方発注側質（応答時間，スループット，ターンアラウンド時間など）に関すの活動は買い手市場で，勢い強権的，いうなれば購買力を背る要件については，具体的な数値や範囲を示す．

景とした横柄な態度になることがある．こうした組織風土と，シス

セキュリティに関する要件については，完全なセキュリティのテム開発に関する技術未熟が重なると，本論で述べたような課実現は難しいため，最低限実現すべき要件を具体的に記述

題が現出する，ということがあるのではなかろうか．

する，若しくは，順守すべきセキュリティ基準を明記すると共に，本論の課題にはソフトウェア・エンジニアリングといった技術セキュリティが破られた際の対応に関する要件を記述する．

視点と合わせて，企業の組織風土のようなことにも踏み込んだ（3）仕様の分からない既存のシステムの移行，連携を求める要論考が必要なように感じられる．

求に関しては，ユーザは既存システムの仕様を提供すること．

5. まとめ（4）将来の課題への対応を求める要求については，例えば「納入後のシステムの保守・運用については，別途保守契約を結ぶこととする．また，新たな要求によるシステムの変更，改良提案依頼書にこうした「無理難題」が含まれている場合，法については，別途委託契約を締結し，それに基づいて実施す務担当が完備し，リスク管理された一流企業は応札しないに違るものとする．」など．

いない．リスク管理不在の企業が，「何でも出来ます，やります」

また，「システム改修などを施しても，改修など機能を含めて方式で応札することになる．一般に受注側の提案書が発注側全機能が使用できること」といった要求は，「システム改修時のによって様々な視点から評価されるのに対し，発注側の調達回帰テストに必要なドキュメントとツールを提供すること」といっ仕様書・提案依頼書が評価される場は少ない．広く評価の視た要求に変更する．

点に曝されることなく「無理難題」の羅列が提示され，それが「出来ます，やります」の姿勢で応札・受注され，調達行為が進3. その後の推移

んで行くのでは，双方にとって幸せな結果は得られないだろう．
ソフトウェア・エンジニアリング以前の話，あるいは超・超上流工

こうした検討を進めているとき，ニュースの中で，本論で取り程の課題，ということになる．本論で示したような，これまであま上げたような課題が含まれていると類推される訴訟事例が目にり明るみに出して議論されることの少なかった課題に対して，留まるようになった．例えば，幅広い認識とコンセンサスの醸成が期待される．

参考文献「旭川医大・NTT 東裁判の事例[3]」，「京都市のシステム刷新失敗の事例[4]」，などがある．

[1] 神谷芳樹：RFP で垣間見たソフトウェア・エンジニ
アリングの現実，未来に発生する要求への対応要求など無いずれも著名な事例で，ここでは内容を省略するが，こうしたニュースを参照すると，本論で対象としたような提案依頼・調達理難題が，IT 記者会 Report（Web）

2014 年 6 月に含まれる課題が，かなりの一般性をもったものであると類推[2] 門田暁人，住吉倫明，神谷芳樹：提案依頼書に含まれるできる．

無理難題の分類，SEC journal 51, 2017 年 12 月
[3] システム裁判は対岸の火事ではない，ユーザ企業が陥りまた一方で公的機関による調達方式の改善努力も進められている．例えば国立大学での高額調達では，事前の仕様書案がちな三つの罠，日経 XTECH，2017 年 10 月 4 日（Web）の公示と意見招請といった施策も試みられるようになった．

[4] システム刷新に失敗した京都市，IT ベンダーと契約解除で訴訟の可能性も，日経 XTECH，2017 年 10 月 12 日（Web）

127

SEA