工程完了判定業務におけるQCサークル活動の実施
オリックス生命保険株式会社
IT品質保証部
中島 輝
akira.nakajima.dd@ins.orix.jp
発表者の発言内容は、個人の見解に基づくものであり、所属する組織の公式見解ではありません。
ソフトウェア品質シンポジウム2023

はじめに➢ 当社では2020年の工程完了判定導入時から、毎年継続的に改善をしている➢ 継続的改善を通して、「上流工程での品質の作り込み」の改善が着実に進んできたことから、本日はこの取り組み内容、およびその効果を紹介する

2

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

１．自己紹介2017年1月にオリックス生命保険株式会社入社
現在IT品質保証部で、品質保証マネジャーとして以下を推進中①開発・保守の品質保証全般②開発とテスティングの分離およびテスト自動化の推進支援③開発・保守に係る標準化④開発案件の品質管理支援
経歴
1999年株式会社東証コンピュータシステムに入社
証券システム部に所属し、証券バックシステム（COSMOシステム）の開発・保守に従事
2007年日本ユニシス（現BIPROGY）株式会社に入社
金融システム部に所属し、証券系大規模プロジェクトのプロジェクトマネジメントに従事

3

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

２．背景
当社では2020年1月から業務アプリケーションのシステム開発・保守を対象に工程完了判定業務を導入
2021年から基盤・ミドルウェア（クラウド含む）の構築・改修案件も工程完了判定の適用対象となるよう改善
また会社の成長に伴い、開発案件が年々増加の一途を辿っている
一方で工程完了判定導入時からレビューアである品質保証マネジャーは2名体制のままである
限られたリソースのなかで品質を向上させるために、より効率的・効果的な工程完了判定業務に継続的に改善する必要があった
工程完了判定審議件数

工程完了判定業務開始
4

ソフトウェア品質シンポジウム2023

基盤・ミドルウェア案件に適用拡大

継続的改善を実施
オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

３．取り組みの前提➢ 当社の開発プロセスは一貫して「上流工程での品質の作り込み」を重視
上流工程の品質の作り込み：欠陥の埋め込みの予防および欠陥の早期検出

5

テスト担当者による上流ドキュメントの第三者検証

システムテスト、結合テストのテスト計画、分析・設計を上流工程から開始

後続工程のタスクを一部前倒し

開発とテスティングの分離開発とテストの並行実施（W字モデル）

上流工程の前倒し実施(V3モデル)2020年6月開始

2021年10月開始

2021年12月開始

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

４．取り組みの大方針➢ 「上流工程での品質の作り込み」に寄与するものをQCサークル活動のターゲットとする➢ 取り組みの効果は、本番障害の要件定義工程の欠陥埋め込み比率でモニタリングする
立
案

調査・企画

方針稟議

工程完了
判定開始

案
件
情報の提出(業務要件＋システム要件)

計画稟議

リス
ク
レ
ベルの判
定

プロジェクト実行

実行計画
内部設計

外部設計

製造
単体テスト

システムテスト

結合テスト

受け入れテスト実行稟議

工
程完了
判
定

①リスクレベル判定の改善

移行・展開
リリース
判定

工程完了
判
定

工程完了
判
定

工
程完了
判
定

工程完了
判
定

総括
総括

モニタリングモニタリング

工程完了
判定終了

②要件定義
（派生開発）の改善

本日は上記2つの取り組み内容、およびその効果を紹介
6

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

５．リスクレベル判定の改善
課題認識➢ リスクレベル判定の基準が曖昧、かつ工程による重みづけがないため、メリハリをつけたレビューができていない
開発規模
300万超

案件内容ヒアリング

リスクレベル高※

リスクレベル中※
システム投資案件
リスクレベル低※

開発規模
300万以下リスクレベル低※開発規模300万超の案件での課題
定量的な基準でのリスクレベルの判定ができていない
品質保証マネジャーは案件内容のヒアリング結果を踏まえて以下定義を考慮したうえで主観でリスクレベルを判定
工程完了判定要領での定義
リスクレベルは、リスクの発生確率と影響度で判定する。
（１）リスクの発生確率：開発難易度を示す対応工数や他システム連携数など（２）影響度：対象業務、影響範囲など

開発規模300万以下の案件での課題
メリハリをつけたレビューができていない
一律要件定義、外部設計、結合テスト、システムテストの証跡提示、工程完了判定の実施、勧告事項の取り込みを求めているため現場側の負荷が高い

リスクレベル高※：対面で工程完了判定を実施
リスクレベル中※：書面で工程完了判定を実施（計画書もレビュー対象）
リスクレベル低※：書面で工程完了判定を実施（計画書はレビュー対象外）

