--- type: guideline title: Step.2 設計・開発を開始するための事前準備 source: デジタル庁 ds_code: ds-120 category: government-system updated: 2025-06-19 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/9ab95eed/20250619_resources_standard_guidelines_guideline_06.zip --- # Step.2 設計・開発を開始するための事前準備 ＰＪＭＯが、設計・開発の活動に適切に関与していくためには、最低限の知識とＰＪＭＯが果たすべき役割と責任を認識しておく必要があります。これらの内容は、要点を押さえれば、それほど難解なものではありません。 では、設計・開発の活動に必要となる前提知識や心構えを見ていきましょう。 ## 設計・開発で職員が行うべき事を理解する 【標準ガイドライン関連箇所：第３編第７章第１節】 設計・開発の具体的な活動を行うのは、調達によって選定された事業者です。事業者は、調達仕様書及び附属資料である要件定義書をインプットに、設計・開発工程の活動を計画し、活動を行います。設計・開発工程の作業は、情報システムを対象とした専門的なスキル・経験が求められます。 では、職員が関与しなくても作業が順調に進むかというとそうはいきません。一般的に、職員の関与が低いほど、設計・開発の成功確率は低下します。 したがって、『専門的』でわかりづらい設計・開発工程の作業において、『職員が関与する』ことで効果がある作業とは何かを理解する必要があります。 まず、職員が作業に関与するに当たり、基本的な役割を以下に示します。 『設計・開発』を行う際の職員の基本的な役割 - 要件の内容を事業者に正しく伝える役割 - 要件どおりに情報システムができたかを確認（テスト）する役割 - プロジェクトの進捗状況を正しく把握し、スケジュールや関係者間において発生する調整を適切に行う役割 - 注記 Fit&Gap 分析とは、パ ッケージ製品の機能が、発注者の要件に適合（Fit）している 点と乖離（Gap）している点を明らかにし、事業者の提供するパッケージ製品と発注者が求める要件との適合性を判断する分析手法のこと。 『要件の内容を伝える役割』 - 注記 カスタマイズの範囲は、パッケージ製品の設定値の変更から機能改修まで多岐にわたるが、左記の文章におけるカスタマイズは、発注者から提示された要件に応じてパッケージ製品の機能改修を行うことを指す。 要件は、既に要件定義書としてドキュメントに取りまとめられています。事業者は、その情報を基に『どうやって作るか』を具体化する設計作業を開始し、徐々に詳細化していきます。その作業の過程で、要件定義書だけでは読み取れない発注者側の意図や要望について、発注者側は正しく伝達することが必要となります。また、設計をする中で見えてくる課題等の対応方法を決めることも必要です。例えば、設計書のレビューにおいて、発注者側の意図とそごがある部分や明確に理解されていないと思われる部分がある場合は、事業者との打合せの場を設け、認識そごを解消する必要があります。また、パッケージ製品等を導入する場合は、設計・開発事業者が提案した製品と業務とのFit&Gap分析に発注者が主体的に関与し、発注者と事業者の双方で製品と業務の適合性を確認する必要があります。Fit&Gap分析の結果、要件と乖離（Gap）している点に対しては、カスタマイズを行うことで要件に合わせるという選択肢もあります。ただし、カスタマイズ範囲を増やしすぎると、運用保守段階で変更が発生する度に当該機能の動作テストも行う必要があるなど、保守性を損なう可能性もあります。これらの長所、短所を勘案した上でカスタマイズ範囲を検討すること - 注記 文書や口頭で丁寧に説明を行ったとしても、伝達ミスや誤認等のコミュニケーションロスを完全に排除することはできない。 このため、Fit&Gap分析を事業者に一任すると誤った要件の理解に基づいて分析が行われ、誤った結果が導かれる可能性があることから、発注者が主体的に関与することが必要。 が重要です。 この段階でコミュニケーションが十分にとれないと、いざ運用段階で実際に利用してみると使い勝手が悪かったり、手戻りが発生したりといった弊害を招きかねません。 以下の事例は、実際のプロジェクトで発生してしまった実例です。このような失敗をしないように留意してください。 - 事例7-1 基本設計段階でのコミュニケーション失敗

事例：基本設計段階でのコミュニケーション失敗

過去の設計段階における画面設計にて、以下のような問題が発生しています。利用者が効率よく、誤解なく正確に使えるように設計段階で留意しましょう。

  1. 固定幅や固定行数で画面が設計されているため、画面の右側や各ブロックの下に空き領域が出てしまうケースがある。

