政府CIOの「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」が とても良かったので紹介したい

#これって何？

政府CIOとは、内閣から任命され日本行政のシステム全体を統括する「日本政府のCIO」です。この政府CIOをサポートするのが各省庁を担当する50名近い政府CIO補佐官からなる政府CIOチームです。（組織としては、内閣官房　情報通信技術（ＩＴ）総合戦略室というようです）

この政府CIOチームがとりまとめた政府職員向けのIT調達とシステム導入に関する標準が「デジタル・ガバメント推進標準ガイドライン」です。

このガイドラインは「本編」「解説書」「実践ガイド」の3点構成になっています。

中でも今日ご紹介したいのが上図一番右の**「実践ガイドブック」**です。

#これを読むと何が手に入るのか？

一言でいえば、「システム開発プロジェクトの歩き方」です。（一言でいう必要なかったか）
組織で商用のシステムを企画して開発・導入・そして維持運用していくための**基本所作（型）**を知ることができます。
（あくまでも政府職員向けのため、具体的なプログラム言語やフレームワークなどに依った実装技術は対象外となっています。設計開発工程は外部委託することが前提ということですね）

#なぜお薦めするの？

• 元々政府CIOは民間から優秀かつ経験豊富な方々が集まったチームです。このドキュメントの位置づけを考えても、こうした方々の知恵が凝縮されていると考えてよいと思います。事実システム開発導入実務経験20年の私から見ても、僭越ながら非常に的を得ているというか、切り口のセンスが絶妙だと感じました。

• もともと知識のない人に向けた実践のための実務書なので、専門的用語も少なく、中身も具体的で読みやすいです。「本編」「解説書」の2つが教科書だとしたら、このガイドブックはわかりやすい解説付き「参考書」と思ってください。

• 事業組織にゼロからシステムを導入する上でやるべきことが網羅的に扱われています。

• 一部行政システムに特化した内容も見受けられますが、大半は行政以外にも全くもって適用できる、きわめて汎用的な内容です。

• 過去既出の類似資料としてはIPAの発注者ビューガイドラインがありますが、そのカバー範囲やわかりやすさの観点では、この実践ガイドブックの方を私はお薦めしたいです。

#想定する読者は？
資料上では以下の記載があります。

ただ行政ITに関わる方だけの資料とするには余りにももったいない！
以下のような方々、つまりシステムに関わるほぼすべての皆様におすすめのコンテンツです！

• 未経験ながら近々システム導入に関わることになった、または今真っ最中の方
• 違う角度でシステム導入の全行程を俯瞰したいシステム開発に関わる方々
• まさにプロジェクトマネジメントに携わっている方で、客観的に自分のマネジメントを見つめたい方

頭から全部読み下すというよりは、必要なタイミングで該当箇所を紐解く**「参考書」的使い方**がよいのではないか？と思います。

ちなみにドキュメントの冒頭付近で以下のような箇所があります。

政府系の資料の割にちょっとエモくないですか？著者はきっとたくさん苦労したんでしょうね・・・
システムに関わる人達の幸せを願う想いが資料全体から何となく感じられるのが、一番この資料を気に入っている理由かもしれません。

#どんな内容なの？
全体像は以下の通りです。全資料がPDF、MS Word、HTMLの3形態で公開されています。
（利用者目線で実際の利用を想定された公開形式も素晴らしい）
引用元はこちらです。

#概要紹介

各章の概要は「３ 本書の概要」からご確認いただけます。
以下では私の個人的おすすめの章を5つピックアップしてご紹介します。

###第２章　プロジェクトの管理
https://cio.go.jp/guide/guidebook_t/guidebook_2/index.html

プロジェクトの立上げ時に、目標を安易に設定してしまうことがあります。第２章の冒頭では、悪い目標設定例を題材にした上で、現場で発生している事実をつかみながら利用者が本当に困っていることを分析して、利用者が実感できる効果を目標に設定する方法を説明します。
また、機能するプロジェクト体制を作ることが重要です。制度所管部門、業務実施部門等を含めた組織的体制で、ＰＪＭＯにも十分な要員を確保する方法を具体例とともに示します。
プロジェクトを実行する段階においては、ＰＪＭＯ自身によるモニタリングを行います。目標、経費、進捗、品質等を確認し、場合によっては抜本的改善のプロセスに入ることもあります。
様式のひな形　プロジェクト計画書、プロジェクト実施要領

プロジェクト管理における具体的業務内容と注意事項がわかりやすく解説されています。
「STEP.2 プロジェクトの立上げ、初動 A. 現場で発生している事実をつかんだ上で今後の目標を定める」というところでは、実態調査が不十分なまま目標設定されることで手戻りが発生することへの警鐘として、下記の事例が挙がっていました。わかりやすい事例です。

プロジェクト管理は経験値の差がどうしても出やすい領域ですが、経験のない方でも想像しやすいように工夫されています。

###第４章　サービス・業務企画
https://cio.go.jp/guide/guidebook_t/guidebook_4/index.html

