技術的整合性検証プロセスの業務試行について（最終報告）

平成２８年３月１８日

特許庁PMO

資料３

目次

2

１．はじめに ・・・P. 3 ～ 4２．スケジュール ・・・P. 5３．技術的整合性検証プロセスの概要 ・・・P. 6 ～ 7４．検証のポイントについて ・・・P. 8５．【検証】ルール適合確認の適用工程について ・・・P. 9６．【検証】プロセスのタスクについて ・・・P. 10７．【検証】特許庁の実施体制について ・・・P. 11８．【検証】設計開発ベンダの実施体制について ・・・P. 12９．【検証】抽出されたルール自体の課題について ・・・P. 13１０．ルール適合確認結果と今後の対応について ・・・P. 14１１．今後の予定 ・・・P. 15

【参考】業務試行全体のプロセス ・・・P. 16 ～ 20

１．はじめに

3

＜システム刷新を進めていくに当たっての留意点＞アーキテクチャは実装して初めて課題が見えてくる。現在の計画では、アーキテクチャを実装するシステム刷新はかなり先になるため、もっと早い時期に他の案件でアーキテクチャのパイロットを行った方がよい。 第13回特許庁情報システムに関する技術検証委員会 議事概要（平成26年4月2日）

技術検証委員会からの指摘に基づき、四法方式審査システム、特実審査周辺システムの刷新に先だって、特許庁アーキテクチャ標準仕様書に準拠する新規システムの構築を、比較的小さなシステム（「ハーグシステム」）で実施。

特許庁アーキテクチャ標準仕様書に準拠するシステム構築は初めての試みであるため、個別プロジェクト(個別PJ)メンバが設計成果物のコントロールを行うプロセスと、PMO技術担当が設計成果物のチェックを行うプロセスを規定し、両プロセスによって、設計成果物に対する特許庁アーキテクチャに係る技術的整合性の検証を実施（業務試行）。

新規システムの構築において、特許庁アーキテクチャ標準仕様書に準拠させることの実施可能性を検証。

第13回技術検証委員会（平成26年4月2日開催）において、「システム刷新を進めていくに当たっての留意点」として、委員から下記の点の指摘を受けた。

（１）経緯

（２）概要

※前回の技術検証委員会（平成27年12月9日開催）において、「技術的整合性検証プロセスの業務試行について（中間報告）」の題で、中間報告を行った。

１．はじめに（続き）

4

（３）結論

以下の確認ができたことから、本業務試行を通じて、技術的整合性検証プロセスの実施可能性を検証することができた。

設計成果物を特許庁アーキテクチャ標準仕様書に準拠させるためのコントロールが可能であることの確認設計成果物のチェックが機能することの確認

一方、業務試行を通じて、以下の問題・課題が抽出された。

技術的整合性検証プロセスの適用工程特許庁及び設計開発ベンダの実施体制特許庁アーキテクチャ標準仕様書のルール自体 等

上記問題・課題を改善したプロセスを適用することで、今後、設計成果物に対する特許庁アーキテクチャに係る技術的整合性の検証を刷新システム向けに実施。

２．スケジュール

5

平成27年 平成28年

4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 4月 5月

ハーグシステム構築

技術的整合性検証プロセス

の業務試行

特許庁アーキテクチャ

標準仕様書

基本設計工程 詳細設計工程結合テスト

工程

基本設計工程に係る業務試行

詳細設計工程に係る業務試行

準備

1.1版検討

意見募集（2/16）

検証結果 検証結果

問題・課題

. 意見募集

1.0版案修正

問題・課題

1.0版公表

1.1版案修正

1.1版公表

プロセス自体の検証・改善

業務試行のスケジュール

最終報告（平成28年3月18日）

中間報告（平成27年12月9日）

製造/単体テスト工程

３．技術的整合性検証プロセスの概要

6

（１）技術的整合性検証プロセス

本業務試行における技術的整合性検証は、以下の2つのプロセスで構成した。（Ａ）技術的整合性コントロールプロセス

個別PJメンバが実施主体となり、特許庁アーキテクチャ標準仕様書に準拠したシステム構築を行うために、継続的に設計成果物の品質をコントロールするプロセス。（PMO技術担当は、コントロールの支援を行う。）

（Ｂ） 技術的整合性チェックプロセスPMO技術担当が実施主体となり、個別PJメンバが実施する技術的整合性コントロールプロセスの妥当性をチェックし、設計成果物のサンプルチェックを行うプロセス。

リリース企画

テスト

開発

設計

要件定義

プログラム設計・開発

結合テスト

総合テスト

受入れテスト

業務見直し要求定義 運用・評価

