ザー要件としてまとめあげるという「ユーザーとの合意形成」が一層重要なものになる。特に、要求の内容がカスタマイズによって実現可能である場合、次項に述べるカスタマイズの作業量に直接影響する。その意味でも、ユーザー要件調整作業の位置付けは重要であり、作業の難度は高いと言える。
1-4 適切なカスタマイズ量設定の困難性
アプリケーション・パッケージが想定する業務モデル(機能,データ,仕事の流れ)と、実際の業務との間に差異が存在する点については第1章で指摘した。この差異を埋めるのがカスタマイズ作業である。
実際には「差異を埋めない=カスタマイズは行わない=アプリケーション・パッケージの機能,データ構造,仕事の流れをそのまま受け入れる」という対処から「差異はすべて埋める=仕事の流れを含めて、ユーザー要件をすべて満たすべくカスタマイズを行う」という対処まで、選択肢は非常に幅があると言える。
カスタマイズを実施すれば、「業務の現状をシステム化する」という観点ではユーザーの満足度が高くなるが、アプリケーション・パッケージが持つ開発自由度の低さという特性によって技術的な困難が予想されるとともに、アプリケーション・パッケージのバージョンアップへの追随が困難になる可能性がある。また、カスタマイズ分の作業コストが開発費用に上積みされることになる。
さらに、カスタマイズの規模を決定するのは単にこうした技術的・経済的判断ばかりではなく、「アプリケーション・パッケージが想定する仕事の流れにしたがって、現状の仕事の在り方を変革する」という政策的判断が働きうる点もカスタマイズに関する意思決定を難しいものにしている。
1-5 信頼性保障と障害切り分けの困難性
アプリケーション・パッケージはソフトウェア製品であり、パッケージベンダーの適切な品質管理によってバグがなくなっていることが望まれる。しかし、実際にはバグのないソフトウェアは希だと考えるのが現実的である。
開発者であるパッケージベンダーがバグや不具合の全容を把握していることが理想ではあるが、クライアント・サーバ形態のアプリケーション・パッケージなどのように激化する開発競争の中では、バグの根絶には期待できないのが現実であろう。
アプリケーション・パッケージのブラックボックスという特性上、こうしたバグや不具合をユーザーが未然に回避することは困難であり、パッケージベンダーによる何らかの保障が必要になるものと考えられる。さらに、こうした状況にあるアプリケーション・パッケージをカスタマイズした場合、方法によっては、カスタマイズ部分に混入したバグとアプリケーション・パッケージが本来含んでいたバグとの切り分けが困難な状況になることが考えられる。