連載
» 2012年09月29日 19時44分 公開

事例で学ぶビジネスモデリング(10):IT技術者は上流に向けて飛翔せよ (1/3)

上流領域でのIT技術者の役割とは、一言でいえば、『ビジネスとITのギャップを埋める』ことにある。

[林浩一(ディレクター),ウルシステムズ株式会社]

1. ビジネスとITのギャップを埋める

 本連載が始まって約2年がたち、当時、出始めだった『ITアーキテクト』という言葉も定着した感がある。また、システム開発を成功させるためには、ビジネスとITの間のギャップを埋めなければならないという考えも、広く支持されるようになってきている。本連載では、これまで著者の所属するウルシステムズのコンサルタントの体験をベースに、上流工程で行うさまざまな活動を具体的に紹介してきた。システム開発に携わる多くの技術者にとっては、あまり縁のなかった上流の領域の様子がお伝えできたのではないかと思う。今回は、連載の締めくくりとして、IT技術者、あるいはITアーキテクトが上流領域で何をすべきなのかについてあらためて総括をしたい。

 上流領域でのIT技術者の役割とは、一言で言えば、『ビジネスとITのギャップを埋める』ことにある。ビジネスとITのギャップとは、すなわちシステム開発を失敗させる原因のことである。つまり、IT技術者が行うことはシステムの失敗要因をなくし、ビジネス上の成功を導き出すことである。

2. システム開発失敗の4つのパターン

 システム開発の失敗というと、読者の皆さんはどんなものを思い浮かべるだろうか? いわゆるデスマーチのような修羅場で、カットオーバーの大幅遅延や予算の超過を引き起こすプロジェクト、あるいは、金融市場や通信網の主要なサービスをストップさせてしまって、新聞に載るような社会問題を引き起こすシステムなどを思い浮かべるかもしれない。これらは、いずれも重大な失敗ではあるが、ビジネスの観点からはシステム開発の失敗はそれだけではない。われわれのこれまでの経験から、システム開発の失敗には4つのパターンがあることが分かってきた。

2.1. ビジネス上の目的を達成しない

 1つ目のパターンは、システムは完ぺきに動いているにもかかわらず、ビジネス上の狙いを達成できないというものだ(図1)。開発の渦中にいると忘れがちになるのだが、システム開発は、ビジネス上の狙いを達成するための手段の1つである。逆にいうと、どんなシステム開発にも何らかのビジネス上の狙いがある。結果的に上位にあるビジネス目的が達成できなければ、どれほど素晴らしいシステムが出来上がっても、開発は失敗である。

ALT 図1 ビジネス目的が達成できなければシステムが素晴らしくても失敗案件になる

 例えば、最新のICタグを使って効率を上げることのできるシステムを作ったものの、結局、どこの業者も商品にICタグを付けてくれなかったとか、高齢者のユーザーにも使いやすいリッチなGUIを作ったものの、その立ち上げ方が分からず使われなかったケースなどがそれだ。少し考えれば、これに似た意味のない機能やそもそもの存在意義が不明なシステムはたくさん思い当たるだろう。こうしたシステムは、ビジネス上の観点からすると、時間と費用の無駄に加えて、当初狙っていたビジネス機会を失ってしまうので大きな損失になる。

2.2. 業務が円滑に回らない

 2つ目のパターンは、システムはビジネス上の価値のあるサービスを実現しているが、実際の業務がスムーズに進まないためにビジネス上の効果が十分に出ないというものだ(図2)。

ALT 図2 使い勝手が悪くて業務がスムーズに進まない

 例えば、受注キャンセルや変更などの例外ケースの考慮が足りないためかえって手間が増えたり、画面の操作性が悪いためコールセンターの業務に支障を来したりするようなケースだ。きっと読者の皆さんも、ユーザーなら絶対に文句をいいたくなるだろうと思うようなシステムを作ってしまった経験があることだろう。ビジネス上の観点からは、出来の悪いシステムのおかげで、業務効率が下がり運営コストが余計に掛かるということを意味している。つまりそれだけ利益が減るわけで、場合によっては赤字の原因になることさえある。

2.3. 予算と納期が守れない

 3つ目のパターンは、システムを作るのに予定のコストとスケジュールを大幅に超えてしまうというものだ。デスマーチなどに代表されるプロジェクトマネジメントの失敗である。

 例えば、大きな進ちょく遅れをカバーするために要員追加を行ったものの、事態は好転せず、要員は不可能に近い目標を達成するために徹夜の連続で頑張っても、結局カットオーバーに間に合わない、といった状態だ。システム開発にかかわる人なら誰でも経験があるだろう。ビジネス上の観点からは、システム構築のためのコスト超過とサービスイン遅延による機会損失が問題となる。特にシステムの構築では、数千万円、数億円の単位のコストがあっという間に消えてしてしまうためコストの問題は重大である。超過したコストをほかのビジネス活動で埋め合わせるのは大変だ。

2.4. 機能や性能の要件が満たせない

 4つ目のパターンは、要求される機能や性能を満たすシステムを作ることができないというものだ。あるいは品質の悪いシステムを作ってしまうと言い換えてもよい。

 例えば、普通なら数秒でできる処理が、負荷が高くなると何十分もかかるようになったり、本来、24時間365日連続稼働しなければならないのに、予想しないときにシステムが停止してしまうといったシステムの性能や安定稼働に問題が生じる。あるいは、仕様では条件に合致する案件をすべてリストできなければいけないはずなのに、どうしても一部漏れてしまう、というような機能上の不備があるといった具合だ。ビジネス上の観点からは、提供したいサービスが実現されていないことに直結する。大抵の場合は、テスト時に問題がなかなか解決できずシステムのカットオーバーが遅れることになるが、システムを完成できず、巨額を投じたプロジェクトが中止になることさえある。それでも本番後に社会的なトラブルを引き起こして、企業の信用失墜につながるよりはましである。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