Contents
1

東京海上日動の業務とシステム概要

2

トラブル削減取り組みの背景（自由化の波とトラブル増加）

３ 開発品質向上施策
４ 開発品質向上施策の効果

２００５年 １月 24日 （月）

５

最後に

６

資料

東京海上日動システムズ株式会社
取締役 品質管理部長
菊島 靖弘
1Contents

１．東京海上日動の業務とシステム概要◆会社の概要1東京海上日動の業務とシステム概要

2

開発品質向上取り組みの背景（自由化の波とトラブル増加）

○創業
○創業
○資本金
○資本金
○正味収入保険料○正味収入保険料
○総資産
○総資産
○従業員
○従業員
○本店所在地○本店所在地３ 開発品質向上施策

１８７９年（明治１２年）８月
１８７９年（明治１２年）８月
１，０１９億円
１，０１９億円
１兆９，０４２億円（２００３年度）
１兆９，０４２億円（２００３年度）
９兆０，７７１億円
９兆０，７７１億円
１７，４０２名
１７，４０２名
東京都千代田区丸の内
東京都千代田区丸の内

４ 開発品質向上施策の効果
５最後に◆東京海上日動のビジネス規模

６資料●お客様総数（法人、個人)●お客様総数（法人、個人)●年間取扱契約件数●年間取扱契約件数●年間保険金支払件数●年間保険金支払件数＜２００４年１０月１日現在＞＜２００４年１０月１日現在＞：約２５００万顧客：約２５００万顧客：約３３００万件：約３３００万件：約４００万件：約４００万件

2

3Contents

１．東京海上日動の業務とシステム概要◆ネットワークの概要

損害ｻｰﾋﾞｽ拠点数

73支店、57営業部
629営業室・課・支社
170ヵ所

代理店数

69，335店

代理店ｵﾝﾗｲﾝ

約12万台

国内拠点数

1

東京海上日動の業務とシステムの概要

２ 開発品質向上取り組みの背景（自由化の波とトラブル増加）
３ 開発品質向上施策
４ 開発品質向上施策の効果●銀行・郵貯のATM網を上回る世界最大級のネットワーク●銀行・郵貯のATM網を上回る世界最大級のネットワーク＜参考＞日本のＡＴＭ台数＜参考＞日本のＡＴＭ台数 銀行：約８万台、郵貯：約２．５万台
銀行：約８万台、郵貯：約２．５万台◆システムの概要

５

最後に

６

資料

●毎月のＪＣＬ変更・追加数は 月平均８０００ＪＣＬ／月●例年の新設修正プログラム本数は 約２万〜３万本／年
開発ステップは約２００万ステップ／年
45

２．開発品質向上取り組みの背景（自由化の波とﾄﾗﾌﾞﾙ増加）

２．開発品質向上取り組みの背景（自由化の波とﾄﾗﾌﾞﾙ増加）◆保険料率の自由化、規制緩和による競争がし烈化◆規模別・要因別トラブル分析◆規模別・要因別トラブル分析

2000年頃から2000年頃から◆競争優位を目的としたシステムの開発、改修作業が多量発生

小規模開発
小規模開発

大・中規模開発
大・中規模開発
本番移行
エラー
17%
その他エラー8%25
大ト ラブル

20

要件エラー
33%

要件エラー
5%
設計エラー
21%

中規模

15

設計エラー
42%

小規模

1050
2 0 0 0 年4月

5月

6月

上流工程の品質に起因す
上流工程の品質に起因する障害が多い
る障害が多い7月•システムの停止はビジネスの停止•システムリスクは経営リスク

その他エ
ラー
11%

本番移行
エラー
63%

本番移行で障害を起こす
本番移行で障害を起こすケースが多い
ケースが多い

２０００年度、詫び状を出状した障害案件４７件を分析
２０００年度、詫び状を出状した障害案件４７件を分析
6

7

Contents

３．開発品質向上施策（要因の傾向と対応策）◆要因の傾向と対応策◆要因の傾向と対応策

開発品質向上取り組みの背景（自由化の波とトラブル増加）

大開発規模

３ 開発品質向上施策
４ 開発品質向上施策の効果
５

最後に

６

資料

要件確定・設計に起因

（原因）

小
上流

③トラブル管理の仕組み

2②発見・基本動作の遵守

東京海上日動の業務とシステムの概要①要件定義と製造・工程管理

1

手続き・作業に起因（ヒューマンエラー）
（発見）
（対策）
開発工程

下流

8

