Neo story
000

CASE/金融/カード/システム企画

基幹システム更改に
ともなうRFP作成と提案評価

サポート終了を起点に始まった更改で、現行の何が問題かを分解し、要求事項に落とし、複数社の提案を同じ物差しで比較して選定と起案まで担当しました。

Client
国内カード事業者
Period
会計・ID権限管理の2案件
Role
発注側の企画担当として一貫
Output
RFP一式・要求一覧ほか
<- 実績一覧

※ 守秘義務に配慮し、企業名・ベンダー名・製品名・個人名はすべて伏せ、金額・件数・工数・期日は桁と単位のみを残しました。掲載しているのは要求の分解の仕方と評価の考え方であり、実際の要件定義書・提案書・見積書の内容ではありません。ご面談では差し支えない範囲でより具体的にお話しできます。

「同じ土俵で比べられる状態」を要件側で作る

PROBLEM比べられなかった各社の提案を並べても、前提も見積の粒度も違い優劣を判断できない。要件が本文に散っていたため
ACTION回答欄を指定した要件を別紙に一覧化し、回答列と入力不要列を色で指定。見積の分け方まで指定して配布した
RESULT差分の確認になった同じ形で回答が返り、比較が読み比べではなく差分の確認になった。失格条件も先に明示した
4層で要求を分解
4段階の記号評価
2段で合否と加点
2系統の契約形態
7課題に紐づけ

価値の中心は製品を選んだことではなく、比べられる状態を要件側で作ったことにあります。

「サポートが切れる」は理由ではあっても、要件ではない

期限だけを理由に同じものを作り直せば、現状の非効率はそのまま持ち越されます。そこで背景から問題へ、問題から課題へ、課題から要求事項へと落とす4層の構造でRFPを組みました。

背景基盤の保守期限が同時に到来。延長サポートで追加費用が発生し、新規のパッチも適用されない状態
問題データが正規化されておらず連携先が増えるたびに改修が発生。更新者と更新日時を保持せず、誰がいつ何を変えたかを追えない
課題保守性・拡張性の向上、人事異動への追随、手作業オペレーションの廃止、調査時間の短縮など7つに集約
結果課題管理表に溜まっていた個別の不満も、この課題番号に紐づけて回収した

「管理画面で完結させたいが、応答が遅いため一度書き出してから絞り込むという非効率が残っている」

現行を測る → あるべき姿を描く → 要求に翻訳する

最初にやったのは、現行の業務とシステムを一枚の全体図に落とすことでした。業務の塊ごとに、どこが自動でどこが手作業かを図の上で色分けしています。

第1段 / 分析

現行分析とあるべき姿の整理

全体図を現状で作成し手作業箇所を特定。課題管理表の個別要望を突き合わせ、原因がデータ構造にあるものと運用ルールにあるものを切り分ける。

第2段 / 方針

統合可否の判断と更改方針の確定

既存システムへの集約や共通基盤への相乗りを先に潰す。そのうえで更改方針を3本に定め、目的に紐づける。

第3段 / 調達

RFP作成・配布と提案評価

本体に背景・課題・前提・制約を書き、要求事項は別紙に一覧化。受領後、評価軸に沿って比較し、選定理由とともに上程する。

同じ図で現状とあるべき姿を並べるやり方を課題ごとに繰り返し、要求事項をその図から機械的に導けるようにしました。

要件は「本文」ではなく「回答欄付きの一覧」に置く

RFP本体には背景・目的・範囲・契約事項を書き、要件そのものは別紙に外出ししました。回答列を指定し、入力不要の列は色で明示。回答形式まで指定したのは、各社の回答を機械的に横並びできるようにするためです。

区分何を定義したか求めた回答
業務・機能要件業務領域別に要求事項を列挙。階層で業務機能を分解し、新規/既存の区分を付与実現可否と実現方法を所定の列に記入
非機能要件可用性・性能・保管期間・復旧目標を数値で明記。求めない範囲も明示充足可否と、充足できない場合の代替案
サービス水準運用として何をどこまでやるかを3階層で定義。監視は対象レベルごとに分解提示可能な水準と、提供体制
セキュリティ・職務分掌機密度区分に基づき環境ごとに機能を制限。機密情報を扱う権限と外部持ち出し権限の重複保有を禁止チェックリストへの回答と、抵触時に理由まで返せるか
役割分担工程ごとに主担当・確認・支援を記号で表にする各工程の役割分担と成果物

要件を本文に散らさず一覧に置いたことで、提案の比較が「読み比べ」ではなく「差分の確認」になりました。

評価は、提案を受け取ってから作るのでは遅い

合否と加点を二段に分けました。必須要件を一項目でも欠けば失格とし、加点評価は通過した提案だけに行います。これで評価に恣意が入る余地が狭まります。

0RFPの段階で揃える構成は自由としつつ記載必須項目を指定。見積の分け方(開発/保守開発/運用、請負/準委任)まで指定する
1必須要件の確認遵守確認がすべて満たされ、かつ提案が具体的に示されている場合のみ通過。一項目でも欠ければ失格
2加点評価充足度を「x件中x件」で数え、性能・計画・運用水準・単価・費用・契約形態を4段階の記号で評価
3総合判定技術と価格を合わせて選定し、選ばれた理由と落ちた理由の両方を起案資料に残す

コストは総額と期間を揃えて比べる

  • 総額で揃える単年ではなく総額のレンジで記号に変換。契約年数が異なる提案が並んでも判断できる
  • 差の理由を書く構成によって追加購入が必要になる差は、理由付きでコスト欄に併記する
  • 自社見積も含める提案側の見積だけでなく、自社が別途負担する費用も評価に含めると明記する

落ちた理由が残っていることが、後から効いてきます。

納品したもの

現状分析から選定・起案までを、他の人が読んで判断を再現できる形で文書化しました。判断の分かれ目になった箇所は、結論だけでなく比較の過程を残しています。

配布したもの(提案側が読む)

  • 提案依頼書(RFP) 背景・課題・前提・制約・提案項目・契約事項。冒頭に用語集を置く
  • 要求事項一覧(別紙) 領域別シートに分け、回答列と入力不要列を色で指定
  • チェックリスト・質問票 セキュリティ要求への回答様式と、質疑応答の様式

残したもの(社内が読む)

  • 現状/あるべき姿の全体図 同一の配置で並べ、自動化される業務を一対一で対応
  • 統合可否の評価資料 既存システムや共通基盤への集約可否を機能項目別に理由付きで判定
  • 投資起案資料 更改方針、製品比較、投資回収の算出、体制、申し送り事項

「なぜ買ったのか」の説明が、後から要らなくなる状態にしました。