Step.4 調達仕様書以外のドキュメント作成

調達を行うためには、調達仕様書以外にも、契約書をはじめ様々なドキュメントが必要となります。ここでは、特に重要となる契約書と総合評価落札方式による調達に必要となる提案依頼書について、説明していきます。

プロジェクトに合わせた契約書を作る

【標準ガイドライン関連箇所：第３編第６章第３節2)】

契約書は、会計担当部門等の契約を所管する部門が作るので、ＰＪＭＯはあまり関係がない。そう思っていませんか？

そんなことはありません。契約書に記載される内容によっては、プロジェクトの遂行に大きな影響を与えることもあります。契約書の作成に当たっての特に重要な確認・調整のポイントは次のとおりです。

調達仕様書と契約書の整合性を確認する

調達仕様書の記載事項には、場合によって契約書に同様の事項を記載することがあります。これらの内容について調達仕様書と契約書でそごが生じている場合、後々問題となることもあるので、契約書を所管する部署と事前に意識合わせを行い、調達仕様書との記述の住み分けを決めておくことが重要です。

調達仕様書の中で特に確認すべき事項を以下に示します。

契約書との整合性を特に確認すべき調達仕様書の内容

標準ガイドライン「第３編第６章２．1)キ成果物の取扱いに関する事項」の知的財産権の帰属、契約不適合責任、検収等に関する内容
標準ガイドライン「第３編第６章２．1)ケ再委託に関する事項」の再委託の制限及び再委託を認める場合の条件、承認手続、再委託先の契約違反等に関する内容
標準ガイドライン「第３編第６章２．1)コその他特記事項」の調達仕様書の変更手順等に関する事項

提案依頼書の内容を工夫する

【標準ガイドライン関連箇所：第３編第６章第４節1)】

総合評価落札方式で調達を行う場合は、提案依頼書の作成が必要となります。調達案件を確実に、かつ効果的に履行できる外部事業者を選定することは、簡単なことではありません。

しかし、提案依頼書の作成の際に、いくつかのポイントを押さえることで、効果的に適切な外部事業者を選定する審査を行うことができるようになります。特に重要なポイントは次のとおりです。

具体的な作業計画を評価する

提案書の内容だけでは、応札事業者が本当に調達案件を履行する能力があるかどうかを判断するのは難しいものです。特に大規模な情報システムや関係者が多数いるような情報システムの構築は、プロジェクトの計画能力や管理能力がとても重要になりますが、提案された体制や要員スキル、過去の実績からだけでは、評価が難しいのが現実です。

外部事業者の技術力を適正に評価するためには、具体的な作業計画の案の提出を求めて評価することが効果的です。

事例6-8

事業者の設計・開発実施計画書の作成能力に問題があった例

ＷＢＳ等のプロジェクトで行うべき作業の一覧、それらの順序やスケジュールなどを計画した文書の提出を求めることは、当該プロジェクトの背景や内容に関する応札者の理解度、プロジェクト計画を含む管理能力及び履行能力を示す指標となります。

ＷＢＳの精度については、総合評価落札方式の技術点としても審査することも可能ですし、最低価格落札方式においても入札参加資格の要件の一部としてＷＢＳの案の提示を求めることにより、事前に審査を行うことが可能です。

ＷＢＳの計画の妥当性を判断できる例を次に示します。

ＷＢＳを精査する

ＷＢＳには大きくプロセスベースと成果物ベースの２種類がありますが、基本的には成果物ベースで作成することを推奨します。仮にある情報システムが４つの独立したサブシステムで構成されていたとすると、最後の総合テストはこの４つのサブシステムを統合した状態でテストを行いますが、その手前では４つのサブシステムは各々準備が整い次第、サブシステム内の総合テストを実施します。準備が整い次第とは、その配下の全ての機能における結合テストが完了したことを指します。さらに、結合テストはその配下の全てのモジュールの単体テストが完了次第、逐次結合テストを実施します。そのように考えると、単体テスト、結合テスト、総合テストそれぞれが１つずつのＷＢＳというのではなく、上流テスト工程に向けて徐々に行（タスク）が集約されてゆくようなピラミッドイメージのＷＢＳとなるはずです。「図6-7 テスト工程の名称を羅列しただけのＷＢＳ」はネットに転がっているようなテンプレート的なＷＢＳで、こんなものは調達仕様書の中身をよく検討しなくても機械的に割り当てるだけで作れてしまい、ＷＢＳとして「手抜き」以外の何物でもありません。

図6-8 テスト工程の名称を羅列しただけのＷＢＳ

