従来型開発では稼働開始時点の品質が最も高く、以降は低下していく。業務や外部環境の変化に素早く対応できるように、カットオーバーを通過点と捉える「カイゼン型開発」に改めよう。

 「改修がわずか1行でも、影響調査に1カ月、テストに数週間かかることが珍しくなかった―」。アマダが従来利用していた基幹システムは、長年の保守でシステムがつぎはぎ状態になっていた。保守作業は属人化が進んで、担当したベンダーの特定のエンジニアでないと、手を付けられない部分が散在。過去の改修内容がドキュメントから漏れていたことがテスト段階で判明し、設計からやり直したことも1度や2度ではない。

 システムがこの状態では、ビジネスも回らなくなる。グループ再編に伴う企業合併や業務改革などの動きにシステムの変更が追い付かず、経営戦略を立てる上でも大きな制約になった。武尾清氏(執行役員 ICT部門長)は、「企業合併をする上で不可欠なシステム改修がいつ終わるのか、経営層から何度も質問された」と打ち明ける。

価値の高いシステムに成長する

 こうした苦い経験を踏まえ、アマダは基幹システムの再構築に際して、開発方法を従来型から大きく変えた(図1)。「従来と同じ作り方をして、同じような保守をしたら、いずれまたシステムがつぎはぎ状態になることが避けられない」(武尾氏)からだ。

図1●システムの変更が追い付かなくなり開発方法を変えた
図1●システムの変更が追い付かなくなり開発方法を変えた
アマダの基幹システムは、長年にわたる場当たり的な保守によって構造がつぎはぎ状態になり、業務改革などの動きに追従できなくなっていた。そこで、再構築を機に開発方法を変えた
[画像のクリックで拡大表示]

 再構築したシステムではまず、6カ月の開発期間に収まる規模で、パイロットシステムを構築。それをベースに、6カ月単位で順次機能を追加していく。従来の開発に比べると、一つひとつの開発規模は小さく、開発サイクルも短い。パイロットシステムは複数部門に共通する機能に絞り込んだもので、機能追加のサイクルでは他部門向けの開発も並行して進められる。

 また、マスター配信や認証、セキュリティといった基盤を整備し、各種システムに共通の機能を部品化した。

 これらの変更によって、短期間でシステムの機能追加を繰り返せるようになった。システムの構造が分かりやすくなり、改修の影響調査に1カ月かかるようなこともなくなった。現在、たいていの改修は、完了まで1~2週間もあれば済むという。

従来型開発では稼働がゴール

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

 その際、「稼働後に継続的に保守しやすいシステムにするという観点はないことが多い」とブックオフの石毛信次氏(管理本部 IT統括部 統括グループ マネージャー)は指摘する。このため、出来上がったシステムは保守が容易なものにはなりにくい。