情報システムアーキテクチャの観点からの情報システムに係る政府調達

情報システムに係る政府調達の課題
－情報システムアーキテクチャの観点からの考察－
産業技術大学院大学
アブストラクト:
南波幸雄
合理的な調達を目的とした「情報システムに係る政府調達の基本指針」が 2007 年 7 月 1
日より適用された. この指針は, 情報システムの相互運用性の確保, 業務処理や使用のブラックボックス化
リスクの排除, ベンダーロックインの回避などを目指して, 分離調達することを規定している. しかし現実
的に分離調達を実行するためには調達側の強力なコーディネーション力が求められる. そのため現状を考え
ると, 各種の制約による体制的な課題およびアーキテクチャ的な課題が残る. 本論文では, これらの制約に
よる課題を明確にし, それを実現するための情報システムとしてのアーキテクチャについて考察する. その
うえで CIO の役割も含めて, 本来の目的を実現するための今後の方向性を提案する.
キーワード: 政府調達, 基本指針, 情報システムアーキテクチャ, 相互運用性
はじめに
1
「情報システムに係る政府調達の基本指針 (以下, 調達指針)[1]」が各府省情報化統括責任者（CIO）連絡
会議決定として 2007 年 3 月 1 日付けで決定され, 同年 7 月 1 日より適用開始された. この指針は, 行政にお
ける「情報システムの調達は, 便利で効率的な電子行政を実現するための重要な手続き」と位置付けている.
その上で, 「各府省における情報システム調達について, 競争促進等によりコスト低減や透明性の確保を図
るための統一的なルールをさだめるもの」としている. そのために, 官・民間, 国・地方間の情報システムの
相互運用性の確保と, 政府調達にあたっての業務処理や技術仕様のブラックボックス化リスクの排除, ベン
ダーロックインの回避, 情報システム間の相互運用性を最小のコストで可能とする戦略的な調達を目指して
いる.
調達指針は, 予定価格が 1 億 3,000 万円(80 万 SDR)以上と見込まれるシステムを対象として, 調達計画書の
作成・公表を義務付け, 調達仕様書の明確化などを求めている. その上で大規模システム(設計・開発が 5 億
円以上のシステム)については, 一括調達ではなく, 原則として分離して調達することを規定している.
分離調達により, 現在大手事業者の寡占状態にある政府の情報システム調達を, 技術力のある中小規模事
業者の参入障壁を低くすることである. それにより事業者間の競争を促し, 調達コストの低減とシステムの
技術水準の向上を期待している. それに加えて受注事業者間の受け持つシステムの独立性を高くし, 領域間
でのインタフェースを明確にすることにより, システムのブラックボックス化リスクの低減と柔軟性の向上
も併せて狙っている.
しかしこの様な施策を決定し適用するだけで, 実効のある運用ができるのであろうか. また実行するため
には, どのような条件が必要なのであろうか.
本報告ではまず, 調達指針と, その関連指針の「業務・システム最適化指針」の概要を示す. そして分離調
達を実行するための制度的な課題と情報システムアーキテクチャに係る課題について述べる. その上で課題
を克服するために今後どのような事をしていかなければならないかを考察する. またそれとともに, 調達側
1
の頂点に立たねばならない CIO とそれを支える CIO 補佐官および CIO スタッフの役割について考察し, 今
後の方向性を提案するものである.
政府調達の基本指針と最適化計画と業務・システム最適化指針
2
2.1 情報システムに係る政府調達の基本指針
調達指針の全般的において, 情報システムに係る工程を「情報システム化計画の策定」から「保守」まで
ウォーターフォールモデルを前提として 8 つの工程として定義している. 次に調達プロセスとして, 「企画」,
「入札」, 「契約」, 「実作業」, 「検収」を必要な手続きとしている. その上で各府省の管理体制を定め, 内
閣官房および総務省による調整等を規定し, 対象機関として CIO 連絡会議を構成する 19 の府省庁を定めて
いる.
調達プロセスの企画で対象システムについて
「調達計画書」の作成を義務付けている. 調達計
従来の構造
指針の示す構造
発注者
発注者
画書は最適化対象業務・システムの構築, 最適化
工程管理
支援事業者
対象外の新規の情報システムの構築, 最適化対象
円以上のシステムに対しては, 従来の元請けへの
一次下請
一次下請
一括調達でなく, 図 1 で示すような構造での分離
調達を求めている.
２次下請
分離調達においては, 原則として「全業務で横
２次下請
３次
２次下請
共
通
基
盤
事
業
者
個
別
機
能
事
業
者
ハードウェア等納入事業者
元請
外の大規模改修を対象としている. その中で 5 億
運
用
事
業
者
保
守
事
業
者
３次
断的に共通して使用される機能をその他の個別業
務のみに必要としている機能とに分類」し, 全社
図1. 分離調達の構造
を共通基盤システム, 後者を個別機能システムとして構築する. このような構造にすることにより, 「将来の
制度改正などの変更に, 個別機能システムの修正・追加等の必要最小限の対応で済むように, 柔軟性および
拡張性を確保」できるようにすることを構想している.
2.2 業務・システム最適化指針
調達指針が出る前の, 2006 年 3 月に「業務・システム最適化指針(ガイドライン)[2]」が制定された. 最適化
指針は, 「エンタープライズ・アーキテクチャ(EA)を基本とした統一的手法を用いて, 最適化すべき業務・
システムの対象範囲やその現状及び将来のあるべき姿, 最適化のための取り組みの内容や手順, 数値による
最適化の効果を明確化したもの」である. 言い換えれば, 政府システムの EA を規定した, 「業務・システム
最適化計画(以下, 最適化計画) [3]」で示されたアーキテクチャのシステムを具体的に構築するための指針で
ある.
最適化計画は, 米国政府 CIO 協議会が作成した, EA:Enterprise Architcture を下敷きにして, IT アソシエイト
協議会が制定したものである. 米国政府の EA はその基本的な文献[4] [5]などによれば, 政府システムの相互
運用性を向上させるため, エンタプライズ(Enterprise)レベルのアーキテクチャを構想して, その中で個別の
システムを構築していくことを基本にしている. EA を構想するためには, エンタプライズを定義しなければ
ならない. 特に最適化というときは, どの範囲で最適化するかを明確にしないと, 最適化の結果が異なって
くる.
最適化指針は, 業務・システム最適化のための, 業務・システム管理手法, アーキテクチャの分類体系と標
2
準記述様式, 最適化計画の策定手順などを定めている「業務・システム最適化計画策定指針(以下,最適化策定
指針) [6]」に則り, 最適化計画作成するための, 最適化工程, 推進体制, 実施にあたってのプロセスなどを詳
細に規定している.
2.3 政府調達関連規定の関係
以上述べた指針や計画の他にも, 政府調達に関連する法律, 規定, 指針(ガイドライン)などは数多くある.
これらの各規定類の内容は複雑に関連し合っているので, これらの関係を実体関連図(ERD)で表して図 2 で
表す. 図 2 において各枠は実体, 矢印は実体間の関連, 矢印終端の三叉は多重度を表す.
図よりも EA としてのアーキテクチャに関しては, 最適化計画が元になっている. そして「今後の行政改革
の方針[7]」に基づき業務・システムの最適化を政府全体で整合性を持って推進するために, 最適化策定指針
に最適化実施と評価に関する指針を加えたものが最適化指針となる. それ故, 調達指針の対象となる情報シ
ステムは, 最適化計画で示されている EA を志向しなければならないことになる.
これらの EA の流れと, IT 戦略本部を中心とする e ジャパン戦略により設定された重点計画により, 具体的
な目標が与えられている「世界一便利で効率的な電子行政」を目指す動き([8], [9], [10], [11])がある. それに,
海外との「政府調達に関する協定[12]」により求められる政府調達の目標が一体となって, 政府府省の情報
システム調達に関連している.
政府調達の基本指針に関する調達側としての課題
3
調達指針において意図されている分離調達を実現するためには, 調達側としての体制と能力が必要になる.
本来情報システムの調達にあたって, 調達側が最低限持たなければならない能力は, 各事業者が設計・構築
を始められる水準の調達仕様書(入札仕様書)を作成することである. それに加えて分離調達するために, ま
ずシステム全体の仕様を作成し, それに基づいて共用データを定義とインタフェース設計を含む分離設計を
することが必要になる. これができて初めて個別仕様を作成することができる. しかし現実的に各府省庁の
調達体制については, 制度的な課題と, 情報システムアーキテクチャの面から課題がある.
3.1 調達側の体制
制度的な課題の一つとして, 調達側の人材の問題がある. この点については, 「行政機関における IT 人材
の育成・確保指針(以下, IT 人材指針)[13]」において, 各府省の全体管理組織(PMO)と個別管理組織(PJMO) の
IT 人材の実態が以下のように分析されている.
-
構成員には CIO 補佐官以外の外部人材はほとんどいない
-
過去に IT 関係の職歴・実績を有する者は約 3 割
-
IT 関係の研修受講歴を有する者は約 2 割
-
IT 関係の資格を保有する者は約 1 割
-
平均在職期間は 2~3 年が約 8 割
その上 IT 業務に特化したキャリアパスについては, 100%の回答が設定されていないと答えている.
これらの問題の原因の第一は, 職員の定期ローテーション制度であろう. 政府本省の職員は, 原則として
2 年～3 年周期で人事ローテーションをする. これは一部の府省庁の技官職を除いて, ジェネラリストとして
の政府職員を養成することに基づいている. しかしこのために, IT を担当する部署の職員も定期異動をまぬ
がれず, やっと業務に慣れてきたところで異動になってしまうことになり, 専門家の育成が難しいことにな
3
4
移行
受入テスト
結合・統合
テストなど
設計・開発
調達仕様書の作
成
仕様書(要件定義
書)の作成
最適化計画の作
成
将来体系の
作成
業務・システム見
直し方針の作成
現行体系の
作成
最適化工程
制定する
相当する
相当する
相当する
相当する
保守
運用
移行
受入テスト
検収
契約
実作業
結合・統合
テストなど
入札
設計・開発
要件定義など
調整する
所有する
PMO
CIO補佐官
CIO
情報化
推進委員会
基づく
政府調達に関する
協定
最適化対象外の新
規構築(>80万SDR)
最適化対象外の大
規模改修(>80万
SDR)
対象となる情報システム
物品に係る政府
調達手続きについ
て(運用指針)
80万SDR以上を
80万SDR以上を
対象にする
対象にする
最適化対象業務・
システムの構築
担当府庁等
連携・調整する
電子政府推進
管理室
2010年度までの担当する
数値目標を定める
府省共通
業務システム
設置を規定
基づく
電子政府
推進計画
基づく
オンライン利
用促進のため
の行動計画
各府庁推進体制
情シスに関する政
府調達の基本指針
(取扱いについて)
会計担当課室
調達担当課室
登録する対象とする
調達計画書
府省管理体制
府省全体管理
組織
基づく
設置を規定
電子政府
構築計画
業務・システム
最適化計画
図２．各種規定・指針などの関係
情報システムに
係る政府調達事例
データベース
企画
IS化計画策定
規定する
調達プロセス
規定する
規定する
個別管理
組織
(PJMO)
基づく
情報システムに係
る政府調達の
基本指針
府省全体
管理組織
(PMO)
最適化推進体制
政府全体
管理組織
(GPMO)
重点計画
2006/2007
具体化する
IT新改革戦略規定する
新戦略等
推進する
制定する
e-Japan戦略
Ⅱ
e-Japan戦略
e-Japan戦略
ISに係る工程
相当する
今後の行政改革
の方針
相当する
基く
業務システム
最適化指針
(ガイドライン)
実施と評価の
指針を加える
業務システム
最適化計画策定
指針(ガイドライン)
管理手法を示す
フレームワーク
具体的に規定する
含む
コンピュータ製品
およびサービス
一般競争入札を
行うことを規定
会計法
規定する
日本の公共部門の
コンピュータ製品及
びサービスの調達
に関する措置
る. また情報システム関連業務は, 各府省庁の主要な業務でないため, キャリアパスにおいても最高位が課
長の下位の室長レベルであるため, この分野に精通しようとする動機にも欠ける.
この点に関してはIT人材指針においても, 求められる人材像の明確化をしたうえで, 研修の充実, 民間も
含めての人事交流の推進などにより内部のIT人材の育成を図るべきと言っている. それと共に外部人材の確
保方策を明確化するよう求めている.
人材の問題に関しては, IT 関連業務の総責任者としての CIO に関しても課題がある. 政府省庁における
CIO は情報システムの専門家ではなく, 省内のまとめ役である官房長や官房審議官クラスが担当している.
このような状態は民間企業における調整型 CIO と同様の役割である. 現行の政府省庁の人事システムが継続
することを前提に考えると, CIO は省内の予算と人事を調整する調整型にならざるをえない. 調整型の CIO
が機能するための条件としては, 本来の CIO としてカバーしなければならない機能の中で, 欠けている部分
を他の人材または機能で補うことが必要である. その一つとして情報システムに係る専門機能を補うために,
外部・民間から複数の CIO 補佐官を補任している. これらの CIO スタッフを有効に活用できる仕組みがとれ
るかが課題になる. その上 CIO もまた人事ローテーションの中に入っているため, 2 年程度で移動してしまう.
このような人事環境下で, 誰がまたはどのような仕組みで, 府省全体としての情報システムの一貫性・整合
性を担保するかも課題である.
3.2 制度的な課題: 単年度予算制度と公開入札制度
次に単年度予算と入札制度に係る課題である. 予算の策定サイクルは, 図 3 で示すように, 省内での調整
から, 財務省との折衝, 概算要求を経て, 国会による予算の決定までで 1 年以上の時間がかかる. このサイク
ルから外れると, 例えば夏頃に企画をしたものは, 当然次年度には間に合わず, 次々年度の予算になってし
まう.
また単年度予算制度を前提とすると,
通常 4 月からの年度に調達した案件は
予算年度(前年度)
～3
4
務負担行為が適用できるが, これも複
6
7
8
9
重点事項
局Î会計課
12
1
2
3
財務省折衝
概算要求
各省 Î財務省
国会審議
次年度
要求案
う事であって, 各年度内の事項はその
ようにいろいろな制約条件もあるため,
11
(会計課ヒアリング)
調整
概算要求案
細目詰め
数年度にわたる要求が認められるとい
年度での受け入れが求められる. この
10
局内検討
年度内(3 月末日)の納品が原則になる.
年度をまたがる案件については国庫債
5
実行年度(当年度 )
4
5
6
7
8
9
10
11
12
1
2
3
4～
入札準備
入札期間
構築期間
なかなか広がらないのが現状である.
瑕疵対応
納品
次に入札制度については, 期間の問
題と入札評価の問題がある. 期間の問
題とは, 運用指針により,「調達仕様書
図3. 政府調達の予算・入札サイクル(例 )
については, 意見招請の期間は少なくとも 20 日関確保することとされており, 入札公告の期間は少なくとも
50 日関確保」とされているが, このスケジュールでは短過ぎ, 実質的に入札制限になっている可能性がある
と言って, より長期間確保することを勧めている. しかし, 現実に 70 日よりも長くとることになるとこれだ
けで 3 か月近くの時間を要する. その上, ここで決定された予算を執行するための公開入札準備として, RFP
5
の作成や必要に応じての RFI のやり取りなども含めると, この期間はさらに長くなり 5 カ月程度要すること
になる. しかも単年度予算であるため, 3 月末には検収しなければならないので, 実質的な設計・構築期間は
7~8 カ月程度しかとれないことになる.
一般的に同一の規模のシステムを構築する場合と, 構築期間において人月のトレードオフは成立しない.
構築期間が短くなればなるほど構築コストが高くなる. IPA[14]によると, 月あたりの要員数とファンクショ
ンポイントあたりの生産性との関係として, 経験値より下記の式が成り立つ.
FP生産性＝0.203/(月あたりの要員数)0.39
P
P
この式を用いて, 6 億円規模のプロジェクトを 1 年かけて構築するのと, 7 か月で構築するのを比較する. 1
人月を仮に 100 万円とすると, 6 億円は 600 人月に相当する. これを 12 か月かけて構築する場合に比べて 7
カ月及び 8 カ月で構築する場合には, FP 生産性はそれぞれ約 81%と 85％になる. 逆にいえば同一のレベルの
システムを構築するのに, 1 年に比べて 7 か月及び 8 カ月になるとそれぞれ 23%と 17％高いものになる.
単年度予算制と公開入札制を前提とすると, 受注側の事業者にとっても大きな問題が出てくる. 第一には
年度の前半は入札作業しかなく, 実質的な設計・構築作業は後半に集中することになる. これは要員計画の
大きな偏りとなり, 後半の人員を確保するためには, 前半は遊ばせておくことも覚悟して抱えておかなけれ
ばならない. これも見えないコストアップ要因になりうる. この点を解決するためには, 事業者側で公共分
野以外の分野でも業務を展開し, 全社レベルで負荷の平準化ができなければならない. しかしこのようなこ
とができる事業者が自ずと大企業に限定されてしまい, ますます中小事業者が参入できない構造になってし
まう.
入札評価の問題については, いわゆる 1 円入札のような事例をどのように防止するかである. この点に関
しては, 総務省も単なる価格方式の入札ではなく, 価格点と技術点とを総合的に評価する総合評価方式を薦
めている. 総合評価方式は単純入札に比べると, 技術点を評価できる分優れているが, 極端な安値受注の場
合には, 価格点の寄与が大きくなり落札してしまう. またいずれの入札方式も, 落札価格ブラインド方式の
ため, どんなに良い提案でも, 落札予定価格より 1 円でも超過した場合には評価対象ではなくなる問題もあ
る. その上すべての応札が予定価格を上回った場合は, 入札不調になり再入札になる. こうなるとまた時間
を浪費することになる.
また競争入札制は, 原理的には悪いやり方ではないが, 現行の予定価格を公開しない方法だと, どんなに
技術的によい提案であっても, 予定価格を超えた時点で落ちてします. またこの際の予定価格を積算するの
が, 情報システムとは無関係の会計部門の仕事であるのも問題である. 未知の内容に関しては, 企画コンペ
方式のように, 最初に価格を提示し上で内容を競わせるものもあるが, 一般のシステム構築の入札には適用
されていない.
3.3 情報システムアーキテクチャとしての課題
アーキテクチャ的な課題は, より本質的な内容を含んでいる. 分離調達するためには, 対象になる情報シ
ステムが, 分離単位としてのモジュール単位で独立した構造になっていなければならない. その為には, ま
ず対象領域の情報システムの全体設計を行い, これを合理的な根拠で共通機能と部分機能に分離し, 両者間
で共通するデータのデータモデルを設計し, インタフェースを明確に規定することが必要になる. この作業
を行うためには, アーキテクチャに関しての深い知識と経験を必要とする. またアーキテクチャをもとに分
離設計をする際には, 当該情報システムだけでなく, それ以外の情報システムとの相互運用性や整合性も含
めて考えなければならない.
6
共通基盤と個別機能とを分離するためには, 以上の作業が必須であり, そのためにはこの部分の設計だけ
で独立したプロセスになる. さもなければ共通基盤を受け持つ事業者が, 共通データとインタフェースの設
計をし, それを前提に個別機能の使用を決めることが必要になる. そのため分離調達にした場合, 基盤業者
は基本的にすぐに作業を開始することは可能である. しかし個別事業者は, 基盤事業者の設計がある程度完
成し, 全体としての設計方針が決まらなければ, 設計作業に入ることはできない. もしそれを待たずに設計
作業に入ったとしたら, 大幅な手戻りを覚悟しなければならない. もともと少ない日程を考えると, 待って
いることはできないので, 早期に開発を始めざるを得ないが, これは手戻りの危険性を内包する. それ故,
この状態で収益性を確保するためには, ある程度の保険をかけざるを得なく, これもコストアップ要因にな
りうる.
またEAの実現にも問題がある. 共通基盤とは調達単位の中での概念であって, エンタプライズの定義の中
での共通基盤ではない. そのためこのような調達を続けている限り, 調達範囲のシステムの最適化はできる
かもしれないが, EAで目指しているはずの定義したエンタプライズの中での最適化にはつながりえない.
以上の観点のほかにもアーキテクチャ的な課題がある. 政府システムの宿命として, 法律や制度を反映し
なければならない. これには2つの課題が出てくる. 第1に通常のビジネスプロセスに対しては, IS側から改
善提案して業務改革に導くパスがある. しかし政治主導の世界では, 決まったことは忠実に反映しなければ
ならないため例外ルールの山になる可能性がある. 第2にスケジュールが実際的でない点である. 法律は国
会期間中に審議され, 採決の結果成立する. 成立時に施行時期も一緒に決定されるが, このときに構築期間
のフィージビリティはほとんど考慮されない. このような場合は成立してからでは間に合わないので, 何ら
かの形で前年度から検討を始め, 実施時期の間に合わせることになる. こうなると分離調達だけでなく, 構
成で透明性のある調達自体が, 実質的に実現できないことになる.
4
考察
4.1 人材の問題
IT人材の育成については, 各種の教育プログラムの提供など, 研修環境についても徐々に整ってきている.
しかしこれらはローテーションで回ってきた職員に一応の業務専門知識を与えるための教育である. そのた
めIT専門家の育成となると, 人事ローテーションを前提とした現行制度のもとでは難しい. やっと情報シス
テムの業務になれ, 一通りの知識を蓄えたころになると, 定期異動になってしまうからである.
現行の人事制度を前提とすると, キャリアプランに基づいた定期的ローテーションにより, 情報システム
部門と現場部門との間を, 2巡, 3巡をさせて, 情報システムの経験と現場経験とを交互にさせることにより,
両方の知識と経験をもつ人材を養成すべきであろう. しかしその場合にも, 最後の到達地位の問題は残る.
この問題を外部人材に頼る方法はあるが, その場合は責任と権限を与えられるかどうかにかかってくる.
責任と権限を与えるには, 外部人材の内部化が必要であり, そのためには制度改革が必須になる. この点に
関しては, 現在でも他の部署では行われている, 民間との人事交流や, 民間人材の枢要ポストへの登用など
を積極的に展開することが有効であろう.
4.2 分離調達できるための要件
分離調達するためには, 全体を構想し, それを前提としてモジュール分割するための設計が必要である.
そのためには調達側がその能力を持たねばならない. しかし現状では, IT人材指針の分析でも認めているよ
うにそれは期待できない. このギャップを埋めるために, 調達指針においても工程管理支援事業者を置くこ
7
とを認めている.
しかし工程管理支援事業者は, 調達指針によると, 調達者としての立場で支援し「情報システムの設計・
開発段階における, プロジェクト管理, 調達関連業務等の作業や成果物に係る検証等を行う」とある. この立
場は基本的に調達計画書の作成や調達仕様書の作成支援およびスケジュール管理しかできない. そのため基
盤事業者と個別事業者との間に問題が発生したときに主体的に調整できる権限を行使できる立場にない.
逆に工程管理支援者が実質的に調達仕様書を作成したとすると, 情報システム全体の機能構造の設計・開
発の中心的な役割を担い全体としての稼働確認を行うとされている共通基盤事業者との責任分解点が曖昧
になってくる.
4.3 アーキテクチャの課題の克服と EA の実現
Ross[15]は数 1000 社のアンケート調査結果をまとめて, 情報システムのアーキテクチャの発展段階を, そ
の成熟度に応じて以下の 4 つのステージに分類できると述べている.
- ステージ 1: 孤立したアプリケーションの単なる集合体（アプリケーション・サイロ）
- ステージ 2: 企業内の標準技術基盤の確立（技術の標準化）
- ステージ 3: 主要なデータの合理化によるデータ（とプロセス）の統合
- ステージ 4: これらの基盤を前提とする全体的なモジュール性の確立
このステージに現在の府省情報システムを当てはめると, ほとんどのものは第 1 ステージのアプリケーシ
ョン・サイロに属すると考えられる. これは今までの調達が個別システム単位で行われていたため, 受注事
業者は自己の受注単位のなかで, 設計構築してきたことによる.
情報システムを個別システムごとに調達し, その中で「最適化」していたのでは, 永久にサイロ構造のま
まになり, 次のステージに行くことはできない. 次のステージ 2 に移行するには, 組織横断的な見識と権限
が必要になる.
今回の調達指針で求めているのは, ステージ 4 のレベルである. しかしこれは Ross も言っているが, 各ス
テージを飛び越していきなり最後のステージに行くことはできない. なぜならば, 各ステージは全段階のス
テージを前提として成り立っているからである. そのように考えると, 本来の EA の目的としての業務・シス
テム最適化を目指すためには, 独立した個別システム(サイロ)の集合体から, 第 2 ステージを経由して第 3 ス
テージへの移行パスを考えなければならない. そのためにはまずサイロからの脱却が必要になる.
4.4 PMO の役割
本来この種の事項を調整し, 計画・実行するのがプログラムをマネジメントする主管部署としての PMO
の役割である. プログラムマネジメントは, P2M ガイドブック[16]によると「全体使命（Holistic Mission）を
達成するために, 外部環境の変化に対応しながら, 柔軟に組織の遂行能力を適応させる実践力である. この
実践力の役割は, プロジェクト間の関係性や結合を最適化して全体価値を高め, 使命を達成する統合活動に
ある」. プログラムマネジメントは有機的に関係した複数のプロジェクトを, 統合的に管理する永続的な組
織を意味する.
EA のような全体に影響を与え, かつ複数のプロジェクトから構成される活動を, マネジメントするには
中長期的な視野が必要になる. このような時に 5 年から 10 年の期間で, プログラムの一貫性と整合性をどの
ように担保するかが課題になる. 前述したように各府省のスタッフは, 数年で人事ローテーションにより異
動してしまうため, 組織的な永続性をどのように設計できるかが EA 導入の鍵になる.
8
5
政府省庁における CIO 機能に係る考察
以上述べた課題を適切に実行するためにはCIOの果たすべき役割が重要になる. しかし現状のCIOは調整
型のCIOしか実現性がない. そのためCIO機能を有効にするには, 本来CIOとしてカバーしなければならな
い領域を, CIOおよびCIOを補佐するスタッフと一体となったチームとしての活動ができるような体制がと
れているかどうかにかかっている.
必要とされるCIO機能は, 対象とする領域の情報システムのレベル(成熟度)により異なってくる. 南波[17]
は情報システムの発展過程におけるCIOの役割の変化を考察(JASMIN)している. Rossのサイロに相当する段
階では, 必要とする機能は専門家としての見識だけなので, 情報システム部長のレベルで十分である. しか
し次の段階になると, 全社レベルの調整が必要になるので, それだけの見識を持ち, 全社に対して影響力を
もちうることが前提になってくる. このレベルまでは, 現行の調整型CIOと専門家としてのCIO補佐官チー
ムがうまく機能すれば対応できる. しかし第3ステージを目指そうとすると現行体制では難しくなる.
第3ステージはデータモデルの統合化が求められる. 基本的にIT基盤の統合や標準化が対象の第2ステージ
に比べると, アプリケーションレベルまで含めての調整が必要になるために, 全社に対する調整は格段に難
しくなる. そのためには, 単なる調整力だけではすまず, 内容に立ち入って関連部門を説得するための, 業
務精通度と技術的なバックグラウンドも求められる. このステージを担当するCIOは, ICT技術の専門家とし
てのCIO補佐官を中心とするCIOスタッフとより緊密な関係を持ちながら, 業務を遂行することが求められ
る. そのためには専門家の言う事を理解して, 決定できるだけの知識と経験が必要になる. CIOのアドバイザ
ーであるべきCIO補佐官の実際の業務は調達プロセスのアドバイザーである. 現在の身分と権限とでは, CIO
アドバイザーとして実効的に役に立つかどうかは, 受け入れ側の対応と本人の力量に依存する.
CIO補佐官に関して, 防衛省と警察庁
が内部人材を登用している外は, 外部人
材に依存している. 外部人材の登用に関
10
しては, 契約形態, 勤務形態など様々で
8
ある. 図4は政府省庁が外部より登用し
6
ているCIO補佐官の出身母体の種類と,
4
その出身母体が政府機関とビジネス上の
関係を持っているかどうかを, ウェブサ
イトなどの公開資料より調査して示した
2
関係あり
0
ものである. CIO補佐官に任命されると
個人
関係なし
コンサル会社
ベンダー
きは, 当該府省と利益相反がないことが
条件になるため, 直接的に所属府省の業
図4.　CIO補佐官の構成
務を出身母体の会社が請け負うことはで
きない. しかしCIO補佐官の所属府省には関係ない, 他の府省に関係する業務を請け負っているコンサルタ
ント会社やベンダー出身のCIO補佐官が多いのがわかる.
一般的に政府府省システムのライフタイムは 5 年である. それを前提とすると, 構想し, それを設計に反
映し, 予算を獲得して構築する時間を 2~3 年かかる. 府省庁の情報システムサイクルを考えると 2 サイクル
必要になるので, 現在稼働している全システムを入れ替えるには 10 年程度の時間が必要になる. これを実行
するためには, 第 3 ステージに対応できる CIO の育成または CIO チームを組織できるような制度的改革も含
めて対応する時間は, 最大 5 年である. この 5 年で第 3 期の CIO を作り出していくのは, 単に指針で決めれ
9
ば良いというような問題ではなく, 実効的な手段が求められる. そのためには, 法律・制度・人事を含めて総
合的な検討が必要である.
おわりに
6
調達指針を本来の意図に沿って実現しようとするといくつかの課題がある. それらの課題が政府の制度に
基づく場合は, 簡単に変更できないため, 立法措置も含めて検討しなければならない. そのためには関係者
間で議論を広め, 合意形成をして行くことが必要である. 情報システムアーキテクチャに係る課題について
は, 各府省庁において合理的なエンタプライズを定義して, その中で全体のアーキテクチャを構想し, それ
に基づいたシステム分割をしていかなければならない. 現実的にこれら諸点を解決するのは短期的には難し
く, 時間をかけて順次行っていかなければならない.
結局, 調達側としての最低限のコンピテンシーがない
と, どんな制度を作っても有効活用できないおそれがある. 場合によっては, マイナスの効果になる危険性
を内包しているのである.
その上現行の単年度予算制度と競争入札制を前提に, 情報システムの調達を行うことは, 意図に反して調
達コストを上昇させる恐れがある. 入札の準備に時間を長くとると, 設計構築のための期間が短くなり, そ
の結果開発生産性の低下を招くからである。
以上を勘案して, これらの課題を解決し, 今後の方向性をより良くするために, 結論に変えて下記の提案
をする.
-
短期的には, CIOまたはCIO補佐レベルの専門人材について, 現状の制度化では内部から専門家を育
成するのは難しい. そのためCIOとCIOスタッフによるチームとしての機能を充実させることが重要
になる.
-
CIO補佐官については, 有期でまたは民間との人事交流などで外部人材を招聘し, 責任と権限とを与
える. このような形で内部化できる様になるまでは, 現行形態で極力中立系の人材の任用を継続す
る.
-
中堅人材については, 計画的なローテーションを実施し, 情報システムと現場を理解できる人材を育
成する.
-
中長期的には, 米国の政府機関で実施しているように, 官民学連携で人材養成を計画的に行い, 有機
的に民間との人事交流できるような制度を確立し, フレキシブルなキャリアパスを実現する.
-
アーキテクチャの問題に関しては, エンタプライズを各省または局ごとに定義し, その中でエンタプ
ライズ・アーキテクチャを構想する. そしてそれに沿った形で個別の情報システムの設計し調達する
ことが可能なように制度設計を行う.
-
以上をプログラムとしてとらえ, これをマネジメントできるPMOを組織し, 継続的に目的の達成を
図る
-
これらを前提として, 調達指針で求められている分離調達を実施する.
最後に今年度より, 財務省において各府省の予算要求の査定をするにあたり, 外部専門会社に委託して,
FP 法を始めいくつかの手法による要求内容の精査始めた. 今後もこのような作業を継続しデータを蓄積し,
これらのデータと民間事例との比較検証をすることにより, 政府調達の課題が明確になれば, より合理的な
調達が可能になるものと期待している.
10
参考文献
[1] 各府省情報化統括責任者(CIO)連絡会議決定: 「情報システムに係る政府調達の基本指針」2007.03.01.
http://www.soumu.go.jp/s-news/2007/pdf/070301_5_bs2.pdf
[2] 各府省情報化統括責任者（CIO）連絡会議決定: 「業務・システム最適化指針（ガイドライン）」2006.3.31.
http://www.e-gov.go.jp/doc/060331/doc1.pdf
http://www.e-gov.go.jp/doc/060331/doc2.pdf
http://www.e-gov.go.jp/doc/060331/doc3.pdf
http://www.e-gov.go.jp/doc/060331/doc4.pdf
http://www.e-gov.go.jp/doc/060331/doc5.pdf
[3] IT アソシエイト協議会:「業務・システム最適化計画について」2003.
http://www.meti.go.jp/kohosys/press/0004840/2/031225it-asosi-3.pdf
http://www.meti.go.jp/kohosys/press/0004840/2/031225it-asosi-4.pdf
http://www.meti.go.jp/kohosys/press/0004840/2/031225it-asosi-5.pdf
http://www.meti.go.jp/kohosys/press/0004840/2/031225it-asosi-6.pdf
http://www.meti.go.jp/kohosys/press/0004840/2/031225it-asosi-7.pdf
[4] Chief Information Officer Council: A Practical Guide to Federal Enterprise Architecture, 2001.
http://www.gao.gov/special.pubs/eaguide.pdf
[5] Chief Information Officer Council: Federal Enterprise Architecture Framework, 1998.
http://www.cio.gov/Documents/fedarch1.pdf
[6] 各府省情報化統括責任者(CIO)連絡会議決定: 「業務・システム最適化計画策定指針」2004.02.01.
http://www.e-gov.go.jp/doc/guideline2.pdf
[7] 閣議決定: 「今後の行政改革の方針」2006.12.26.
http://www.gyoukaku.go.jp/jimukyoku/houshin.pdf
[8] IT 戦略本部: 「e-Japan 重点計画 2003」2003.8.8.
http://www.kantei.go.jp/jp/singi/it2/kettei/030808honbun.pdf
[9] IT 戦略本部: 「IT 新改革戦略」2006.1.19.
http://www.kantei.go.jp/jp/singi/it2/kettei/060119honbun.pdf
[10] IT 戦略本部: 「重点計画-2006」2006.7.26.
http://www.kantei.go.jp/jp/singi/it2/kettei/060726honbun.pdf
[11] IT 戦略本部: 「重点計画-2007(案)」2007.
http://www.kantei.go.jp/jp/singi/it2/pc/2007keikaku.pdf
[12] 「政府調達に係る協定」
http://www5.cao.go.jp/access/japan/chans/kyoutei.html
[13] 各府省情報化統括責任者(CIO)連絡会議決定: 「行政機関における IT 人材の育成・確保指針」2007.04.13
http://www.e-gov.go.jp/doc/20070424honbun.pdf
[14] IPA. ソフトウェアエンジニアリングセンター: ソフトウェア開発データ白書 2006, 日経 BP 社, 2006.
[15] Ross, J.W.: Creating a Strategic IT Architecture Competency: Learning in Stage, CISR Working Paper No.334,
April 2003.
[16] プロジェクトマネジメント資格認定センター: Ｐ２Ｍガイドブック, 2002.
11
http://www.meti.go.jp/report/downloadfiles/ji04_04_02.pdf
[17] 南波幸雄: 企業情報システムアーキテクチャ発展段階におけるCIOの役割の変化, 経営情報学会2006年
春季全国研究発表大会予稿集, pp. 224-227, 2006.
12

Download Report