３．開発品質向上施策◆開発品質向上施策◆開発品質向上施策①アプリオーナー・サプライヤー制度の設置①アプリオーナー・サプライヤー制度の設置①アプリオーナー・サプライヤー制度の設置①アプリオーナー・サプライヤー制度の設置要件定義と要件定義と製造･工程管理
製造･工程管理②要件確定プロセスの改善②要件確定プロセスの改善②要件確定プロセスの改善②要件確定プロセスの改善③③プロジェクトレビュー制度の設置（透明化の実現）
プロジェクトレビュー制度の設置（透明化の実現）③
プロジェクトレビュー制度の設置（透明化の実現）③プロジェクトレビュー制度の設置（透明化の実現）④④要件変更管理の改善
要件変更管理の改善④④要件変更管理の改善
要件変更管理の改善⑤テスト品質向上策⑤テスト品質向上策⑤テスト品質向上策⑤テスト品質向上策

発見・基本動作の遵守
発見・基本動作の遵守

発見・基本動作の遵守
発見・基本動作の遵守⑥手続き、確認の徹底⑥手続き、確認の徹底
トラブル管理の仕組み
トラブル管理の仕組み

9３．開発品質向上施策◆開発品質向上施策◆開発品質向上施策

要件定義と要件定義と製造･工程管理
製造･工程管理

サービスイン
サービスイン

⑦トラブル対応・防止の各種施策⑦トラブル対応・防止の各種施策⑥手続き、確認の徹底⑥手続き、確認の徹底
10トラブル管理の仕組み
トラブル管理の仕組み⑦トラブル対応・防止の各種施策⑦トラブル対応・防止の各種施策

11

３．開発品質向上施策

３．開発品質向上施策◆アプリオーナーとサプライヤーの役割分担◆アプリオーナーとサプライヤーの役割分担
アプリケーションオーナー（発注部門）
供給責任
こういう物（要件）を作って欲しい「僕つかう人、わたし作る人」の時代ではない！

要求通りになっているか
確認

負担量

オーナー
テスト

かつては「発注者」であり「使用者・評価者」

利用促進
マニュアル
教育

業務・商品設計者

今やマーケットが利用者であり、評価者。
両部門が新しいビジネスモデルの供給者として、共同し、業務・事務設計、システム設計・開発を行う体制に！

＜製造装置＞
こういう物（要件）でどうですか

開発部隊（内製･ｿﾌﾄｳｪｱﾊｳｽ）
ｿﾌﾄｳｪｱﾊｳｽ）

テスト
要求通りにできているか確認

サプライヤー（開発部門）
製造責任
要件確定

設計・製造設計

テスト

ＩＴ部門

稼働・供給

プロジェクトの進行12

３．開発品質向上施策

13

３．開発品質向上施策◆開発品質向上施策◆開発品質向上施策◆開発打診時の初動クオリティが大切◆開発打診時の初動クオリティが大切①アプリオーナー・サプライヤー制度の設置①アプリオーナー・サプライヤー制度の設置要件定義と要件定義と製造･工程管理
製造･工程管理

かつては「受注者」

システム開発案件発生時の基本構造

1.電話1本の打診で仕事が発生②要件確定プロセスの改善②要件確定プロセスの改善

2.回答で責任が発生③③プロジェクトレビュー制度の設置（透明化の実現）
プロジェクトレビュー制度の設置（透明化の実現）

3.抱え込みで問題が発生④④要件変更管理の改善
要件変更管理の改善
守らねばならない基本動作・可視化⑤テスト品質向上策⑤テスト品質向上策

1.事実を記録

発見・基本動作の遵守
発見・基本動作の遵守⑥手続き、確認の徹底⑥手続き、確認の徹底
トラブル管理の仕組み
トラブル管理の仕組み

2.アグリーメントマネジメントの強化⑦トラブル対応・防止の各種施策⑦トラブル対応・防止の各種施策

3.担当者扱いプランのマネジメント
14

３．開発品質向上施策

15

３．開発品質向上施策

ビジネスフィールド（１）

実現したいビジネス

システム化
要求

システム要件が発生する4分野

実現したい
ビジネス

既存ｼｽﾃﾑｺﾈｸﾃｨﾋﾞﾃｨ要件

システム要件

1.ビジネス構想の未熟さ対応を織り込む（把握不足、判断誤り、目論見違い、事情変更）

システム要件
非機能要求

2.実現したい世界の構想は往々にして、主観的、非定量的、一方的、個別・部分最適であり、結果として、みなし、決め付け、プロジェクト要件

思い込み、勘違い、漏れ、誤りを含むことを評価する
3.システム化要求の内容は未承認であることが多い、承認レベルをおさえて進める1617

３．開発品質向上施策

３．開発品質向上施策

ビジネスフィールド(2)ＮＦＲフィールド

システム
システム要件
要件

システム化
要求

１.システム化要求の承認レベルをおさえる