技術的整合性コントロールプロセス

技術的整合性チェックプロセス

基本設計

詳細設計

中間報告と同内容

業務試行

【主な設計成果物】

・業務フロー図（ＢＰＭＮ分析モデル図）・機能定義書・画面定義書・帳票定義書・外部インタフェース定義書・サービス化方針書・ＵＩ規約・各種処理方式概要設計書・概念データモデル

【主な設計成果物】

・画面設計書・帳票設計書・ジョブ設計書・外部インタフェース設計書・フロー処理設計書（処理連携図）・各種処理設計書・ＡＰ基盤設計書・論理データモデル・設備条件整理結果報告書

３．技術的整合性検証プロセスの概要（続き）

7

（Ａ）主体1PMO技術担当、CIO補佐官から構成。技術的整合性コントロールプロセスにおける個別PJメンバの役割を担当。

（Ｂ）主体2PMO技術担当から構成。技術的整合性チェックプロセスにおけるPMO技術担当の役割を担当。

（３）業務試行における実施体制（役割）について

（４）業務試行の対象工程

業務試行では、基本設計工程と詳細設計工程のみで実施した。

（２）業務試行について

技術的整合性検証の業務試行では、下記の（ａ）、（ｂ）、（ｃ）を目的として、新規システムであるハーグシステムが特許庁アーキテクチャ標準仕様書に準拠しているかどうかの技術的整合性検証プロセス（技術的整合性コントロールプロセス及び 技術的整合性チェックプロセス）を実施した。

【目的】（ａ）技術的整合性検証プロセス自体の妥当性の検証及び改善。（ｂ）技術的整合性検証プロセスに必要となるリソース（人，能力等）の検証。（ｃ）特許庁アーキテクチャ標準仕様書の問題・課題の抽出。

中間報告と同内容

４．検証のポイントについて

8

目的 検証項目 検討事項（詳細は後述）

（ａ）プロセス自体の妥当性の検証及び改善

ルール適合確認の適用工程について

ルールの適合確認の工程が基本設計工程・詳細設計工程のみとしているが、その妥当性について検証し、その改善方法について検討。 （５．参照）

プロセスの各タスクについて

コントロールプロセスのタスク、チェックプロセスのタスク、それぞれについての妥当性を検証し、その改善方法について検討。（６．参照）

（ｂ）プロセスに必要となるリソース（人、能力等）の検証

特許庁の実施体制について

プロセスに必要とする主体1，2のリソース（人、能力）・実施体制について検証し、その改善方法について検討。（７．参照）

設計開発ベンダの実施体制について

設計開発ベンダに要求される実施体制について検証し、今後、期待される実施体制について検討。（８．参照）

（ｃ）特許庁アーキテクチャ標準仕様書の問題・課題の抽出

抽出されたルール自体の課題について

特許庁アーキテクチャ標準仕様書のルール自体の課題と今後の対応を示す。（９．参照）

本業務試行では、（ａ）プロセス自体の妥当性の検証及び改善、（ｂ）プロセスに必要となるリソース（人、能力等）の検証、（ｃ）特許庁アーキテクチャ標準仕様書の問題・課題の抽出を目的に実施。目的ごとに、検証を行ったので、その検討事項の概要を示す。

５．【検証】ルール適合確認の適用工程について

9

特許庁アーキテクチャ標準仕様書は、基本設計工程及び詳細設計工程を適用工程としているが、ルールの適合確認の妥当性・課題及び改善案については以下のとおり。

課題①要件定義において、ルールを強く意識しないと、後続の基本設計工程に影響を及ぼすルールが存在（例、多階層構造、BPMN、画面、帳票、冗長化） 。

改善案①要件定義工程においても、適合確認のプロセスを確立する必要がある。

課題②基本設計工程、詳細設計工程の後続の工程（プログラム設計・開発以降の工程）で、仕様変更や設計変更が発生することが想定。（最終承認を詳細設計工程で行うのは時期尚早。）

改善案②プログラム設計以降の工程においても、仕様変更や設計変更が生じた場合は必要に応じて各種設計成果物の品質を確認する必要があり、プロセスを当該工程においても確立する必要がある。

改善案①

改善案②

改善案②

現行（業務試行） 改善案（刷新システム向け）

６． 【検証】プロセスの各タスクについて

10

技術的整合性検証プロセスには、主に、①開始準備、②コントロール＆チェック、③サンプルチェックのタスクがあるが、その妥当性・課題及び改善案については以下のとおり。その他、④工程完了の基準については、以下のとおり。

