[オピニオン from CIO賢人倶楽部]

2020年8月11日(火)CIO賢人倶楽部

リスト

再起した特許庁システム刷新プロジェクト

　「55億円無駄に、特許庁の失敗」──2012年12月、日経コンピュータがこう報じた。遡ること8年前の2004年、特許庁は当時の政府が打ち出した「業務・システム 最適化計画」に沿って、特許審査や原本管理といった基幹系システムの全面刷新に乗り出した。

　だが、プロジェクトは要求定義の段階から進捗が滞り、2012年1月に外部監査機関である技術検証委員会が「開発終了時期が見通せない」とする報告書を公開するに至った。これを根拠に当時の枝野幸男経済産業大臣がプロジェクトの中止を正式に表明。実質55億円を投資したプロジェクトは破綻したのである。

　しかしながら、知財戦略の根幹でもある特許庁の基幹システム刷新を放置したままにはできない。当時の技術検証委員の1人であり、後に日本初の政府CIO（内閣官房政府情報化統括責任者）に就いた遠藤紘一氏は、リコーのCIOを務めた経験などから特許庁のプロジェクト失敗の原因を分析。プロジェクトをマネジメントするための5つの指針を組み入れた『改定最適化計画』を2013年に公表し、特許庁はこれを基本としてプロジェクトを再スタートさせた。その5つの指針とはこうである。

①システム開発方式の見直しによる難易度の大幅な低減とリスクの最小化
②プロジェクト推進、監理体制の強化
③業務等についての徹底的な分析
④調達手順の改善
⑤外部監査体制の確立による客観性の確保

　実は、筆者は⑤に基づいて選任された技術検証委員の1人であり、委員長の大山永昭先生、小尾高史先生（共に東京工業大学）に加えて民間出身の委員としては他に菊川裕幸氏（JFEシステムズを経て現在は日本情報システムユーザー協会専務理事）、石野普之氏（リコーITソリューションズ）が選任されている。

　民間出身者3人に共通する考え方は「ベンダーなど外部に依存するのではなく、経営者やシステム部門がイニシアティブを持ってプロジェクトを推進すること」である。これは特許庁の最初のプロジェクトに欠けていた最も大きな課題であり、ことあるごとにギャップを埋めるべく検証委員会でのレベル合わせを図った。

　それもあって、①に基づく「特許庁アーキテクチャ標準仕様」作りから始まった新しいプロジェクトは、本丸の基幹システムの要求・要件定義が順調に進み、現在では順次、システム開発とリリースが行われていて、プロジェクト完遂への道筋ができたと言える状況である。そこで、ここでは技術検証委員の立場で見た成功要因、また特許庁のような官庁における大規模プロジェクトの課題について考察したい。併せてコロナ禍で明らかになった行政システムの問題にも言及する。

成功要因1：プロジェクトマネジメント

　2013年の『改定最適化計画』策定から7年以上が経過し、その間、特許庁長官は6名が変わった。それでも当初目指した目的や目標、目指すシステムの姿、最適化のロードマップはぶれていない。年4回程度の有識者レビュー（技術検証委員会）を実施し、また庁内でのいわゆるステアリングコミッティを運営して、幹部と業務部門、システム部門間で目指す姿の共有・確認とフェーズ毎の課題解決を行ってきたのである。

　プロジェクトの規模が大きくなれば期間も長くなるため、3年から5年、あるいはそれ以上の中計レベルでの推進が必要である。そうなると人が変わるので、最初は大きな目標を掲げるものの尻つぼみで終わるプロジェクトが少なくない。特許庁の新プロジェクトではこの問題を排除した。一般企業で言えば社長と業務部門のトップを巻き込み、当初掲げた目的、目標と現状のギャップからテスト結果を踏まえた立ち上げのリスクまでをしっかりと共有し、庁内が一丸となって取り組んできた。それを見ながら筆者は自分自身の活動を振り返り、あらためて襟を正したほどである。

　「経営者がITを理解しない」は、CIOやIT部門の方からよく聞く言葉だが、ではIT部門は経営戦略や業務課題をどれだけ理解しているのか？ 経営者とIT専門家の会議体では、どちらかが（あるいはどちらもが）歩み寄らないと会話はかみ合わない。常に経営者目線、ユーザー目線での資料の提示や説明が欠かせない。実のところ特許庁は現業部門とIT部門の人材ローテーションが頻繁に行われる。これが奏功している面もあるが、意思疎通、情報共有の大事さは学ぶべきである。

成功要因2：システムアーキテクチャの刷新

　旧システムは十数年をかけて業務ごとに個別に、その時々の技術で構築してきた。よく言われる、”増改築を繰り返した古い旅館”のようなシステムそのものであり、何をするにも時間と費用がかかる問題が生じていた。新プロジェクトでは、業務要件定義と並行して「アーキテクチャ標準」を策定した。狙いは、環境変化への臨機応変な対応を可能にする、個々のプロジェクト失敗リスクを低減させる、先行プロジェクトで得た技術的ノウハウを後続プロジェクトに活かす、ベンダーロックインを避ける、などである。

　アーキテクチャ標準は、大きく次の3つを基本とした。

●SOA（サービス指向アーキテクチャ）により業務アプリケーション同士を疎結合とする（図1）
●個別システムの基盤機能とデータベースを分離。その上で共通データベースに集約する
●BPMN（Business Process Model and Notation）による業務要件定義からシームレスな開発を行うため、BPMSツールを標準とする

図1：業務アプリケーションの疎結合化のイメージ（出典：特許庁「特許庁アーキテクチャ策定指針」2014年2月28日発表）
拡大画像表示

　SOAは、筆者の所属先であるカシオ計算機が標準として取り入れていたため、特許庁のメンバーとカシオのスタッフが何度も会合を重ね、導入における課題を潰し込んでいった。また、大規模導入には敷居が高いと思われたBPMNやBPMS（Business Process Management System）も、業務要件に応じて汎用的に適用できるツールを選択したことなどから、しっかりと実装までつなげている。

　褒めすぎかもしれないが、特許庁のIT部門は新しいシステム技術や構造をグローバル標準から学び、しっかりと自らのシステムに取り入れているのだ。再始動させたプロジェクトだけに“背水の陣”であり、同時に日本の技術を束ねる特許庁だからできたとも言えるが、多くのIT部門にとって、お手本となり得る活動である。特に「技術の目利き」ができることは、大規模システムの刷新には重要だと思う。

●Next：BPMNがもたらした業務の可視化、骨太方針2020に思うこと