1.かってに、そうなるとおもいこんでいるところの吟味（機構、承認、体制、事務の仕組、使い勝手、背景不明作業 など）

2.システム化要求にかかる、全てのステークホルダーの

2. レスポンス、キャパシティ、セキュリティ、トレーサビリティ、モニタリング、メンテナンスビリティ

意見反映レベルをおさえる
3.発注者は利用者でなくなってきていることを考慮する

3. 有事対応スキーム、リカバリー、コンテンジェンシープラン（マーケットの声が聞こえていない）

4.環境（何台までしかつながらない、どこでしか出来ない）、人（誰しか出来ない、同時に出来ない等）、物、金（後年度負担）、24時間３６５日等

4.特に、担当者が勝手にこうなると思い込んでいると判断される要求は吟味・管理する
5.最悪は同じという要求（同じにするのは大変だ）

システム要件

非機能要求

18

３．開発品質向上施策

5.特許対応、法律･認可対応

19

３．開発品質向上施策
ﾚｶﾞｼｰﾌｨｰﾙﾄﾞ

ｺﾈｸﾃｨﾋﾞﾃｨ
要件

ﾌﾟﾛｼﾞｪｸﾄﾌｨｰﾙﾄﾞ
システム要件

プロジェクト要件

システム要件

1. 受発注者、ﾏｰｹｯﾄ、客先要望事情等、ｽﾃｰｸﾎﾙﾀﾞｰの個別事情

1.現行システムとその利用、運用