課題①（開始準備）主体1が、ルール毎の適用工程に基づいて、ルールと設計成果物との対応関係を示す対応マトリックス表を作成したが、実際は想定された対応関係とはならなかった。

3.1.1.3 　 多階層構造の詳細3.1.2.5 連携処理方式3.2.13.4 システム監視方式設計の3.2.7.1.1 ビジネスルールをアプリ3.2.2.1 クライアント構成 ○3.2.2.2 画面とリクエストの作成 ○ ○ ○ ○3.2.2.4.1 画面のアクセシビリティ ○ ○3.2.2.4.2 画面の定義に関するルー ○ ○ ○3.2.2.4.3 画面の内容に関するルー ○ ○3.2.2.5.1 帳票の出力項目に関する ○ ○3.2.2.5.2 帳票のレイアウトに関す ○ ○

サー

ビス一覧

ビジネスルー

ル定義

基本設計

ビジネスルー

ル一覧

機能定義書

画面一覧

画面定義書

画面遷移図

帳票一覧

帳票定義書

サー

ビス化方針書

メッ

セー

ジ設計書

外部インタフェー

ス

外部インタフェー

ス

ＵＩ規約（

機能定義

ルール作成者：主体１（特許庁の個別PJ）

作成者：設計開発ベンダ

改善案①（開始準備））設計開発ベンダは、基本設計工程前からルールを強く意識しなければならないため、プロジェクト実施計画書策定時に対応マトリックス表の作成を義務づける必要がある。

作成 作成

対応マトリックス表

現行（業務試行） 改善案（刷新システム向け）

課題なし②（コントロール＆チェック）主体1が、定期的にルール適合確認報告を実施することで、手戻りを少なくし、設計成果物の品質の向上を実現。

当該プロセス・タスクは妥当

課題なし③（サンプルチェック）主体1、設計開発ベンダ以外の第3者が監査的な立場で適合確認することで、更なる設計成果物の品質向上を実現。

当該プロセス・タスクは妥当

課題④（工程完了）工程完了の基準・条件として、ルール適合の要件が曖昧。

改善案④（工程完了報告）ルール適合の条件を明確化することで、品質の向上を図る必要がある。

ルールを遵守させるために必要なスキル

処理方式

BPMN業務内容

SW／HW

開発手法

設計開発経験

コントロールプロセスの主体

個別PJメンバ兼

PMO技術担当（職員）

○ △ ◎ △ ○ △

PMO技術担当（派遣）

○ △ △ △ ◎ ◎

CIO補佐官

◎ △ △ ◎ ◎ ◎

７． 【検証】特許庁の実施体制について

11

技術的整合性検証プロセスの実施において、特許庁のリソース（人、能力）・実施体制の課題及びその改善案については以下のとおり。

課題①（コントロール体制）主体1の構成では、ルールを遵守させるために必要なスキルを、各メンバで相互に補完し合える実施体制が確立されていたが、BPMNのスキル・経験については不足していた。

改善案①（コントロール体制）すべてのルールに精通している者で体制を組むことは困難であるので、業務試行と同様に、補完し合える体制が必要。BPMNのスキル等については、研修などを通して、強化する必要がある。

ルールを遵守させるために必要なスキル

処理方式

BPMN業務内容

SW／HW

開発手法

設計開発経験

コントロールプロセスの主体

個別PJメンバ

（職員）○

△→

○研修

◎ △ ○ △

PMO技術担当

（職員、派遣）

○△→

○研修

△ △ ◎ ◎

CIO補佐官

◎△→

○研修

△ ◎ ◎ ◎

◎：高度な知識・経験 ○：一般的な知識・経験 △：若干の知識・経験

課題②（チェック体制）業務試行前半のサンプルチェックがリソース不足により、未実施。業務試行後半のサンプルチェックも97ルール中6ルール。

改善案②（チェック体制）充実したチェック体制を整備するためには、PMO技術担当の強化が必須。

現行（業務試行） 改善案（刷新システム向け）

補完（現行と同様）補完個別PJの支援者

個別PJの主体

個別PJの支援者

個別PJの支援者

個別PJの支援者

個別PJの主体

８． 【検証】設計開発ベンダの実施体制について

12

設計成果物に対するルール適合作業において、設計開発ベンダのリソース（人、能力）・実施体制の課題及びその改善案については以下のとおり。

課題設計開発ベンダ側による、ルール適合確認については、確認の漏れ・判断誤りなどがあり、品質管理体制が十分ではなかった。

改善案設計開発ベンダ側の体制として、各ルールに対する高度な知識・経験を有する者が品質管理を行い、また、特許庁アーキテクチャ標準仕様書に関する事項について、個別ＰＪメンバとの連絡・調整を実施する必要がある。

