技術標準等作成支援業務の進捗報告

平成27年２月１６日

特許庁PMO

資料２

目次

1. 技術標準等作成支援業務の進め方 (1.1 ‒1.４)

2. 論理構成(2.1 ‒2.9)

3. アーキテクチャ標準仕様書（案）概要(3.1 ‒3.8)

2

1.1 技術標準等作成支援業務：位置付け

3

本業務（アーキテクチャ標準仕様策定、データ統合方針検討、詳細統合計画の策定等）

アーキテクチャ標準仕様等に基づき個別システムを刷新

本業務は、特許庁業務・システム最適化計画（平成２５年３月１５日策定）における、システムを段階的に刷新するために必要となるアーキテクチャ標準仕様等の策定を支援する業務であり、本業務で策定されたアーキテクチャ標準仕様等に基づき個別システムを刷新することで、個別システムの構造を画一化しその後のデータの集中化を可能にする。

※「特許庁業務・システム最適化計画」（平成２５年３月）から抜粋。なお、上記工程表は平成２５年３月時点のものであり、その後、技術標準等作成支援業務の再調達に伴い、「アーキテクチャ標準仕様策定」、「データ分析・データ統合方針検討」及び「個別システム刷新方針の検討」の完了時期は延期されている。（スケジュールの詳細については、マスタースケジュールを参照のこと。）

1.2 技術標準等作成支援業務：成果物

4

移行方針書

全体システム概念設計書

特許庁システムに対する主要ニーズ（環境変化に可能な限り迅速・柔軟・低コストで対応できること、個別システムに分散したデータを統合すること等）に基づき、特許庁システムの理想的な全体システム構成（ＴｏＢｅモデル）を検討する。

データ統合方針書全体システム構成図

全体移行方針書

特許庁システムの現行の全体システム構成（ＡｓＩｓ）とＴｏＢｅモデルとのギャップを分析することで、段階刷新のための移行方針を策定し、各段階的刷新毎の全体システム構成（次期モデル）を検討する。

個別業務システム概念設計書

各段階刷新毎の次期モデルに基づき、個別システム毎の次期モデルの検討（概念設計）を行う。概念設計時に、それぞれの業務の特性（例えば、方式審査の場合、自動的に方式審査を行うアルゴリズムがプログラム化されている点）を考慮する。

個別移行方針書

個別システム毎の概念設計に基づき、移行戦略を個別システム毎に詳細化する。

方式審査 特実審査周辺

記録ファイル管理 意匠・商標審査周辺

公報（編纂） 審判

登録

アーキテクチャ標準仕様書

各モデルにおける検討結果に基づき、アーキテクチャに必要な仕様をまとめ、アーキテクチャ標準仕様を策定する。

アーキテクチャ標準仕様書

AsIsとToBeのギャップ 業務特性の考慮

各刷新段階の前提

システムごとの移行方針

○要件定義書○基本設計書

要件定義書へのインプット情報アーキテクチャ標準仕様書に準拠して基本設計を実施

エッセンスの抽出

5

スケジュール（平成２６年７月～平成２７年５月）

1.3 技術標準等作成支援業務：マイルストーン

現在

今回ご説明する内容• 全体システム構成図（論理構成）• アーキテクチャ標準仕様書目次（案）

6

1.4 技術標準等作成支援業務：全体システム構成図の検討事項概要

期間 将来アーキテクチャの方向性 方向性に対する全体システム構成図の考え方

主な検討・検証事項

Step1H26.7～H26.8

業務アプリケーションを疎結合化する- 保守性（モジュール性、解析性、変更性、試験性）

- 移植性（設置性、置換性）

• 「多階層構造（α版、β版）」を検討する

• システム構成要素の各層への配置方針を立てる

• 各層の関係性、システム構成要素間のアクセスパスについてルール化する

• SOAの考え方の適合サービスの粒度、サービス化対象、サービスの構成指針

• 業務開始契機発見手段・業務フローBPMSの適用

• 内部～外部システム連携手段階層の責務定義、ＥＳＢ、プロトコルデータ・ステータス管理方針

Step2H26.9～H26.10

業務の変更に対し、パラメータ等の変更により調整するのみで対応可能とする－ 保守性（変更性）

• 「論理構成」を検討する• 業務フロー（ワークフロー）、業務ルール（ビジネスルール）の業務アプリケーションからの独立に関して方針・ルール化する

• BPMS及びBRMSの適用・適合範囲（※BRMSは主に論理構成を定義する際に検討する）

データフォーマットや実装方法を統一し、システム資産の再利用性を高める－ 保守性（再利用性、解析性、変更性、試験性）

• 「論理構成」を検討する • システムの構造の詳細化、等

Step3H26.11～H27.1

業務アプリケーションのハードウェアに対する依存性を排除する－ 移植性（順応性、置換性）

• 「物理構成」を検討する • 非機能要件、プラットフォーム• プロダクト製品、外部影響分析

Step2: 論理構成

Step1: 多階層構造

Step3: 物理構成

7

2.1 論理構成：得られるドキュメントとその位置付け