※画面の一覧視認性を高める配置・構成にすべきです。

  1. 大事な情報が横スクロールしないと見られない作りになっている。

※縦スクロールする利用者画面において横スクロールのUIは避けるべきです。

  1. 直感的に使いにくいボタン配置

  • 「更新」ボタンが中央付近、「戻る」ボタンが最も右端にあり、操作ボタンが離れている

  • ボタンレイアウトのトレンドを意識する

例：WebやスマートフォンにおけるUI（ユーザインタフェース）では

「修正」「更新」

「戻る」「進む」

「キャンセル」「OK」

のように、左側のボタンが後ろ向き操作、右側のボタンが前向き操作とすることがトレンドです。

  1. 否定文を使った確認ダイアログの利用は利用者の迷いや誤操作を招きやすい

例：この操作をキャンセルしますか？「キャンセル」「OK」

  1. 開いたWebページのサイトにおける位置を示すものがない機能構成ツリーやパンくずリストを設定しないと、利用者に全体像が伝わらない、操作が煩雑になる、あるいは迷子になることが発生します。

  2. エラーメッセージがわかりにくい

どのシステムのどのデータ、どの処理でエラーが起きたかを明示することが望まれます。

  1. インポート機能がない

複数の申請を一括処理するための機能・UIがない

※一括申請の利用者の存在と利用頻度を考慮するべきです。

  1. 異常処理系において面倒な運用操作が必要

プルダウンの選択肢を変更しようとした場合に、プルダウン項目を決めている別の項目設定をいったん空欄にしないと変更できないつくりになっていた。

※親子関係のある設定や選択肢は、子側を変更しようとした際に親側の変更もできるつくりにすべきです。
- 参考7-1 使い勝手の良いシステムを構築するための工夫

参考：使い勝手の良いシステムを構築するための工夫

どのような使い勝手にするかということまで調達仕様書に完全に反映できれば望ましいですが、実際にはそこまでイメージが固まっておらず難しい場合が多いです。そこで、基本設計段階で画面イメージや画面遷移図を作りますが、それらのドキュメントを主体として発注者と受注者で認識合わせをしたとしても実際にできあがったものを試してみると使い勝手が悪いということがあります。利用者にとって使い勝手の良いシステムを構築するためには、どのような工夫をすればよいでしょうか。

以下では、そのような観点から有益な工夫をご紹介します。

  • 実機を用いた認識合わせ

思っていた使い勝手と違っている、と受入テスト段階で気がついても、大きな修正は難しいことが多いです。このため、できるだけ早いタイミングでシステムの使い勝手を確認することが重要です。

パッケージ製品を利用するなど動作する環境を事前に用意しやすい場合は、調達前の市場調査時に実機を用いたデモによって使い勝手を確認することができます。ただし、当該製品の基本的な機能を用いたシナリオのデモを確認しても、実際に業務で使用する場合の使い勝手までは確認できない場合があるため、想定した使い勝手と違っていたと導入後に気づく懸念があります。

このため、当該製品の基本的な機能だけでなく実際の業務における使い勝手を確認することを目的として、調達後における要件定義の内容の調整・確定段階で利用者の業務環境に合わせてパラメータ設定等を行った環境を構築し、利用者がシステムを自由に操作できる機会を設けることを要件として定めることも有効です。

一方で、スクラッチ開発のように開発の終盤になるまで実際の動作を確認することが難しい場合には、利用者を巻き込みプロトタイピングにより認識合わせをする、結合テスト段階で実際に開発された画面を用いて動作を確認するといった工夫が考えられます。なお、結合テスト段階における動作確認で使い勝手が違うと気づいたものが、要件定義や設計内容を正しく反映していない場合は当然に修正を求めることができますが、仕様変更の場合はこの段階での対応が困難であることが多いことに留意が必要です。そのため、基本設計のような上流工程でプロトタイピング等の手法を使ってしっかりと使い勝手を確認することを推奨します。

また、認識そごを発生させないための上記のような工夫について応札事業者から提案を求めることも有効です。

いずれの場合でも、一度認識合わせをして終わりとするのではなく、それ以降の設計やテストの段階で、できるだけ確認やフィードバックを行うこと、業務で実際に当該情報システムを利用することとなる職員が主体となって使い勝手を確認することが重要です。

  • 利用者を限定したスモールスタート