2.同時期イベント
立法、通達、認可、契約完了、契約条件変更等
3.社内インフラ改定、関連システム改定、制度改定、機構改革等（前提、内容、事情、制約、研修、運用、特殊運用、担当、契約、過去のイベント対応等）
2.アウトプット活用内容 (追加加工、データ2次活用）
3. アウトプットステークホルダー対応

4. ＯＳバージョンアップ、保守切れ等必須対応要素（代理店、客先（個人、企業）、社員、利用管理者、監督官庁、ｺｰﾙｾﾝﾀｰ）

5. 社外利用インフラ改定（郵便番号等）、料金改定等外部環境条件

4. 関連システム（含む社外、インターフェイス、内容、事情、制約、運用等）

6.開発力確保、パートナー・アウトソーサー・客先の開発力

5. インフラ（ｷｬﾊﾟｼﾃｨ、ＯＳﾊﾞｰｼﾞｮﾝ、ﾈｯﾄﾜｰｸ、認証契約、ｱｳﾄｿｰｽ関連等）

7.開発中・展開時有事対応（地震等天災、展開季節、利用ﾊﾟｯｹｰｼﾞ
会社買収）

20

３．開発品質向上施策

21

３．開発品質向上施策◆（透明化を実現するﾌﾟﾛｼﾞｪｸﾄ管理）◆レビュー制度（透明化を実現するﾌﾟﾛｼﾞｪｸﾄ管理）
レビュー制度（透明化を実現するﾌﾟﾛｼﾞｪｸﾄ管理）◆開発品質向上施策◆開発品質向上施策①アプリオーナー・サプライヤー制度の設置①アプリオーナー・サプライヤー制度の設置

サービスイン

運用受け入れレビュー

テスト計画レビュー⑤テスト品質向上策⑤テスト品質向上策
発見・基本動作の遵守
発見・基本動作の遵守

要件確定レビュー④④要件変更管理の改善
要件変更管理の改善

開発着手③
プロジェクトレビュー制度の設置（透明化の実現）③プロジェクトレビュー制度の設置（透明化の実現）

サーービ
ビス
スイイン
ン承承認
認レレビ
ビュ
ュ
ーサー

②要件確定プロセスの改善②要件確定プロセスの改善

プロジェクト計画レビュー

要件定義と要件定義と製造･工程管理
製造･工程管理①開発過程でカットオーバーまでに５回のレビューを義務付け①開発過程でカットオーバーまでに５回のレビューを義務付け②アプリオーナーと共同で主催、部長レベルでの承認取り付け②アプリオーナーと共同で主催、部長レベルでの承認取り付け③品質管理部門によるチェック③品質管理部門によるチェック⑥手続き、確認の徹底⑥手続き、確認の徹底
トラブル管理の仕組み
トラブル管理の仕組み⑦トラブル対応・防止の各種施策⑦トラブル対応・防止の各種施策

22

23

３．開発品質向上施策

３．開発品質向上施策◆開発品質向上施策◆開発品質向上施策①アプリオーナー・サプライヤー制度の設置①アプリオーナー・サプライヤー制度の設置要件定義と要件定義と製造･工程管理
製造･工程管理②要件確定プロセスの改善②要件確定プロセスの改善③③プロジェクトレビュー制度の設置（透明化の実現）
プロジェクトレビュー制度の設置（透明化の実現）④
要件変更管理の改善④要件変更管理の改善⑤テスト品質向上策⑤テスト品質向上策【参考】2003年度レビュー開催回数内訳
PRJ計画 SA／ＵＩ
A+以上
37
60
A以下
546
119
計
583
179

テスト58
123
181

ｻｰﾋﾞｽｲﾝ97642
739

発見・基本動作の遵守
発見・基本動作の遵守

計
252
1430
1682

⑥手続き、確認の徹底⑥手続き、確認の徹底
24

３．開発品質向上施策

トラブル管理の仕組み
トラブル管理の仕組み⑦トラブル対応・防止の各種施策⑦トラブル対応・防止の各種施策

25

３．開発品質向上施策◆開発品質向上施策◆開発品質向上施策

◆変更管理
◆変更管理
→５つのポイント→５つのポイント①アプリオーナー・サプライヤー制度の設置①アプリオーナー・サプライヤー制度の設置

③

①担当者

要件定義と要件定義と製造･工程管理
製造･工程管理

②責任者②要件確定プロセスの改善②要件確定プロセスの改善③③プロジェクトレビュー制度の設置（透明化の実現）
プロジェクトレビュー制度の設置（透明化の実現）

⑤

③期限
④代替案

② ①

④
④要件変更管理の改善
要件変更管理の改善⑤テスト品質向上策⑤テスト品質向上策④
発見・基本動作の遵守
発見・基本動作の遵守⑤エスカレーションプラン

⑥手続き、確認の徹底⑥手続き、確認の徹底② ①26

３．開発品質向上施策

トラブル管理の仕組み
トラブル管理の仕組み⑦トラブル対応・防止の各種施策⑦トラブル対応・防止の各種施策

27

３．開発品質向上施策◆開発品質向上施策◆開発品質向上施策◆品質評価シート◆品質評価シート①アプリオーナー・サプライヤー制度の設置①アプリオーナー・サプライヤー制度の設置＜品質評価指標＞＜品質評価指標＞①テスト密度①テスト密度②テストケース消化②テストケース消化
③障害密度
③障害密度
④障害率
④障害率
⑤収束率
⑤収束率
⑥仕様変更収束率⑥仕様変更収束率⑦未解決バグ件数⑦未解決バグ件数⑧ペンディング件数⑧ペンディング件数（⑨総合評価）（⑨総合評価）要件定義と要件定義と製造･工程管理
製造･工程管理②要件確定プロセスの改善②要件確定プロセスの改善③③プロジェクトレビュー制度の設置（透明化の実現）
プロジェクトレビュー制度の設置（透明化の実現）④④要件変更管理の改善
要件変更管理の改善⑤テスト品質向上策⑤テスト品質向上策

発見・基本動作の遵守
発見・基本動作の遵守⑥手続き、確認の徹底⑥手続き、確認の徹底

サービスイン品質を総合的に評価
28

トラブル管理の仕組み
トラブル管理の仕組み⑦トラブル対応・防止の各種施策⑦トラブル対応・防止の各種施策

29

３．開発品質向上施策

３．開発品質向上施策◆品質保証確認シート◆品質保証確認シート◆ヒューマンエラー対策◆ヒューマンエラー対策

チェックポイント
年間２万本の年間２万本のプログラム本番移行
プログラム本番移行①プログラム本番移行管理者①プログラム本番移行管理者の任命の任命

月間８千個の月間８千個のＪＣＬ修正とＪＣＬ修正と画面・ＴＢＬ変更作業
画面・ＴＢＬ変更作業②業務内容のチェック②業務内容のチェック•テストの徹底•テストの徹底•品質保証確認シート•品質保証確認シート•本番結果確認を徹底•本番結果確認を徹底•作業の背景・目的・理由・概要•作業前の品質保証手段・保証内容•作業後の確認手段･確認内容・確認結果•トラブル時の対応方法•なぜ保証できると言えるのかを具体的に記述•なぜこれで確認できるのかの理由を記述
30

３．開発品質向上施策

31

３．開発品質向上施策◆開発品質向上施策◆開発品質向上施策①アプリオーナー・サプライヤー制度の設置①アプリオーナー・サプライヤー制度の設置要件定義と要件定義と製造･工程管理
製造･工程管理⑦トラブル対応・防止の各種施策⑦トラブル対応・防止の各種施策②要件確定プロセスの改善②要件確定プロセスの改善①トラブル発生時対策①トラブル発生時対策③③プロジェクトレビュー制度の設置（透明化の実現）
プロジェクトレビュー制度の設置（透明化の実現）④④要件変更管理の改善
要件変更管理の改善②トラブル予防施策⑤テスト品質向上策⑤テスト品質向上策
発見・基本動作の遵守
発見・基本動作の遵守⑥手続き、確認の徹底⑥手続き、確認の徹底⑦トラブル対応・防止の各種施策⑦トラブル対応・防止の各種施策

トラブル管理の仕組み
トラブル管理の仕組み

32

３．開発品質向上施策

33

３．開発品質向上施策◆ＦＦＡ（＝FireFire Fighting）とは...
...
◆ＦＦＡ（＝Action◆ＦＦＡ（＝FireFightingAction）とはAction）とは...

◆お客様迷惑度指数◆お客様迷惑度指数
トラブルを数値化して客観評価
トラブルを数値化して客観評価

運用部門が窓口になっての秒刻みのトラブル対応！

館内放送による緊急召集
館内放送による緊急召集

迷惑度指数＝緊急対策会議緊急対策会議係数のかけ算で数値化

緊急復旧作業緊急復旧作業（消火活動）（消火活動）

業務の重要度

×

時間的要素

×

影響範囲

×

地域の広がり×

発生日のピーク性 ×

再発、反復性

軽微・小規模・中規模・大規模に分類

経営レベルまでの共有認識に！

初期消火より第一報！
初期消火より第一報！
34

35

３．開発品質向上施策

３．開発品質向上施策◆トラブル対策会議（１）◆トラブル対策会議（１）⑦トラブル対応・防止の各種施策⑦トラブル対応・防止の各種施策①トラブル発生時対策

全管理者が出席＜会議内容＞•トラブル発生状況の報告•トラブル事例の紹介•再発防止策（ワクチン）②トラブル予防施策②トラブル予防施策

36

３．開発品質向上施策

37

３．開発品質向上施策◆トラブル対策会議開催数◆トラブル対策会議開催数◆トラブル対策会議（２）◆トラブル対策会議（２）

30

29
25
20
15

16

10

トラブルをおこすのは担当者、トラブルをなくすのは管理者

10◇2001/5 品質管理部設立

59◇2004年度
9月末
2004年度902001

2002

2003

会議
開催
数

2004

38

39

Contents

３．開発品質向上施策◆トラブルの再発防止策（ワクチン）◆トラブルの再発防止策（ワクチン）1

東京海上日動の業務とシステムの概要

2

開発品質向上取り組みの背景（自由化の波とトラブル増加）

３ 開発品質向上施策
４ 開発品質向上施策の効果
５ 最後に
６

40

資料

41

４．トラブル削減の軌跡

４．トラブル削減の軌跡◆システム修正変更量◆システム修正変更量
30000

250 ◆トラブル発生件数◆トラブル発生件数

27964

200

193

25000
20000

150

19025

15000

13231

13775

100

本番移行本数

10000

50

5000
043

43
14
２０００年度

2002

2003

合計

1

東京海上日動の業務とシステムの概要

2

開発品質向上施策取り組みの背景（自由化の波とトラブル増加）

250

２００３年度

59

24

23

43

５．最後に
システム開発は全てが人間ワザシステム開発は全てが人間ワザ（方法論としての性悪説）（方法論としての性悪説）
レビューも基本動作も手段、不断の見直しが必要
レビューも基本動作も手段、不断の見直しが必要
誤りをおかすのは担当者、誤りをおかすのは担当者、誤りをなくすのは管理者
誤りをなくすのは管理者

４ トラブル削減の軌跡

資料

２００２年度トラブルが１／１０に激減（２０００年度対比）
トラブルが１／１０に激減（２０００年度対比）

３ 開発品質向上施策

６2001年度

42Contents

最後に

12
7
4

2004･10末●毎月のＪＣＬ変更・追加数は月平均８０００ＪＣＬ／月●毎月のＪＣＬ変更・追加数は月平均８０００ＪＣＬ／月●例年の修正プログラム本数は約２万〜３万本／年●例年の修正プログラム本数は約２万〜３万本／年
修正ステップは約２００万ステップ／年
修正ステップは約２００万ステップ／年

５175
2

12
402001

大トラブル
中規模
小規模

１／１０１／１０

警備八割、捜査二割（近代警察）
警備八割、捜査二割（近代警察）
発注者と受注者の役割と責任の適正化が鍵発注者と受注者の役割と責任の適正化が鍵
継続は力なり継続は力なり44

45

Contents
1

東京海上日動の業務とシステムの概要

2

開発品質向上施策取り組みの背景（自由化の波とトラブル増加）

３ 開発品質向上施策

ありがとうございました

４ トラブル削減の軌跡

46

５

最後に

６

資料47

【資料①】【資料②】◆レビューの目的とポイント◆レビューの目的とポイント・透明化とリスク評価（→エスカレーションマネジメント）、責任と担当の明確化・透明化とリスク評価（→エスカレーションマネジメント）、責任と担当の明確化◆レビュー事例①◆レビュー事例①

ﾌﾟﾛｼﾞｪｸﾄ
ﾌﾟﾛｼﾞｪｸﾄ
計画ﾚﾋﾞｭｰ
計画ﾚﾋﾞｭｰ

要件確定
要件確定
ﾚﾋﾞｭｰ
ﾚﾋﾞｭｰ

ﾃｽﾄ計画
ﾃｽﾄ計画
ﾚﾋﾞｭｰ
ﾚﾋﾞｭｰ

運用受け入れ運用受け入れﾚﾋﾞｭｰ
ﾚﾋﾞｭｰ

ｻｰﾋﾞｽｲﾝｻｰﾋﾞｽｲﾝ
承認ﾚﾋﾞｭｰ
承認ﾚﾋﾞｭｰ

体制、役割分担、ﾘｽ体制、役割分担、ﾘｽｸを確認する。
ｸを確認する。
ｽｹｼﾞｭｰﾙ、品質、ｺｽﾄ
ｽｹｼﾞｭｰﾙ、品質、ｺｽﾄの点から問題がないの点から問題がないかを検証し、ﾌﾟﾛｼﾞｪかを検証し、ﾌﾟﾛｼﾞｪ
ｸﾄの開始可否を判断
ｸﾄの開始可否を判断する。（使い物になする。（使い物になるかﾁｪｯｸ）
るかﾁｪｯｸ）

要件の妥当性、必要要件の妥当性、必要性を検証するととも性を検証するとともに要件が正確にｼｽﾃﾑに要件が正確にｼｽﾃﾑ仕様に展開されてい仕様に展開されている事を確認する。ｽｹる事を確認する。ｽｹｼﾞｭｰﾙ等計画内容をｼﾞｭｰﾙ等計画内容を再確認する。（なぜ、再確認する。（なぜ、こういう要件になっこういう要件になったか。ｼｽﾃﾑ仕様の合たか。ｼｽﾃﾑ仕様の合理性の説明）
理性の説明）

ﾃｽﾄ計画における体ﾃｽﾄ計画における体制、ｽｹｼﾞｭｰﾙ、ﾃｽﾄ方制、ｽｹｼﾞｭｰﾙ、ﾃｽﾄ方法などの妥当性（要法などの妥当性（要件確認が十分かつ効件確認が十分かつ効率的にできるか）を率的にできるか）を検証する。（実施ﾃｽ検証する。（実施ﾃｽﾄの確定、検証ﾌﾟﾗﾝ、ﾄの確定、検証ﾌﾟﾗﾝ、変更管理の徹底）
変更管理の徹底）

稼働品質、障害回復、稼働品質、障害回復、運用効率面等による運用効率面等による受入条件を運用部門
受入条件を運用部門と確認する。と確認する。

ﾃｽﾄ結果、積み残し
ﾃｽﾄ結果、積み残し案件や運用面の準備案件や運用面の準備状況を確認し、サー状況を確認し、サービスインの可否を判
ビスインの可否を判断する。（ｼｽﾃﾑの完断する。（ｼｽﾃﾑの完成度だけでなくﾋﾞｼﾞ成度だけでなくﾋﾞｼﾞﾈｽをｽﾀｰﾄさせる点かﾈｽをｽﾀｰﾄさせる点から過不足を検証すら過不足を検証する）
る）①要件の実現性①要件の実現性②スケジュール、②スケジュール、③要員計画
③要員計画
④リスク
④リスク
⑤他システムとの関⑤他システムとの関連連⑥開発費・工数⑥開発費・工数⑦アウトソース等、⑦アウトソース等、外部委託先の妥当性
外部委託先の妥当性⑧ステークスホル⑧ステークスホル
ダーのポジションとダーのポジションとミッション
ミッション①ペンディング管理①ペンディング管理（前回ﾚﾋﾞｭｰの指摘（前回ﾚﾋﾞｭｰの指摘事項等）事項等）②セキュリティ②セキュリティ③ユーザビリティ③ユーザビリティ④信頼性、保守性④信頼性、保守性（ゼロメンテ）（ゼロメンテ）⑤リスク⑤リスク⑥外部委託先との役⑥外部委託先との役割分担（事務・運用割分担（事務・運用要件）要件）⑦ｺﾝﾃｨﾝｼﾞｪﾝｼｰの明⑦ｺﾝﾃｨﾝｼﾞｪﾝｼｰの明
確化
確化⑧後年度負担の明確⑧後年度負担の明確化
化①ペンディング管理①ペンディング管理（前回ﾚﾋﾞｭｰの指摘（前回ﾚﾋﾞｭｰの指摘事項等）事項等）②テストケースの妥②テストケースの妥
当性（１００％カ当性（１００％カバー）バー）④テストスケジュー④テストスケジュー
ルル⑤テスト体制・要⑤テスト体制・要員・環境員・環境⑥テスト管理⑥テスト管理①ペンディング管理①ペンディング管理（前回ﾚﾋﾞｭｰの指摘（前回ﾚﾋﾞｭｰの指摘事項等）事項等）
②稼働品質
②稼働品質
③障害回復性③障害回復性④運用効率④運用効率①ペンディング管理①ペンディング管理（前回ﾚﾋﾞｭｰの指摘（前回ﾚﾋﾞｭｰの指摘事項等）事項等）②稼働品質（品質評②稼働品質（品質評価シート）価シート）
③本番確認
③本番確認
④運用面確認④運用面確認⑤トラブル対応方法⑤トラブル対応方法⑥関係者手配、関係⑥関係者手配、関係ｼｽﾃﾑの完成度の確認ｼｽﾃﾑの完成度の確認⑦先送り案件の管理⑦先送り案件の管理

アプリケーションオーナーとサプライヤーのアプリケーションオーナーとサプライヤーの要員計画、作業分担の明確化
要員計画、作業分担の明確化

4849【資料④】レビューにより実現する品質管理【資料③】◆レビュー事例②◆レビュー事例②

アプリケーションオーナーとサプライヤーのアプリケーションオーナーとサプライヤーの検証作業分担、スケジュールの明確化
検証作業分担、スケジュールの明確化

１．透明化・可視化
２．情報マネジメント
３．スキルサプライ
７．プロダクト品質管理
４．リスク管理
６．プロセス品質管理
５．コスト管理50【資料④】レビューにより実現する品質管理【資料④】レビューにより実現する品質管理

１．透明化・可視化
１．透明化・可視化

２．情報マネジメント
２．情報マネジメント

管理の実現（レビューはＰＭの武器）コーチ（2塁ランナーにライトからの返球は見えない）

担当者抱え込みリスクの排除(担当者は本能的にプロダクトに顔を向け、プロジェクトに背を向ける）
あいまい事項管理（担当者は手の動かせるものを優先させる）

51

爆走防止・視野の確保
ステークホルダーによる情報共有化＆ステークホルダータスクの明確化

52

プロジェクト外イベント53

【資料④】レビューにより実現する品質管理【資料④】レビューにより実現する品質管理

４．リスク管理
４．リスク管理

３．スキルサプライ
３．スキルサプライ

評価とエスカレーション（トリガー・プラン・アクション）

要求レベル充足（組織レベルのアウトプット品質保証、担当者スキルディペンドからの開放）

何とかしてしまう病予防
プロダクト以外アクティビティ
前向き朝令暮改

識者の活用説明による自浄作用

遅延リスク（特にサービスイン）
コンテンジェンシープラン
54

55【資料④】レビューにより実現する品質管理【資料④】レビューにより実現する品質管理

５．コスト管理
５．コスト管理

６．プロセス品質管理
６．プロセス品質管理

見積もり評価（特に、プログラム開発以外費用、見積もり前提評価）

ポテンヒット防止（自分のことと思っていない）

アイドリング防止

臨機応変な体制構築サポート（自分からは言いにくい）理由と企みの根拠検証（なぜ、どうして、どうするつもり？）

コスト負担者明確化

クロスファンクショナル・チェック

後年度負担明確化
56【資料④】レビューにより実現する品質管理

オフィシャルな場での確約効果

57【資料⑤】

７．プロダクト品質管理
７．プロダクト品質管理◆信頼度成長曲線◆信頼度成長曲線

目標リマインド （担当者はプロジェクトが進めば進むほどプログラムプロダクトに執着し、ビジネスゴールを見失いがちになる）

バグ収束の判定
バグ収束の判定

テスト進捗の管理
テスト進捗の管理

最適ソリューションの実現（家庭にヒノキ風呂はフツウ要らない、システムも「早い・安い・うまい」の時代）

製造装置（プログラム）の品質を超えて、製造物の品質
58

テスト管理とバグ収束状況の確認59

【資料⑦】【資料⑥】

サービスイン
サービスイン【資料⑧】トラブル削減への拾七ヶ条

トラ
ラブ
ブル
ル削
削減
減へへのの拾
拾七
七ヶヶ条
条
ト
壱︑︑ 書
書い
いててあある
る要要件
件ははややららね
ねばばな
なららなないい︒
︒
壱
書い
いててなないい要
要件
件ははややっっててははいいけけなないい︒
︒
書
弐︑ ﹃〜と同じ﹄という要件はない︒
弐︑﹃〜と同じ﹄という要件はない︒﹃とと同同じじににすするる﹄
﹄た
ため
めのの要
要件
件定
定義
義ををすするる︒
︒﹃
参︑︑ 口口頭
頭ででのの要要件件︑︑修修正正変変更
更ののややりりととりりはは行
行わ
わなないい︒
︒
参四︑︑ 積
積み
み残残しし︑︑先先送送りり案
案件
件をを明明確確化化すする
る︒
︒
四
伍︑︑ エ
エス
スカ
カレ
レーーシ
ショ
ョン
ンマ
マネ
ネジ
ジメ
メン
ント
トをを行行うう︒
︒
伍六︑ コンティンジェンシープランを作成する︒
六︑
コン
テ
ィ
ン
ジェ
ン
シープ
ランを作成する︒
七︑︑ 有有識
識者
者ななき
きレ
レビ
ビュ
ュー
ーはは開開かかなないい︒
︒
七八︑︑ 期
期限
限がが迫迫っってていいる
るかかららとと言言っってて︑︑テテス
スト
ト︑︑八
レビ
ビュ
ュー
ーをを省
省略
略ししなないい︒
︒
レ
九︑ ソフトウェアハウスや開発メンバーのの九
︑
ソ
フ
ト
ウ
ェ
ア
ハウ
ス
や開発
メン
バー
成果
果はは現現物物でで確確認認すする
る︒
︒
成
拾︑︑ 修
修正
正時
時のの影
影響
響分
分析
析はは有
有識
識者
者のの経経験
験やや
拾ツーール
ルをを駆駆使使ししてて入入念念にに行行う
う︒
︒
ツ拾壱
壱︑︑ＪＪＣ
ＣＬＬ修修正正ののみ
みででもも︑︑修
修正
正規
規模
模がが小小規
規模
模ででもも
拾
テス
スト
ト︑︑レ
レビ
ビュ
ュー
ーをを必
必ずず実実施施すする
る︒
︒
テ拾弐
弐︑︑必
必ずず原
原本本にに戻戻っっててテテス
スト
ト・・検検証
証をを行行うう︒
︒
拾拾参︑リグレッションテストは必ず実施する︒
拾参︑
リ
グ
レッ
シ
ョン
テス
ト
は必ず
実施する︒
拾四
四︑︑プ
プロ
ログ
グラ
ラム
ムのの修
修正
正がが無無いい場
場合
合ででももデデー
ータ
タのの
拾
流れ
れる
るシ
シス
ステ
テム
ムははテ
テス
スト
ト・・確
確認
認をを実実施施すする
る︒
︒
流
拾伍
伍︑︑プ
プロ
ログ
グララム
ム類
類のの本
本番
番移移行
行管管理
理はは確確実
実にに行行うう︒
︒
拾拾六︑サービスイン︵カットオーバー︶時には
拾六︑サー
ビス
イン
︵カットオーバー︶
時には必ずず本
本番
番チチェ
ェッック
クをを実実施施すする
る︒
︒
必
拾七
七︑︑そ
それれででもも起起こ
こっっててししままっった
たららす
すみ
みややか
かにに報報告
告をを︒
︒
拾62

61
60

稼働監視
稼働監視部門部門

お客様迷惑度指数
お客様迷惑度指数

変更管理･ｴｽｶﾚｰｼｮﾝ管理
変更管理･ｴｽｶﾚｰｼｮﾝ管理

トラブル対策会議
トラブル対策会議

品質評価シート
問題点記述シート
問題点記述シート
要件追加・変更要望シート
要件追加・変更要望シート

トラブル管理ＤＢ
トラブル管理ＤＢ
リスク評価
リスク評価シート
シート

ＦＦＡ
ＦＦＡ

レビュー制度サービス
サービスインＲ
インＲ

要件Ｒ要件Ｒ

品質保証
信頼度成長
信頼度成長 品質保証
確認シート
確認シート
曲線
曲線

東京海上日動システムズ
品質管理部門アプリオーナー制度◇本番トラブルの発生に対しては、東京海上日動かつミレアＨＤ・経営会議、ＦＳＡまで迅速かつ適切な報告・連絡を行い最適な障害管理・連絡体制を構築。

テストＲ
運用受入Ｒ
テストＲ 運用受入Ｒ
計画Ｒ
計画Ｒ【コントロールタワー機能】•情報集約窓口による一元管理•携帯メールによる一報連絡•ＦＦＡ•ユーザー部門へのオンライン一斉連絡の判断•経過管理

ミレアＨＤ・東京海上日動

本番運用
開発工程
運用部門
運用部門
開発部門
開発部門

◆システムズの各種取り組み（まとめ）◆システムズの各種取り組み（まとめ）◆障害管理体制◆障害管理体制