全3507文字
PR

 本コラムで何度も東京海上日動火災保険の「アプリケーション・オーナー制度」を取り上げてきた。ビジネスサイドがシステム開発に深く関わるための制度である。この制度では、ビジネスサイドは要件定義に責任を持つだけでなく、自ら定めた要件定義通りにシステムができているかどうかを、自らテストケースをつくり、自らテストを実施して確認する。これがプロジェクトを成功させる上での肝だとも述べてきた。

 セミナーなどでこの話をすると、「どうしてそんなことができるのか」「厳格な規則があるのか」という質問をよく受けた。

 この制度が成立する基本は、会社全体でシステム開発に「自分事」として向き合う態勢ができていることだ。それが肝要であって、東京海上日動にアプリケーション・オーナー制度の実効性を高めるための規則などは存在しない。ただし、この制度を継続的に機能させるために、様々な工夫をしてきたということはある。最も工夫したのは、システム開発の前提となる年度ごとのシステム開発計画だ。

 東京海上日動は原則として、10月頃から半年をかけて翌年度のシステム開発計画をつくり、3月の経営会議、取締役会での承認を経て、新たなシステム開発に着手する。この過程で大きく3つの工夫をした。

システム部門の「設計士」の工数で開発量が決まる

 1つは「開発キャパシティ」という考え方を基本に据えたことだ。開発キャパシティは、アプリオーナーとともにシステムの要件を定義するシステム部門(システム子会社の東京海上日動システムズを含む)の「設計士」の工数のことだ。

 入社したてのルーキーでは設計はできない。アプリオーナーの言うことを十分に理解して一緒に設計を進めるためには、保険商品や保険ビジネスに対する一定の知識が必要になる。システム部門の部員のうち3分の1程度にその力を認め設計士とした。毎年、その工数によって東京海上日動のシステム開発のボリュームを決めるとしたのだ。

 そこには、システム開発を外部のITベンダーに「丸投げ」するという考え方は全く存在しない。システム部門の設計士の工数でシステム開発全体のキャパシティが決まるという考え方は、取りも直さず会社全体で丸投げを否定しているということである。

 もちろん、システム開発の種類によって社員の関わり方を変えた。例えばITベンダーの力に頼るところが大きい技術的な開発は、社員が関わる度合いを少なくした。外部の人材を生かしたほうがよい領域と、社員が深く関わる必要がある領域をきめ細かく分けて、システム開発計画をつくったのだ。

 どこの会社でも通常、ビジネスサイドのシステム開発要望がそのまま実現することはないはずだ。多くの場合、予算上の制約によると思うが、東京海上日動ではむしろ開発キャパシティの制約が先立つことが多かった。

 この開発キャパシティについて、ビジネスサイドの役員からはよく不満の声が上がった。外部に任せればもっと自分たちの要望を満たせるのにという意見も少なからずあったので、丸投げがいかに経営の力とならないシステムを生み出してしまうかを繰り返し説明した。さらに、社員の工数にこだわっているのは要件定義の局面であって、要件が固まった後のプログラミングの工程ではほとんどを外注としていることなどを丁寧に説明し、徐々に会社全体に理解を広げていった。

 このように、システム開発計画の策定過程から丸投げを否定し、システム開発を社員が徹底的に関わらなくてはいけない仕事として捉えるという考え方がベースにあって、アプリケーション・オーナー制度は機能していたと言える。