本セミナーの概要 長期にわたって保守開発をしてきたシステムは レガシー化が進んでいませんか? このようなシステムの再構築は 簡単ではありません そこには 現行業務仕様の理解不足 などによる再構築に特有の難しさという課題が内在します この課題の解決には 上流工程においてリスクを明らかにし 対策と共にユ

上流工程強化セミナー in 大阪

～システム再構築を成功に導くために～

大阪市立総合生涯学習センター

2018年3月17日

共催 独立行政法人情報処理推進機構 （IPA）

ソフトウェア技術者協会（SEA） 関西支部

後援 一般財団法人関西情報センター（KIIS）

特定非営利活動法人ITコーディネータ協会（ITCA）

本セミナーの概要

長期にわたって保守開発をしてきたシステムは、

レガシー化

が進んでい

ませんか？ このような

システムの再構築

は、簡単ではありません。そこ

には、「

現行業務仕様の理解不足

」などによる再構築に特有の難しさと

いう

課題

が内在します。この課題の解決には、

上流工程においてリスク

を明らかにし、対策と共にユーザとベンダとで合意

することが重要です。

そこで、IPA/SECでは、現場における知見やノウハウをまとめた書籍「シ

ステム再構築を成功に導くユーザガイド～ユーザとベンダで共有する再

構築のリスクと対策～」を発行しました。このガイドは、ユーザが現行シ

ステムの再構築を計画する際に、最適な手法を選択し、正確でかつベ

ンダと齟齬を生じさせない「システム化計画」の策定を支援します。

今回は、ユーザとベンダとが合意形成する際に役立つ

事例

を交えて、

課

題解決のポイント

を解説します。また、現場のリーダが経営層などとコ

ミュニケーションを図るイメージを掴んでいただくことを期待し、新たに発

行した小冊子「デジタル変革に向けたITモダナイゼーション企画のポイ

ント集～注意すべき7つの落とし穴とその対策～」について説明します。

背景：ITシステムの変貌に伴う課題

当初、業務支援であったITシステムは、その技術自身の進展と

時代の要請から、その利用が質、量ともに拡大してきた。

背景：守りの分野の課題

長年保守開発を続けたITシステムの再構築に「

特有の難しさ

」

上流工程で対応しないと・・・下流工程でリスクが顕在化

ユーザは、ベンダと協力して、内在するリスクを開発着手前に

評価し、対策を検討することが重要。

背景：IPA/SECの取組み概要

【基本領域】

システム化要求ＷＧ

※システム開発に共通

するベーシックな要件

定義の品質を向上

【応用領域】

モダナイゼーションＷＧ

※再構築特有のリスクに

対する対策を計画に

反映して、品質を確保

開発着手前（企画、要件定義）における品質の確保及び向上に取り組む。

開発

設計

製造

試験

稼動判定

稼動

現行仕様把握

システム化計画

企画

要件定義

要件定義

ベーシックな

システム開発

ライフサイクル

 システムや業務の特性、再構築手法などを考

慮し、品質確保の範囲や方法、粒度を整理

 稼動判定時のカットオーバークライテリアにつ

 現行仕様（業務マニュアル・業務フロー・

各種設計書等）の理解が全ての出発点

 現行仕様の理解が起点となり、質の高い

 求められる要件の抜け・漏れ・あいまいな定義を

なくし、 設計・製造・試験の品質向上につなげる

凡例：

取組み

 きちんと現行業務を見て、要件として定義する

 業務要件とシステム要件の整合性をとる

活動の成果



ガイドブックの公開

ユーザのための要件定義ガイド

～要求を明確にするための勘どころ～

システム再構築を成功に導くユーザガイド

～ユーザとベンダで共有する再構築のリスクと対策～

2017年1月31日 PDF版公開

2017年3月10日 書籍発行

https://www.ipa.go.jp/sec/publish/tn16-008.html

https://www.ipa.go.jp/sec/publish/tn16-009.html

https://www.ipa.go.jp/sec/reports/20170131.html

2018年2月26日 第２版発行

ポイント集も公開

「再構築ガイド」

本セミナーの構成

講演1．システム再構築の現場で陥りやすい落とし穴

講演2．システム再構築におけるリスクの把握から対策の合意まで