サービスデザイン思考という言葉や、サービス・業務改革（BPR）という言葉を聞いたことがあっても、いざ自分が担当したときに何をどう検討すればよいのかわからないかもしれません。
まず、サービス設計１２か条の内容に基づいて、検討への心構えと視点を説明します。そして、利用者の立場からの分析を行うために、ペルソナ分析やジャーニーマップといった手法を説明します。また、サービス・業務の現状把握のために、どのように調査を行い、どのような資料を集め、どのように分析するかを詳細に解説します。事例を交えた解説の中で、平均や合計での分析だけでは不十分であること、時間と期間を区別すること等、本当の事実をつかむための分析の着眼点や注意点を示しています。
このような検討を通して作成した企画案について、様々な方向から見直せるように、見直しの観点も多数示しています。
様式のひな形　現状分析結果報告書、業務要件定義書

この章は以下の「サービス設計１２か条」というものが中心になっています。

ここに登場する言葉を見ていただくとピンとくる方も多いと思いますが、具体的な言葉は登場しませんが明らかにプロダクトマネジメントを意識されていることは間違いありません。12か条それぞれの説明も非常に具体的かつわかりやすいもので、この章だけでも手元に置いておく価値はあると思います。（でも他の章も見て！）

###第５章　要件定義
https://cio.go.jp/guide/guidebook_t/guidebook_5/index.html

これまでの検討で作り上げた業務要件を実現するために、情報システムに求める要件を具体化します。
まず、RFIや事業者からの情報収集といった活動を通して、市場にあるサービス、海外や国内の類似事例、新たな技術の動向や製品のライフサイクル、概算の予算規模、スケジュール等について把握を行います。
その上で、機能要件と非機能要件を明確にします。機能要件では画面、帳票、情報・データ、外部インタフェース等について、非機能要件ではユーザビリティ、システム方式、規模、性能、信頼性、情報セキュリティ等について記載します。記載項目のそれぞれについて、記載する目的、作成するドキュメントのイメージ、注意点等を説明しています。
様式のひな形　機能要件定義書、非機能要件定義書

オーソドックスなアプローチながら、流派が分かれる要件定義における1つの型を提供いただけているのは、広く教育的観点において非常に有益だといえます。もちろん具体的な表現方法はRDRA¹など各種モデリング手法を活用するのも有効です。

当然のごとく要件定義書のひな型も添付されています。（「実践ガイドブック別紙一括版」というファイルに含まれています）
至れり尽くせりです。

ちなみに画面機能要件の定義の部分では以下のような箇所があります。

このあたりはプロトタイピングツールを使用して、より現実的な利用感をユーザーと確認できれば尚よいですね。²

また非機能要件にも十分な記載がなされているのも好感が持てました。
非機能要件の大切さはどれだけ言っても言い過ぎということはありません。

以下のような要件定義における王道的金言が記載されているのもありがたいですね。

• 「人は間違うものであり、やり直しやイレギュラーにこそ気を配れ」
• 「どのように処理するか」ではなく「結果としてどうなるか」を決めるのが要件定義だ
• 「非機能要件」が「機能要件」に影響を与える場合もある
• 要件定義は終わったら、関係者への周知共有とプロジェクト計画書への反映を忘れずに

###第７章　設計・開発
https://cio.go.jp/guide/guidebook_t/guidebook_7/index.html

設計・開発を事業者に丸投げしては、良い情報システムは作れません。要件を事業者に正しく伝え、関係者間の調整を行い、進捗状況を正しく把握し、情報システムの出来具合をテストするのは発注者である職員自身です。設計・開発において、職員自身が実施することにフォーカスして、業務内容を説明しています。
例えば、テストについても、結合テスト、総合テスト、受入テストといった工程の中で、機能面（シナリオテスト、業務サイクルテスト等）はもちろんのこと、非機能面（負荷テスト、セキュリティテスト、縮退テスト等）をそれぞれ確認します。職員自身がテスト計画やテスト結果について正しく判断できるように、テストの内容と確認ポイントについて説明しています。また、移行、リハーサル、運用・保守の準備、マニュアル等、重要なのに見落とされがちな作業について、計画の立て方、ドキュメントの作成方法、注意点等を示しています。
様式のひな形　　　　設計・開発実施計画書、設計・開発実施要領、受入テスト計画書

上記のサマリをみて頂ければわかるように、これは設計開発をベンダーに依頼する場合の、発注側の振る舞いについて記載されています。
よっていわゆる技術論的な設計手法や開発スタイルに対しての記載はありません。
ただ開発チーム側の立場の方々にとっても、開発が本格化してエンジニアチームに主軸が移りだしたときに、ユーザー側の人たちがどういうことを懸念し、どういう振舞をエンジニアチームに期待しているのかを知ることは、大いに意味のあることだと思います。

まずこの工程におけるユーザー側担当者の大切な3つの役割を明示しています。

A. 『要件の内容を伝える役割』
B. 『要件どおりに情報システムができたかを確認する役割』
C. 『プロジェクトの進捗状況を正しく把握し適切な調整を行う役割』

特にAを敢えて取り上げている点が注目です。