7

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

５．リスクレベル判定の改善
改善内容：開発規模300万超の案件に対する改善➢ リスクの発現可能性とリスクの影響度の積から算出したリスク値をもとに、リスクレベルの判定を実施➢ リスクの発現可能性は、算出項目の最大値をリスク値算出に使用
1（Low）

2（Medium）

3（High）

300万円超1000万以下

1000万円超1億円以下

1億円超

1億円超の案件の経験あり 且つ成功実績あり1000万円超の経験あり

1000万円超の経験なし

本番障害検出率※​※本番障害件数／移行案件数

社外秘

社外秘

社外秘

リスクパラメータ

1（Low）

2（Medium）

3（High）

経済的な損失は発生しないが、顧客等への謝罪などが必要

経済的損害リスクが生じる可能性あり経営に影響するような事態に発展する可能性あり

リスクパラメータ

リスクの発現可能性

リスクの影響度
リスク値
8

開発規模
開発リード経験

経営に与える影響度

リスク値

1

2

3

4

5

6

7

8

9

リスクレベル

低

低

中

中-

中--

高

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

５．リスクレベル判定の改善
改善内容：開発規模300万以下の案件に対する改善➢ 前年度の本番障害発生状況を踏まえて、品質の良いシステムはテスト工程の工程完了判定を免除➢ 改善後も本番障害検出率は安定して推移していることから、今期はさらに上流工程重視の工程完了判定にシフト
改善前
対象工程は以下のとおり
要件定義
外部設計
結合テスト
システムテスト

改善後
対象工程は以下のとおり
前年度の300万以下の案件で埋め込んだ本番障害が1件でも発生した場合
要件定義
外部設計
結合テスト
システムテスト

今期（2024年3月期）
対象工程は以下のとおり
要件定義
外部設計

上記以外
要件定義
外部設計

余った時間を外部設計書のレビューにシフトレフト
9

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

６．要件定義（派生開発）の改善
課題認識➢ 要件定義工程の工程完了判定のレビュー指摘率が他工程より高く、かつ2020年度から改善していない開発ガイドラインで定義した要件定義書

新規開発は標準化が進んだ
10

ソフトウェア品質シンポジウム2023

現状•

新規開発時には、プロジェクト特性に応じてテーラリングしたうえで、必要な成果物を作成することになっている•

第三者である品質保証マネジャーが、上記テーラリング結果の妥当性を全案件確認している•

派生開発は基本300万未満の案件が多く、左記成果物を作成することは開発規模からみて重厚長大である•

派生開発用の要件定義書テンプレートは存在しないため、要件定義書の記載内容・記載粒度は、各システムによってバラバラである

派生開発は標準化が進んでいない
オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

６．要件定義（派生開発）の改善
改善の目的➢ XDDP（派生開発に特化した開発方法論）の取り込みによる品質の作りこみを強化する
要件定義工程における欠陥の埋め込みの予防および欠陥の早期検出

XDDPの取り込み標準化することによる効率的・効果的な継続的改善の実施

XDDP

USDM

変更要件と変更仕様を階層構造で記載
変更仕様を変更前・変更後で記載
11

思い込みや勘違いの問題の防止

ソフトウェア品質シンポジウム2023

変更要求
仕様書

PFD

トレーサビリティ
マトリクス

変更設計書

変更仕様に対して、変更をどのモジュールで行うかを記載
オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

６．要件定義（派生開発）の改善
改善の進め方➢ ストーリーボードを活用して、改善活動スタート前にステークホルダーに改善の目的・背景などを丁寧に説明
背景
(why)

現在IT本部の開発プロセスには以下の課題がある。
①派生開発用の開発プロセスは、新規開発用の開発プロセスとの違いについての明確な定義がない。（特に要件定義）②投資金額が300万以下の案件の対応概要書は各システムによってバラバラであり、標準化されていない。
③最重要工程である要件定義、外部設計に対して、要件定義の工程完了判定のレビュー指摘率が極めて高く、且つ2020年度から改善されていない

目的(What)

派生開発における要件定義工程のドキュメント（対応概要書）を標準化することで以下を実現する。
①要件定義工程における欠陥の埋め込みの削減、および欠陥の早期検出②システムテスト工程で要件定義工程に戻っての手戻り工数の削減③標準化を実現することによる、効率的・効果的な継続的改善の実施

対応内容

スコープ

対応概要(How)✓ 投資金額が300万以下の案件を対象とする。
✓ 対象工程は要件定義工程とする。
✓ 対象ドキュメントは要件定義書とする。

