Scope3算定システムは安い買い物ではなく、導入後の乗り換えコストも大きい。デモ画面の印象ではなく要件で選ぶためのチェックリストです(移行タイミングの判断とコスト構造はExcel管理の限界を先にお読みください)。本記事では12項目の一覧に加えて、各項目をベンダーにどう聞けば実態が分かるか、RFPに書くべきこと、トライアル評価シートの作り方、価格交渉の観点まで踏み込みます。
要件チェックリスト12項目
| # | 要件 | 確認ポイント |
|---|---|---|
| 1 | 排出係数DBの更新 | 電力係数・原単位DB(IDEA等)の更新がベンダー側で自動反映されるか。過去年度の係数も保持されるか |
| 2 | 組織階層の管理 | 拠点・部門・連結子会社の階層を持て、組織改編の履歴を保持できるか |
| 3 | Scope3カテゴリ対応 | 自社の主要カテゴリの算定方法(金額ベース/物量ベース/一次データ)を全てサポートするか |
| 4 | データ収集ワークフロー | 各拠点への入力依頼・督促・承認の流れがシステム内で完結するか |
| 5 | 監査証跡 | 入力値の変更履歴、根拠ファイルの添付、承認記録が残るか(第三者保証の必須要件) |
| 6 | 一次データの受け入れ | サプライヤー実測値を製品・取引先単位で管理し、二次データと混在計上できるか |
| 7 | 既存システム連携 | 会計・購買・エネルギー管理システムからのデータ取込(CSV/API)が現実的か |
| 8 | 過去データ移行 | Excel時代の過去年度データを取り込み、基準年比較が継続できるか |
| 9 | 開示様式への出力 | SSBJ・CDP・温対法など提出先別の様式で出力できるか |
| 10 | 目標管理 | SBT目標に対する進捗(基準年比)を自動で追えるか |
| 11 | 価格構造 | 拠点数・ユーザー数・排出量のどれで課金されるか。自社の成長でコストがどう変わるか |
| 12 | 撤退可能性 | 解約時に全データをオープン形式でエクスポートできるか(ロックイン回避) |
各項目の確認方法 — ベンダーへの質問文例
「対応しています」という回答は情報量ゼロです。過去の実績・具体的な操作・制約条件を聞く形に変えると、製品の実力が見えます。番号は上の表に対応します。
1. 排出係数DBの更新
- 「直近の電力係数の改定は、公表から何営業日で反映されましたか」— 日数を即答できないベンダーは運用体制が弱い可能性があります
- 「2024年度の算定を今から再実行した場合、当時の係数が自動で使われますか。それとも手動で指定しますか」
2. 組織階層の管理
- 「期中に子会社を売却した場合、当年度は在籍期間分だけ計上し、前年度比較には注記をつける、という処理は画面上でどう行いますか」— 実演を依頼します
3. カテゴリ対応
- 「カテゴリ1で、同じ取引先について金額ベース推計と一次データを品目単位で使い分けられますか」(Cat.1の算定方法参照)
- 「対応済みカテゴリの一覧ではなく、各カテゴリで選べる算定方法の一覧をください」
4. 収集ワークフロー
- 「未提出の拠点への督促は自動ですか。督促の文面・頻度は変更できますか」
- 「拠点担当者はログインが必要ですか。ライセンス費は入力専用ユーザーにもかかりますか」— 費目11に直結します
5. 監査証跡
- 「第三者保証を取得した顧客は何社ありますか。保証機関から求められた証跡で、システムから出せなかったものはありますか」— 後半の質問が本命です
6. 一次データ
- 「サプライヤーから受領した原単位の出典・算定年度・検証有無をデータに紐づけて保持できますか」(一次データと二次データ参照)
7. 既存システム連携
- 「当社の会計システムは◯◯です。同じ構成での連携実績はありますか。CSV取込の場合、列マッピングは保存できますか」
8. 過去データ移行
- 「移行用のテンプレートを見せてください。過去3年分の移行にかかった顧客の平均工数はどの程度ですか」
9〜10. 出力・目標管理
- 「SSBJ様式の出力サンプルを実物でください」「SBT進捗(SBT分析参照)は基準年の再計算(組織改編時)に対応しますか」
11〜12. 価格・撤退
- 「3年後に拠点数が1.5倍になった場合の料金シミュレーションをください」
- 「解約時のエクスポートで出力されないデータは何ですか」— 添付ファイルや変更履歴が出ない製品は珍しくありません
RFP(提案依頼書)に書くべき項目
候補を2〜3社に絞ったらRFPを出します。A4で5〜10枚あれば十分です。最低限、次を含めてください。
- 自社の現状 — 拠点数、連結範囲、算定済みカテゴリ、現在のExcel運用の概要、年間の算定スケジュール
- 絶対条件(3つまで) — 満たさなければ選外となる要件を明示。全12項目を「必須」にしない
- ユースケース記述 — 「経理部が四半期ごとに購買データをCSVで取込み、環境部が承認し、監査法人が証跡を閲覧する」のように登場人物と頻度つきの文章で書く。機能名の羅列より、認識のずれが減ります
- データ量の前提 — 年間の仕訳件数・品目数・サプライヤー数の概数。価格見積りの精度が上がります
- 見積りの内訳指定 — ライセンス・初期設定・データ移行・教育を分けて提示するよう指定。総額一式の見積りは比較できません
- 回答期限と選定スケジュール — トライアル期間を含めた全体日程
トライアルの評価シート例
トライアルは必ず自社の1拠点分の実データで行います。デモデータは常に美しく動きます。評価は印象ではなく採点表で行い、複数人で独立に採点して持ち寄ります。例として次のような形です。
| 評価項目 | 確認内容 | 配点例 |
|---|---|---|
| データ取込 | 自社の購買CSVを、何分・何ステップで取り込めたか。エラー時の原因表示は分かるか | 25 |
| 算定の再現 | Excelでの前年度算定結果と一致するか。差異の原因を特定できたか | 25 |
| ワークフロー | 依頼→入力→承認を実際に回せたか。拠点担当役の社員が説明なしで入力できたか | 20 |
| 証跡・出力 | 変更履歴の確認と開示様式の出力を実施できたか | 15 |
| サポート品質 | トライアル中の質問への回答速度と的確さ | 15 |
特に「算定の再現」は重要です。Excelとシステムで数字が合わない原因(係数の版、按分ロジック、丸め)をトライアル中に特定できれば、本導入後の並行運用が大幅に短縮されます。
トライアル運用の注意点
- 期間は2〜4週間、課題を決めてから始める — 「触ってみる」だけのトライアルは印象評価に戻ります。上の採点表の項目を事前にベンダーへ共有し、必要なデータ(前年度の1拠点分の購買CSV、Excelの算定結果)を初日に揃えます
- 採点者は3役を混ぜる — 算定担当(推進室)、入力担当(拠点)、承認担当(管理職)で使う画面が違います。推進室だけの採点は偏ります
- 質問の記録を残す — トライアル中にベンダーへ聞いた質問と回答は一覧化しておきます。回答の速度と正確さは導入後のサポート品質の予告編であり、そのまま採点根拠になります
- 同一データで横並び比較 — 2社を比較する場合は必ず同じ拠点・同じ期間のデータを使います。データが違うと所要時間もエラー率も比較できません
比較表は「事実」と「評価」を分けて書く
候補間の比較表を作る際は、列を「事実(回答・実測値)」と「評価(点数)」に分けます。「係数反映: ◯」ではなく「係数反映: 直近改定を5営業日で反映(ベンダー回答)/評価4点」のように、根拠が後から辿れる形にします。稟議で経営層から「なぜこちらなのか」と問われたとき、印象の◯×表は説明になりませんが、事実つきの表はそのまま答えになります。ベンダーの回答は日付とともに記録し、契約時の前提条件として提案書に残してもらうと、導入後の「言った言わない」を防げます。
選定体制 — 誰を巻き込むか
算定担当だけで選ぶと導入後に詰まります。最低限、次の関係者を選定段階から入れてください。
- 情報システム部門 — セキュリティ審査(クラウド利用規程・データ所在地・認証方式)は契約直前に始めると1〜2か月の手戻りになります。候補が2〜3社に絞れた時点で審査を並行させます
- 経理・購買部門 — データ連携元の当事者。「そのCSV、月次で出せます」の一言を選定前に取っておかないと、項目7の前提が崩れます
- 拠点担当者1名 — 入力側の代表。トライアルの採点者として参加してもらいます
- 監査法人・保証機関(予定がある場合) — 第三者保証を視野に入れているなら、証跡要件について事前に相談しておくと、項目5の確認が具体的になります
価格交渉の観点
- 複数年契約と引き換えの単価 — 年契約より2〜3年契約の方が単価は下がるのが通例。ただし項目12(撤退可能性)を確認してから縛りを受けること
- 初期設定費の内製化 — 組織設定やマッピングを自社で行う分、初期費を下げられないか聞く。前記事の設計ルールが整ったExcelがあれば現実的です
- 段階導入 — 初年度は主要カテゴリのみ、翌年度にCFPモジュール追加、のように機能を段階契約にして初年度負担を抑える
- 入力専用ユーザーの扱い — 拠点担当者分の課金有無は総額を大きく左右します。無償枠の交渉余地はよくあります
- 値引きより条件 — 単純値引きが難しい場合、データ移行支援の無償化や教育回数の追加など、工数の重い部分の支援で実質を取る方が効きます
契約前の最終確認と、導入後の評価
契約書の段階では、(1)解約時のデータ返却の形式と期限が条文にあるか(項目12を口頭合意で終わらせない)、(2)SLA(障害時の復旧目標)と算定繁忙期のサポート体制、(3)係数DBのライセンスが自社契約かベンダー包含か、の3点を必ず条文で確認します。導入後は「収集にかかった日数」「督促メールの件数」「開示資料作成の工数」を導入前と比較できるよう、移行前の現状値をいま記録しておくことをお勧めします。効果を数字で示せると、翌年度以降の予算確保と機能追加の稟議が格段に通りやすくなります。導入初年度は並行運用で工数がむしろ増えるのが普通なので(コスト構造の解説参照)、評価は2年目の数字で行う、と最初に決めておくのが公平です。
ポイント: システム選定の失敗は「機能不足」より「運用が回らない」で起きる。質問は「対応可否」ではなく実績と実演で聞き、絶対条件3つのRFPと実データのトライアル採点表で決める。価格は内訳を分解してから交渉する。