通常、５～20程度のサブシステムが存在するようなシステム規模であれば、サブシステム数の10倍程度の機能数の結合テストは必要となります。確かに全くモジュール分割されずに１サブシステム１機能１モジュールなら、単体テスト→結合テスト→総合テストが順に隙間なく並びますが、多くの場合、結合テストは五月雨に始まって順次終了することになります。開発要員が少人数の場合は、プログラマーが希少資源となるので、単体テストは同時並行ではなくプログラマーの数以上に並列化できません。逆に大規模開発の場合であっても設計者が各サブシステムに固定化されて案件ごとに柔軟に要員を増加できないこともあるので、やはり全てのモジュール、機能が同時に単体・結合テストを開始・終了することはありえないのです。

図6-9 成果物（＝機能）単位に分解されたＷＢＳ

普通にＷＢＳに分解すると「図6-8 成果物（＝機能）単位に分解されたＷＢＳ」のようになります。左上１列目がサブシステム、２列目が機能、３列目がモジュール単位です。まずコーディング・単体テストを一緒に実行し（水色のボックス）、機能の下位のモジュールについて全て完了した後で結合テストを実行し（黄緑色のボックス）、サブシステムの下位の機能について全て完了した後でシステムテスト（オレンジのボックス）を実行します。さらに担当者によっては１機能が終わった後で次の機能に着手する場合もあり、これらの順次処理を→で表記しています。「テンプレート的な標準ＷＢＳ」である図6-7と比べると検討の深さが違い、プロジェクトの実現性が十分担保されています。

ＷＢＳの妥当性が疑われる例

テスト工程を羅列しただけになっている。
単体テスト、結合テスト、総合テストそれぞれが１つずつで、それぞれの関係性がわからない。
開発要員が少人数の場合に、単体テストがプログラマーの数以上に並列化されている。

ＷＢＳの妥当性があると判断できる例

成果物（＝機能）単位に分解されている。
20～200ぐらいの機能（あるいはこれ以上の数ならサブシステムに分割する。）に切り分けられている。
サブシステムが複数ある場合、結合テストはサブシステム数の10倍程度の機能数分ある。
単体テスト、結合テスト、総合テストの関係性がわかる。
多くの場合、結合テストは五月雨に始まって順次終了する計画になる。特に大規模開発の場合、設計者が各サブシステムに固定化されることが多いので、全てのモジュール、機能が同時に単体・結合テストを開始・終了することはありえない。

ただし、これらの評価には専門的な能力が必要となりますので、適正な評価ができる審査体制を組成することを忘れないでください。

加点の配分を工夫する

総合評価落札方式では、公正性・透明性を確保するために、評価基準となる評価事項ごとの配点を事前に決める必要があります。しかし、やみくもに（例えば均等に）配点すればよいわけではありません。

参考6-3

総合評価落札方式の加点配分について

技術審査を行う際は、当該調達で何を重視するかをよく検討し、重視する項目に対する優れた提案に高い配点がされるように検討する必要があります。配点に関する工夫を次に示します。

配点に関する工夫

基礎点の合計と加点の合計の割合は、基礎点の合計の割合を最低限にして、加点の割合を高くする（基礎点の割合が高い場合、実質の価格競争となるため）。
評価事項ごとに均等に配点するのではなく、プロジェクトで重視する評価事項に加点が多くなるように配点する。
一つの評価項目に対しても、評価が高ければ加点が大きくなるよう、加点に傾斜をつける。

なお、審査で重視する項目を設定する場合は、プロジェクトの目的に応じて発注者として期待する内容が応札者に適切に理解された上でそれが応札者の提案に反映されるよう、調達仕様書及び要件定義書とも整合を図ることが大切です。

情報システムの調達では、ライフサイクルコストを評価することが重要です。ライフサイクルコストを評価するためには、整備経費だけでなく、運用等経費も考慮する必要があります。調達の対象となる工程ごとに、評価方法を次に示します。

調達の対象が設計・開発工程のみの場合価格点では整備経費のみを評価せざるを得ませんが、以下の方法により、運用等経費を評価します。
- 事業者が効率的に運用・保守作業を進める工夫を技術点として加点する項目を設定することで、経費を定性的に評価する。
- 運用・保守作業の実施内容と、ライフサイクル全体で見るとどの程度コストを低く抑えられるかを示す想定コストを技術点として加点する項目を設定することで、経費を定量的に評価する。
調達の対象に設計・開発工程だけでなく、運用・保守工程も含まれる場合整備経費と運用等経費の両方を価格点で評価できます。ただし、調達の対象となる期間がライフサイクル全体をカバーしていない場合は、前述の設計・開発工程のみの場合と同様に、運用等経費を評価します。