要件定義書の標準化✓ XDDP（派生開発に特化した開発方法論）の取り込み※※3点セットの成果物のうち、変更要求仕様書とトレーサビリティマトリクスを対象とする※変更設計書は既存の外部設計書があるため対象外とする
変更要求仕様書システム要件が発生した理由、システム要件を実現するための変更仕様（変更要求と変更仕様を階層構造で表現、before（変更前）/after（変更後）で表現）
トレーサビリティマトリクス
変更仕様と外部設計書の紐づけ✓ 工程完了判定におけるレビュー指摘事項の取り込み✓ 有識者（ＸＸさん、ＸＸさん、ＸＸさんなど）の知見の取り込み

進め方✓ 2022年11月：各システムの要件定義書の理解、および整理※※各システムの要件定義書記載項目の比較表の作成✓ 2023年1月～2023年2月：要件定義書の標準化、有識者のレビュー✓ 2023年3月：システム担当者へ取り組み説明✓ 2023年4月：一部システムへ適用開始
12

ソフトウェア品質シンポジウム2023

期待効果✓ 要件定義工程における欠陥の埋め込みの削減、および欠陥の早期検出✓ システムテスト工程で要件定義工程に戻っての手戻り工数の削減✓ 第三者によるテスト設計の容易性
オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

６．要件定義（派生開発）の改善
改善概要➢ 要件定義書は、多くの大規模プロジェクトの経験がある有識者とともに何が必要なのかを定義➢ 各システムの要件定義書は現行を踏襲したうえで、不足している項目を追加
要件定義書の構成
ベースライン文書
背景
目的
前提条件・制約事項
対応概要
対応内容
他システムへの影響
修正対象の外部設計書
テスト方針
移行方針
非機能要件への影響
並行案件
影響調査結果スケジュール13

説明

改善ポイント

要件定義書のインプットとなるドキュメントを記載 ベースライン文書の追加（バージョン情報まで記載要）目的で記載した内容がなぜ起きているのか、その原因を分析したものを記載
なぜこの対応が必要なのか、それによりどのような目的を達成しようとしているのかを簡潔な一文で記載
未確定事項に対しておいた推定や仮定を記載 前提条件の明確化

改善後の要件定義書と現行の要件定義書の突合結果システム要件IDと要件の概要を表形式で記載 変更要件と変更仕様を階層構造で表現
14頁
システム要件に紐づく対応内容を記載
変更仕様は変更前・変更後で表現参照
他システムへの影響有無を記載
他システムへの影響の追加
システム要件に対して、修正が必要なシステム要件と外部設計書の紐づけ
外部設計書を記載
テストレベル・テストタイプ毎のテスト観点を記載 テスト観点は、テストケースの意図を具体的、かつ端的に記載
移行を実施するにあたっての考え方・方針を記載
性能・拡張性要件、可用性要件、運用要件への影響有無を記載（影響有の場合は、その内容を記載）
並行案件の影響調査結果を記載

ソフトウェア品質シンポジウム2023

15頁
参照
16頁
参照

現行の要件定義書は過去の継続的改善結果が蓄積されているので現行の要件定義書を踏襲したうえで改善を実施

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

６．要件定義（派生開発）の改善
代表的な改善内容（１／３）

XDDPUSDMPFD➢ 変更要件と変更仕様を階層構造で表現することで、仕様の抜け・漏れを予防➢ 変更仕様はbefore（変更前）/after（変更後）で表現することで、開発担当者の認識を特定（Specify）
No

変更要件

要件ID

要件名

要件概要

1 SR001 ワーニングメッセージの追加商品が終身保険かつ払込経路が「全期前納」の場合、ワーニングを表示する。

2 SR002 付属書類のチェック追加

商品が終身保険かつ払込経路が「全期前納」の場合、付属書類の本人確認報告書（取引時確認書）にチェックを入れる。

3 SR003 帳票印刷対象の追加商品が終身保険かつ払込経路が「全期前納」の場合、印刷画面にて本人確認報告書（取引時確認書）が出力できるよう対応する。

要件ID
SR001

枝番01
■ワーニングメッセージの追加
ID
名称
イベント
GA001R
申込書作成・修正画面 「申込書確認へ」ボタン押下時

変更
仕様

要件
詳細
商品が終身保険(RISE、Candle、With終身、CSP終身保険特約付)かつ「全期前納」の場合、下記ワーニングを次画面（GA002R）に表示<改修前>
・既存のワーニング

