提案依頼書に含まれる 無理難題の分類sec journal, vol.10, no.3, 30-37, sep. 2014....
TRANSCRIPT
提案依頼書に含まれる無理難題の分類
*1岡山大学大学院自然科学研究科*2岡山大学工学部情報系学科*3みたに先端研
SEC journal論文2017年11月
みたに
(C)岡山大学:門田暁人
2
背景:提案依頼書(RFP)とは
計画 提案 設計・開発 保守・運用テスト
提案依頼書
提案書 ソフトウェア仕様書
テスト仕様書
保守・運用
マニュアルプログラム
[1] 齊藤康廣, 門田暁人, 松本健一, "非機能要件に着目したRequest For Proposal (RFP)の評価,"
SEC journal, Vol.10, No.3, 30-37, Sep. 2014.
筆者らは,提案依頼書に非機能要件を漏れなく記述するための方法を研究してきた[1].
提案依頼書(RFP)とは,ユーザ(調達側)企業がベンダ(開発側)企業にシステムの提案を求める文書であり,システムの目的,機能/非機能要求,調達条件などが記載される.
RFPの品質がプロジェクトの成否を左右する.
含:見積もり
3
背景:RFPの無理難題
ベンダの視点で見ると,RFPにユーザによる無理難題が含まれていることに気づいた[1].
[1] 神谷芳樹,RFPで垣間見たソフトウェア・エンジニアリングの現実,IT記者会レポート(Web),2014年06月13日
「できます」「やります」でこのような案件に応札してしまうと,後で大きな問題となりそうだ.
・・・・新システムのテストに際し,現行システムの利用が必要となる場合はその費用を負担すること(既存業者と直接契約すること)・・・将来の機能拡張等におけるデータ移行時に特別な費用が発生しないこと
提案依頼書に含まれる無理難題の例
4
疑問と研究目的
疑問
世の中のRFPには,どの程度の無理難題が含まれているのだろうか?
そもそも無理難題にはどのような種類があるのだろうか?
研究目的
一般公開されているRFPを分析し,無理難題を分類し,事例集として整理することで,ベンダ・ユーザに役立ててもらう.
「無理難題」という観点での従来研究(要求工学)は筆者の知る限り存在しない.
5
ホットな話題...
ユーザの無理難題による係争が報告されている[1].
病院情報管理システムの開発失敗に関して,旭川医科大学とNTT東日本が争っていた.
仕様凍結の合意後も現場の医師からの追加開発の要望が止まらず,開発は遅延した.
旭川医大は,期日通りにシステムを納品できなかったとして,NTT東に契約解除を通告した.
一審は,過失割合をNTT東8割,旭川医大2割と認定
二審では,旭川医大10割と認定
[1] 浅川直輝,失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決, 日経コンピュータ 2017年9月28日号pp.8-9
「無理難題」を整理して世の中に知らしめることは,情報システムの受発注の健全な発展のために意義のあることではないだろうか.
6
題材となるRFP
RFPの非機能要件の評価に用いた5つのRFP[1]
[1] 齊藤康廣, 門田暁人, 松本健一, "非機能要件に着目したRequest For Proposal (RFP)の評価,"
SEC journal, Vol.10, No.3, 30-37, Sep. 2014.
7
分析の手順
1. 多くのベンダにとって実現が困難な要求や,実現のために多大な費用負担を強いらせる可能性のある要求を抽出する.→74件
2. 抽出した要求のうち,記述そのものの品質の問題を除外.→35件
3. 傾向が似ているものを同じグループとして分類する.→5分類
4. 実務者を交えて分類の見直しを行う.→4分類
8
分類結果
U1:事績を求める要求(7件)
U2:技術的に実現が難しい要求(9件)
U3:仕様の分からない既存のシステムの移行,連携を求める要件(10件)
U4:将来の課題への対応を求める要件(9件)
9
分類結果と例(1/4)
U1:事績を求める要求
「医療情報システムとして,XXX病院以上の規模・機能の病院において,相当数の安定稼働実績のあるソフトウェアであること」
大規模病院にシステム納入した実績のある企業でないと応札できない.
実績を求める要件がすべて無理難題であるとは限らないが,ベンダを特定の1社に限定する手段となっているのであれば問題である.
10
分類結果と例(2/4)
U2:技術的に実現が難しい要求
「同時処理件数の増加により,レスポンスに影響を与えないよう考慮されていること」
「マルチベンダ環境での利用を保証すること」
「永久保存データとして管理できること」
これらの表記をそのまま解釈すると,実現は困難であるため,ベンダとしては,実現可能な範囲を明記して提案する必要がある.
11
分類結果と例(3/4)
U3:仕様の分からない既存のシステムの移行,連携を求める要件
「現行図書館システムのデータを漏れなく,完全に新システムに移行すること」
「現行システムからの業務の引継ぎサポートの費用を負担すること」
「新システムのテストに際し,現行システムの利用が必要となる場合はその費用を負担すること(既存業者と直接契約すること)」
既存システムの詳細仕様が与えられていたとしても,現行システムを熟知していない限り,妥当な見積もりは困難である.
12
分類結果と例(4/4)
U4:将来の課題への対応を求める要件
「将来の機能拡張などにおけるデータ移行時に特別な費用が発生しないこと」
「将来連合立病院になる5病院において連携できるシステムであること」
未定義の条件によって将来発生する作業を,費用が顕在化しない形で実施するように求めており,将来大きな問題となり得る.
13
無理難題の件数
全てのRFPに3件以上の無理難題が含まれていた.
最も多いのは,U3(仕様の分からない既存のシステムの移行,連携を求める要件)であった.
既存システムの仕様の重要性をユーザが理解していない?
U4(将来の課題への対応を求める要件)も4つのRFPに含まれていた.
将来の改修,保守に費用がかかるのは当然という認識がユーザ側にない?
A:自治体 B:図書館 C:政府機関 D:大学 E:病院10 3 5 5 12 合計35 件
U1(実績):7, U2(技術):9, U3(既存):10, U4(将来):9
14
無理難題のページあたり件数
ページあたりの件数は0.075~0.273
およそ3.7~14ページに1件
A:自治体 B:図書館 C:政府機関 D:大学 E:病院0.165 0.273 0.238 0.070 0.075
15
無理難題の記述箇所(例:A.自治体)
7件の無理難題が「システム要件」に含まれていた.
U1(実績):2, U3(既存):4, U4(将来):1
本システムは,既存システムの再構築となることから,既存システムの利用,引継ぎ,データ移行に関する無理難題が生じた.
16
無理難題の記述箇所(例:C.政府機関)
3件「性能・信頼性・拡張性・安全性の要件」に含まれていた.
全体的に記述が不足していた.
U1(実績):0, U2(技術):1, U3(既存):2, U4(将来):0 合計:3
要件数:13 要件当たりの無理難題:23.1%
17
従来研究との比較
[1] 齊藤康廣, 門田暁人, 松本健一, "非機能要件に着目したRequest For Proposal (RFP)の評価,"
SEC journal, Vol.10, No.3, 30-37, Sep. 2014.
RFP
評価者
ページ数 無理難題エキスパート
教員エンプラ系SE
A.自治体 2.71 5.99 6.88 59 10
B.図書館 27.31 32.79 33.40 11 3
C.政府機関 18.91 15.16 16.91 21 5
D.大学 5.06 5.88 5.34 71 5
E.病院 42.75 44.08 64.90 160 12
非機能要件の記述の網羅性・明確さを100点満点で評価[1]
非機能要件がしっかり書けているかどうかと,無理難題を含むかどうかは,あまり関係がない.
18
論文には無理難題の事例集(付録)を収録
改善に向けて
実績の要求『○○に関する直接的な実績がない場合には,類似する実績や技術についてのエビデンスにより,○○の実施に支障がないことを示すこと』
実現困難な要求稼働率や稼働品質(応答時間など)に関する要件については,具体的な数値や範囲を示す.
セキュリティに関する要件については,最低限実現すべき要件を具体的に,若しくは,順守すべきセキュリティ基準、あるいはセキュリティが破られた際の対応に関する要件を記述する。
関係する既存システムについて既存システムの仕様の提供(最低限、必須)
将来の課題への対応別途契約へ
『システム改修時の回帰テストに必要なドキュメントとツールを提供すること』など。
19
望ましい文言
『本システムの実現に際して第三者との協議や契約が必要となることが想定される場合には,その時期や費用見積もり,費用負担も含めてユーザとベンダが別途協議し解決する。』
避けるべき:現時点で不明確な要求についてのリスクや費用を受注者に負わせる。ユーザ、ベンダ双方の利益につながらない。
20
21
まとめ
従来(学術的/工学的に)注目されていなかった
「無理難題」に着目
5つのRFPを対象とした実態調査
4種類の無理難題
実績を求める
技術的に難しい
既存システムとの連携(定義、情報提示のない既存システム)
将来(起こる未知なこと)への対応(将来の追加費用無く)
■今後
無理難題の記述の改善方法
民間企業(産業界一般)のRFPの分析
無理難題プロジェクトのトレース