講演3．システム再構築の課題に対する企業の対応事例

～再構築プロジェクトだからこそ知っておきたい、

上流工程におけるコミュニケーションのツボ～

課題

解決策

事例

システム再構築の現場で陥りやすい落とし穴

上流工程強化セミナー in 大阪

～システム再構築を成功に導くために～

大阪市立総合生涯学習センター

2018年3月17日

山下 博之

独立行政法人情報処理推進機構（ＩＰＡ）技術本部 ソフトウェア高信頼化センター（ＳＥＣ）

講演１

本講演の趣旨

システム再構築

が抱える課題は、時間が経過して仕様が不明瞭になっている現行

システムの状況にも関わらず、

仕様があいまいなまま開発に着手

してしまうこと

です。このことは何年も前から指摘されていますが、いまだにシステム再構築の

トラブル

事例の報告が絶えません。この課題を解決するには、過去に同様の課題

に直面し上手く対応した、あるいは苦い経験をした企業の知見を参考に、再構築

の企画／計画工程で検討すべき観点を整理・提示することが有用です。

そこで、

IPA/SEC

では、このテーマの経験豊富なユーザ企業及びベンダ企業の

方々による検討結果を取りまとめ、

「システム再構築を成功に導くユーザガイド

～ユーザとベンダで共有する再構築のリスクと対策～」

(第1版)を2017年3月に

発行しました。さらに2018年2月、対象範囲を拡充した第2版を発行しました。

本日のセミナーの導入となる本講演では、再構築プロジェクトの現場で直面する

「現行踏襲」と「品質保証」に関する

問題

について、事例を交えて説明します。

また、再構築プロジェクトにおいて陥りやすい事象を整理し、

「落とし穴」

とし

てまとめましたので、それを紹介します。問題の解決策については、以降の講演

で解説します。

本講演の目次

1．システム再構築に関わるトラブル

2．システム再構築の現場で何が起こっているか

3．課題のまとめ：落とし穴

4．再構築ガイドの活用

Public Domain

「ウィキペディア-大阪城」より

本講演の目次

1．システム再構築に関わるトラブル

2．システム再構築の現場で何が起こっているか

3．課題のまとめ：落とし穴

システム再構築に関する最近のトラブル事例報道

・失敗の全責任はユーザー側に、旭川医

⼤とNTT東の裁判で逆転判決

http://tech.nikkeibp.co.jp/it/atcl/column/14/346926/092501136/

・東

⼤病院でシステムトラブル、電⼦カルテ刷新直後に混乱

http://tech.nikkeibp.co.jp/it/atcl/column/14/346926/020501300/

・京都市とIT企業がシステム裁判に、基幹系刷新の完

_{了は3年延期}

http://tech.nikkeibp.co.jp/it/atcl/column/14/346926/111601207/

・27億円の賠償巡り新たなIT裁判始まる、文化シヤッターが提訴

http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/00014/

・要件固めに失敗した責任はベンダーかユーザーか、JTBとビーコンIT

のシステム裁判

http://tech.nikkeibp.co.jp/it/atcl/column/17/110700489/110700005/

最近のトラブル事例報道事例から見た

システム再構築の“リスク”

 要件が固まらない

 設計が進まない

 試験が終わらない

 途中でやり直し

業務効率の低下

プロジェクトの失敗

損失

「現行」が不明確

明確化不十分

開発プロジェクトへの影響

で進めると

 旧システムと

操作が異なる

 旧システムの

問題がそのまま

明確化した「新仕様」の

合意不十分で進めると

システム利用者への影響

（再改造）

（ユーザ，ベンダ共）

適切なステークホルダ

（エンドユーザ，等）

システム再構築の“リスク”を低減するには？

要件定義の前，企画／計画工程にもっと時間をかけて，

ユーザ/ベンダ双方が協力

し，

現行システムの仕様の明確化を図ると共に，

不明点等に関する以降の

リスクについて合意

する

ユーザ

 簡単にできると思うな

ベンダ

 安易に請け合うな

• セキュリティ強化

• 新サービス対応し易く

• ムダの排除

単なる再構築にも

コストをかけるだけの価値はある

• 想定リスクとその対策

