PR

パターン3:アドオン開発の範囲が膨らむ

 早期リリースや開発工数の削減を狙ってパッケージソフトを導入するプロジェクトも珍しくない。この場合、「利用部門の要求に対して、パッケージソフトの標準機能で対応できる範囲とアドオン開発が必要な範囲を特定する」作業が重要になる。この特定作業を誤り、アドオン開発が膨らんでしまうことが往々にしてある。

 さくら情報システム 開発本部 ビジネスソリューション第2部 EA第1グループの村井信行リーダーは「トラブルに発展するのは、パッケージソフトに対するエンジニアの理解が浅い場合が多い」と指摘する。パッケージソフトの標準機能について「おそらくできるだろう」程度で要件定義を完了してしまい、導入時にできないことが判明するのだ。

さくら情報システムの村井信行リーダー
さくら情報システムの村井信行リーダー
[画像のクリックで拡大表示]

 例えば、「パッケージソフトは経理部門向けに伝票入力画面を用意している。この画面を使って、業務部門が個別に入力しても同じだろう」と勝手に思い込むのは危険だ。パッケージソフトは経理部門の少人数の利用しか想定していないかもしれない。もしそうだと、多くの社員が同時に登録するような要件は標準機能では満たせない可能性が高い。

 こうしたトラブルを回避するため、「要件定義やその前の段階で、本当に動くかどうか実機で必ず確認する」(村井リーダー)。設計・実装段階で「初めて触る機能」は存在しないようにする。

方法論にちょっとしたプラスαを

 要件定義については、REBOK(要求工学知識体系)や非機能要求グレードなど知識体系が存在する。こうした“教科書的”な方法論に、プラスαのエッセンスを加えるのがここまで紹介してきた達人流だ。

 アビームコンサルティングの渡邉シニアマネージャーは「方法論は役立つし、素晴らしいものだ。とはいえ、方法論だけで引っ張っていけるのは小規模なプロジェクトに限られる」と話す。

 達人に共通するのは、自分が関わるプロジェクトに存在する落とし穴に気付き、回避するプラスαを実施している点だ。今回紹介した三つのワザがそのまま役立つ現場もあれば、そうでない現場もあるだろう。ただ、どういった現場にいるのであれ、プラスαを考え、実践する姿勢は共通するはずだ。