商品が終身保険(RISE、Candle、With終身、CSP終身保険特約付)かつ「全期前納」の場合、下記ワーニングを次画面（GA002R）に表示<改修後>
・既存のワーニング
・本人確認報告書の提出を促すワーニング ※→CSP（医療保険）が終身保険特約付の場合のため、下記以外に追加でメッセージを出す可能性あり※:下記ワーニングメッセージ案[商品名]：終身保険かつ全期前納の場合、「本人確認報告書（取引時確認書）」の提出が必要です。

14

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

変更
要求
仕様書

６．要件定義（派生開発）の改善
代表的な改善内容（２／３）

トレーサ
ビリティ
マトリクス

変更
設計書

➢ 開発担当者はシステム要件と外部設計書の紐づけを実施することで、仕様の抜け・漏れを予防○…外部設計書修正 △…テストのみ実施
画面

外部設計書

SR001

GA001R_申込書作成・修正画面○

SR002SR003

GA002R_申込書確認画面
GA003R_申込書完成画面
PD000R_設計書（共通）

帳票〇

PD001R_設計書（表紙）
PD010R_設計書（試算表）
バッチ
外部インターフェース

BT001_不要データ自動削除〇

BT003_申込データ△

提案書・申込書サービス_内規・申込チェック
提案書・申込書サービス_P計算
提案書・申込書サービス_経過年別P計算
取扱報告書情報TBL（t_fes_talk_report）

テーブル

〇

品質保証マネジャーは、外部設計工程の工程完了判定時に上記紐づけ結果と外部設計書の証跡の整合性を必ず確認
15

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

６．要件定義（派生開発）の改善
代表的な改善内容（３／３）➢ テスト観点は、テストケースの意図を具体的、かつ端的に記載➢ 品質保証マネジャーは、テストケース作成前に開発担当者が構造化、モデリングして考えていることを確認
高齢者現況届伝送ファイル作成におけるテスト観点（例）
テスト観点①
・高齢者現況届伝送ファイルの対象となる契約が抽出されることを確認※する。
※別紙「別紙1_抽出マトリクス」に記載されている条件を全件実施
テストモデルと網羅基準を明確化

テスト観点②・抽出されたデータが、以下の名寄せ条件※にて同一の名寄シーケンス番号となることを確認する。
※契約者名（カナ）、契約者性別、契約者生年月日、契約者住所コード※同一名寄シーケンスとなる件数の確認として、10件未満、12件、13件、100件名寄シーケンス同一の確認を行う。
網羅基準※を明確化※水準網羅

テスト観点③・名寄せした結果、同一名寄せシーケンス内に経過1年未満の契約と経過1年以上の契約がある場合は、ともに出力対象となることを確認する。
網羅基準※を明確化※水準網羅16

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

６．要件定義（派生開発）の改善
改善スケジュール
➢ 2023年4月から10システムで適用を開始し、効果を見極めたうえで残りのシステムにも横展開していく

2023年9月～
2023年4月～

2023年3月

システム担当者へ取り組み説明
2023年1月～2月

要件定義書の改善内容検討

17

ソフトウェア品質シンポジウム2023

10システムで適用開始

10システム以外へも横展開

継続的改善

要件定義の工程完了判定件数が多い
上位10システムに説明※上位10システムで全体の72％を占める

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

７．取り組みの効果➢ 上流工程での品質の作り込みを重視した取り組みにより、要件定義工程での欠陥の埋め込みは着実に減少➢ 今期は15％以下の要件定義工程の欠陥埋め込み比率※を目指す※8月末時点で9％
要件定義工程の欠陥埋め込み比率
年度

埋め込み比率※

2021年
3月期

24％

工程完了判定開始

16％

基盤・ミドルウェア（クラウド含む）の構築・改修案件にも適用開始

17％

継続的改善を実施

2022年
3月期
2023年
3月期

特記事項

今期（2024年3月期）

15％以下※要件定義工程で埋め込んだ欠陥の件数／本番障害件数

18

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

８．結論と今後の展開■結論
この2年間のQCサークル活動を通して、効率的・効果的な工程完了判定業務への改善が進み、 「上流工程での品質の作り込み」の強化が実現
一方で開発案件は今後さらに増加していく見込みのため、さらなる継続的改善が必要■今後の展開・品質リスク、および成熟度に合わせて、さらにメリハリのある品質保証ができるようにする
・上流工程重視の工程完了判定業務をさらに発展・拡大させる
・クラウドシフトやアジャイル開発に対応した品質保証ができるようにする

19

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社
Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.

ご清聴ありがとうございました

本発表に関するお問合せ先
オリックス生命保険株式会社
IT品質保証部
中島 輝
akira.nakajima.dd@ins.orix.jp

20

ソフトウェア品質シンポジウム2023

オリックス生命保険株式会社Copyright © 2023 ORIX Life Insurance Corporation All rights reserved.