ある省庁では、地方自治体の職員が利用するシステムの整備に当たって、緊急性の高さから、現場の業務実態が不明確だったものの、まずは動くシステムを構築し、一部の利用者に限定して運用を開始する方針としました。このスモールスタートによって、例えば、一件ずつ逐次処理するだけでなく複数件を一括処理する必要があること、自治体の規模等によって決裁の仕方が異なり組織形態に合わせた処理が必要であること、職員の負担を減らすために自動化など効率化の余地があることがわかりました。このシステムでは、これらの利用者からの意見を踏まえてシステムをブラッシュアップし、使い勝手をより良くしてから本格運用を開始できました。

一部の利用者で小規模に運用を開始するという方法はすべてのシステムで採用できるものではありませんが、利用者にとって使い勝手の良い機能を提供するためには有用な方法です。

また、同じようにスモールスタートを行った事例として、「第3編第4章Step.6-2-A.事例 4-14：一部地域で試行してから、サービスを全国へ展開」も合わせて参照してください。
- 注記 プロトタイピングとは、情報システムを本格的に構築する前に、試作品（プロトタイプ）を作成し、実物を見ながら要件を具体化していく手法 ### 『要件どおりに情報システムができたかを確認する役割』 構築された情報システムが、伝えた要件を満たすものになっているかを確認するのは職員の役割です。 もちろん、情報システムの様々な処理がきちんと動作できるのかは、職員が確認する前に、事業者がテストで十分に確認していることが前提となります。 テストにおいて職員に求められることは、テストすべき項目（テスト仕様書）をレビューし、内容の正しさをチェックすることと、事業者が実施したテストの結果を確認することです。 テストを実施する作業の中では、テスト項目に従って情報システムが正しく動作しているかどうかを確認していきます。テスト項目とは、情報システムにどう動いてほしいかの要求を詳細化したものです。これが間違えていたり、抜け漏れがあったりすると、情報システムが要求どおりに構築されたとは言えなくなります。したがって、職員は、テスト仕様書に目を通し、要求を反映したテスト項目となっているかを確認することが重要となります。 もちろん、テストには様々な種類が存在し、テストごとに職員の関わり方は異なります。詳細は「Step.3-3 テストの計画を立てる」を参照ください。 通常のテストは上記のとおりですが、受入テストは例外扱いで、職員自らがテストを実施する必要があります。 ### 『プロジェクトの進捗状況を正しく把握し適切な調整を行う役割』 この役割は、発注者側の立場によるプロジェクト管理の一つとして、ＰＪＭＯに求められるものです。 設計・開発工程では、プロジェクト期間が長く、プロジェクト開始時には概要レベルの全体スケジュールを立案し、詳細な計画は、段階的に作成していくことになります。この作業を進める中で、様々な関係者が登場します。新たな情報システムを導入する際には、ほとんどのケースで業務を見直して、手順や内容の変更を行います。その過程で業務関係者間での調整がうまくいかないことは、プロジェクトの進捗を遅延させる要因となります。 また、プロジェクトには期間と予算の制約がありますので、どんなに良い方法であってもこれらの制約の関係で妥協しなければならないこともあります。 そのため、ＰＪＭＯは、プロジェクトを正常に進めるための調整が重要であることを認識し、その役割を担う必要があります。 ## 設計・開発全体を通して理解すべき点とは 【標準ガイドライン関連箇所：第３編第７章第１節】 ＰＪＭＯが、発注者として設計・開発を適切に管理していくために、設計・開発の活動全体を俯瞰的に理解しておく必要があります。ここではその内容を説明していきます。 ### 要件を理解した職員の継続的な関与がプロジェクトを安定させる 大規模なプロジェクトの場合、設計・開発工程だけで１年以上の期間が必要となることが多くあります。 要件定義において、多くの職員からの意見を集約し、様々な情報を分析して、新しい業務を決定しましたが、その全体像を理解している職員は、要件定義に関わった職員の中でもごく一部に限定されます。 このような職員は、プロジェクトにとって非常に貴重な存在です。設計・開発工程において、事業者に要件の全体像を説明し、要件追加変更に伴う影響度の調査を行うには、全体を理解していないとスムーズにできないからです。また、要件がどのような背景で発生し決められたのかの経緯を正しく理解していないと、誤った説明や安易な変更を行うおそれがあります。 こういった問題を発生させないためにも、要件定義に関わった発注者側の職員、特に業務を理解している業務実施部門の職員をプロジェクトの体制に参画させ続けられるよう、体制の組成時に調整を行うことは効果的です。 ### 要求とコストと納期のバランスをとる 設計・開発の活動を進めていく中では、要件変更や当初計画からのかい離は、様々な要因により発生します。要因には、政権交代や世の中の情勢変化に伴う方針変更、連携する情報システムの要件変更等のプロジェクト外部で発生する要因や、設計として詳細化していく中で発覚した要件定義の誤りや受入テスト時に発見される要件の抜け漏れ等のプロジェクト内部で発生する要因があります。 このような場合に、「納期は絶対で、追加発注も不可能。でも、変更は受け入れて当初計画どおりに仕上げてください。」と指示を、建設的な議論をせずに行ったとしてもプロジェクトはうまく進みません。 事業者は、要件定義の内容、納期・スケジュールに基づいて、コストを見積り、計画を立てます。つまり、「要件（スコープ）」「コスト」「納期（スケジュール）」のいずれかが変更されると、ほかにも必ず影響が発生します。 では、「今年度の計画は変更できないので、追加や変更は全て来年度以降に先送りします」としても、そこに重要な要件が含まれている場合は、今年度出来上がった情報システムがまともに動かないリスクもあります。 これは、要件の変更だけではなく、スケジュールや納期の変更でも同様です。 では、このような場合にどう対処すればよいでしょうか？ これらを適切に管理するための仕組みが「変更管理」です。変更管理は、変更の必要性が発覚した際に、「変更に対する影響の調査」「影響度合いに応じた変更の決定の手続」等の変更に対する管理方法を定めるものです。まずは計画時に、これらを明確に定め、これに則り設計・開発工程作業中に発生する様々な追加変更を取捨選択していくことが大切です。影響度の判断によっては、当初の要件を諦め、新しく発生した要件と差し替える等、柔軟な対応が求められます。 ### 設計・開発の全体像と流れを理解する 設計・開発の活動は、設計・開発・テスト・移行等のいくつかの作業工程に区切って進めていくことが一般的です。しかし、これらの工程の組み方は多種多様で、それぞれメリット・デメリット、向き・不向きがあります。ＰＪＭＯは、これらを踏まえた上で、事業者が立案した計画を理解して、プロジェクトにあった進め方となるよう、事業者に要望を伝えていきます。 ここでは、事業者の計画を正しく理解し適切な進め方を検討していくことができるよう、設計・開発全体の進め方に係る知識やノウハウを解説していきます。 #### 設計・開発工程に含まれる全ての活動内容を俯瞰的に理解する 設計・開発では、様々な活動が行われます。事業者が作成するスケジュールを確認する際、まずは俯瞰的に工程の流れを押さえて、大きなそごがないかを見ていきましょう。 情報システムの設計・開発は、大まかに捉えると以下のような流れになります。 - 図7-1 工程の全体像 ![](../assets/ds-120-ch07-image1.png) これらの活動ごとの成果物を洗い出し、その成果物を得るために必要な作業を細分化し、作業にかかる時間や作業順を当てはめていったものがＷＢＳに基づいたスケジュールとなります。ＷＢＳの確認については、「Step.3-2-E. ＷＢＳで作業計画を確認し進捗を把握する」を参照してください。 なお、工程の名称は、事業者によって呼び方が異なります。同じ名称でも、事業者によって捉え方が異なることがあるため、注意が必要です。工程の捉え方を間違えていると、適切な時期に求めたレベルの成果物ができていなかった、というようなことが発生します。 - 表7-1 標準ガイドラインと各社が定義する工程の比較

