...

講座プレゼン資料4-3

by user

on
Category: Documents
1

views

Report

Comments

Transcript

講座プレゼン資料4-3
レガシー移行に伴うマネジメント
自治体
CIO養成
CIO育成
講座
研修
1
4-3 レガシー移行に伴うマネージメント
自治体CIO育成研修
本日の講義の内容
1.レガシー移行方法決定の留意事項
2.レガシー移行実施計画の立案の留意事項
3.レガシー移行における開発監理の留意事項
4.レガシー移行における新システムの移行の留意事項
グループ演習課題
4-3 レガシー移行に伴うマネージメント
2
自治体CIO育成研修
レガシー移行に伴うマネジメントの定義
¾ システムのマネージメントとしては、以下の2つが考えられる。
9システムのライフサイクルに対する各工程のマネージメント(企画立案段階、基
本計画段階、業者選定段階、システム開発段階、運用段階など)
9システムそのものの世代ごとのマネージメント(1世代システム、2世代システ
ムなど)
¾ レガシー改革に関しても、システムの最適化を行う段階として、何世代かに分けて
最適化を行う(当面の課題を解決したシステム→将来的な理想システムなど)場合
もある。
¾ ライフサイクルに対する各工程のマネージメントに関しては、各工程ごとに計画
(plan)、実施(do)、評価(check)、対策(act)のプロセスが実施され、システムそ
のものの世代ごとのマネージメントに関しても、各世代ごとに計画(plan)、実施
(do)、評価(check)、対策(act)のプロセスが実施される。
¾ 本講座におけるマネージメントの範囲としては、レガシー改革によりシステムを再
構築するための、システムのライフサイクルに対する各工程のマネージメントとす
る。
4-3 レガシー移行に伴うマネージメント
3
自治体CIO育成研修
レガシー移行に伴うマネジメントの定義
4-3 レガシー移行に伴うマネージメント
4
自治体CIO育成研修
1.レガシー移行方法決定の留意事項
4-3 レガシー移行に伴うマネージメント
5
自治体CIO育成研修
自治体におけるレガシーシステムの現状
† レガシーシステムの現状
¾個別業務の効率化を図るために、信頼性の高いメインフレームを使用してシ
ステムの構築を図ってきた。しかし、その後のIT技術の進展に伴い、以下の
様な様々な問題が生じてきた。
‹システムが複雑化し、改修や運用が困難
→システムの複雑化によるメンテナンス性の低下
‹ハードウェア、ソフトウェアが高価
→維持・運用コストが高額
‹拡張性に乏しく、柔軟な対応が難しい
→システム改修に多大な工数と費用が発生
‹熟知した技術者の確保が困難
→中央計算機固有の技術による人的制約やメンテナンス業務負荷の増大
¾更に、クライアントサーバーシステムやWebシステムの混在により、システム
全体が複雑化してきている。
4-3 レガシー移行に伴うマネージメント
6
自治体CIO育成研修
レガシー移行の必要性と方法
† レガシー移行の必要性
¾現在のメインフレームのシステムの課題を根本から解決するものとして注目
されているのが、「レガシー移行」である。これは、これまでのメインフレーム
の資産を引き継ぎながら、運用費用のかかるメインフレームからの脱却を図
るものである。
¾メインフレーム中心のレガシーシステムを単にオープン環境に切り替える(移
行する)ことではなく、組織運営と密接に関連する重要な課題として捉え、最
適な情報システムのあり方を目指すことにより、競争力の強化やサービスの
向上などに寄与する手法を、本講座では、「レガシー改革」と定義する。
4-3 レガシー移行に伴うマネージメント
7
自治体CIO育成研修
レガシー移行の必要性と方法
† レガシー移行の方法
¾以下の4つの方法に大別される。
‹ラッピング:メインフレーム上のデータベース(またはアプリケーション)を、接続し
たオープン系システムからアクセスできるようにする手法。従来特定の環境でし
か使えなかったソフトウェアのインタフェースの固有部分をラッパーと呼ばれるプ
ログラムが吸収することで、統一されたインタフェースで、データ(またはコード)
の検索・抽出を行う。
‹リホスト:メインフレーム上のプログラムやデータを、基本的にプログラムの修正
は行わず、そのままの形でオープン系に移植する手法。
‹リライト:メインフレーム上のプログラムやデータを基に、プログラムやデータベ
ースを全てオープン系言語で書き換えてしまう手法。
‹リエンジニアリング:業務そのものを根本から見直し、アプリケーションを最初か
ら作り直す手法。新規開発と同様の期間とコストが必要となる。
4-3 レガシー移行に伴うマネージメント
8
自治体CIO育成研修
レガシー移行方法の選択
† レガシー移行の目的に合致した方法を選択
方法
ラッピング
リホスト
長所
短所
非常に短期間・
低コストで実現
できる
データ活用以外
の課題はまったく
解消されない
短期間・低コス
トで実現できる
現状の課題がそ
のまま残る
リライト
コスト削減・ICT
推進要求にバ
ランスよく対応
できる
期間、コストがか
かり、安定稼動
までに時間がか
かる
リエンジニ
アリング
現状の課題が
全て解消される
期間とコストが膨
大にかかる
リエンジニアリング
I
T
技
術
対
応
・
業
務
の
効
率
化
等
の
効
果
4種類の手法を理解し、レガシー移行の目的
に合致した手法を選択する
4-3 レガシー移行に伴うマネージメント
ラッピング
リライト
リホスト
コスト削減効果
9
自治体CIO育成研修
パッケージ利用の留意事項
自治体のレガシー移行においては、最もバランスよく対応できるとされている「リライ
ト」の手法を用いるよりも、パッケージソフトを利用して「リエンジニアリング」する手法
が取られるケースの方が多い。パッケージソフトの利用により、 「リエンジニアリング」
の欠点である、長期にわたる開発期間や高コストの問題が解消できるからである。
東京23区の某区における実績においても、パッケージソフトを利用したダウンサイジン
グにより、運用保守費用が年間80%程度削減されている。
† パッケージソフトによるレガシー移行のポイント
パッケージソフトのカスタマイズ規模を10%以下に抑えることにより、初期導入コ
ストを低減する。また、これにより、法改正対応等が、保守契約基本料のみで対応
できる様になり、運用コストの低減にもつながる。
† ハードウェア更改時に対する考慮
オープン系のパッケージソフトでも、通常10年程度使い続けることは可能である
が、サーバ更改時(通常4年∼5年)には、再度購入するケースも生じている。
また、OSやデータベースソフトがバージョンアップされていることにより、それに対
する対応で、追加費用が発生するケースも生じている。
4-3 レガシー移行に伴うマネージメント
10
自治体CIO育成研修
2.レガシー移行実施計画の立案の留
意事項
4-3 レガシー移行に伴うマネージメント
11
自治体CIO育成研修
実施計画の作成
† レガシー改革のための実施計画の作成手順
目的と範囲の明確化
目的と範囲の明確化
開発方針の明確化
開発方針の明確化
開発内容の検討
開発内容の検討
スケジュール・体制の検討
スケジュール・体制の検討
4-3 レガシー移行に伴うマネージメント
‹オープン化や標準化への対応の考え方
‹安全性・信頼性指針
‹柔軟性・確証性に関する考え方 等
‹既存資産の活用指針
‹開発期間の指針
‹Web化等の構築指針 等
‹開発課題の検討
‹実施手順の明確化
‹ツール、ドキュメント化方針の検討 等
‹開発スケジュールの立案
‹開発体制の立案
‹開発費用の試算 等
12
自治体CIO育成研修
マイルストーンの設定
† マイルストーンの設定方法
¾マイルストーンを設定した上で、作業工程ごとに、タスクをリスト化し、マイル
ストーンに従って、スケジュール化する。
標準的なレガシー改革手順
現行システムの
ソフトウェア資産
システムへの変換
システム変換後の
ソフトウェア資産
システムの
移行
ツールによる変換
レ
ガ
シ
ー
シ
ス
テ
ム
プログラム
制御言語
画面
帳票
ファイル
DB
外字
ツールによる変換
+人手による変換
調
査
・
分
析
機能追加
新規開発
プログラム
制御言語
画面
帳票
ファイル
DB
外字
検
証
オ
ー
プ
ン
シ
ス
テ
ム
運
用
テ
ス
ト
変換不能
廃棄
ポイント
現行ソフトウェア資
産の調査・分析、棚
卸
ポイント
プログラムの一部試
行変換による課題抽
出
4-3 レガシー移行に伴うマネージメント
ポイント
移行するソフトウェア
資産の決定
ポイント
新システムのソフト
ウェアの可視化と管
理
ポイント
移行後のシステムと
現行システムでのテ
スト結果の照合
ポイント
実運用部門の職員
による確認
13
自治体CIO育成研修
開発スケジュールの作成
† 開発スケジュール作成例
××
4-3 レガシー移行に伴うマネージメント
14
自治体CIO育成研修
開発体制の設定
† 開発体制の設定方法
¾設定した目標やタスクリストから必要なリソースの要件を見積り、リソースを各
タスクに割り当てる。なお、必ず原課担当者を含めた体制とする。
【体制記載例】
【開発体制の実例】
4-3 レガシー移行に伴うマネージメント
15
自治体CIO育成研修
開発コストの試算
† 開発コストの試算方法
¾各ソースのコストに基づき、タスクごとのコストを算出し、予算の範囲内である
ことを確認する。また、費用対効果の分析を行う。
項
H16年度
目
現行システム運用・保守費用
新システム開発費用
計
H18年度
H19年度
H20年度以降
620,000
620,000
620,000
310,000
−
50,000
200,000
300,000
−
−
−
−
−
350,000
350,000
670,000
820,000
920,000
660,000
350,000
新システム運用・保守費用
合
H17年度
費用削減効果
費用比較
1,000,000
800,000
900,000
600,000
800,000
400,000
600,000
200,000
費用(千円)
費用(千円)
700,000
500,000
400,000
300,000
0
平成16年
平成17年
平成18年
平成19年
平成20年
平成21年
平成22年
平成23年
-200,000
200,000
-400,000
100,000
-
-600,000
平成16年
平成17年
平成18年
平成19年
平成20年
平成21年
平成22年
平成23年
年度
現行システムの運用・保守費用
新システムの開発および運用・保守費用
4-3 レガシー移行に伴うマネージメント
-800,000
年度
16
自治体CIO育成研修
3.レガシー移行における開発監理の留
意事項
4-3 レガシー移行に伴うマネージメント
17
自治体CIO育成研修
開発監理項目
† 開発監理の内容
¾PMBOK(ピンボック、Project Management Body of Knowledge)等、標準
的(国際標準、デファクトスタンダード)な手法の基に、以下の項目について管
理を行う。
‹進捗管理:進捗の遅れを防ぐため、定量的な数値に基づいた予実対比で実施する。
‹課題管理:課題の処置漏れを防ぐため、一覧形式で、重要度、緊急性を含めて管理する。
‹品質管理:システムの品質を確保するため、各工程ごとに品質評価基準を設けて評価を実施
する。
‹仕様管理:仕様の不整合や伝達漏れを防ぐため、仕様を一元的に管理する。
‹コスト管理:予算のオーバーを防ぐため、定量的な数値に基づいた予実対比で実施する。
‹契約・調達管理:外部委託した作業の仕様伝達漏れ、工程遅延、品質の劣化などを防ぐため、
実施計画に基づく進捗等報告により実施する。
‹その他管理:伝達の漏れなどを防ぐため、連絡表の一元管理等を実施する。
4-3 レガシー移行に伴うマネージメント
18
自治体CIO育成研修
開発監理の実施サイクル
† 開発監理の実施方法
¾計画(plan)、実施(do)、評価(check)、対策(act)のプロセスを順に実施し、
最後の改善を次の計画に結び付け、らせん状に品質の維持・向上や継続的
な業務改善活動などを推進する。
4-3 レガシー移行に伴うマネージメント
19
自治体CIO育成研修
開発監理の実施例(1)
† 進捗管理実施例
【進捗状況からの分析】
ST試験実施状況(○○システム)
300
4000
3500
250
3000
150
2000
1500
件数(当週)
件数(累計)
200
2500
100
1000
50
500
0
9/2∼
9/9∼ 9/16∼ 9/23∼ 9/30∼ 10/7∼
40
10/14
10/21
10/28
∼
∼
∼
80
180
210
11/4∼
11/18
11/25
∼
∼
∼
240
200
230
12/2∼ 12/9∼
12/23
12/30
∼
∼
∼
235
22
0
0
40
実績(当週)
0
0
0
0
273
294
140
168
131
88
122
70
66
0
99
予定
0
0
0
0
40
80
160
340
550
790
1030
1230
1460
1690
1935
2170
2192
2192
2357
2442
2557
2675
2795
2915
3035
3155
3215
3275
3335
3395
実績
0
0
0
0
273
363
536
665
841
1061
1163
1309
1458
1587
1739
1853
1858
1858
2009
2094
2388
2528
2696
2827
2915
3037
3107
3173
3173
3272
220
102
146
149
129
152
114
5
0
151
85
85
115
118
120
120
120
120
3/3∼ 3/10∼ 3/17∼ 3/24∼ 3/31∼
0
176
165
2/3∼ 2/10∼ 2/17∼ 2/24∼
0
129
245
1/6∼ 1/13∼ 1/20∼ 1/27∼
0
173
230
12/16
0
90
240
11/11
予定(当週)
60
60
60
60
4/7∼ 4/14∼
5
10
5
3400
3410
3415
【品質からの分析】
ST故障発生状況(○○システム)
30
試験不良
バ
グ
検
出
密
度
20
件数
品質不良
品質不良
25
15
10
指標値範囲内
品質良
試験不足
5
0
9/16
9/23
9/30
10/7
12/2
12/9
∼
∼
∼
∼
∼
∼
∼
∼
∼
∼
∼
∼
∼
∼
∼
∼
0
2
0
1
0
1
0
0
0
0
0
0
0
0
1
0
2
0
2
0
1
0
0
0
0
0
1
0
0
0
0
0
0
1
2
2
4
4
5
5
6
6
6
6
6
6
6
6
6
7
7
2
2
4
4
5
5
5
5
5
5
6
6
6
6
6
6
6
9/2∼ 9/9∼
発生( 当週)
0
2
解決( 当週)
0
2
発生
0
解決
0
10/14 10/21 10/28
11/4
11/11 11/18 11/25
4-3 レガシー移行に伴うマネージメント
12/16 12/23 12/30
1/13
1/20
1/27
∼
∼
∼
0
0
1
0
1
0
1
0
9
9
9
10
7
8
8
9
1/6∼
2/10
2/17
2/24
∼
∼
∼
0
3
1
0
1
2
1
1
10
10
13
14
9
10
12
13
2/3∼
3/10
3/17
3/24
3/31
∼
∼
∼
∼
0
0
1
0
0
0
14
14
14
15
14
14
14
14
3/3∼
試験密度
20
自治体CIO育成研修
開発監理の実施例
† 品質管理実施例
¾ システム開発の各工程において、「不良の防止」、「不良の早期検出」、「品質評価」、「不良の再発防
止」を品質目標管理・レビュー実施管理・障害管理の手段を用いて実施する。
¾ これにより、プロジェクトの円滑な推進を図り、システムの品質を保証する。
品質管理実施計画の設定
●システムの品質管理目標とそれを達成するための活動項目、活動目標を設定する。
事前準備
●レビュー実施計画(体制、スケジュール、品質目標等)を設定する。
●障害管理計画(不良検出目標、障害管理体制、品質評価目標等)を設定する。
レビューに対する品質管理
システム設計
ソフトウェア
製作
システム試験
システム移行
●レビュー実施計画に従
い、各段階において、設
計者およびユーザを含め
たレビューを行う。
●レビュー状況から、システ
ム全体の品質や個々の
成果物の品質を評価す
る。
●必要に応じ、対象ドキュメ
ントの再レビューを行う。
●次工程へ移行するため
の、品質評価会議を実施
する。
4-3 レガシー移行に伴うマネージメント
試験に対する品質管理
●障害票の起票により発生した全障害を把握し、重
要度などから、処置の優先度、期限を決定する。
●障害票の起票から処置終了を一括して管理し、原
因・対策・他への影響を判断する。
●障害処置状況を把握し工程や体制面での問題が
あれば、人員補強などの対策を講じる。
●品質評価指標の実績値と予測値の比較により、
品質評価を行った上で、次工程へ移行するため
の、品質評価会議を実施する。
品質管理の総括
●システムの品質目標、品
質管理活動の目標に対
する達成状況を総合評価
する。
●本稼動を行うための、品
質評価会議を実施する。
21
自治体CIO育成研修
外部委託管理
† SLAによる管理
¾外部委託を行う場合には、SLA(Service Level Agreement)により、サービ
ス品質の保証項目や、それらを実現できなかった場合の利用料金の減額に
関する規定などを含めて契約を行うことが望ましい。
管理指標
目標値
社内レビュー回数
作業項目毎に1回以上
自治体参加レビュー回数(改造項目)
改造項目毎に1回以上
自治体参加レビュー回数(運用設計)
1回以上
自治体参加レビュー回数(データ移行)
工程完了報告回数
バグ予測件数に対する検出数
改造項目単位レビュー回数
テスト項目数
移行データ毎に1回以上
改造項目毎に1回以上
予定項目数以上
機能要求の変更回数
0回
データ移行計画に対する仕様漏れ件数
0件
データ移行計画の変更回数
0回
1回に複数改造項目レビュー可
予定項目数は自治体基準
1回以上
100%
期間±許容範囲
遅れが14日以内
進捗の予実
予定数=完了数
4-3 レガシー移行に伴うマネージメント
1回に複数移行項目レビュー可
予測件数 n±3√n以内
0件
開発基準の遵守率
1回に複数改造項目レビュー可
各工程1回以上
機能要求に対する仕様漏れ件数
運用説明回数
備考
22
自治体CIO育成研修
レガシー移行における留意事項
† 棚卸分析の実施
¾やみくもに移行を行わず、現行ソフトウェア資産から移行対象となるプログラ
ム・ソースなどを棚卸し分析する。
¾実際にパイロット変換を行うことで課題を抽出したり、運用面から見た調査を
実施することで、不要な資産を除いた移行対象資産を確定させる。
4-3 レガシー移行に伴うマネージメント
23
自治体CIO育成研修
4.レガシー移行における新システムの
移行の留意事項
4-3 レガシー移行に伴うマネージメント
24
自治体CIO育成研修
新システムへの移行
† システム移行に関する留意事項
¾移行は、情報システムやデータ移行を行うのみでなく、新規の情報システム
を使った業務そのものが移行されて、初めて完了と言える。
¾業務が連続して、安定運用されることが重要である。
¾移行後も、庁内の情報システム全体が安全に安定的に運用されるよう適切
にガバナンスすることがCIO及びCIOチームの重要な役割である。
【検討項目】
‹業務
:業務そのもの移行を行う。所管部署が変更された場合等には、
業務の引継ぎも必要となる。
‹データ
:新システムからのデータの移行を実施する。新旧システムで管
理する項目が異なる場合には、補完データの収集・入力や、デー
タの統合などが必要となる。
‹プログラム:旧プログラムの移行を実施する。システム移行の方法により、そ
のまま移行する場合や、新言語に置き換える場合などがある。
‹運用
:新システムによる業務の流れに従った業務処理の変更を行う。
運用マニュアルの整備や十分な教育期間が必要となる。
4-3 レガシー移行に伴うマネージメント
25
自治体CIO育成研修
システムの移行ための教育
† ユーザ部門の移行に関する留意事項
¾ 突然、新運用を開始することなく、新システムの操作方法や新システムにお
ける運用方法などに対する事前の十分な利用者教育が必要である。
† システム運用の移行に関する留意事項
¾メインフレームの場合には、情報部門が大型設備を集中的に管理するが、オ
ープンシステムの場合には、端末やサーバを部門で管理することも考えられ
る。サーバ設置部門で混乱を起こさない様、サーバ設置部門のサーバ管理
者への事前の教育を十分に行う必要がある。
4-3 レガシー移行に伴うマネージメント
26
自治体CIO育成研修
システム移行における検証
† システム検証に関する留意事項
¾システムの検証は、テストケースごとに、現行環境と移行後の環境で実施し、
その結果を照合することにより、移行が正確に行われたことを検証する。可
能であれば、現行環境で実施したテスト結果と移行後の環境で実施したテス
ト結果の照合用ツールを作成し活用することで、効率性・正確性の向上を目
指す。
† 運用試験に関する留意事項
¾運用試験は、システム要件どおりの機能が実装され、稼動に問題が無いこと
を原課担当者が確認する。更に、本番稼動への切替の合否判定のためには、
以下の観点でも検証する。
◆異常終了ケースの動作
◆セキュリティテスト
◆日次オペレーション
◆過負荷・高負荷導入切替テスト
◆操作性・応答性
◆リカバリテスト
◆休日オペレーション
◆性能テスト(日次処理のスループット、ターンアラウンドタイム)
◆サイクルテスト(日次、週次、月次、四半期、年次)
4-3 レガシー移行に伴うマネージメント
27
自治体CIO育成研修
Fly UP