オルタナティブ・ブログ > IT業界のマーケティングを問う >

戦略、プロモ、広報など実務から見たマーケティングをお話します

業務とシステムの仕様確認

»

今や殆どのシステム開発は業務の刷新や改善を伴い、新しい業務の構築でもシステムの準備が必要なほど、ITと業務は密接に関わっています。アクセンチュアで仕事をしていたころには、業務とシステムの要件の整合性を確保し、サービスを開始するまでの期間での開発、テスト、移行を通して、如何にその状態を維持・改善していくかを、方法論のみならずプロジェクト毎でも様々な工夫をしていました。

しかし、現実としては、要件定義までは業務側が主導で作業が進むことが多い一方で、実際の設計・開発は業務とシステムの間での確認は手薄になり、テスト後半になるとシステムのテスト主導でプロジェクトが進んでいくことが多いと感じます。

その原因としては、システムと業務の間には、構築の時間軸にずれがあること、設計・構築・テストに関するアプローチが異なること、さらには設計文書の作成方法、記述レベルが異なることなどが挙げられます。その結果、システム側の設計内容と業務とのずれや、改善が必要な部分は、かなり後のフェーズ(業務統合テストですかね)で発見され、修正工数がかかったり、場合によってはシステムに業務を合わせるということになります。

私個人が直面している課題として、どうやって設計・構築中に業務とシステムの整合性確認を取っていくか、またテストでも如何にシステムとの統合テスト以前に業務の確認を行うかなど、出来る限り前倒しで問題を発見し、つぶしていくかということがあります。

規模が大きくなると、一般的な方法論や、決まりきったアプローチでは、上記の問題への対応が難しくなります。失敗するプロジェクト、効果の出ないプロジェクトが多い原因でもあるので、あらゆる方法を検討してみたいと思っています。

システムのサポート無しに、業務の確認をするためには、業務設計書や業務マニュアルベースで、業務の流れを机上でシュミレーションし、システムに求める細かい機能要件を抽出してみようと思っています。これは手始めですが、それに加えて個々のシステム・テスト毎(機能毎)にユーザ・アクセプタンス・テストを設定して、できるだけアセンブリーの完了・システム統合テスト完了前に、業務側のチェックを入れるようにしてみようと思います。

結構大変なのですが、地道にやることが一番の解決策だと感じています。

Comment(1)

コメント

従来の開発モデルを維持しつつもアジャイル開発の要素を取り入れていこうとされているのではないかとお見受けしました。

日本企業の商習慣上、工数見積りなどで導入が困難といわれていますが、実際にやってみると、非常に便利です。

小さなプロジェクトや社内プロジェクトで徐々に実績を積んでいくことができればいいのですけど、なかなか思い通りにはいかないんですよね。

コメントを投稿する