標準

ガイドラインの定義

 Ａ社 Ｂ社 Ｃ社 Ｄ社 Ｅ社 Ｆ社
要件定義 要件定義 要件定義 RD：システム要件定義 要件定義 要件定義 要件定義
設計 基本設計 外部設計 BD：基本設計 UI：ユーザーインタフェース設計 外部設計 基本設計 基本設計
FD：機能設計 SS：システム構造設計
詳細設計 内部設計 DD：詳細設計 PS：プログラム構造設計 内部設計 詳細設計 詳細設計

実装・

単体テスト

コーディング

／テスト

 CD：コーディング PG：プログラミング 開発 開発/単体テスト 開発/コーディング
UT：単体テスト PT：プログラムテスト 単体テスト
結合テスト 結合テスト IT：結合テスト IT：結合テスト 統合テスト 結合テスト 結合テスト
総合テスト システムテスト ST：総合テスト ST：システムテスト システムテスト システムテスト 総合テスト
受入テスト 運用テスト RT：受入テスト OT：運用テスト・移行 -

運用テスト

受入テスト

 運用テスト
#### プロジェクトの特性（新規構築・更改等）によって、作業は異なる 設計・開発で行う作業の内容は、プロジェクトの特性によって異なります。例えば、情報システムを新規に構築するプロジェクトと既存情報システムの更改のプロジェクトでは、作業の内容が大きく変わります。 - 表7-2 プロジェクト特性の概要
プロジェクト特性 概要 他の特性との違い
新規構築 新たに情報システムを構築する。 情報システムの構築に係る全ての作業が必要となる。
更改

