教訓7:ビジネス要件を整理/グルーピングし、アーキテクチャ決定のInputにせよ。
ただ漠然とアプリケーションの要件や求められる機能を検討していても駄目であり、今回のように、要件や機能をグルーピングすることで、それぞれアーキテクチャ決定の核となるものが見えてくる。
教訓8:システム開発の費用対効果を明確にさせ、導入後、それをモニターせよ。
効果実現の責任は、本来オーナーであるユーザー側の責任者にあるはずである。このあたりを明確にした上で、ユーザー側責任者を巻き込めば、意思決定も容易になる。もし、それでもユーザー側責任者がオーナーシップをもたないようであれば、責任者失格なので、上長に掛け合うなどの強硬手段しかないかもしれない。
2回に渡って、弊社のシステム開発の例を基に、いろいろな教訓を紹介してきたが、皆さんのお役に立ったであろうか? 次回は、今回の教訓でも出てきた、ユーザー部門の責任者とのコミュニケーションについてお話したい。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
杉山 正二
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
関連記事
- 特集:顧客満足度ナンバーワンSEの条件
- すこしのことにも先達はあらまほしきことなり
- システム化を図るSEのスーパーテクニック
- ベストオブブリードで構築する高精度の在庫管理システム
- SEが木を見て森を見て本質を見抜くために
- SEが自分の「売り」を見極めるために
- プロとしてお金を稼げるSEの条件
- IT部門のリストラの進み方
- 生き残るためにITアーキテクトをめざすのも一法
- 函館空港ビルをひとり支えるSEに聞く
- SEに求められる経営的視点
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.