Mieruka of competition of Agile IT system development (Japanese)

このシステムは我が国の重要インフラ（通信）を担うA基幹システムの刷新プロジェクトで開発に成功したものである。このプロジェクトのミッションムは、競合の激しい通信分野において、他社に勝るシステムを、他社に先駆けて開発することであった。しかし、10年以上修正を重ねてきた現行のレガシー・システムの仕様を厳密に反映しているドキュメントは残されていなかった。このような状態で、よくユーザは、ベンダに対し要件定義で「現行踏襲」の一言で済ませ、不完全な要件定義義務しか負わずにベンダに請負委託することが多い。この場合、ＩＴ開発がとん挫し、ミッションを達成することが出来ないことを、このユーザ企業・ＩＴ部門は良く理解した上で、ベンダと開発をすすめた。

このユーザは、仮の要件をベンダに伝え、ベンダはそのソフトウェア（SW）を迅速に試作し動かせて、ユーザに見えるようにした。ユーザは、それを踏まえ、そのSWを廃棄し、全く新らしい要件を再検討し、ベンダに再びＳＷ試作を依頼し、再び、その結果をみて再検討した。このような、要件のちゃぶ台返しや試作ＳＷの廃棄を繰り返した。その様子を品質俯瞰図で示すと下図（におけるｍ回のイテレーション）で示す。また、要件が固めってきても、要件の部分修正を何度も繰り返した（下図におけるｎ回イテレーション）。その上で、ユーザは最後の要件の微修正を加えた上で、「要件定義の凍結」を宣言した（この要件には、踏襲が欠かせないレガシーな現行仕様（AsIs）に加え、IT刷新の仕様（ToBe）も加えた最終的なシステム全体の要件が定義されていた）。

　ベンダは合意したプロジェクト憲章（要件定義書）に従い、その要件品質の土台の上に、設計品質・製造品質・試験品質を積み上げ、ベンダの受託品質確認や最終運用試験（現行システムから刷新システムへの移行やその後のシステム運用の最終確認）を経て、このＩＴ開発は「完成」した。

ベンダは合意したプロジェクト憲章（要件定義書）に従い、その要件品質の土台の上に、設計品質・製造品質・試験品質を積み上げ、ベンダの受託品質確認や最終運用試験（現行システムから刷新システムへの移行やその後のシステム運用の最終確認）を経て、このＩＴ開発は「完成」した。

このAgile型の開発プロジェクトでは、試作ＳＷの廃棄の繰り返しでコストが増加した。しかし、コストを犠牲にしてもAgilityは向上(Waterfall型と比べて納期Dを短縮）、その結果、通信分野の 競合他社に勝るITへ、いち早く刷新することに成功した。このため、刷新後、新料金サービス提供などで、現在でも業界シェアでトップを走っている。

　この事例から、紛争防止の原理は

・要件定義義務をユーザが果たすこと

・開発品質積上義務をベンダが果たすこと

である。