はじめに
なんだかおもしろそうな論文情報が Twitter で流れてきたのでメモ。
論文の概要
- 提案依頼書に含まれる無理難題の分類
- 2017年12月
- SEC journal論文
- 岡山大学
ベンダの視点で見ると，RFPにユーザによる無理難題が含まれていることに気づいた。「できます」「やります」でこのような案件に応札してしまうと，後で大きな問題となりそうだ。世の中のRFPには，どの程度の無理難題が含まれているのだろうか？そもそも無理難題にはどのような種類があるのだろうか？一般公開されているRFPを分析し，無理難題を分類し，事例集として整理することで，ベンダ・ユーザに役立ててもらう．
要求の分類
本論文では、無理難題な要求を以下４つに分類している。
| 要求 | 内容 |
|---|---|
| 事績を求める要求 | ここでは事績 ≒ 過去実績のような意味合いで使われている。自社と同規模もしくはそれ以上の同業種での導入実績がなければならないという要求は、必ずしも無理難題とは言えないが、特定の１社に要求する場合は無理難題となりえる。 |
| 技術的に実現が難しい要求 | 「同時処理件数の増加により，レスポンスに影響を与えないよう考慮されていること」「マルチベンダ環境での利用を保証すること」「永久保存データとして管理できること」など、このまま解釈すると実現困難な要求は無理難題となりえる。ベンダは実現可能な範囲を明確にすることが望ましい。 |
| 仕様の分からない既存システムの移行・連携を求める要件 | 現行システムからの完全な移行を要求される場合。「既存システムの詳細仕様が与えられていたとしても，現行システムを熟知していない限り，妥当な見積もりは困難」であり、無理難題といえる。 |
| 将来の課題への対応を求める要件 | 「将来の機能拡張などにおけるデータ移行時に特別な費用が発生しないこと」「将来連合立病院になる５病院において連携できるシステムであること」などは、未定義の条件によって将来発生する作業を、費用が顕在化しない形で実施するように求めており無理難題と言える。 |
おわりに
昔と違って、ど新規のシステム開発という機会は減っており、「仕様の分からない既存システムの移行・連携を求める要件」というのはよくある話だと思う。これを「無理難題」と思えているか否かで話は大きく変わってくるので、自身も頭の片隅に置いておきたいし、ユーザーサイド／ベンダサイド共に理解しておくべき事項と思った。
以上
