ブログ:アプリケーション保守の問題点は何か、アウトソーシングはこれを解決できるか?

  において、アウトソーシングでは保守コストは一応、下げられますが、根本的な問題解決は開発の場合と同様に、よりよい「保守要求を開発」することだと述べました。

1.GUTSY-4による「保守要求のレビュー・開発」

  ビジネスアナリシスの通常の流れでは、まず、ビジネスプロセス上からなぜ(Why)、何を解決して欲しいかのIT要求(Whatが出てきて、これを実現する手段としてソフトウェア要求仕様(How)が定義されます。このWhy-What-Howの3者の関係は、新規開発の場合と全く同様です。

(1) 適応保守

  これは、ビジネスプロセス(Why)を起因としますので、ビジネスアナリシスによって、有効なIT要求(What)を定義できます。GUTSY-4では、ビジネスプロセスからIT要求を引き出しますので、さらに有効なIT要求を定義できます。 →ITへの要求をどうやって引き出すか、IT要求開発するか

(2)完全化保守

  ところが、アプリケーション保守要求は、あの画面にあの項目をとか、あの帳票にあのデータ項目をとか、具体的に手段・Howであるソフトウェア要求仕様として出てきます。したがって、一見、正当に見えますが、システム機能の約64%が全く、あるいはほとんど利用されていないことを鑑みれば、これを検証する必要があります。

  すなわち、ソフトウェア要求仕様(How)から、ビジネスプロセス(Why)に立ち戻って、アプリケーション保守要求の業務上の価値を評価したり、もっと優れた保守要求(What)を開発することが必要となります。これは、ビジネスアナリシス方法論GUTSY-4によって、各々の要求を定義するためのWBSをリバースエンジニアリングして適用することで可能となります。

2.筆者が行ったソフトウェア要求仕様のレビュー事例

  これは、筆者がIT要求定義にも関わっていない中、ソフトウェア要求仕様について、当時の業務参照モデルを利用してレビューした事例です。レビューの結果、このプロセス(Why)からは、通常、こんなIT要求(What)がある筈だとかを指摘。ユーザは、「旧システムにその機能があるので、改めてIT要求として出さなかった」と述べた。

  そして、ソフトウェア要求仕様の中には、アウトプットを「メール添付できるように」というのもありました。しかし、これは、メールという手段(How)に立ち入っています。さらに、プロセス(Why)に立ち戻れば、アウトプット共有のような別のIT要求(What)が出てくる可能性もあります。Why-Whatをレビューせずに、Howという手段に飛びつくのは極めて安易です。

  最終的に、この事例では、アプリケーションシステムは15カ月の開発期間でオンタイムで本稼働し、途中でのIT要求への手戻りは皆無。

3.GUTSY-4を適用した「保守要求の開発」の効果

  GUTSY-4をアプリケーション保守に適用する効果は、

  第一に、アプリケーション保守作業では50%のムダを省いて、新規開発に回すことができます前ブログからの簡単な試算による)。

  第二に、さらに優れて有効な保守要求を開発できたり、第三に、無駄な保守作業の排除によってアプリケーションシステムの劣化も防止できます

 

カテゴリ