• プロジェクトを通した，円滑なコミュニケーション手段

• プロジェクト中に発生し得る問題の解決の仕組み

本講演の目次

1．システム再構築に関わるトラブル

2．システム再構築の現場で何が起こっているか

3．課題のまとめ：落とし穴

4．再構築ガイドの活用

システム再構築のニーズ

モダナイゼーション

SoE

SoR

アジャイル

攻めのIT

Agile

Digital Transformation

インテグレート

オープンAPI

長年運用しているシステムを最新のIT技術に対応させて

近代化するモダナイゼーションが注目されている。

メインフレーム

システム再構築現場の実状



システム再構築でユーザもベンダも苦戦。特に企業の基幹となる

システムの再構築において期間やコストの超過といった

問題プロ

ジェクトが後を絶たない。



モダナイゼーション作業が一巡。大規模・高難度案件の残留。

モダナイゼーション人材難。

旧システム

(大型メインフレーム)

・ハードウェア入替え

・業務仕様は継続して

新システムへ

・業務を作り直して

サーバ機種も変更

・パッケージへ変更・・

APｻｰﾊﾞﾌﾞﾛｯｸ

DBｻｰﾊﾞﾌﾞﾛｯｸ

・・・

・・・・

Webｻｰﾊﾞﾌﾞﾛｯｸ

運用監視ｻｰﾊﾞ

帳票ｻｰﾊﾞ ﾊﾞｯﾁｻｰﾊﾞ

ﾊﾞｯｸｱｯﾌﾟｻｰﾊﾞ

負荷分散

負荷分散

KVMｽｲｯﾁ/ｺﾝｿｰﾙ

・膨大な既存資産

・現行踏襲要求

・後継者不足

さらに・デジタル革新への備え

新システム

業務知識が失われる背景

○○業務

Ａ機能

Ｂ機能

××業務

Ｃ機能

Ｄ機能

帳票

Ｅ処理

Ｆ処理

Ｇ処理

オンライン

開発者

バッチ

開発者

業務ユーザ①

業務ユーザ②

業務ユーザ③

業務ユーザ③

の異動

バッチ開発者

の離任

断片化

体制の縮小

、

人事異動

などにより

システムに関わる人が交代

△△業務

Ｈ機能

Ｉ機能

Ｊ処理

業務ユーザ④

新たな業務・

サブシステムの

追加

領域の変化

ビジネスや技術の環境の変化

に

合わせて、システムは仕様変更が

繰り返される

断片化

体制の縮小

、

人事異動

などにより

システムに関わる人が交代

細分化

複数のユーザや開発者が

業務知識

の領域を分けて理解している

レガシー化したシステムでは、「

細分化

」「

断片化

」「

領域の変化

」

により業務知識の欠落が生じている。

再構築の現場で何が起こっているか

「現行踏襲」に関する問題

「品質保証」に関する問題

「現行踏襲」を実現する上で、「現行踏襲」の「現行」が何か、

ユーザとベンダとの間でギャップ

が発生する場合がある。

再構築の「品質保証」では、

業務継続性の担保

が求められるが、

現行業務知識が不足していることで、様々な困難が発生する。

再構築の現場で起こり得る問題

再構築の現場で何が起こっているか

～「現行踏襲」に関する問題～ （1）

現行踏襲の「現行」が何かについて、

ユーザとベンダとの間で

ギャップが生じる

ことで問題が発生することがある。

再構築の現場で何が起こっているか

～「現行踏襲」に関する問題～ （2）

～設計書やソースコードと動作しているシステムのギャップによる問題事例～

現行システムより処理時間が遅く業務が滞るため改善して欲しいという要望が寄せられ

当該処理を

作り直すことになり、予定していたサービス開始が延期

される事態となった。

再構築の現場で何が起こっているか

～「品質保証」に関する問題～

現行業務知識不足

テストをどこまで実施する必要があるのか判断が困難

テスト項目の作成が困難

トラブル時に解析が困難

３

問題化

１

２

業務継続性の担保

が求められるが、現行業務知識が不足して

いることで、様々な困難が発生する。

【事例2】プロジェクト推移

変換設計・変換

試験工程で問題が一気に噴出し、

大幅な手戻りにより開発コストが膨れ上がってしまった

