Step.2 設計・開発を開始するための事前準備

ＰＪＭＯが、設計・開発の活動に適切に関与していくためには、最低限の知識とＰＪＭＯが果たすべき役割と責任を認識しておく必要があります。これらの内容は、要点を押さえれば、それほど難解なものではありません。

では、設計・開発の活動に必要となる前提知識や心構えを見ていきましょう。

設計・開発で職員が行うべき事を理解する

【標準ガイドライン関連箇所：第３編第７章第１節】

設計・開発の具体的な活動を行うのは、調達によって選定された事業者です。事業者は、調達仕様書及び附属資料である要件定義書をインプットに、設計・開発工程の活動を計画し、活動を行います。設計・開発工程の作業は、情報システムを対象とした専門的なスキル・経験が求められます。

では、職員が関与しなくても作業が順調に進むかというとそうはいきません。一般的に、職員の関与が低いほど、設計・開発の成功確率は低下します。

したがって、『専門的』でわかりづらい設計・開発工程の作業において、『職員が関与する』ことで効果がある作業とは何かを理解する必要があります。

まず、職員が作業に関与するに当たり、基本的な役割を以下に示します。

『設計・開発』を行う際の職員の基本的な役割

• 要件の内容を事業者に正しく伝える役割

• 要件どおりに情報システムができたかを確認（テスト）する役割

• プロジェクトの進捗状況を正しく把握し、スケジュールや関係者間において発生する調整を適切に行う役割

• 注記

  Fit&Gap 分析とは、パ ッケージ製品の機能が、発注者の要件に適合（Fit）している 点と乖離（Gap）している点を明らかにし、事業者の提供するパッケージ製品と発注者が求める要件との適合性を判断する分析手法のこと。

『要件の内容を伝える役割』

• 注記

  カスタマイズの範囲は、パッケージ製品の設定値の変更から機能改修まで多岐にわたるが、左記の文章におけるカスタマイズは、発注者から提示された要件に応じてパッケージ製品の機能改修を行うことを指す。

要件は、既に要件定義書としてドキュメントに取りまとめられています。事業者は、その情報を基に『どうやって作るか』を具体化する設計作業を開始し、徐々に詳細化していきます。その作業の過程で、要件定義書だけでは読み取れない発注者側の意図や要望について、発注者側は正しく伝達することが必要となります。また、設計をする中で見えてくる課題等の対応方法を決めることも必要です。例えば、設計書のレビューにおいて、発注者側の意図とそごがある部分や明確に理解されていないと思われる部分がある場合は、事業者との打合せの場を設け、認識そごを解消する必要があります。また、パッケージ製品等を導入する場合は、設計・開発事業者が提案した製品と業務とのFit&Gap分析に発注者が主体的に関与し、発注者と事業者の双方で製品と業務の適合性を確認する必要があります。Fit&Gap分析の結果、要件と乖離（Gap）している点に対しては、カスタマイズを行うことで要件に合わせるという選択肢もあります。ただし、カスタマイズ範囲を増やしすぎると、運用保守段階で変更が発生する度に当該機能の動作テストも行う必要があるなど、保守性を損なう可能性もあります。これらの長所、短所を勘案した上でカスタマイズ範囲を検討すること

• 注記

  文書や口頭で丁寧に説明を行ったとしても、伝達ミスや誤認等のコミュニケーションロスを完全に排除することはできない。

  このため、Fit&Gap分析を事業者に一任すると誤った要件の理解に基づいて分析が行われ、誤った結果が導かれる可能性があることから、発注者が主体的に関与することが必要。

が重要です。

この段階でコミュニケーションが十分にとれないと、いざ運用段階で実際に利用してみると使い勝手が悪かったり、手戻りが発生したりといった弊害を招きかねません。

以下の事例は、実際のプロジェクトで発生してしまった実例です。このような失敗をしないように留意してください。

• 事例7-1

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

• 参考7-1

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

• 注記

  プロトタイピングとは、情報システムを本格的に構築する前に、試作品（プロトタイプ）を作成し、実物を見ながら要件を具体化していく手法

『要件どおりに情報システムができたかを確認する役割』

構築された情報システムが、伝えた要件を満たすものになっているかを確認するのは職員の役割です。

もちろん、情報システムの様々な処理がきちんと動作できるのかは、職員が確認する前に、事業者がテストで十分に確認していることが前提となります。

テストにおいて職員に求められることは、テストすべき項目（テスト仕様書）をレビューし、内容の正しさをチェックすることと、事業者が実施したテストの結果を確認することです。

