企業内技術者も一度は読みたい「デジタルガバメント推進標準ガイドライン」の“勝ちパターン”：政府CIO補佐官が説く「デジタル改革」の具体像（2）

政府のデジタルトランスフォーメーション（DX）を考え、民間企業にも通じる知見を共有する本連載。今回は政府が作成し、ガバナンス強化のために活用している「デジタルガバメント推進標準ガイドライン群」を解説します。

[ITプロセスコンサルタント 細川義洋，＠IT]

プロジェクトごとにバラバラなITプロセスが課題

　読者の皆さまは「デジタルガバメント推進標準ガイドライン」をご存じでしょうか。ITを企画、立案、調達する場面から、開発（あるいは導入、利用）、テスト、検収、運用、保守に至る一連の活動について、そのプロセス（段取り）や規則、役割と責任などを政府が規定したものです。

　ITは建築や製造業とは異なり、段取りが整備されておらず、個々がそれぞれの流儀で進めています。そのため、製品の品質にバラつきが出てしまいます。ある会社が「当然作るべき」と考える設計書を他の会社は知りません。ある人が必須と考えるレビューやテスト項目を他の人は平気で飛ばします。これらが頻繁に起きる結果、バグだらけのシステムやせっかく作ったのに使われないシステムができてしまうのが、現在のITです。

　ITに関するプロセスが世の中全体で、しっかりと定まっていないことを象徴する出来事として以下のような裁判例もあります。

あるシステム開発においてベンダーが納入したシステムに対してユーザーは費用の支払いを拒んだ。理由は、納入されたシステムに不具合が多数残存していることだったが、東京地方裁判所はこれについて、「一般にソフトウェア開発においては、プログラムに一定程度の確率でバグが生ずるのは不可避であって、納入後にデバッグすることを予定せざるを得ないものであるところ、仮に、ユーザー主張の上記画面（不具合の残存する画面）が、本件システムの納品および検収の際に残存していたとしても、ユーザーがこれを指摘すればベンダーにおいて遅滞なく補修を行い得ることは明らかであって、そのような場合をもって納品物に瑕疵（かし）があるとか、まして本件システムが未完成であるなどということはできない」と述べて支払いを命じた。

（東京地方裁判所 平成24年2月29日判決より）

　この判例が示すのは、そもそもIT開発において、何が「仕事の完成」に当たるのかが、まだ世の中には認知されておらず、少なくともユーザーとベンダーが合意したプロセスがないことでしょう。これ以外にも「システムの完成は予定された工程が完了しているかどうかで判断する」「契約の目的に資するものが納められていれば不具合が残っていても完成である」などさまざまな判断基準があります。

　検収というごく限られた部分だけでも、誰もが納得するプロセスが存在しないことを象徴する例ではないかと思います。ましてシステムの要件定義や開発、テストあるいは契約事項も世の中の解釈はいまだにバラバラです。ITは何ができれば完成なのか、完成のためには何が必要なのか、これらに共通認識は存在しません。

政府のITプロセスもバラバラだった

　政府においても、ITの導入に関するプロセスについて共通認識がなく、おのおのが我流で、そして多くはITベンダーの担当者たちの知識に頼りきっていました（今はないとは言い切れませんが）。その結果、重要な不具合を見落としたままリリースしてしまうとか、業務に適していないとして誰も利用しないシステムもかなりあったと聞いています。

　一例を挙げると、企業からの申請を紙で受け付ける業務をオンライン化する際、申請の内容に誤りがあっても申請者が修正する機能を用意せずシステムをリリースしてしまったことがあるそうです。従来、紙で行われていた申請は、たとえ誤りがあってもその場ですぐに修正ができたため、業務マニュアルには修正に関する記載がありませんでした。それを頼りにベンダーが作ったシステムには申請事項の修正機能がなかったのです。通常、データの登録機能があれば、修正や削除も必要だと気付くはずですが、政府側の担当者もそこまで考えが及ばず、ベンダーも業務マニュアルしか見ていなかったので、初歩的なミスを犯してしまったのです。

　政府の職員は多くの場合、2年程度で別の部署に異動します。ITを学ぶには余りに短い時間で、結局、IT開発の現場には常に経験の浅いユーザーしかいないことになるわけです。ITを導入するために、どんな段取りが必要なのか、何をすべきで、何をしてはいけないのか、政府方針や法律との関係はどうなのか、それらを一気に学べというのは、いくら頭脳明晰（めいせき）な国家公務員でも無理があります。

　こうした背景を受け、ITの企画、立案、調達、開発、運用、保守のプロセスや役割、責任、チェック項目などをしっかりと定義し、経験のない役人でもこの通りにやれば必要なITを効率的に導入できて、ITベンダーもこれに準じて作業すれば一定の品質を担保できる文書を作ることになりました。それが「デジタルガバメント推進標準ガイドライン群」というわけです。この文書は「政府CIOポータル」というWebサイトでMicrosoft Word版、PDF版、HTML版が公開されています。

標準ガイドライン群の概要