既存の情報システムを再構築する。

ただし、再構築には様々な方法があり、インフラのみを変更して、新しい環境（ハードウェア・ミドルウェア等）上で既存の情報システムが稼働するようにすることや、現在の情報システムをいかしつつ機能の改修を行うこと等がある。

更改の方針に応じて、作業が異なる。

また、新規構築と比べ、テストや移行の比重が高くなる傾向にある。

事前検証を行う等、新規構築とは異なる作業が必要となる可能性がある。
また、一から情報システムを構築（＝スクラッチ開発）する場合、クラウドサービスの利用、パッケージ製品等の導入・カスタマイズでは、それぞれ活動の内容が異なってきます。例えば、クラウドサービス（PaaS）の利用では、機能に関する実装・テストよりも運用視点でのテストの比重が増えるかもしれません。 情報システムの更改を行うタイミングは、情報システムの機能を見直すに当たり、またとないチャンスです。現在のサービス・業務運営上の課題や既存情報システムの運用の中で寄せられた要望等を確認し、情報システムの機能改善を検討しましょう。なお、やむを得ない事情により、機能改修を伴わない更改を行うこともありますが、その際には機能の実装・単体テスト等を実施する必要がないかもしれません。このようなプロジェクトの特性に合わせて、作業内容の必要十分性を確認しましょう。 確認に当たっては、「Step.3-2 設計・開発の実施計画を立てる」で解説する設計・開発実施計画書のひな型を参考にして比較を行い、不足や不明点は事業者に確認して、事前に漏れや誤りをなくすようにしましょう。 #### プロジェクトの進め方や開発手法により作業内容も異なる 設計・開発の進め方には、様々なものがあります。以前は、情報システムの構築といえば、ウォーターフォール型で進めることが主流でしたが、ソフトウェア開発の過去の失敗事例等を踏まえて、様々な進め方が考案されています。 標準ガイドラインで定義するプロジェクトは、大きく以下の２つに分類できます。 - 表7-3 プロジェクト全体の進め方の種類 | 進め方の種類 | 概要 | 適用の基準例 | |----|:---|:---| | 通常の開発 | 定義した要件に基づいて全ての機能を構築してサービス・業務を開始する。その後、必要に応じて機能追加等を行う。 | プロジェクト目標に対する具体的な実現方法が定まっており、要件の詳細な定義が可能な場合 | | 実証実験型開発 | 必要最低限の機能を構築してサービスを開始し、効果をモニタリングしながら要件を明確にし、段階的に情報システムを構築していく。 | プロジェクト目標に対する具体的な実現方法が定まっておらず、要件の詳細な定義が困難である場合 | また、情報システムの開発手法も、複数あります。代表的な開発手法には、次のようなものがあります。 - 表7-4 開発手法の比較
開発手法の種類 概要
ウォーターフォール

図7-1で示したような工程を時系列に進め、原則として前工程の完了後に次工程を開始する情報システム構築作業の進め方である。

設計・開発の途中で変更が少ないと見込まれる場合に用いる。

工程を時系列で進めることから、計画が立てやすく、進捗の管理がしやすい。
アジャイル

開発対象となる機能（１～複数）の設計・開発・テストをイテレーション（反復）と呼ばれる短い期間に分けて進め、イテレーションが終了するごとに動く機能が出来上がる情報システム構築作業の進め方である。

設計・開発の途中で変更が多く発生すると見込まれる場合に用いる。

