大規模システムの
調達支援とベンダー選定
市場に何ができるかを先に確かめ、その回答を前提に方式と範囲を確定し、最後に評価できる形で提案を求める。聞く・決める・問うを三つの文書に分けて設計しました。
- Client
- 公共性の高い事業体
- Period
- 約xxヶ月・3段階で実施
- Role
- 調達の設計から評価基準まで
- Output
- 計画書・依頼書ほか6点
※ 守秘義務に配慮し、発注機関名・事業者名・製品名・個人名およびシステムの固有名称はすべて伏せ、数値は桁と単位のみを残しました。事業の内容が特定できる固有名詞は業務の性質だけを残して一般化しています。掲載しているのは調達の進め方と要求の組み立て方に限られます。
聞く・決める・問うを、三つの文書に分ける
文書を分けたことで、決めた順序が後から追える状態になりました。
「積み上げた機能を、棚卸しできていない」
現行システムは再構築・更改・移行を重ね、安全性と信頼性を優先して機能を足し続けてきました。その結果、どの機能が実際に使われているかを示す資料がなく、削る根拠を誰も持てない状態にありました。
同時に、系統をまたぐ調整も属人化していました。センター系・拠点端末・回線が別々の事業者に委ねられる前提でありながら、誰が全体を束ねるかは文書化されていなかったのです。
「過剰な機能・運用がないか、機器は適正規模となっているかという観点で再点検を行う必要がある」
聞いてから決め、決めてから問う
市場に何ができるかを先に確かめ、その回答を前提に方式と範囲を確定し、最後に評価できる形で提案を求めました。三段階を別々の文書として分離したことが、この案件の骨格です。
市場に何ができるかを聞く
系統別に記載依頼事項を分けて提示。概算価格は全体・明細・年度別の3表に分解して回答させる。現行端末の実演を開催し、質問を複数回に分けて往復する。
方式と範囲を決める
背景・課題から要件・運用・体制までを章立てで確定。調達区分と責任分界点、統括管理の担い手を明記する。機能削減の候補を別紙化し、削る根拠を文書に残す。
評価できる形で問う
系統ごとに依頼書を分け、記載依頼事項を規定。必須要件の確認表で合否を先に切る二段構成にし、質問とヒアリングの時間まで設計する。
先に聞かずに仕様を固めると、市場にできないことを要求してしまいます。
現行を測ってから、要求に翻訳する
要求は理想から書かず、現行の実測値を先に置きました。故障率、応答時間、駆付時間といった数字を評価の基準値として示し、次期はそれと同等以上、という形で要求を立てています。
削る側も同じ作法をとりました。二つの実績調査を根拠に削減候補を別紙化し、端末側では削減の提案そのものを要求に含めています。
| 要求領域 | 測った現行 | 次期の要求の書き方 |
|---|---|---|
| 応答性能 | 端末・回線・センターの内訳ごとの秒数 | 合計の上限を秒で明示。内訳の配分も示す |
| 可用性 | 切替の所要時間、データ同期の方式 | 切替時間の上限、データ欠損なし、業務の縮退なし |
| 保守品質 | 駆付時間の達成率、平均故障回復時間、故障率 | 現行の評価基準値と同等以上を明示 |
| 問合せ対応 | 放棄率、平均応答秒数、一次回答率 | 同等以上。判定の対象外とする条件まで定義 |
| 機能削減 | 利用頻度調査・運用作業調査の結果 | 削減候補を別紙化し、削除の提案を求める |
測れない要求は書かない。書いた要求は必ず測る。
線を引くより、束ねる人を先に決める
既存の系統境界をそのまま調達単位にしました。移行時の調整相手が増えないためです。分界点も現行踏襲とし、更改と同時に動かして障害時の切り分けが曖昧になることを避けています。
境界をまたぐ取り決め
- 三者・四者で合意する事業者の選定後、発注側を含めた合意を交わす
- 段階ごとに締結する覚書は開発段階と運用段階で、それぞれ別に締結する
- 提供元を決めておく系統間の通信基盤は、センター系の事業者が端末側へ提供する
境界を引いた分だけ、束ねる責務を明文化します。
納品したもの
情報提供から提案依頼までを、役割の異なる文書群として設計しました。各文書は本体と別紙に分かれ、本体には手続きと判断基準を、別紙には現行実績・記入様式・評価基準を置いています。