テストを実施する作業の中では、テスト項目に従って情報システムが正しく動作しているかどうかを確認していきます。テスト項目とは、情報システムにどう動いてほしいかの要求を詳細化したものです。これが間違えていたり、抜け漏れがあったりすると、情報システムが要求どおりに構築されたとは言えなくなります。したがって、職員は、テスト仕様書に目を通し、要求を反映したテスト項目となっているかを確認することが重要となります。

もちろん、テストには様々な種類が存在し、テストごとに職員の関わり方は異なります。詳細は「Step.3-3 テストの計画を立てる」を参照ください。

通常のテストは上記のとおりですが、受入テストは例外扱いで、職員自らがテストを実施する必要があります。

『プロジェクトの進捗状況を正しく把握し適切な調整を行う役割』

この役割は、発注者側の立場によるプロジェクト管理の一つとして、ＰＪＭＯに求められるものです。

設計・開発工程では、プロジェクト期間が長く、プロジェクト開始時には概要レベルの全体スケジュールを立案し、詳細な計画は、段階的に作成していくことになります。この作業を進める中で、様々な関係者が登場します。新たな情報システムを導入する際には、ほとんどのケースで業務を見直して、手順や内容の変更を行います。その過程で業務関係者間での調整がうまくいかないことは、プロジェクトの進捗を遅延させる要因となります。

また、プロジェクトには期間と予算の制約がありますので、どんなに良い方法であってもこれらの制約の関係で妥協しなければならないこともあります。

そのため、ＰＪＭＯは、プロジェクトを正常に進めるための調整が重要であることを認識し、その役割を担う必要があります。

設計・開発全体を通して理解すべき点とは

【標準ガイドライン関連箇所：第３編第７章第１節】

ＰＪＭＯが、発注者として設計・開発を適切に管理していくために、設計・開発の活動全体を俯瞰的に理解しておく必要があります。ここではその内容を説明していきます。

要件を理解した職員の継続的な関与がプロジェクトを安定させる

大規模なプロジェクトの場合、設計・開発工程だけで１年以上の期間が必要となることが多くあります。

要件定義において、多くの職員からの意見を集約し、様々な情報を分析して、新しい業務を決定しましたが、その全体像を理解している職員は、要件定義に関わった職員の中でもごく一部に限定されます。

このような職員は、プロジェクトにとって非常に貴重な存在です。設計・開発工程において、事業者に要件の全体像を説明し、要件追加変更に伴う影響度の調査を行うには、全体を理解していないとスムーズにできないからです。また、要件がどのような背景で発生し決められたのかの経緯を正しく理解していないと、誤った説明や安易な変更を行うおそれがあります。

こういった問題を発生させないためにも、要件定義に関わった発注者側の職員、特に業務を理解している業務実施部門の職員をプロジェクトの体制に参画させ続けられるよう、体制の組成時に調整を行うことは効果的です。

要求とコストと納期のバランスをとる

設計・開発の活動を進めていく中では、要件変更や当初計画からのかい離は、様々な要因により発生します。要因には、政権交代や世の中の情勢変化に伴う方針変更、連携する情報システムの要件変更等のプロジェクト外部で発生する要因や、設計として詳細化していく中で発覚した要件定義の誤りや受入テスト時に発見される要件の抜け漏れ等のプロジェクト内部で発生する要因があります。

このような場合に、「納期は絶対で、追加発注も不可能。でも、変更は受け入れて当初計画どおりに仕上げてください。」と指示を、建設的な議論をせずに行ったとしてもプロジェクトはうまく進みません。

事業者は、要件定義の内容、納期・スケジュールに基づいて、コストを見積り、計画を立てます。つまり、「要件（スコープ）」「コスト」「納期（スケジュール）」のいずれかが変更されると、ほかにも必ず影響が発生します。

では、「今年度の計画は変更できないので、追加や変更は全て来年度以降に先送りします」としても、そこに重要な要件が含まれている場合は、今年度出来上がった情報システムがまともに動かないリスクもあります。

これは、要件の変更だけではなく、スケジュールや納期の変更でも同様です。

では、このような場合にどう対処すればよいでしょうか？

これらを適切に管理するための仕組みが「変更管理」です。変更管理は、変更の必要性が発覚した際に、「変更に対する影響の調査」「影響度合いに応じた変更の決定の手続」等の変更に対する管理方法を定めるものです。まずは計画時に、これらを明確に定め、これに則り設計・開発工程作業中に発生する様々な追加変更を取捨選択していくことが大切です。影響度の判断によっては、当初の要件を諦め、新しく発生した要件と差し替える等、柔軟な対応が求められます。

設計・開発の全体像と流れを理解する

設計・開発の活動は、設計・開発・テスト・移行等のいくつかの作業工程に区切って進めていくことが一般的です。しかし、これらの工程の組み方は多種多様で、それぞれメリット・デメリット、向き・不向きがあります。ＰＪＭＯは、これらを踏まえた上で、事業者が立案した計画を理解して、プロジェクトにあった進め方となるよう、事業者に要望を伝えていきます。