短期間で動く機能が出来上がるため、情報システムの利用者に確認を取りやすい。
ウォーターフォール型は従来型の開発手法ですが、その工程の中でプロトタイピングをとることも増えてきています。プロトタイピングとは、情報システムを本格的に構築する前に、試作品（プロトタイプ）を作成し、実物を見ながら要件を具体化していく手法です。ウォーターフォールでの開発においても、設計工程の中でプロトタイピングを導入することで、関係者からの意見を聞きながら要件をとりまとめやすくなります。 昨今、開発手法として増えているのがアジャイルです。現時点においては、開発工程全てにわたってアジャイル開発を貫いた事例はまだ少ないですが、部分的に設計工程においてモックアップ画面等を導入して仕様確定を - 注記 「アジャイルソフトウェア開発宣言」とは、従来型のソフトウェア開発のやり方とは異なる手法を実践していた開発者・研究者が2001年に作成した、アジャイル開発を進める上での「マインドセット」が書かれたもの 促進するケースは増えてきています。アジャイル開発の進め方は、サービス設計12か条にある「何度も繰り返す」、「一遍にやらず、一貫してやる」といった視点に沿うものですので、積極的に導入を検討してみてください。 アジャイルの考え方の規範は、「アジャイルソフトウェア開発宣言」として一般に公開されています。 - 図7-2 アジャイル開発の基本的な進め方 ![](../assets/ds-120-ch07-image2.png) 一方で、形式だけでアジャイル開発を採用すると失敗することになりかねません。以下のような形だけのアジャイル開発にならないように気を付けましょう。 - **投げっぱなしアジャイル** 発注者の要件を調達以前の段階で十分に定めず、要件自体を設計工程で決めるというように後送りにする方法。調達する事業者の能力や経験によって、構築できるシステムの機能や品質が大きく変わってしまう。特に、事業者の能力が十分でなかった際に、要件定義内容を元に改善指摘をすることが難しくなってしまう。 - **優先度をつけないアジャイル** 設計を進める中で出てきた要件について、発注者が優先度の判断をせず、全てを実現することを求めてしまう方法。限られた工数の中で効果の大きい部分を選び出していくことがアジャイルの特徴であり、優先度を判断しないのであれば後出しした要件を全て実現させるという非合理的な契約形態となってしまう。 なお、アジャイルが適さないと言われているプロジェクトもあります。一般的には、大規模なプロジェクトやミッションクリティカルなプロジェクトはアジャイルに適していないと言われています。ただし、大規模なプロジェクトであっても部分的にアジャイルを適用することは可能です。 開発手法は、必ずしもプロジェクト全体で統一しなくてはいけないわけではありません。メリット・デメリットを理解して、特定の機能群についてはアジャイルで進める、というように「良いどこ取り」していくことも大切です。 - 事例7-2 ウォーターフォールとアジャイル開発を組み合わせた開発計画

事例：ウォーターフォールとアジャイル開発を組み合わせた開発計画

ある省において、大規模な情報システムの更改を行うことになりました。既存の情報システムは長期間運用していたこともあり、現場からは多くの要望が上がっていたため、更改に合わせて情報システムを刷新することとしました。

現場からの要望は多種多様であったため、早めに実働する情報システムを用いた現場の確認を行わないと、実現イメージがすり合わずに後々変更や追加要望が多発することが予見されました。そのため、設計・開発は、アジャイルで行うことを検討しましたが、大規模な情報システムであるため、全てをアジャイルで構築しようとすると、管理コストが高くなる、要員の確保が難しい等の懸念がありました。

そこで、ＰＪＭＯは、マイルストーンを明確にした上で、アプリケーションをアジャイルで、インフラをウォーターフォールで開発、構築する計画としました。アプリケーションの設計・開発は、一ヶ月単位で計８回行う計画とし、その都度受入テストを実施します。そして、出来上がったアプリケーションを確認しながら改善要望を収集し、アプリケーションの機能やユーザーインタフェース等を見直していくことにしました。

![](../assets/ds-120-ch07-image3.png)

このような工夫をこらした結果、現場の要望を十分に反映した実用的な情報システムを計画どおりに構築することができました。

また、既存システムには、統計分析を行う基盤となるサブシステムがありましたが、分析の切り口を変える度に、当該サブシステムの改修や運用事業者へのデータ抽出の依頼でコストが掛かっていました。

そこで、更改にあたっては、この情報システムからデータを抽出するインタフェースを整備するとともに、職員自身がデータ分析をできるようにBIツールを導入しました。これによって、複雑なサブシステムがなくなりシステム構成がシンプルになったことで調達時の競争性が向上するとともに、改修費用も抑えることができるようになりました。

事例：設計・開発工程における利用者体験向上に向けた取組み

あるプロジェクトにおいて、各府省や自治体にまたがった業務をワンストップ化するサービスを実現するための情報システムを構築しました。当該システムの構築に当たり、利用者体験を特に重視し、可能な限り利用者に近い関係者を巻き込んだり、利用者の視点で情報システムをチェックしたりする工夫を行いました。

まず、従来利用していた紙の帳票の記載方法の説明は、紙への記載を前提としたものとなっていたり、法律用語をそのまま使っていたりしたために、わかりにくいものも多かったため、電子申請の導入に当たり、項目をリストから選択できるようにすることや利用者目線で作業がイメージできるようなメッセージで記載方法の説明を追加することなどを検討しました。そのために、このプロジェクトでは、設計段階からワイヤフレームやモックアップ画面を作成し、情報システムの動作や画面に表示される文言を各省や自治体の担当者に確認してもらうことで、仕様確定を促進しました。