　このガイドライン群は数多くのガイドを掲載しています。今回紹介した「IT導入のプロセス」に関して述べているのは、「標準ガイドライン」「標準ガイドライン解説書」「標準ガイドライン実践ガイドブック」という3つで、これらがまさにガイドライン群の中心ともいうべき3編です。これらは「CMMI（Capability Maturity Model Integration：能力成熟度モデル統合）」「PMBOK（Project Management Body of Knowledge：プロジェクトマネジメント知識体系ガイド）」「ITIL（Information Technology Infrastructure Library）」といった世界的なナレッジベースも参考に作られています。他方で、これまでに政府で起きたさまざまな失敗や勝ちパターンを参考にしているため、調達手続きなど政府独特のプロセスを除けば、民間企業でも活用できるでしょう。それぞれ簡単ですが概要を説明していきます。

標準ガイドライン

　サービス、業務改革ならびにこれらに伴う政府情報システムの整備および管理に関して、その手続き、手順に関する基本的な方針および事項と政府内の各組織の役割などを定める体系的な政府の共通ルールです。

　約100ページあるため、ここで全てを解説するわけにもいきませんが、一例を挙げると以下のようなことが書かれています。

第5章　要件定義

　PJMOは、「第4章 サービス・業務企画」で企画した内容を踏まえ、政策目的の実現に資する業務と、これを支える情報システムの機能（以下「機能要件」という。）や情報システムが備えるべき機能要件以外の情報システム要件（以下「非機能要件」という。）を明らかにするため、調達に先立ち、次の通り、要件定義を行うものとする。

　要件定義は、プロジェクトの目標を達成する上で、極めて重要な工程であり、要件定義が不十分なときには、計画の遅延又は情報システムの機能・性能が要求水準に満たないものとなる事態等が発生する可能性が高まるため、適切に実施する必要がある。

1　要件定義の準備　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

1)　RFIの実施・・・詳細略

2)　事業者へのヒアリング等の実施・・・詳細略

3)　必要な資料の作成・・・詳細略

2　要件定義　　　　　　　　　　　　　

1)　要件定義書の記載内容

ア　業務要件の定義・・・詳細略

イ　機能要件の定義

　機能要件について、次のA）からF）までに掲げる事項をもって定義する。なお、機能要件は、業務の質の向上、業務の効率化等に対する有効性等を踏まえ、優先度の高い機能から整備する必要があること、また、他の情報システムと連携する場合には相互運用性及びデータ互換性についても併せて記載する必要があることに留意するものとする。なお、クラウドサービス（SaaS）、府省共通システム等が提供する機能を利用する場合には、その利用する機能について記載するものとする。

A)　機能に関する事項

　情報システムにおいて備える機能について、処理内容、入出力情報・方法、入力・出力の関係等を記載する。なお、他の情報システムが類似の機能を持つ場合は、その機能を活用することも検討する。

B)　画面に関する事項・・・詳細略

C)　帳票に関する事項・・・詳細略

D)　ファイルに関する事項・・・詳細略

E)　情報・データに関する事項・・・詳細略

F)　外部インタフェースに関する事項・・・詳細略

（後略）

（参考　標準ガイドライン 要件定義部）

標準ガイドライン解説書

　標準ガイドラインの下位文書として標準ガイドラインの記載の趣旨、目的などを記載した参考文書です。

第5章　要件定義

（中略）

2　要件定義

（略）

1.趣旨

　要件定義で定める業務要件、機能要件、非機能要件は、多くの関係者と共有し、内容を合意する必要があり、後工程の作業を実施する際の元情報としても活用される。

　このため、PJMOは、これら要件を、網羅的かつ詳細に検討した上で、関係者が共有可能な文書として整備する必要がある。さらに、様々な要件を統合し、情報システム全体構成の実現案を作成することで、要件の抜け漏れを無くし、実現性の高い情報システムの全体像を明らかにする必要がある。

（要件定義を事業者へ外部委託する場合）

　要件定義を事業者に委託するかどうかにかかわらず、PJMOは要件定義内容の決定について責任を持つ必要がある。ただし、その決定に至るまでの進め方については、次の点に留意する。

　業務要件は、「第４章 サービス・業務企画」で決定した内容を基に業務に必要な要件を検討し、内容を確定するものである。その際、事業者が作成する各項目の定義内容について、PJMOは全ての内容に目を通し、理解する必要がある。

　機能・非機能要件は、業務要件を基に、情報システムに必要とされる要件を検討し、内容を確定するものである。その内容には、専門的なものが含まれるため、PJMOが全ての内容を理解することが困難な場合がある。そのため、PJMOは内容について理解できるように事業者に説明を求める必要がある。

（後略）

（参考　標準ガイドライン解説書 要件定義部）

　標準ガイドライン本編に書かれている言葉の意味や趣旨、留意点について、より具体的かつ詳細に説明しているのが解説書です。続いて実践ガイドブックも見てみましょう。

標準ガイドライン実践ガイドブック

　標準ガイドライン、標準ガイドライン付属文書、標準ガイドライン解説書の下位文書として、これまでに得られたノウハウや教訓などを盛り込んだ実践的な参考文書です。簡単にいえば、これまで政府がしてきたITの導入や運用、保守で経験した失敗や成功、そこで得られた知見やノウハウをまとめたもので、読み物としては最も興味深いものです。