全体システム構成図

全体システム概念設計書

システム構成図

ソフトウェア構成図

業務を分類した表にシステムをマッピングしたもの。移行方針を策定するために作成する。

最小の論理ノードを定義したもの。物理構成を検討するために作成する。

論理構成

多階層構造

物理構成

データ統合方針書

8

2.2 論理構成：システム構成図とは

システム構成図

システム構成図とは、横軸に産業財産権関連法（特許法、実用新案法等）、縦軸に特許庁の電子化業務の分類（工業所有権に関する手続等の特例に関する法律に規定された電子化業務等）をとって作成される表である。この表に、既存システムをマッピングしてAsIsシステム構成図を、概念データモデル分析に基づいて分割したサブシステムをマッピングしてToBeシステム構成図を得た。AsIsシステム構成図とToBeシステム構成図を比較することで、移行方針を策定する際のギャップ分析が可能となる。

9

2.3 論理構成：AsIsとToBeのギャップ分析で得られる内容

既存システム一覧

AsIs

業務単位毎にシステム化を積み重ね、個別に最適なシステムを構築してきた結果、現状は以下のとおり複雑な構造になっている。• システム間の構造の不統一• 類似した機能がいくつかのシステムに重複して存在• システム間に多様な相互依存関係が存在

概念データモデル分析

ToBe

以下のとおり現状（H27.1現在）の特許庁システムを整理した。• データの更新整合性を保証する観点で最小単位であるサブシステムに分割

• 法改正等により必要ではなくなった機能の削除• サブシステムの責務の整理

AsIsシステム構成図とToBeシステム構成図を比較することにより、AsIsのシステムが新たにどのように分割され、どのように機能配置がなされるのか把握することができる。

10

2.4 論理構成：AsIsシステム構成図

1-1 1-2

P.12でAsIsとToBeのギャップを説明するエリア

11

2.5 論理構成：ToBeシステム構成図

（※サブシステムの名称は仮称である。 ）

P.12でAsIsとToBeのギャップを説明するエリアP.13でAsIsとToBeのギャップを説明するエリア

2-12-2

2-3

2-4

12

2.6 論理構成：システム構成図のAsIsとToBeの比較（１）

（※現時点のもので、今後変更される可能性あり。）

AsIs ToBe

特許・実用新案の出願及び審判に関連するシステムについて比較した場合

1-1

1-2

2-1

2-2

13

2.7 論理構成：システム構成図のAsIsとToBeの比較（２）

ToBeでは以下のシステムが新たに設けられることが確認できた。• 「出願申請管理」サブシステム、「中間手続管理（出願）」サブシステム：前回ご報告した、各サブシステムと連携するサブシステム。

• 「外部システム連携」サブシステム：刷新過程・刷新後に、内部システムと外部システムの通信ギャップを埋めるサブシステム。

• 「ビジネスルール」サブシステム：BRMSの導入にともなってビジネスルールを管理するサブシステム。

2-3

2-4

AsIs ToBeToBeで新しく設けられるサブシステム

14

2.8 論理構成：ソフトウェア構成図

サブシステム内の構造について、多階層構造（P.15参照）で示すシステム構成要素に対して論理ノード（ソフトウェア及びデータベースを組み合わせて利用する際の最小構成要素（物理的に配置する際にこれ以上分けられない単位））を定義した。

ソフトウェア構成図

1 2 3

4 56 7

8

9 10 11 12

Ｘ

番号は、多階層構造（P.15参照）のシステム構成要素に付された番号と対応する。

代表凡例

15

2.9 多階層構造（γ版）1 2

34

5

6

78

9

1011

12

3

※前回からの変更点• 「BPMS補完機能」 （上記「5」）の追加

-サブシステム間の密接な連携を実現するためのアプリケーション• 「BRMS」（上記「9」）の追加

- ビジネスルールを管理するシステム構成要素

16

3.1 アーキテクチャ標準仕様書（案）概要：章立て

章 章タイトル

- はじめに

1章 設計方針- 特許庁アーキテクチャ策定指針に示された方向性でアーキテクチャ標準を具体化するための方針

2章 技術方式- 設計方針に従った、標準化されたシステムの静的な構造、及び、動的な振る舞い

3章 ルールの強制力の考え方- 技術方式に則ったシステムを構築するのに必要な、設計・開発業者等に課されるルールの適用範囲や強制力

4章 ルール（設計指針・規約）- ルールの強制力に基づいて分類される設計・開発業者等に課されるルール

章立ては以下のとおり。

17

3.2 アーキテクチャ標準仕様書（案）概要：目次（案）

目次（案）は現在のところ以下のとおり。

章 目次

はじめに

本書の位置付け

本書の利用者及び利用目的

本書の文章構成

本書の利用方法

本書の運用方法

1 設計方針

1.1 アーキテクチャの設計方針の導出

1.2 アーキテクチャの設計方針

2 技術方式

2.1 全体構成

2.2 処理方式

2.2.1 オンライン処理方式

2.2.2 バッチ処理方式