また、このプロジェクトの担当者は、利用者体験を向上させるためには、情報システムから作業がイメージできるような適切なメッセージが出力されることが重要だと考えていました。そのため、利用者のストレスにならないよう、ユースケースに即して利用者の適切な行動を促すメッセージが出力されているかレビューを徹底しました。

一例を挙げると、業務のワンストップ化の一部である複数の段階を踏んで実施するオンライン申請においては、利用者は前段のオンライン申請時に通知される受付完了メッセージを見て、業務処理が完了したと勘違いし、すぐに後段のオンライン申請に進んでしまうことが想定されます。

しかし、本サービスにおいては、府省や自治体間で複数のデータベースを連携するので、受付の完了から業務処理の完了まで10分ほどかかります。そのため、後段のオンライン申請をすぐに実施した場合、業務処理が完了しておらず、「該当のデータがありません。自治体の窓口を訪問してください。」というエラーメッセージが出力され、利用者の混乱を招くおそれがあることが分かりました。

そこで、利用者がとるべき行動とメッセージの内容が合うように受付完了メッセージにおいて、「受付完了しました。他の情報システムにデータを登録するため、15分程度経ってから後続のオンライン申請を行ってください。」という趣旨のメッセージに修正し、かつ、後続のエラーメッセージも「後続の申請を行うためのデータがありません。最初のオンライン申請が行われていない、又は最初のオンライン申請後データが登録中の可能性があります。最初のオンライン申請を行う、又は15分程度待って再度アクセスしてください。それでもエラーが解消されない場合は、自治体の窓口に問い合わせてください。」にしました。
- 事例7-3 設計・開発工程における利用者体験向上に向けた取組み - 参考7-2 アジャイル開発におけるテスト

参考：アジャイル開発におけるテスト

社会的影響が大きい情報システムをアジャイル開発で構築する場合は、小さなバグでも大きな問題になりかねないため、スプリントやイテレーションで開発した機能等をそのまま市場にリリースすることが難しいことがあります。

このような場合に、リリースを内部リリースと外部リリースに分けるとともに、テストを複数チームで実施するという方法があります。スクラム開発を例にすると、内部リリース前に実施するテストはスクラムチームが担当し、内部リリース後、外部リリース前に実施するテストはスクラムチーム以外の第三者（第三者検証チーム、品質保証（QA）チーム、限られた内部のユーザ等）が実施するのが良いでしょう。

アジャイル開発は、ウォーターフォール開発と異なり段階的なプロセス定義をしないこともありますが、単体テスト・結合テストのようにテスト工程を分けることは難しい場合があります。それぞれのテストの要件や役割については、以下に示す「アジャイルテストの四象限」を参考に、各チームが実施するテストの対象範囲を明確にして、テストに抜け漏れが発生しないようにしておくことが重要です。

・「アジャイルテストの四象限」

出典：アジャイルテストの４象限とスクラムチームとしての活用方法

https://www.scrum.org/resources/blog/how-the-four-agile-testing-quadrants-support-scrum-teams-jp　を基に加筆修正

・「アジャイルテストの四象限」を踏まえて、テストをチーム分担する一例

![](../assets/ds-120-ch07-image5.png)

出典：同上

なお、テストの作業分担を定義した場合においても、品質については作業分担の垣根を越えてチーム全体で責任を持つ必要があります。