ここでは、事業者の計画を正しく理解し適切な進め方を検討していくことができるよう、設計・開発全体の進め方に係る知識やノウハウを解説していきます。

設計・開発工程に含まれる全ての活動内容を俯瞰的に理解する

設計・開発では、様々な活動が行われます。事業者が作成するスケジュールを確認する際、まずは俯瞰的に工程の流れを押さえて、大きなそごがないかを見ていきましょう。

情報システムの設計・開発は、大まかに捉えると以下のような流れになります。

• 図7-1

工程の全体像

これらの活動ごとの成果物を洗い出し、その成果物を得るために必要な作業を細分化し、作業にかかる時間や作業順を当てはめていったものがＷＢＳに基づいたスケジュールとなります。ＷＢＳの確認については、「Step.3-2-E. ＷＢＳで作業計画を確認し進捗を把握する」を参照してください。

なお、工程の名称は、事業者によって呼び方が異なります。同じ名称でも、事業者によって捉え方が異なることがあるため、注意が必要です。工程の捉え方を間違えていると、適切な時期に求めたレベルの成果物ができていなかった、というようなことが発生します。

• 表7-1

標準ガイドラインと各社が定義する工程の比較

プロジェクトの特性（新規構築・更改等）によって、作業は異なる

設計・開発で行う作業の内容は、プロジェクトの特性によって異なります。例えば、情報システムを新規に構築するプロジェクトと既存情報システムの更改のプロジェクトでは、作業の内容が大きく変わります。

• 表7-2

プロジェクト特性の概要

また、一から情報システムを構築（＝スクラッチ開発）する場合、クラウドサービスの利用、パッケージ製品等の導入・カスタマイズでは、それぞれ活動の内容が異なってきます。例えば、クラウドサービス（PaaS）の利用では、機能に関する実装・テストよりも運用視点でのテストの比重が増えるかもしれません。

情報システムの更改を行うタイミングは、情報システムの機能を見直すに当たり、またとないチャンスです。現在のサービス・業務運営上の課題や既存情報システムの運用の中で寄せられた要望等を確認し、情報システムの機能改善を検討しましょう。なお、やむを得ない事情により、機能改修を伴わない更改を行うこともありますが、その際には機能の実装・単体テスト等を実施する必要がないかもしれません。このようなプロジェクトの特性に合わせて、作業内容の必要十分性を確認しましょう。

確認に当たっては、「Step.3-2 設計・開発の実施計画を立てる」で解説する設計・開発実施計画書のひな型を参考にして比較を行い、不足や不明点は事業者に確認して、事前に漏れや誤りをなくすようにしましょう。

プロジェクトの進め方や開発手法により作業内容も異なる

設計・開発の進め方には、様々なものがあります。以前は、情報システムの構築といえば、ウォーターフォール型で進めることが主流でしたが、ソフトウェア開発の過去の失敗事例等を踏まえて、様々な進め方が考案されています。

標準ガイドラインで定義するプロジェクトは、大きく以下の２つに分類できます。

• 表7-3

プロジェクト全体の進め方の種類

また、情報システムの開発手法も、複数あります。代表的な開発手法には、次のようなものがあります。

• 表7-4

開発手法の比較

ウォーターフォール型は従来型の開発手法ですが、その工程の中でプロトタイピングをとることも増えてきています。プロトタイピングとは、情報システムを本格的に構築する前に、試作品（プロトタイプ）を作成し、実物を見ながら要件を具体化していく手法です。ウォーターフォールでの開発においても、設計工程の中でプロトタイピングを導入することで、関係者からの意見を聞きながら要件をとりまとめやすくなります。

昨今、開発手法として増えているのがアジャイルです。現時点においては、開発工程全てにわたってアジャイル開発を貫いた事例はまだ少ないですが、部分的に設計工程においてモックアップ画面等を導入して仕様確定を

• 注記

「アジャイルソフトウェア開発宣言」とは、従来型のソフトウェア開発のやり方とは異なる手法を実践していた開発者・研究者が2001年に作成した、アジャイル開発を進める上での「マインドセット」が書かれたもの

促進するケースは増えてきています。アジャイル開発の進め方は、サービス設計12か条にある「何度も繰り返す」、「一遍にやらず、一貫してやる」といった視点に沿うものですので、積極的に導入を検討してみてください。

アジャイルの考え方の規範は、「アジャイルソフトウェア開発宣言」として一般に公開されています。

• 図7-2

アジャイル開発の基本的な進め方

