|
|
|
|
|
各府省情報化統括責任者(CIO)連絡会議において、政府全体の方針として「電子政府構築計画」(2003年(平成15年)7月17日決定、2004年(平成16年)6月14日一部改定)が決定され、この中で「システムの見直しのための警察庁行動計画(アクション・プログラム)」(以下「アクションプログラム」という。)が策定されたところである。
警察庁においては、アクションプログラムに従い保有する「全国的情報処理センター用システム」、「指紋業務用システム」及び「運転者管理等のシステム」の各々に関して更なるシステム経費の削減等の刷新可能性調査を行う。
システム経費等の削減の調査に当たり、システム関連業務分析、現状システムの概要分析、現状システムを踏まえた関連システム技術整理、オープンシステム化の可能性の検証及び再構築の方向性検討、必要な機器(ソフトウェアを含む。)の費用算定方法の妥当性及び費用対効果等について検討を実施する。
本調査は、平成17年度に予定される業務・システム最適化計画策定のための予備調査として位置付けられており、「全国的情報処理センター用システム」(以下「本システム」という。)を新たなシステムに刷新した場合に、使用者及び利用者の利便性を損なわず、またシステムの安全性、機密性の確保及び信頼性の維持にも配慮しつつ、トータルコストを削減できるか否か、システムの刷新方法も含めて検討し、結論を得ることを目的とする。
本調査の対象範囲は、本システムの中心であるメインフレーム[1]及び都道府県警察設置の端末装置とする。
警察庁全体で共有している共用ネットワーク、及び都道府県警察で個別に維持管理している都道府県警察電子計算機等は対象範囲外とする。
図 1 本調査の対象範囲
本システムは、犯罪捜査に必要な各種情報を迅速かつ的確に、第一線の捜査担当者に提供するためのシステムである。
全国的な捜査関連情報を、警察庁情報処理センター(以下「情報処理センター」という。)に設置した電子計算機で一元的に管理することによりシステムサービスを提供しており、次のような特徴を備えている。
本システムの主要な機能は、現場警察官からの照会依頼に基づく情報提供である。したがって、取り扱う情報の特性から生じる「機密性」はもとより、24時間いつでも利用可能である「可用性」、照会依頼時の情報提供の「迅速性」が重視される。
さらに、捜査活動を支援するための柔軟で多角的な情報分析機能も、本システムの重要な機能である。
したがって、取り扱う情報の特性から生じる「機密性」はもとより、管理している情報を分析する際の「柔軟性」が重視される。
本調査で対象とする業務を、表 1 全国的情報処理センター用システム 対象業務一覧に示す。
No. |
大分類. |
分類 |
概要説明 |
1 |
犯罪情報管理システム |
照会センター系業務 |
警察庁及び都道府県警察に設置されている照会センター端末装置並びに都道府県警察電子計算機及び車載用端末装置から行う業務。 計3業務。 |
2 |
専務系業務 |
警察庁及び都道府県警察の業務担当課等に設置されている端末装置から行う業務。 計4業務。 |
|
3 |
画像情報検索システム |
画像検索業務 |
警察庁及び都道府県警察に設置されている端末装置及び都道府県警察電子計算機から行う業務。 計2業務。 |
本システムは、情報処理センターに設置されたメインフレーム、オープン系サーバ[2]と都道府県警察に設置された端末装置等からなる全国規模のシステムである。
図 2 本システムを取り巻くシステム全体構成
メインフレームは帳票編集・印刷機能、エントリ処理機能、DB処理機能等を有し、照会センター系業務等を実装する。オープン系サーバは、メインフレームの補完的機能を担う。
また、端末装置等は利用プロトコルとしてTCP/IPを利用したオープン系端末、プリンタ等を利用している。
本システムのメインフレームは、基幹業務の高可用性・高性能等の要件に耐え得る中大型クラスの機器を導入している。オープン系サーバには、メインフレームとの連携を考慮したエンタープライズサーバを導入している。
また、都道府県警察本部等に設置する端末装置としてPC/AT互換機等のパソコンを導入している。
図 3 情報処理センターにおけるハードウェア構成
なお、メインフレームにおいて要求される性能及び可用性等を実現するための特徴として以下の点が挙げられる。
・ トランザクション負荷分散機能によるCPU負荷の分散
・ 装置の二重化による高信頼性
・ 電子ディスク装置の利用による高速化
・ ディスクアレイ装置又はRAID方式(ストレージ信頼技術)による冗長構成
・ 仮想計算機により実運用に影響を与えることなく試験環境の構築が可能
・ 自動運転制御及びシステム運用監視による運用負荷の軽減
・ ディスク障害時における媒体復旧処理の自動化
本システムのメインフレームでは、OS上に汎用DBMS及び警察庁独自仕様のDBMS並びに業務プログラムを実装している。オープン系サーバはOSとしてUNIXを採用し、統合運用プログラムを実装している。
また、端末装置にはWindows系OSに警察庁独自開発の業務プログラムを実装している。
図 4 メインフレーム及び端末装置におけるソフトウェア構成
本システムの平成15年度の運用コストは、メインフレーム及び端末の電算借料が全体の運用コスト[3]の89%を占めるコスト構成となる。電算借料以外の既定経費等(消耗品等システム運用にかかる経費及び一時経費)は全体の運用コストの11%である。
表 2 運用コスト構成(平成15年度)
(単位:百万円)
内訳 |
運用コスト |
電算借料 |
2,960 |
既定経費等 |
374 |
合計 |
3,334 |
図 5 運用コスト割合(平成15年度)
平成6年から平成15年度までの過去10年間における運用コストは、表 3 運用コスト推移のとおりである。平成9年度から平成10年度においてシステム更改(OS変更等)に伴う一時経費が発生しており、移行期間中の運用コストが増大している。
表 3 運用コスト推移
(単位:百万円)
内訳 |
年度 |
|||||||||
H6 |
H7 |
H8 |
H9 |
H10 |
H11 |
H12 |
H13 |
H14 |
H15 |
|
電算借料 |
3,025 |
3,104 |
3,170 |
3,410 |
3,387 |
3,371 |
3,422 |
3,492 |
3,540 |
2,960 |
既定経費等 |
369 |
379 |
363 |
734 |
824 |
367 |
388 |
325 |
305 |
374 |
合計 |
3,394 |
3,483 |
3,533 |
4,144 |
4,211 |
3,738 |
3,810 |
3,817 |
3,845 |
3,334 |
図 6 運用コスト推移
運用コスト算定時の見積算定方法等については以下のとおりである。
・ 機器の老朽化及び機能追加による機器増設等のシステム更改に当たり、現行機器の稼働率及びピーク時利用率、将来想定されるシステム拡張、性能、価格性能比等を総合的に判断し、運用コストを導き出している。
・ 過去のシステム構築及び運用コスト算出の経緯、運用コスト実績を勘案し、次年度の運用コスト算出を行っている。
今後は、比較的類似しているシステムの運用コスト、市場価格に関する調査及び複数ベンダからの見積取得等を適宜実施し、一層のコスト削減に向けた継続的な取組みが必要である。
一般的なオープン化に関する対象事象、方策等は表 4 オープン化対象事象と方策例のとおりである。
オープン化対象事象 |
方策例 |
メインフレーム |
・ オープン系プラットフォーム(サーバ、OS、DBMS等)の導入 ・ 業務パッケージソフトの導入 |
端末 |
・ オープン系端末の導入 ・ 業務パッケージソフトの導入 |
ネットワーク |
・ 標準プロトコル(TCP/IP)の利用 ・ 標準的なネットワーク機器の導入 ・ 各種回線サービスの導入 |
本システムでは、端末は既にWindows系端末を導入していること、ネットワークは、標準プロトコルを採用していることからメインフレームのオープン化を対象範囲として検討する。
オープン化を検討するに当たり、メインフレームにて実装しているシステム機能を論理的にEnterprise Application Integration[4]層(EAI層)、アプリケーション層(AP層)、データベース層(DB層)の3階層に分けて各機能に適した機器構成を検討した。
表 5 システム論理階層
システム論理階層 |
特徴 |
EAI層 |
端末及び他システムとの接続機能をEAI層に収容し、1対N若しくはN対Nの接続環境に依存する対応をEAI層のサーバに集約する。接続環境の変化を極力アプリケーション層に影響を与えない構造とする。 |
AP層 |
業務機能の拡張、業務処理量の増加等、業務環境への変化の対応をAP層のサーバに集約する。業務処理増加時の対応は物理ノードの増加、新業務APサーバの増加で対応する。 |
DB層 |
データベース機能を集約し、DB層単独の高可用性、高レスポンスを実現する。業務アプリケーションはDBノードの切り替えを意識せずに構築が可能となる。 |
各システム論理階層の機能の特徴を鑑みると、EAI層、AP層については、柔軟性、拡張性への対応が重要な要件であり、DB層においては、性能が特に重視されるポイントとなる。
本システムの最適構成を検討するに当たり、信頼性、可用性等の観点からメインフレームとオープン系サーバの比較を行った。
表 6 メインフレームとオープン系サーバの比較
観点 |
メインフレーム |
オープン系サーバ |
比較優位 |
信頼性 可用性 |
基幹業務で培われた完成度の高いOSのため信頼性が高い |
OSのバージョンアップが繰り返されOSとしての完成度は発展途上 |
メインフレーム |
構成するコンポーネントが集約されているため、障害の発生要因は少ない |
性能と信頼性の向上を目指すハードウェア及びミドルウェアの冗長化が必要で、障害発生要因が増加 |
||
故障検出機能が充実しているため、障害に強いハードウェアによる高可用性を実現 |
冗長化等により高可用性は実現可能であるが、チューニングや整合性の事前調査が必要 |
||
OLTP、DBMS、ファイルシステム等において、OSレベルで統一的なリカバリ機能を提供 |
OLTP、DBMSのミドルウェアごとに個別にリカバリ機能が提供されているため、統一的なリカバリ方式について詳細設計が必要 |
||
性能 |
データIOや通信等の専用機器を構成できるため、バッチ処理等大量データ処理に強い |
高性能なハードウェア及び分散構成をとることでメインフレームを凌ぐ性能を実現可能である(バッチ処理で分散処理が出来ない場合は劣る) |
メインフレーム |
メインフレーム、オープン系とも単一処理はCPU性能に依存するが、汎用機OSは資源配分の最適化を目標として進化してきたため、安定的なレスポンスが期待できる |
オープン系OSは資源配分のバランス調整が適切に出来ていないため、トラフィックが増大するとレスポンスタイムが極端に悪化する場合がある |
||
機密性 |
各ベンダ固有のOSであり技術情報が公開されていないため、情報が漏洩しにくい |
OSの技術情報が公開されているため、セキュリティホールに対する攻撃を受けやすい |
メインフレーム |
柔軟性 拡張性 |
1台のメインフレームで多様な役割を担うため、負荷が集中しやすく、きめ細かなチューニングが必要 |
個々の業務要件に応じた構成を組むことが可能であり、業務変更、新規業務追加等に柔軟に対応可能 |
オープン系サーバ |
オープン系に比べオープン環境で導入された最新技術の導入にタイムラグが発生する |
Webサービス等の最新技術については、オープン系から成熟するため、最新技術の早期導入が可能 |
||
運用性 保守性 |
あらゆる機能を一箇所に集中しているため、運用管理が容易 |
分散システムの形態をとる場合、全体としての管理が煩雑になり、管理に必要な労力が大きい |
メインフレーム |
ハードウェア、ソフトウェア共に同じ製造元の製品であり迅速なサポートが可能 |
ハードウェア、OS、ミドルウェア、アプリケーションの提供ベンダが異なり、原因の特定や問題解決までに時間がかかることがある |
||
運用操作はコマンドラインが基本であり、コマンド投入ミス、入力タイムラグは発生するおそれがある |
GUI操作を実現した統合監視製品等が充実しており、オペレーションミスが少ない |
オープン系サーバ |
|
ネットワーク変更、及び機器増設の際はハードウェアの構成定義を変更する作業が発生し、システム停止を伴う |
分散システムの形態をとることでハードウェア構成変更に対する影響を局所化することができる |
||
コスト |
ハードウェアについては、一般的にコストは高くなる
|
単体としてのハードウェアについては、一般的にコストは低くなる(ただし、メインフレーム系と同等以上の性能、可用性の実現を目指すとなると、様々なプロダクト、構成技術、新規アプリケーションが必要となり、これらのコストがメインフレームのコストを上回る可能性がある) |
オープン系サーバ |
メインフレーム製造元への依存度が高いため、調達先や選択肢の多様性は低い |
調達先や製品選択の選択肢の多様性は高い |
前述のメインフレームとオープン系サーバの比較のとおり、信頼性、性能、機密性を重視する場合はメインフレームが採用され、柔軟性、拡張性、コストを重視する場合はオープン系サーバが採用される傾向がある。
したがって、オープン化のパターンとしてメインフレームの機能を全てオープン系サーバに置き換えた構成(パターンA)とそれぞれの特徴を活かし、DB層以外をオープン系サーバに置き換えた構成(パターンB)においてコスト試算を行った。
また、参考情報としてメインフレームを継続利用した場合(パターンC)を併せて試算した。
表 7 オープン化検討パターン
パターン |
パターンごとの特徴 |
パターンA |
・ メインフレームの全ての機能を全てオープン系サーバに置換え |
パターンB |
・ メインフレームのEAI層、AP層の機能をオープン系サーバに置換え ・ DB層の機能はメインフレームを利用 |
パターンC (参考情報) |
・ メインフレームを継続利用 |
メインフレームを全てオープン系サーバに置き換えた場合(パターンA)のシステム構成概要を以下に示す。
図 7 完全オープン化(パターンA)のシステム構成概要
一部オープン系サーバに置き換えた場合(パターンB)のシステム構成概要を以下に示す。
図 8 一部オープン化(パターンB)のシステム構成概要
パターンごとのオープン系サーバの機器構成は、メインフレームにて求められる性能等と同等の要件を満たす構成[5]を想定した。
オープン系サーバの機器等のリース期間は4年間、リース料率は2.4%とした。
オープン系サーバにおいて価格性能比の向上、競争調達の導入等による価格下落を想定し、機器及びソフトウェアを標準価格の3割減とした。また、機器及びソフトウェアの保守費用も同様に標準価格の3割減とした。
メインフレームに求められる可用性をオープン系サーバ等の機器で実現するため、機器構成の冗長化等の安全性、信頼性を高める技術の採用に加えて、可用性を維持するサービス(CE常駐サービス等)を追加し費用計上した。
メインフレームを継続利用する場合、メインフレームの価格下落により電算借料が1割低減することを想定してコスト試算を行った。
メインフレームを継続利用する場合(パターンC)、平成15年度のメインフレームの電算借料は20億300万円であるため、将来想定されるメインフレームの電算借料は、1割減じた18億300万円とした。
また、一部オープン系サーバに置き換えた場合(パターンB)、メインフレームの規模及び機能縮小に伴い電算借料が2割低減することを想定し、価格下落の1割減と合わせて14億4,200万円とした。
一時費用は、業務構築基盤の開発、運用環境の構築、運用設計等に関する費用を想定した。また、システム移行期間中の機器の設置期間を2年間とし、機器、ソフトウェア及び保守費用を一時費用に含めた。
なお、警察庁職員で実施する移行設計、移行作業等の費用は除外した。
システム更改後の機能追加及びシステム規模拡大等は実施されないことを前提とした。
施設費用、電源費用、通信回線関連費用及び運用支援費については、パターンごとに大きな差異はないとし、コスト試算からは除外した。
想定パターンごとのランニングコストは、メインフレームを全てオープン系サーバに置き換えた場合(パターンA)が最も低く、一部オープン系サーバに置き換えた場合(パターンB)とメインフレームを継続利用した場合(パターンC)はほぼ同額となる。
表 8 ランニングコスト比較
(単位:百万円/年)
分類 |
オープン系 サーバ (パターンA) |
一部オープン系 サーバ (パターンB) |
メインフレーム 継続利用 (パターンC) |
オープン系サーバ 機器・ソフト・保守費用 |
900 |
238 |
- |
オープン系サーバ 可用性維持サービス |
450 |
119 |
- |
メインフレーム 機器・ソフト・保守費用 |
- |
1,442 |
1,803 |
ランニングコスト合計 |
1,350 |
1,799 |
1,803 |
図 9 ランニングコスト比較
パターンごとの一時費用は、メインフレームを継続利用した場合(パターンC)が最も低額で、全てオープン系サーバに置き換えた場合(パターンA)、一部オープン系サーバに置き換えた場合(パターンB)の順に高額になる。
表 9 一時費用比較
(単位:百万円)
分類 |
オープン系 サーバ (パターンA) |
一部オープン系 サーバ (パターンB) |
メインフレーム 継続利用 (パターンC) |
一時費用 |
3,100 |
5,060 |
210 |
図 10 一時費用比較
本システムのメインフレームをシステム論理階層ごとに全てオープン系サーバに置き換えた場合(パターンA)、メインフレームを継続利用した場合(パターンC)よりも4億5,300万円のコスト削減効果があり、ランニングコストは25%削減される。
また、一部オープン系サーバに置き換えた場合(パターンB)は、400万円のコスト削減効果があるが、メインフレームを継続利用した場合(パターンC)とほぼ同額であり、コスト削減効果は少ない。
本システムをメインフレームから全てオープン系サーバに置き換えた場合(パターンA)の一時費用は31億円である。
前述のランニングコストの削減額及びシステム更改時の一時費用より、メインフレームから全てオープン系サーバに置き換えた場合(パターンA)の一時費用の回収期間は6.8年となる。
本システムは、対象とする業務及びデータの特殊性により、国内に類似する事例は存在しない。
また、海外事例についても、業務の機密性により調査が及ばない分野である。
前述したとおり、ランニングコストについては、すべてオープン系サーバに置き換えた場合(パターンA)の方が、メインフレームを継続利用する場合(パターンC)に比べて25%低くなる。
ただし、オープン系サーバへの置き換えには、可用性を高めるサービスを追加する必要性や、移行時の一時費用の精査等、実現可能性に関する諸問題が存在する。
したがって、機器・ソフトウェア及び保守費用等のコストの単純比較にとどまらず、システム移行期間、移行時期及び移行手法等における課題と合わせて総合的に判断する必要がある。
ここでは、こうした課題を次の5つの観点で整理分類する。これらの課題については、今後の最適化計画やシステム設計の中で引き続き詳細な検討が必要である。
今後、業務・システムの最適化を検討する上では、業務プロセスの見直しが必要である。現行のシステムにとらわれることなく、業務の流れや情報の流れ等を整理・分析し、あるべき業務プロセスを導き出すことが重要である。
オープン環境で情報資産の共有やシステム構築の効率化を図るためには、データ定義の標準化を促進することが望ましい。具体的には、各業務のデータ項目やシステム間連携のインタフェース仕様を整理した上で、データ項目定義及び連携インタフェースの標準化を検討することが必要となる。
現行システムにおいては、即時処理のほかに準即時処理や一括処理等が存在し、データ量、処理件数、処理の緊急度に応じた使い分けを行っている。業務の見直しに当たっては、バッチ処理を含め、新業務における最適な処理方式について検討を行う必要がある。
本システムでは厳しい性能要件を満足するために、警察庁独自仕様のDBMSを採用することにより、照会・更新処理の高速化を実現している。
本システムのオープン化に当たっては、現行の処理性能を実現できるか、十分な検証が必要となる。
オープン系プラットフォームでシステムを構築する場合、処理性能は同時に処理する業務の組合せやトランザクション特性に大きく依存する。性能設計のためには、各業務の処理フローを詳細化し機能単位で分類整理した上で、処理負荷を見積もることが重要である。また、設計値の検証を目的としたプロトタイプシステムの構築も検討する必要がある。
前述のとおり、本システムは24時間無停止運転のシステムであり、高度な可用性が要求される。
オープン系プラットフォームで可用性を確保するためには、CPUやディスク、ファンといった各種装置・部品の冗長化構成をはじめとして、複数系統による電源確保等の可用性向上策を十分に検討する必要がある。
前述のとおり、本システムは取り扱う情報の特性から高度な機密性が要求される。機密性確保のための技術的アプローチとして、バイオメトリクス認証等をはじめ、最新の技術動向を踏まえた検討が必要である。
現在行っている他システム間連携について、本システムをオープン化した際の連携方式をはじめ、ファイルレイアウトや文字コード変換等、影響範囲の確認と対応策の検討が必要となる。
メインフレームシステムで最適化されたプログラムのオープン化手法については、主にリホスト[6]、リライト[7]、リビルド[8]の3つがある。
表 10 主なオープン化手法と一般的な特徴
手法 |
リホスト |
リライト |
リビルド |
システム構成の見直し(複雑さの改善、資産整理) |
現状と変らない |
見直しが 可能 |
大幅な見直しが可能 |
新サービスへの対応、他業務との連携(統合DB(データの一元化)、連携基盤の構築)) |
現状と変らない |
見直しが 可能 |
大幅な見直しが可能 |
法改正への対応 |
現状と変らない |
見直しが 可能 |
大幅な見直しが可能 |
経費(移行、開発経費) |
小 |
中 |
大 |
経費(運用経費(ハード、ソフト、運用保守委託) |
削減が可能 |
||
開発期間 |
小 |
中 |
大 |
運用体制(運用課、システム利用課) |
見直しが可能 |
||
業務改善(あるいは現行業務変更度など) |
現状と変らない |
見直しが可能 |
|
セキュリティの向上 |
検討が必要 |
||
SE問題 |
ある程度解決される |
解決される |
|
性能(信頼性、安定性など) |
検討が必要 |
このほか、メインフレームを存続させたままオープン環境での利用を可能とするエミュレーションやラッピング等の手法もある。
オープン化検討に当たっては、それぞれの手法の特徴やメリット・デメリットを十分に検討した上で、慎重に手法を選択する必要がある。
一般的に、長年利用してきた既存アプリケーションは内在する不具合の割合が少なく、動作信頼性が高いとされている。
手法の選択に当たっては、こうした傾向も踏まえた上で、これまで蓄積してきた既存資産の有効活用についても検討することが重要である[9]。
新システムへの移行に当たっては、データ移行についても検討する必要がある。
データ移行の方式としては、デ-タ特性(データ量や更新頻度)、移行期間等を勘案し、最適な移行方式を決定する必要がある。
データ量が非常に多い場合、データ移行に相当の期間が必要となるが、移行期間中に更新が発生した場合、更新内容を移行データとして反映させる必要がある。したがって、新旧システムでの並行運用についても検討が必要となる。
また、メーカ独自方式で保存されている画像データについては、業務特性を踏まえた上で慎重に取扱いを検討する必要がある。
新旧システムの並行稼動期間については、ハードウェア機器の設置スペースを二重に確保する必要がある。他システムのリプレース計画等にも十分配慮の上、情報処理センター内の機器設置計画を策定しなければならない。
また、本システムを利用する端末側にも新旧2つのシステムのインタフェースが必要となる。並行稼動環境の正系副系の取り決めや利用端末の制限等、並行稼動期間中の運用ルールとともに検討する必要がある。
オープン化によりハードウェアのコンポーネント数が増加し、それに伴って障害監視等の運用管理業務が煩雑となる可能性がある。
そこで、システムを統合して運用管理を行う仕組みが必要となる。統合運用管理ソフトの導入により、プラットフォームを意識しない運用管理の実現は可能であるが、効率的な運用管理を実現するためには、運用要件を整理した上で運用設計に反映させることが必要となる。
業務の新体系への移行やシステムの新プラットフォームへの移行により、運用面においては大幅な変更が発生する。
したがって運用体制を早期に整備し、運用に携わる警察庁職員の教育訓練を十分に行うことが必要となる。
一部オープン化案を採用した場合、メインフレームの保守運用に従事するCOBOL技術者と、新オープン系システムの保守運用に従事するJAVA等の技術者が混在する体制となる。(完全オープン化案の場合でも過渡期は同様である。)
技術体系が大きく異なる2系統のシステムの保守運用に当たっては、経費の増大だけでなく、開発効率の低下や品質の劣化が懸念される。このような事態が生じないよう、保守運用体制の確保や開発標準の確立等について、慎重に検討を行う必要がある。
本システムでは業務の重要性により、可用性及び完全性の確保について検討が必要である。
解決策の一つとして、バックアップセンターの設置が考えられるが、その検討に当たっては以下のような課題がある。
・ バックアップセンターに整備するハードウェア機器の手配
・ 情報処理センターとバックアップセンター間の高速伝送回線の整備
・ バックアップセンターの維持経費、運用要員の確保
オープン化の検討及び推進に当たっては、専門性の高い知識を要する分野が存在する。こうした分野については、外部の専門家を積極的に活用し、効率的かつ効果的に計画を推進することが望ましい。
オープン化の推進に当たっては、「性能の確保」「可用性の確保」「機密性の確保」といった本システムの特徴に十分配慮した上で、可能な限り公平性及び透明性の向上を意識した入札による調達を行うことが望ましい。
情報処理センターに設置されているメインフレームをオープン化するに当たり、前項「2 オープン化に関する課題」の解決を図る必要がある。
また、「国民の安全・安心の確保」の観点から、警察庁並びに都道府県警察の業務の高度化についての検討が実施及び計画されていることも考慮する必要がある。
したがって、今後策定される「最適化計画」においては、情報処理センターのメインフレームのオープン化のみならず、より高度な警察の業務の実現も考慮された「効率的」且つ「効果的」なシステムの実現について検討されることが重要である。
[1] 官公庁及び企業の基幹業務システムなどに用いられる汎用大型コンピュータ。電源やCPU、記憶装置をはじめとするほとんどの部品が多重化されており、並列処理による処理性能の向上と耐障害性の向上が図られている。
[2] 本調査では、パソコン・サーバやUNIXサーバを総称してオープン系サーバとした。
[3] ネットワーク関連費用(情報処理センター内LAN機器、配線等の費用)、運用人件費については本調査の対象外とした。
[4] 業務に使用される複数のコンピュータシステムを有機的に連携させ、データやプロセスの効率的な統合を図る一連の技術やソフトウェアの総称。組織内のシステム統合や電子商取引を行うためのシステム間連携の手段として利用される。
[5] 開発用の機器及びソフトウェア並びに保守料等については除外した。
[6] プログラムソースをオープンCOBOL等でリコンパイルし、オープン環境に移植する手法。単純なオープン化であり、システム機能や運用管理体制は変わらない。
[7] リホストに加えて、一部ユーザインタフェースに関る部分をJava等のオープン系標準言語で書き換える手法。Java等のオープン系標準言語の採用により、技術者の確保も容易でメンテナンス性の向上が期待できる。
[8] 既存システムの機能やアーキテクチャを分析し、全面的にオープン系システムに最適化して再構築する手法。新技術の採用やアーキテクチャの最適化により、システムの柔軟性が大きくなる。
[9] 本システムでは、リホストに関して平成16年度に一部検討を実施した。