図．計画見直しによるコスト遷移

開発コ

ス

ト

試験

棚卸し・再利用分析

変換設計・変換 試験

棚卸し・再利用分析

設計見直し

試験

業務・システムの

十分な理解なく

再利用が進む

問題が噴出

問題切り分

けが困難

システム全体の

業務理解を行った

上で、追加試験

計画

_実績

計画

実績

ケース：再構築にパッケージ製品を利用する場合

使用しない

パッケージ標準機能

適合

（Fit部分）

パッケージ

標準機能

パッケージ製品を

ほぼそのまま利用

（タイプ①）

パッケージ

提供機能

パッケージ製品が提供する

機能で開発して実現

（タイプ②）

カスタマイズ対応

（Gap部分）

パッケージ外

機能

不適合

（Gap部分）

外付け（アドオン）で

開発して実現（タイプ③）

運用対処など

パッケージの

機能分類

Fit&Gap分析

現行要件

パッケージのカスタマイズ量の増大に伴い，リスク増加

ケース：再構築時に業務要件の変更／追加を行う場合

再構築と業務要件の変更／追加とを同時に行うと，

試験結果の原因切分けが困難になる．

本講演の目次

1．システム再構築に関わるトラブル

2．システム再構築の現場で何が起こっているか

3．課題のまとめ：落とし穴

1. 「. 再構築だから」と企画・要件定義フェーズを軽視

していませんか？

【ポイント】

再構築であっても、後工程に大きな影響を及ぼす課題を、企

画段階で出し尽くすまで議論し、認識しておくことがプロジェク

ト成功の鍵と

なる。

2. 「今と同じ」という要件定義になっていませんか？

【ポイント】

再構築の要件定義であっても、現行システムの「何を」「どの

ような状態に」実現したいのかを明確にし、要件定義工程の成

果物としてアウトプットする。

3. 現行システムの調査が「表面的」になっていません

か？

【ポイント】

後工程で上流工程まで手戻りを発生させないために、普段目

にしないシステムの全貌も含めて現行調査を行う。

4. 業務部門はメンバの一員として上流工程から参加し

ていますか？

【ポイント】

長期の運用により、現行システムの「利用実態」は、ドキュメン

トに表し切れていない場合がある。再構築には業務部門が上

流工程から参加することを必須とする。

5. 現行システムが動いているから、品質保証を簡単に

考えていませんか？

【ポイント】

「品質保証方針」は、スケジュールやコストに影響する。品質

保証方針の検討不足は、最悪の場合、ビジネス機会損失も招

くことから、

上流工程で

決定し、

ステークホルダ

間で合意を図る。

6. 担保すべき「業務継続性」は明確になっていますか

？

【ポイント】

何が運用できれば「業務」を継続できるのか、企画段階からそ

の判断基準をステークホルダが一体となって作り上げ、再構

築のゴールを明確にする。

7. モダナイゼーションのリスクを甘く見ていませんか？

【ポイント】

単に「リスク」を共有するだけでなく、対応方針をステークホル

ダで整理し合意する。リスク対策状況をタイムリーに把握する

ことが、計画したスケジュールやコストのコントロールに繫がる。

本講演の目次

1．システム再構築に関わるトラブル

2．システム再構築の現場で何が起こっているか

3．課題のまとめ：落とし穴

再構築の問題化を防ぐために

再構築ガイド

の目的

本ガイドの利用について

インプット

アウトプット

：共通フレーム

：PMBOK

：社内標準類

：システム化計画

・新規開発の標準類

からの計画内容

・本ガイドで検討した

計画内容

：本ガイドブック

：RFP

運用検証

要件定義

基本設計

詳細設計

プログラム設計

システムテスト

結合テスト

単体テスト

製造

企画工程

本ガイドは

企画工程

で使用することを想定している。

本ガイドの前提条件と再構築手法の定義

要件定義

基本設計／詳細設計

プログラム設計

プログラムソース

＜凡例＞

_{：非互換の変更}

_：再作成

再構築ガイドの構成

SEC BOOKS：システム再構築を成功に導くユーザガイド

～再構築のリスクと対策の合意に向けて～

http://www.ipa.go.jp/sec/publish/tn16-009.html