一方で、形式だけでアジャイル開発を採用すると失敗することになりかねません。以下のような形だけのアジャイル開発にならないように気を付けましょう。

• 投げっぱなしアジャイル

発注者の要件を調達以前の段階で十分に定めず、要件自体を設計工程で決めるというように後送りにする方法。調達する事業者の能力や経験によって、構築できるシステムの機能や品質が大きく変わってしまう。特に、事業者の能力が十分でなかった際に、要件定義内容を元に改善指摘をすることが難しくなってしまう。

• 優先度をつけないアジャイル

設計を進める中で出てきた要件について、発注者が優先度の判断をせず、全てを実現することを求めてしまう方法。限られた工数の中で効果の大きい部分を選び出していくことがアジャイルの特徴であり、優先度を判断しないのであれば後出しした要件を全て実現させるという非合理的な契約形態となってしまう。

なお、アジャイルが適さないと言われているプロジェクトもあります。一般的には、大規模なプロジェクトやミッションクリティカルなプロジェクトはアジャイルに適していないと言われています。ただし、大規模なプロジェクトであっても部分的にアジャイルを適用することは可能です。

開発手法は、必ずしもプロジェクト全体で統一しなくてはいけないわけではありません。メリット・デメリットを理解して、特定の機能群についてはアジャイルで進める、というように「良いどこ取り」していくことも大切です。

• 事例7-2

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

• 事例7-3

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

• 参考7-2

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

通常シナリオだけでなく、緊急時の対応計画も準備する

設計・開発のスケジュールを作成する際に、各工程が順調に進むことを前提とした楽観的なプランを１つだけ策定してしまうことが多くみられます。

実際にプロジェクトを進行する中では、予想していなかった様々な制約や問題が判明することもあり、スケジュール自体を大幅に見直すことも少なくありません。

このような際に役立つのが、緊急時対応計画（コンティンジェンシープラン）です。

緊急時対応計画の中では、予想していなかった問題が発生した際に後続工程の開始を遅らせたり、工程を分割して同時並行で進めたりするような形で、プロジェクトへの影響を最小限に抑えるための計画を準備します。このような計画を事前に準備しておけば、実際に問題が起こった際にも比較的冷静に正確な判断を行うことができます。

緊急時対応計画は、設計・開発工程だけでなく、情報システムが稼働した後の運用工程でも有効です。災害発生時等の緊急事態に際して、誰がどのように行動し何を優先して作業すべきかを定めます。

なお、緊急時対応計画と業務継続計画は類似する内容となりますが、緊急時対応計画は災害発生時の対応そのものに焦点を当てていることに対して、業務継続計画は災害発生後に必要となる業務を継続して実施することに焦点を当てているという違いがあります。

メンテナンス性を考慮した成果物の構成、内容を考える

プロジェクトで作成される成果物は、調達仕様書でも指定されているとおり、多岐に渡ります。ここでは、その中でも特に重要な基本設計書に関して説明していきます。

システム開発においては、事業者に基本設計以降の工程を委託することが通常の形ですが、「Ｃ．設計・開発の全体と流れを理解する」でも説明しているとおり、事業者は設計の詳細化を行いながらシステム開発を進めていきます。そのような工程において、基本設計工程は、発注者から示される要件内容を理解し、実際のシステムの設計に落とし込む、という発注者―事業者間のインタフェースとなる工程になります。完成するシステムの良し悪しはこの工程、つまりアウトプットとしての基本設計書の内容により大きく左右される重要な工程になります。本当に要件を正しく反映したシステムができるか、使いやすいシステムができるか、あるいは保守・運用を効率良くかつ長期に維持していくためのシステムができるか、などまさに「システムの命運を握る設計図」を作成していくということになります。

また、基本設計書は要件を実現するための設計図のみならず、システムを品質良く完成させるためのテストのためのインプットドキュメントであり、保守・運用フェーズにおいては設計変更等の「要」となるドキュメントでもあります。

• 図7-4

基本設計書の位置づけ

特に留意する事項としては、

• データと機能・処理の連携を含めた全体を俯瞰できるドキュメントになっているか

• データに関する設計・定義事項が一元的に漏れなく記載されるようになっているか

など、要件を反映した全体像の把握とデータ利活用・連携の観点からデータに関する設計・定義状況の把握が容易なメンテナンス性の高いドキュメント構成、内容になっているかということです。

表7-5は基本設計書の構成例です。システムの特徴あるいは受託した事業者によって構成や内容は異なることもありますが、おおむね以下のとおりです。全体編、機能編、データ編等まずは全体構成を確認し、その上で観点や考慮点が満たされているか、あるいは分かりやすい目次構成になっているか等を十分に確認していきましょう。

• 表7-5

  基本設計書の構成例