2.2.3 帳票出力方式

2.2.4 連携処理方式

3 ルールの強制力の考え方

3.1 スコープ（ルールの適用範囲）

章 目次

4 ルール（設計指針・規約）

4.1 インタフェースのルール

4.2 UI層・プレゼンテーション層のルール

4.3 ワークフロー層のルール

4.4 業務アプリケーション層のルール

4.5 外部システム連携層のルール

4.6 基盤機能層のルール

4.7 データ設計に関するルール

4.8 プログラムプロダクトのルール

4.9 文字コードの扱いのルール

4.10 開発言語の選定指針

4.11 非機能要求グレードのルール

4.12 システム機能に関する共通的なルール

別紙1 アーキテクチャ標準仕様書適合確認チェックリストの雛形

18

3.3 アーキテクチャ標準仕様書（案）概要：はじめに

「はじめに」の概要は以下のとおり。

・特許庁アーキテクチャ策定指針に対する本書の位置付けを記載する

本書の位置付け

本書の章構成

・「１章 設計方針」～「４章 ルール（設計指針・規約）」とする本章の構成を記載する

本書の利用方法

・利用者（特許庁、事業者等）と利用方法を記載する

（参考）アーキテクチャ標準仕様書の位置付け（特許庁アーキテクチャ策定指針から抜粋）

19

3.4 アーキテクチャ標準仕様書（案）概要：1章「1章 設計方針」の概要は以下のとおり。

アーキテクチャ設計方針の導出

・アーキテクチャ設計方針の導出の経緯、期待する効果を記載する。

20

3.5 アーキテクチャ標準仕様書（案）概要：1章

「1章 設計方針」の概要は以下のとおり。

- システム構造の簡素化

多階層構造の定義○階層・システム構成要素・アクセスパスを定義して定型化

SOA＋BPMS○BPMSでサービスの実行を制御することにより、サービス間の関係を疎結合化○類似機能の重複開発を防止し、サービスの再利用を促進○ビジネスルールをアプリケーションから切り出しBRMS上で実行○刷新過程・刷新後におけるESBを活用した外部システム連携

サブシステム分割○概念データモデル分析に基づくサブシステムに分割により、サブシステム間の関係を疎結合化、類似機能の重複配置の防止○ビジネスプロセスをサブシステム単位で作成し、業務処理変更による影響の

他サブシステムへの波及抑止疎結合化、類似機能の重複配置の防止

- 保守性、移植性を確保し、長期的に利用可能なアーキテクチャの採用

業界標準技術の採用

アーキテクチャ設計方針の詳細

・アーキテクチャの設計方針の詳細を記載する。

（※アーキテクチャ設計方針のさらに詳細な内容については、現在内容と文案を検討中）

21

3.6 アーキテクチャ標準仕様書（案）概要：2章

「2章 技術方式」の概要は以下のとおり。

全体構成

・アーキテクチャの静的な構造を記載する

- 多階層構造の定義

- 全体システム構成図（多階層構造）（論理構成）等によるアーキテクチャイメージ

処理方式

・システムの動的な振る舞いとして、アプリケーションを動作させる方式を実現する仕組みを記載する

- オンライン処理方式

- バッチ処理方式

- 連携処理方式

・処理方式パターンの定義及びパターン選択の指針、APレイヤ及びコンポーネントの定義、処理シーケンス、データの整合性を保つための仕組み、エラー処理方式等について、各処理方式単位で言及する

22

3.7 アーキテクチャ標準仕様書（案）概要：3章

「3章 ルールの強制力の考え方」の概要は以下のとおり。

適用範囲

• 標準化を適用する対象（定型化対象システム、個別にアーキテクチャを定めるシステム）を記載する。

• ルールの種類（規約、設計指針）の定義を記載する。

- 規約：設計開発業者が設計時に遵守することによりアーキテクチャを実現することを目的として策定するもので、基本的に定められた設計を採用するため裁量の余地はないものとなる。

- 設計指針：設計開発業者が設計指針に従って設計を行うことによりアーキテクチャを実現することを目的として策定するもので、設計指針に従う限り、設計の裁量の余地が残されているものである。

強制力

23

3.8 アーキテクチャ標準仕様書（案）概要：4章「4章 ルール（設計指針・規約）」の概要は以下のとおり。

・インタフェースのルール

レイヤ間、サブシステム間を定められたプロトコルで通信するインタフェースを設計するルールを定める。また、刷新過程や刷新後における内部システムと外部システム間で通信するインターフェースを設計するルールを定める。

・多階層構造の階層ごとに遵守すべきルール

サブシステムを構成する多階層構造の階層ごとに遵守すべきルール（例えば、画面設計規約、BPMSを介したデータの授受ルール、サービスの構成指針、等）を定める。

・その他の共通的なルール

多階層横断的に係る以下の設計要素について遵守すべきルールを定める。

- データ設計

- プログラムプロダクトの選定

- 文字コード

- 開発言語の選定

- 非機能要求グレード

- システム機能（システム監視やセキュリティなど）

設計指針・規約