最も力点を置いているのは、要件定義・基本設計フェーズであり、多少の工数超過はやむをえないものと考えている。システム設計上の品質造り込みはここにあるのではないか。システム設計の各フェーズごとに、仕様のレビューと凍結・ユーザー承認を繰り返してゆく作業である。
作業に当たってのポイントは、
(1)改造(カスタマイズ)工数は最小限に抑制する。
アプリケーション・パッケージは、改造すればするほどバグリスクが高まる。
誤解を招く表現となるが、ある面では業務をアプリケーション・パッケージに合わせることも念頭においている。
(2)エンドユーザーニーズの網羅性を高めることは、改造工数の増加につながる面もある。真に要求されるニーズのみを反映させる、客観的な立場よりの指摘も必要である。
(3)改造を加えることにより、効率性にどの程度影響するかを検討する。
(4)画面等の操作性の向上を図る。
(5)セキュリティ要件を確保する。
7-4 運用後のパグや修正の対処について
アプリケーション・パッケージの性格上、ブラックボックス化は避けられない。
運用段階では、バグと修正要件の見極めが困難な部分も生じてくる。明確にソフトウェアに内在していたバグと認識できるものは修正すれば済む。問題は、開発の上流工程での意思の疎通が不十分であったことによって生ずる、修正ともバグとも判別が困難な案件が開発チームメンバー間の不協和音を引き起こす。これはブラックボックスであることも影響を与えている。
本市では、運用段階に至ったシステムは、ベンダーとの間でシステム技術支援契約を締結している。これは、業務の仕様変更、システム環境の変化に的確に対応することを目的とするものである。情報管理課・依頼原課・ベンダーSEの三者による運用業務検討会議を定例的に開催し、案件の整理と解決に努めている。
また、運用後の要員育成で重視している点は、「システム外部仕様書」「取扱説明書」の充実を図り、タイムリーに更新することによって担当者の異動等にも可能な限り対処しうるように努めている。