個別ＰＪメンバ兼

PMO技術担当（職員）

PMO技術担当（派遣）

ＣＩＯ補佐官

設計成果物

設計開発ベンダ 特許庁

PMO技術担当（職員、派遣）

ＣＩＯ補佐官

個別ＰＪメンバ（職員）

特許庁アーキテクチャ標準仕様書に関する品質管理者・連絡窓口

特許庁設計開発ベンダ

特許庁アーキテクチャ標準仕様書に関する専門の品質管理者

【不在】

設計成果物

レビュー

ルール適合確認（品質チェック）

レビュー

現行（業務試行） 改善案（刷新システム向け）

個別PJの支援者

個別PJの支援者

個別PJの主体

個別PJの支援者

個別PJの支援者

個別PJの主体

９． 【検証】抽出されたルール自体の課題について

13

本業務試行で抽出された特許庁アーキテクチャ標準仕様書のルール自体の課題については、以下のとおり。

課題業務試行を通じて抽出したルール自体の課題は、111件。内訳は下記のとおり。①記載内容が不明瞭であるルール ：48件②ルール自体に問題があるルール ：42件③適合対象工程の見直しが必要なルール ：12件④記載の意図が不明瞭であるルール ：6件⑤その他 ：3件

改善案①主に、「ルールの目的」、「ルールの確認観点（何をチェックするのか）」、「ルールの適合基準」を明確化する対応。②主に、ルールの要件・強制力を見直す対応。③適合対象工程の規定をはずす対応④表現の修正、図解等で、意図を明瞭にする対応

（１）具体例1データの保護方式において、「他のビジネスプロセスインスタンスによってデータベースの値が更新され、それを自ビジネスプロセスインスタンスが知る必要がある場合、基本的にはＢＰＭＳが通知することで、データ不整合が起きないよう制御すること」と記載されているが、当該記載の内容が不明瞭。

（２）具体例2BPMNの記載ルールに関して、シームレス開発を行えるように、記述モデル、分析モデル、実行可能モデルで使用できるパレットを制限し、トレーサビリティ担保したが、記述モデルにおいて、自由度がないという問題点があった。

（１）具体例1事例を追記する必要がある。

（２）具体例2記述モデルをルールから外すことで、自由度を与えた。

現行（業務試行） 改善案（刷新システム向け）

１０．ルール適合確認結果と今後の対応について

14

本業務試行では、詳細設計工程終了時までのルール不適合数が16ルール、ルール不適合率が20％。

設計工程 確認ルール数

適合確認の結果次工程以降で

確認適合 不適合ルール確認対象外

(BRMSなし、動き・音なし)

基本設計 終了時点【結果】

5938

（76%）12

（24%）9 38

詳細設計 終了時点【結果】

9464

（80%）16

（20%）14 3

結合テスト 終了時点【想定】

97（すべてのルール）

83（98%）

2（2%）

12 0

No. 「不適合」原因 件数 今後の対応方針

1 設計者のルール理解不足のため 12 結合テスト終了までにはルールに適合するように設計成果物を修正。

2

ルール自体の整備不足のため※ルールが実情に適していない。（例：境界（中断）イベントメッセージ、画面部品、仮想マシンの監視サーバの配置）

4 特許庁アーキテクチャ標準仕様書（第1.1版）に向けルール内容の見直し。

（１）適合確認結果

（２）「不適合」原因

「結合テスト終了時点【想定】」の不適合ルール（２件）は、基本設計工程のデータモデルの命名ルールに関するもの。詳細設計工程のデータモデルが適合しているので、基本設計工程のデータモデルの命名ルールを見直す必要性はないと判断。

※

※

１１．今後の予定

15

平成28年 平成29年

1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 4月 5月

技術的整合性検証プロセス

【業務試行】の継続

技術的整合性検証プロセス

ガイドライン策定

特実審査業務システム【刷新】

特許庁アーキテクチャ標

準仕様書

1.0版

最終報告（基本設計工程、詳細設計工程）

ハーグシステム 製造／単体・結合・総合テスト 【業務試行】

調達仕様書作成 開発業者調達

（２）今後の予定現時点

①技術的整合性検証プロセスのガイドライン化業務試行の具体的なプロセスに関し、基本設計工程、詳細設計工程部分について、 「技術的整合性検証プロセスガイドライン」としてガイドライン化を実施。対応マトリックス表の作成については、特実審査業務システムの調達仕様書に一部反映させる予定。

（１）今後の作業

1.1版

策定

②リソース・実施体制の整備特許庁側のリソース・実施体制については、PMO技術担当の強化を進め、特実審査業務システムの設計開発が開始される平成２９