要件は、既に要件定義書としてドキュメントに取りまとめられています。事業者は、その情報を基に『どうやって作るか』を具体化する設計作業を開始し、徐々に詳細化していきます。その作業の過程で、要件定義書だけでは読み取れない発注者側の意図や要望について、発注者側は正しく伝達することが必要となります。また、設計をする中で見えてくる課題等の対応方法を決めることも必要です。

この「行間を埋める」仕事が本当に大切だと思っています。エンジニアにはそもそも資料をあまり読まない人も一定数いて、これはこれで問題なのですが、資料に書いてあるから読んでおいてという態度も、理解の齟齬を生みます。
もう十分伝わっただろうとと思ってから念押しするぐらいコストをかけてでも、要件を正しく設計開発側に伝えるという仕事はやる価値があります。

ちなみにこのA,B,Cは開発ベンダーのPMが最も意識すべきことだと言い換えることもできます。
特にエンジニア歴の浅いPMにとって、参考にしてもらいたい章です。

また職員（発注側担当者）として特に意識すべきこととして、以下の3つが挙げられています。

A. 要件を理解した職員の継続的な関与がプロジェクトを安定させる
B. 要求とコストと納期のバランスをとる
C. 設計・開発の全体像と流れを理解する

Aは本当に私も共感度大で、「要件定義が終わったらもう仕事が終わり」と言い出すこともある発注側の担当者に釘をさす意味で、極めて効果的な記載です。（プロジェクト開始前に共有しておくことが大切）

Cでは開発の進捗管理の考え方や各テストの定義などもユーザー側もユーザー側としては十分過ぎるレベルで記載されています。ベンダーを適切にマネジメントする上で、ちゃんと理解していないとうまく誤魔化されるぞという警鐘にも受け取れますね。
一方で実際の設計開発工程の実践という観点でいえば、少し古典的な印象もぬぐえません。ただ改めて基本に立ち返ることで、何か目の前の問題が解決するヒントが手に入るかもしれません。特にテスト定義や品質管理の基本的な考え方、移行計画の立て方といったくだりは、若手エンジニアの方には特にお薦めしたい箇所です。

###第８章　サービス・業務の運営と改善
https://cio.go.jp/guide/guidebook_t/guidebook_8/index.html

この章が運用保守から独立していることがまず素晴らしいと感じました。
まさにシステムに命を吹き込むにはこの仕事が不可欠なのです。³

この図で整理されているように、一般的なシステムの立ち上げが

• 業務サービス運営（サービス・業務の運営の開始→運営→改善）
• システム開発（サービス・業務企画→設計開発）
• システム運用保守（＋システム監査）

という3軸で整理されていることに非常に重要な意味があると考えます。

• システム開発
• システム運用保守（＋システム監査）

ではない、ということですね。

ここでは、この「業務サービス運営」とは具体的にどういうことをやるのかが言及されています。

SI業界的な用語でいえば「業務移行」、少しかっこをつけると「チェンジマネジメント」という表現にもなりますね。
システムが変わるということを明確な一大イベントととらえ、現場を巻き込んでしっかり準備を行おうという内容です。

以下の事例などは業務システムでは比較的起こってしまいがちなトラブルです。最後に手抜きしたというよりは、そもそものプロジェクトのゴール設定が間違っていた（システムを作ることではなく、システムを使って効果を出してもらうことがゴール）と理解すべきだと思います。

この章の最後に紹介されているダブルダイヤモンドという図も印象的でした。
把握と分析を繰り返すことの重要性がうたわれています。まったく同感です。

#最後に
以上、本当に一部分だけですが、政府CIOの「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」を紹介をさせていただきました。
今回このコンテンツを書くにあたってガイドブックを通読しましたが、多くの箇所で気付きを得ました。一度は学んだはずの基本事項も繰り返し体系的に呼び起こすことで、本当に使える知識になるはずなのです。そういう意味で色々な使い方ができる資料だと思っています。

こうした資料を公開いただいた政府CIOチームには心から感謝したいです。
目的用途的には省庁内でローカルに公開する形でも良かったはずですが、政府CIOチームは日本国内へのIT産業への貢献を意識され、全面的な公開に至ったのだと思います。元は税金という意味では国民に還元するのはある種当たり前かもしれませんが、政府CIOチームの日本の未来のIT産業への期待はしっかり受け取りました。

なお他の政府CIOポータルのガイドラインも、すべては精読できていませんが参考になりそうなものが沢山あります。是非チェックしてみてください。
https://cio.go.jp/guides

「第４章　サービス・業務企画」のような手法で企画されたような行政システムが増えてくれば、日本はもっと便利になるに違いありません。
このガイドブックの成果をユーザーとして実感できる日を楽しみにしたいと思います。

1. RDRAについては、要件定義品質向上への突破口～RDRA2.0の提案～を是非ご覧ください。
   ↩

2. プロトタイピングを活用した上流工程の推進については、業務システムでも効果的なデザイン先行型開発アプローチを是非ご覧ください。 ↩

3. システムの定着化や活用促進については、システムは使われてナンボ～プロマネが考えるべき定着化・活用促進のための勘所～を是非ご覧ください。 ↩