| « 2006年9月9日 | 2006年9月10日の投稿 |
2006年9月11日 » |
今や殆どのシステム開発は業務の刷新や改善を伴い、新しい業務の構築でもシステムの準備が必要なほど、ＩＴと業務は密接に関わっています。アクセンチュアで仕事をしていたころには、業務とシステムの要件の整合性を確保し、サービスを開始するまでの期間での開発、テスト、移行を通して、如何にその状態を維持・改善していくかを、方法論のみならずプロジェクト毎でも様々な工夫をしていました。
しかし、現実としては、要件定義までは業務側が主導で作業が進むことが多い一方で、実際の設計・開発は業務とシステムの間での確認は手薄になり、テスト後半になるとシステムのテスト主導でプロジェクトが進んでいくことが多いと感じます。
その原因としては、システムと業務の間には、構築の時間軸にずれがあること、設計・構築･テストに関するアプローチが異なること、さらには設計文書の作成方法、記述レベルが異なることなどが挙げられます。その結果、システム側の設計内容と業務とのずれや、改善が必要な部分は、かなり後のフェーズ（業務統合テストですかね）で発見され、修正工数がかかったり、場合によってはシステムに業務を合わせるということになります。
私個人が直面している課題として、どうやって設計・構築中に業務とシステムの整合性確認を取っていくか、またテストでも如何にシステムとの統合テスト以前に業務の確認を行うかなど、出来る限り前倒しで問題を発見し、つぶしていくかということがあります。
規模が大きくなると、一般的な方法論や、決まりきったアプローチでは、上記の問題への対応が難しくなります。失敗するプロジェクト、効果の出ないプロジェクトが多い原因でもあるので、あらゆる方法を検討してみたいと思っています。
システムのサポート無しに、業務の確認をするためには、業務設計書や業務マニュアルベースで、業務の流れを机上でシュミレーションし、システムに求める細かい機能要件を抽出してみようと思っています。これは手始めですが、それに加えて個々のシステム・テスト毎（機能毎）にユーザ・アクセプタンス・テストを設定して、できるだけアセンブリーの完了・システム統合テスト完了前に、業務側のチェックを入れるようにしてみようと思います。
結構大変なのですが、地道にやることが一番の解決策だと感じています。
| « 2006年9月9日 | 2006年9月10日の投稿 |
2006年9月11日 » |
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命