年８月迄に整備していく予定。また、設計開発ベンダ側の実施体制については、特許庁アーキテクチャ標準仕様書を準拠させるための品質管理体制を、調達仕様書で義務化していく方向で検討する予定。

③技術的整合性検証プロセスの業務試行の継続本業務試行については、プログラム設計・開発（製造／単体・結合・総合テスト）以降の工程で仕様変更や設計変更の発生を見据えて、継続的に実施。

検討1.1版案修正

1.2版検討

1.1版公表 1.2版公表

1.2版案修正

策定

【参考】業務試行全体のプロセス（１）

16

「①開始準備」では、特許庁アーキテクチャ標準仕様書の各ルールが、どの設計成果物に反映されるかを整理するために、主体1が各ルールと設計成果物とを対応させた対応マトリックス表を作成。

サブタスク サブタスク概要 作成物

・対応マトリックス表の作成 ・主体1が各ルールと設計成果物とを対応させた対応マトリックス表を作成して、「何を見るか」を整理。・事前に「何を見るか」を整理することで、主体1が適用すべきルールを強く意識して、適合確認漏れを防ぐ。

・対応マトリックス表

業務試行前半（基本設計工程） 業務試行後半（詳細設計工程）

ルール

対応マトリックス表

各工程の設計成果物

マトリックス表

【参考】業務試行全体のプロセス（２－１）

17

「②ルール適合コントロール＆チェック」では、主体1が、適合すべきルールを中心に、設計成果物に対して技術的整合性のコントロールを行い、適合確認結果報告書を作成し、主体2に対し、定期的に（隔週で）レビューを実施。また、特許庁アーキテクチャ標準仕様書の課題を抽出。

業務試行前半（基本設計工程） 業務試行後半（詳細設計工程）

【参考】業務試行全体のプロセス（２－２）

18

サブタスク サブタスク概要 作成物

②－1 ：コントロール ・主体1は、設計開発ベンダに対するレビューに参加し、設計成果物を対象に、ルールの適合状況の確認。・主体1は、確認したルールごとに、ルール適合確認結果報告書を作成。

・ルール適合確認結果報告書（主体1作成）

②－2－1：ルール適合確認結果報告（主体1）

②－2－2：妥当性チェック（主体2）

・主体1は、ルール適合確認結果報告会を隔週で実施。・主体2は、報告会を通じて、ルール適合確認結果の妥当性をチェック。

②－3 ： 報告会まとめ ・主体1は、適合確認報告書の修正、及び、抽出された特許庁アーキテクチャ標準仕様書の課題を、技術的整合性課題管理表に起票。

・技術的整合性課題管理表

②－4 ：技術的整合性課題対応 ・主体2は、特許庁アーキテクチャ標準仕様書の課題に対して、改定版に向けて対応。

【参考】業務試行全体のプロセス（３－１）

19

「③サンプルチェック」では、主体2が、ルールを機械的に選定し、そのルールに対応する設計成果物に対して、ルール適合確認を行い、適合・不適合の判断を主体1に報告。主体1は、適合確認結果報告に基づき、不適合となったルールに対しては、対処方針を説明。

業務試行前半（基本設計工程） 業務試行後半（詳細設計工程）

未実施 実施

【参考】業務試行全体のプロセス（３－２）

20

サブタスク サブタスク概要 作成物

③－1：対象ルール選定 ・主体2は、サンプルチェック対象ルールの選定を下記を基準に設定。□コントロールプロセスで1回以上不適合となったルール。□コントロールプロセスの最終評価が「適合」以外となったルール。□主体1、主体2が検証を必要とするルール。

③－2：対象設計成果物抽出 ・主体1は、対応マトリックス表を用いて対象ルールに対応する設計成果物を抽出。

③－3：サンプルチェック ・主体2は、ルールの適合状況を確認し、ルール適合結果報告書を作成。 ・ルール適合確認結果報告書（主体2作成）

③－4：ルール適合確認結果報告（対主体1）

・主体2は、不適合となったルールに対して、ルール適合確認結果を主体1に報告。

③－5：対処方針報告 ・主体1は、不適合となったルールに対して、今後の対応方針又は弁明内容を主体2に報告。

③－6：報告書再作成 ・主体2は、対応方針又は弁明内容として、①不適合とした理由がルール自体の不備に基づくものか、②ルールを逸脱する根拠とそれに対する設計内容が受け入れられるものか、③後工程へ申し送り可能なものかを確認して報告書の再作成を行い、報告書（修正版）を主体１に提出。

・ルール適合確認結果報告書（修正版）