例えばスクラムチーム以外の第三者が把握すべき不具合が修正されないままリリースしてしまったとしても、スクラムチームも含め全体が責任を持ち、次に同じような不具合を起こさないための改善を全体で行います。
### 通常シナリオだけでなく、緊急時の対応計画も準備する 設計・開発のスケジュールを作成する際に、各工程が順調に進むことを前提とした楽観的なプランを１つだけ策定してしまうことが多くみられます。 実際にプロジェクトを進行する中では、予想していなかった様々な制約や問題が判明することもあり、スケジュール自体を大幅に見直すことも少なくありません。 このような際に役立つのが、緊急時対応計画（コンティンジェンシープラン）です。 緊急時対応計画の中では、予想していなかった問題が発生した際に後続工程の開始を遅らせたり、工程を分割して同時並行で進めたりするような形で、プロジェクトへの影響を最小限に抑えるための計画を準備します。このような計画を事前に準備しておけば、実際に問題が起こった際にも比較的冷静に正確な判断を行うことができます。 緊急時対応計画は、設計・開発工程だけでなく、情報システムが稼働した後の運用工程でも有効です。災害発生時等の緊急事態に際して、誰がどのように行動し何を優先して作業すべきかを定めます。 なお、緊急時対応計画と業務継続計画は類似する内容となりますが、緊急時対応計画は災害発生時の対応そのものに焦点を当てていることに対して、業務継続計画は災害発生後に必要となる業務を継続して実施することに焦点を当てているという違いがあります。 ### メンテナンス性を考慮した成果物の構成、内容を考える プロジェクトで作成される成果物は、調達仕様書でも指定されているとおり、多岐に渡ります。ここでは、その中でも特に重要な基本設計書に関して説明していきます。 システム開発においては、事業者に基本設計以降の工程を委託することが通常の形ですが、「Ｃ．設計・開発の全体と流れを理解する」でも説明しているとおり、事業者は設計の詳細化を行いながらシステム開発を進めていきます。そのような工程において、基本設計工程は、発注者から示される要件内容を理解し、実際のシステムの設計に落とし込む、という発注者―事業者間のインタフェースとなる工程になります。完成するシステムの良し悪しはこの工程、つまりアウトプットとしての基本設計書の内容により大きく左右される重要な工程になります。本当に要件を正しく反映したシステムができるか、使いやすいシステムができるか、あるいは保守・運用を効率良くかつ長期に維持していくためのシステムができるか、などまさに「システムの命運を握る設計図」を作成していくということになります。 また、基本設計書は要件を実現するための設計図のみならず、システムを品質良く完成させるためのテストのためのインプットドキュメントであり、保守・運用フェーズにおいては設計変更等の「要」となるドキュメントでもあります。 - 図7-4 基本設計書の位置づけ ![](../assets/ds-120-ch07-image6.jpg) 特に留意する事項としては、 - データと機能・処理の連携を含めた全体を俯瞰できるドキュメントになっているか - データに関する設計・定義事項が一元的に漏れなく記載されるようになっているか など、要件を反映した全体像の把握とデータ利活用・連携の観点からデータに関する設計・定義状況の把握が容易なメンテナンス性の高いドキュメント構成、内容になっているかということです。 表7-5は基本設計書の構成例です。システムの特徴あるいは受託した事業者によって構成や内容は異なることもありますが、おおむね以下のとおりです。全体編、機能編、データ編等まずは全体構成を確認し、その上で観点や考慮点が満たされているか、あるいは分かりやすい目次構成になっているか等を十分に確認していきましょう。 - 表7-5 基本設計書の構成例 | 項番 | 目次 | 内容 | 備考 | |----|----|----|:---| | 1 | 全体編 | | | | 1-1 | システム全体図 | システム、業務、Ｈ／Ｗ，Ｓ／Ｗ，Ｎ／Ｗ等の各々視点から全体俯瞰する資料 | | | 1-2 | データの流れと機能構成 | データ及びその流れとそれぞれの機能との関係全体を記載 | | | 1-3 | 機能分割 | サブシステム構成、機能分割、処理方式など基本的な設計の考え方を記載 | マイクロサービス定義及び連携の設計コンセプトも記載 | | ・・・ | ・・・ | ・・・ | ・・・ | | 2 | 機能編 | | | | 2-1 | 機能・画面・帳票一覧 | 分割された機能を一覧として記載。また関連する機能と対応させた画面・帳票を一覧形式で記載 | | | 2-2 | 画面・帳票フロー | 画面、帳票と機能の流れ（展開条件、戻り条件など）を記載 | バッチの場合はジョブフローとして記載 | | 2-3 | 各機能別処理内容 | 機能毎の処理概要、入出力（データベース、ファイル、画面、帳票など）関連図、チェック／編集要領など定型標準フォームに記載 | オンライン、バッチ、共通機能（ＡＰＩ等）を処理／提供形態等により分ける。マイクロサービスごとの処理概要を含む。 | | ・・・ | ・・・ | ・・・ | ・・・ | | 3 | データ編 | | | | 3-1 | データモデル | 要件定義で作成した概念レベルのモデルを詳細化。全てのデータ（データベース、ファイル、テーブル等）を関連づけて記載 | | | 3-2 | データ一覧、データ定義／レイアウト | データベース、ファイル、テーブルなどのデータに関する説明（マスターデータ等の分類、標準化レベル等も記載） | 全てのデータ項目（コード含む）の意味定義も記載 | | 3-3 | CRUD | データと機能の処理別マトリックス。データの生成から更新、参照、消滅までのライフサイクルを記載 | | | ・・・ | ・・・ | ・・・ | ・・・ |