一般的なシステム開発方法では、カットオーバーが開発チームにとってのいわばゴールであり、そこに無事こぎ着けることが目標となる。それゆえゴールを明確にする必要があるので、開発がスタートする前にすべての要件を確定させる。そして開発チームは、事前に定められたコストと期間の中で、事前に確定させた要件を満たすシステムを作り上げることに専念する。

 その際、稼働後に継続的に保守しやすいシステムにするという観点がないことが多い。このため、出来上がったシステムの保守は容易なものにはなりにくい。また、完成したはずのシステムが、稼働開始時点で既に改善が必要になることが多い。開発中に組織や業務が変わったり、競合他社との関係や市場ニーズといった外部環境に変化が生じたりするからである。

 システムがひとたび稼働するとプロジェクトは解散し、開発チームの仕事は完了となる。そして、保守しづらいシステムに対して、保守チームは開発時の事情をよく把握しないまま力ずくで保守を行う。ユーザーの変更要望に効率良く対処するため、担当者が自己流のやり方で場当たり的な作業をしてしまうと、システムはさらに複雑化する。品質がみるみる低下し、やがて変化に追従できなくなってしまう。

1行の改修に1カ月、業務改革のネックに

 長期間にわたり場当たり的な改修作業を繰り返したことで、つぎはぎ状態になってしまったある製造系企業の基幹システムでは、「たった1行変えるだけでも、影響調査やテストが大変で1カ月以上かかることが珍しくなかった」そうだ。システムがそのような状態では、ビジネスがスムーズに回らなくなる。経営陣にとって、システムの改修が遅々として進まないことが、経営戦略を立てたり、業務改革を行ったりする上で大きな制約になっていたという。

 経営陣ばかりではなく、共通部門を中心に一般社員も必要なデータを基幹システムから得られず困り果てた。仕方なく、基となるデータを各種帳票からかき集めたり、製造や販売部門から聞き出したりして、それをExcel上の手組みのマクロで処理することによって何とか業務を回していた。そうして得た数字の精度が問題になることもあった。例えば、販売方針を決める上で重要な意味を持つデータを関係者が持ち寄った際に、同じ値であるべき指標が処理方法の違いから相互に異なる数値として認識され、議論がかみ合わないありさまだった。

 こうした問題を回避するには、開発方法の切り替えが有効だ。日経SYSTEMS4月号の特集1「カイゼン型開発のススメ」の取材では、カットオーバーを単なる通過点と捉え、稼働後にも開発チームが機能を次々と付加したり、業務や外部環境の変化に合わせて機能をどんどん作り変えたりする“カイゼン型開発”に改めることによって、環境変化への対応力が高まった事例を数多く見聞きした。

 前述の製造系企業は、つぎはぎになった基幹システムをカイゼン型開発によって再構築した。まず、6カ月の開発期間に収まる規模で、パイロットシステムを構築。それをベースに、6カ月単位で順次機能を追加していく。従来の開発に比べると、一つひとつの開発規模は小さく、開発サイクルも短い。パイロットシステムは複数部門に共通する機能に絞り込んだもので、機能追加のサイクルでは他部門向けの開発も並行して進められる。また、マスター配信や認証、セキュリティといった基盤を整備し、各種システムに共通の機能を部品化した。

 これらの変更によって、再構築後の基幹システムは「改善サイクルが短期間で回る」「持続的に改善できる」ようになった。システムの構造が分かりやすくなり、改修の影響調査に1カ月かかるようなこともなくなった。たいていの改修は、完了まで1~2週間もあれば済むという。

 従来は改善サイクルが長く、次の改善がいつになるか分からない状態だったので、利用部門の担当者は使うかどうかはっきりしない機能も含めて、一度に多数の機能追加を求める傾向があったそうだ。しかし再構築後は改善サイクルが短いので、必要性がはっきりしない機能については先送りして、必要になった段階で追加してもらえばよいと考えるようになった。つまり、カイゼン型開発に切り替えたことで、「作ったのに使われない」という開発の無駄を減らす効果も得られたのである。