　例えば、要件定義担当者がよく迷う「要件の優先順位付け」は以下のようなことが書かれています。

Step4　要件の全体像

（中略）

2 機能の優先順位は改善後の業務で判断する

　要件定義で検討する機能は、必ずしも全てを実現できるわけではありません。予算やスケジュールの関係から、実現する機能を絞らなければならないことはよくあります。

　機能の実現要否を検討する際には、政策目的やプロジェクト目標との関係、費用対効果等の観点を主眼として優先順位を判断していきます。また、機能を代替する方法（業務担当者の手作業や運用・保守作業にする等）も合わせて検討します。

業務要件や機能要件の整理・検討イメージ

（参考　標準ガイドライン実践ガイドブック 要件定義部より）

　この例示は、開発において政府の職員が迷い、結果こうやったらうまくいったという経験を元に書かれています。こうしたノウハウは、企業でも参考になる箇所が多いのではないかと思います。

政府のための文書だと考えるともったいない

　「デジタルガバメント推進標準ガイドライン群」を一部紹介しました。このガイドはITのライフサイクルについて、世界的なナレッジベースや法令、政府ならではの制度などに基づいた基本的な事項を書き連ねた上で、解説と実践に基づくノウハウや知見をとりまとめています。

　私も政府で仕事をする前、幾つもの企業でこうした標準ガイドを作ってきましたが、ここまで網羅的かつ広範に記されているものは珍しいといえるでしょう。

　もちろんこのガイドにはまだ足りない部分もあります。例えばアジャイル開発に関しての記述は、今、まさに検討しているところですし、2020年4月に施行された新しい民法の適応などはこれからです。今後、デジタル庁が創設されれば、役割や責任、ガバナンスプロセスも変えていかなければならないでしょう。

　その意味では、このガイドは、恐らく永遠に完成を見ることのないものかもしれません。しかし、ここに書かれている内容は、ユーザーの立場からすれば本当に自分たちが必要とするITを導入するために、ベンダーの立場からすれば顧客が本当に満足するITを構築するために、非常に大切な知見が幾つもちりばめられていると考えています。ぜひ一度ご一読いただきたいと思います。

標準ガイドラインの読み方

　さて、「ぜひ、ご一読を」と申し上げましたが、このガイドラインは、3つ合わせて1192ページほどあり、最初から最後まで読むのは容易ではありません。最初から読むのではなく「辞書」のように調べたいところを探すという方法もありますが、それも何となく面白みのない読み方です。

　そこで筆者なりに、この文書に取りあえず入り込んでいく読み方を考えてみました。政府の役人にも何人かこうした読み方を説明したところ、最初から読むよりもずっと早く内容を理解したようですし、興味を持って読めるということでしたので紹介します。

　ポイントは実践ガイドブック内にある「事例」です。実践ガイドブックには、実際の開発で経験した失敗や成功の例が章別に記されています。まずは章別の目次（全体の目次には出ていません）の事例の部分だけを見てみましょう。同じく要件定義部分からです。

事例・参考の一覧

事例：発注者側のキーマン交代で目的が異なる情報システムが出来上がる

参考：砂上の楼閣を防ぐデータ・マネジメント

事例：要件の考慮不足が設計開発工程の遅延に繋がる

事例：非機能要件が機能要件に影響することもある

参考：最適なシステム構成

参考：拡張性要件の記載例

参考：上位互換性要件の記載例

参考：オープンな標準的技術又は製品の採用を求める場合の記載例

参考：事業者交代時の対応を求める場合の記載例

参考：継続性に関する事項の記載例

参考：業務継続の分かれ目

参考：最低限記述すべき情報セキュリティ対策要件

参考：クラウドサービスの要件例

参考：運用要件（バックアップ）の記載例

　これらの事例の中から自分が気になる部分、「あるあるだな」と思う部分からまず読んでみてはいかがでしょうか。例えば「事例：発注者側のキーマン交代で目的が異なる情報システムが出来上がる」ではこんなことが書かれています。

　これを読んで参考になると思ったら、関連する部分を読んでみると、これらの事例に対するノウハウが整理されているはずです。事例から入り、本編の標準ガイド、解説書の関連部分を読んでいくわけです。

　網羅性はありませんが、こうして読んでいけば、本当に興味があるITプロセスについて、その基本的な事項（標準ガイド）、意味合い（解説書）、ノウハウ（実践ガイド）から必要な知識を得られるはずです。これで全ての文書を読み下せるわけではありませんが、部分的にでも得られた知識をご自身のプロジェクトで適用していけば、このガイド類を活用できたということになるのではないでしょうか。

　「デジタルガバメント推進標準ガイドライン」が作られた背景、そして読み方について解説しました。政府が公表している文書はとっつきにくく敬遠されがちですが、そこにはさまざまなプロジェクトで活用できる知見がたくさんちりばめられています。ITに関係する人、これから関わろうとしている人は、ぜひ、ご一読ください。必ずどこかに、役に立つ部分があるはずです。