私が保険会社でITの仕事をしていたとき、「ITに関する常識」が見方を変えると実は正しくない、という経験を何度もした。過去の常識は鵜呑みにするのではなく、疑ってかかった方がいいというアドバイスとして3つの事例を書こうと思う。
１．外注する方が安い ソフトウエアの開発業務についていえば、外注したほうが実は高い。自社のエンジニアが開発するコストと、ソフト会社へ委託する場合とを比較すると、委託したほうが高い。それは、考えてみれば当たり前で、開発量は同じだとすると、ソフト会社の単価はエンジニアの人件費に利益とリスク分が加味されているのに対して、自社のエンジニアは人件費だけで済むからだ。 しかし、ビジネスの領域では外注したほうが安いという常識が一般的なので、よくビジネス部門の方に「外注して安くつくってくれ」と言われることが多かった。ソフトウエアの開発を誰でもできる単純作業と誤解している人が多いということだろうか。
２．二つの会社のシステムを統合すると合計の運用コストが下がる システムを統合すると、量が増えるから効率化効果が発揮されて安くなる、とよく言われる。しかし、システムはそんな単純ではない。 私が経験した保険会社合併に伴うシステム統合の例で言おう。大きな会社とそれより小さな会社で統合すると、大きな会社の情報システムに寄せることになる。例えば、契約の証として発行する「保険証券」の作成費で見てみると、大きな会社が作成している証券の紙質は小さな会社のそれよりいいものを使っていたので、全件いい紙質の紙になり作成コストは上昇した。 量が大きくなれば効率化が図れる、という常識は、かなりの量とかなりの量を一緒にしたときには通用しない。むしろ、別の要素によってコストが上昇するケースも出てくる。常識には思わぬ罠があるものだ。
３．業務要件を漏らさず書けば、ソフトウエア開発の品質が上がる 以前から、システムトラブルの原因の60％は、要件定義の甘さによるものだと言われてきた。しかし、「要件定義」をしっかり書くということは実に難しい。 ソフトウエア開発の要件定義は、業務要求とソリューション要求とに分かれる。この両方を正確に書くことができるか、ということが大きな課題なのだ。いかに難しいかを保険の事例で説明したい。 保険手続きでは、保険契約を締結後に、解約せずに現存契約の契約条件を変更することができる規則にしている。これを「業務要求」として書くと、「契約条件の変更を可能にする。そのとき、変更後の条件に合わせて保険料を追徴したり、返戻したりする。その計算方法は、・・・・の通り。」という記載に留まる。 これを「ソリューション要求」として考えると様々なケースが想定される。契約条件の変更をわかりやすく自動車の買い替えを例にケースを想定してみる。買い替える車に条件変更するというケースが通常ケースだが、手続した後に急に車の納期が変わり結果として買い替えを取りやめにしたときに、どういう手続きにするのか、とか、同時に年齢条件を変更するのを忘れたことに気づき、それも合わせた「変更」に訂正してほしいというときに、どういう手続きにするのか、とか、「ソリューション要求」として詰めていくことが急に膨らんでいく。 ここで気がつくのは二つのこと。
以上、3つの事例を挙げたが、情報システムは一般的な常識で済むような内容ではないので、ビジネス側とIT側それぞれで、専門性を持つ担当者がボールを投げ合うように行ったり来たりの対話によって、その内容を詰めていく業務だということを経営は理解すべきだと思う。
しかし、ビジネス・IT双方に深刻な経営的課題が出始めている。 ビジネス側は、業務の多くがシステム化された結果、現在の担当者にとってはブラックボックスが多くなり業務全体が理解できなくなっているという課題、機能縦割り部門の担当者では、システムの一部しか担当できず、システム全体を理解している人が不在でエンジニアと対話できる人がいないという課題が出ている。 IT側もノウハウがSEの高齢化や退職などで散逸してしまうケースが増えている。このままいくと、これからの事業運営に致命的な支障が出てくる可能性もあり、経営としての対策が必要になっていると思われる。
他のDBIC活動
他のDBICコラム
他のDBICケーススタディ
一覧へ戻る
一覧へ戻る
一覧へ戻る
このお知らせをシェアする
