← 一覧に戻る

要約カード

JA 2026-04-22 23:00
RFPセキュリティ強化外注

TechSolutions社の図面管理ツールリファクタリング依頼。RFPが整えた、急ぎの外注が陥る落とし穴と、正しい仕様書が引き寄せる正しいベンダー。

ROI事件ファイル No.482『署名が止めた十七本のツール』

JA 2026-04-22 23:00

ICATCH

署名が止めた十七本のツール


第一章:動かなくなった自動化

「十七本のツールが、ある朝いっせいに動かなくなりました」

TechSolutions社の情報システム部長、森本健司氏は、そう言いながらサーバーのログ画面を指した。画面には赤い文字でエラーが並んでいる。HTTPS署名エラー、認証タイムアウト、アクセス拒否——原因は全て同じだった。

「セキュリティ強化の一環で、社内システムへのアクセスに署名付きHTTPS通信が必須になりました」と森本氏が続けた。「結果、これまでSeleniumで動いていた自動化ツールが全滅です。十七本あります。社内システムへのログイン、データ取得、データ登録——全部止まっています」

「ツールはどなたが作りましたか」とClaudeが確認した。

「元社員です。三年前に退職しました」と森本氏が答えた。「VBAで書かれていて、設計書はありません。コードの中にコメントも少ない。何をしているか、コードを読めば分かるが、読むのに時間がかかる」

「業務への影響はどのくらいですか」と私は尋ねた。

「一本あたり、担当者が手作業で代替しています」と森本氏が答えた。「例えば、取引先から届くCSVの取り込みが毎朝一時間。元は五分で終わっていた。十七本すべてで、月間の追加工数は百二十時間を超えています」

「社内で作り直す選択肢は」とGeminiが尋ねた。

「ありません」と森本氏が即答した。「情シス部員は四名。通常業務で手一杯です。Pythonが書けるのは一名だけ、しかも他案件の兼務中。外注するしかない状況ですが、急ぎすぎて失敗するのが怖い」

「失敗というのは」とClaudeが確認した。

「以前、別件で外注したら、成果物がブラックボックスで返ってきました」と森本氏が答えた。「保守できない状態で納品されて、ベンダーに頼み続けることになった。今回は同じことを繰り返したくない。でも、急いでいる。このジレンマです」

「急いでいる時こそ、仕様書が必要です」と私が静かに言った。

第二章:RFPが問う提案の土俵

「この案件には、RFPが必要です」

Claudeがホワイトボードに三つの文字を書いた。R・F・P。

「RFPとは、Request For Proposalの略で、発注側がベンダーに提出する要求仕様書のことです」と私が説明した。「RFPの本質は、仕様を書くことではなく、比較の土俵を揃えることにあります。仕様書がない状態で複数ベンダーから提案を受けると、各社が自社の得意な切り口で提案してくるため、比較できません。RFPを作ると、全社が同じ土俵で提案を返してくる。急いでいる時こそ、この土俵を先に作ることが、手戻りを減らす最短距離です」

「まず現状のコストを測りましょう」とGeminiがROI Polygraphを開いた。森本氏から提供されていた業務記録を入力する。

「月間の代替コストが出ました」とGeminiが読み上げた。「十七本のツール停止により、担当者五名が月平均百二十時間を手作業に使用。時給三千円で月三十六万円。さらに、本来の業務への集中が阻害されることによる残業増加が月四十時間、月十六万円。ツール再構築を急ぐための焦りから生じる意思決定ミスの潜在コストを月五万円と仮置き。合計で月五十七万円が、ツール停止から発生する継続コストです。年間換算で六百八十四万円」

森本氏が計算結果を見つめた。「手作業の時間は数えていましたが、残業と焦りは数えていなかった」

「焦りが高くつくんです」と私が応じた。「では、RFPで設計します」


[RFP第一層——要件を分解する]

「最初に、十七本のツールを三つに分類します」とClaudeが言った。「第一に、業務影響が大きく、早急にリプレイスが必要なもの——推定五本。第二に、動かないが代替手段があり、緊急度が低いもの——推定七本。第三に、廃止を検討してもいいもの——推定五本。分類することで、外注の優先順位と範囲が決まります」

「全部を一度に発注しない、ということですね」と森本氏が確認した。

「そうです」と私が答えた。「全部を一度に出すと、ベンダー側も見積もりが膨らみ、納期も延びます。優先五本に絞って第一弾のRFPを出し、残りは第二弾以降に回す。段階発注は、急いでいる案件ほど効きます」


[RFP第二層——比較の軸を書く]

「RFPに記載する評価軸を決めます」とGeminiが続けた。「第一に、技術要件——PythonまたはUiPathでのリファクタリング、HTTPS署名対応。第二に、保守要件——納品時に設計書・コードコメント・運用手順書を必須添付。第三に、引き継ぎ要件——納品後三ヶ月間、社内メンバーへのコード解説セッション月一回。第四に、体制要件——担当者の連絡先を明示し、属人化しない体制を約束できること」

「保守要件が、前回の失敗を防ぐ部分ですね」と森本氏が確認した。

「そうです」とClaudeが答えた。「前回ブラックボックスになった原因は、RFPに保守要件が書かれていなかったことです。要件に書かれていないものは、納品されません。逆に、書かれていれば守られます」


[RFP第三層——候補を絞り込む]

「候補ベンダーは最初に広く集めて、絞り込みます」と私が続けた。「業界紙、技術コミュニティ、既存取引先からの紹介——十社前後から情報収集します。一次選定は実績確認のみ、VBAからPython・UiPathへの移行経験があること。二次選定でRFPを送付、提案書を返してもらう。三次選定で上位三社に絞り、役員面談で担当者と会う。この三段階で絞り込みます」


[RFP第四層——投資回収を試算する]

ROI Proposal Generatorで試算しましょう」とGeminiが提案した。

リファクタリング費用と削減効果が並んだ。

  • 初期費用:優先五本のリファクタリング費用四百五十万円、RFP作成・ベンダー選定工数社内換算五十万円、合計五百万円
  • 月次費用:保守サポート月八万円
  • 月次削減効果:優先五本再稼働による手作業削減=月二十八万円(百二十時間のうち九十時間相当)、残業削減=月十二万円、焦りコスト解消=月五万円、合計月四十五万円
  • 月次純削減:四十五万円-八万円=月三十七万円
  • 投資回収期間:五百万円÷三十七万円=約十三・五ヶ月

「一年強での回収です」とGeminiが整理した。「即効性は高くありません。ただし、残り十二本を段階発注することで、二年目以降は削減効果が上積みされます。また、設計書・運用手順書が揃うことで、将来のセキュリティ変更時にも同じ混乱を繰り返さずに済みます」

森本氏が数字を確認しながら言った。「急いで安く発注すると、将来また同じことが起きる。RFPに保守要件を書くと初期費用は上がるが、二年目以降の見えないコストが下がる——そういう構造ですね」

「急ぎの案件で、一番損をするのは急ぎすぎた発注です」と私が応じた。

第三章:仕様書が引き寄せるベンダー

「進め方を整理します」と私がホワイトボードの前に立った。

「第一週——十七本のツール分類と優先五本の選定。業務担当者にヒアリングし、停止影響の大きさで順位付け。第二週——RFP文書の作成。技術・保守・引き継ぎ・体制の四要件を明記。第三週——候補ベンダー十社への情報収集依頼と一次選定。第四・五週——上位五社にRFP送付、提案受領。第六週——三社絞り込みと役員面談。第七週——契約締結、開発開始。第十五週——納品、並行運用開始。第十七週——切り替え完了」

「三ヶ月以上かかりますか」と森本氏が確認した。

「かかります」とGeminiが答えた。「ただし、急いで一ヶ月で発注先を決めた場合、納品後に保守問題が再発すると、結局三ヶ月以上の手戻りが発生します。最初の三ヶ月で、二年目以降の手戻りを消す投資だと考えてください」

森本氏がノートを閉じながら言った。「急ぎすぎて失敗するのが怖い、と最初に言いました。怖さの正体が、今日言語化できた気がします」

第四章:同じ事故を、二度起こさない設計

九ヶ月後、森本氏から報告が届いた。

優先五本のリファクタリングは第十六週に納品、並行運用を経て第十九週に切り替え完了。選定したベンダーはRFPで指定した全要件を満たし、設計書・コードコメント・運用手順書・引き継ぎセッション録画を含めて納品した。森本氏の報告書にはこう書かれていた。「コードを開くと、なぜこの処理をしているかがコメントで読める。三年前のツールと比べて、別の世界に来た感覚がある」

残り十二本のうち、七本は第二弾として同ベンダーへ追加発注。五本は業務プロセス見直しにより廃止判断。「動かなくなったタイミングは、要否を見直す機会でもあった」と森本氏は書いていた。

並行稼働中、追加で社内システム側のセキュリティ仕様が一部変更された。新しい仕様でのテストが必要になった際、ベンダー側の担当者が二営業日で対応。森本氏いわく「以前ならパニックだった変更が、淡々と処理された」。

情シス部員四名の月次残業時間は、切り替え前の平均六十時間から、二十五時間に減少。ツール再稼働後、森本氏はメンバーに「本来の業務に戻ろう」と言ったと記されていた。

RFPを書いた三週間が、一年の混乱を防いだ日だった。

「急ぎの案件ほど、仕様書が効く。仕様書がない状態で集めた提案は、比較できない。比較できない提案の中から選んだベンダーは、納品後に揉める。RFPが設計するのは、比較の土俵だ。技術・保守・引き継ぎ・体制の四要件を書くと、ベンダーが同じ土俵で答えを返してくる。土俵の上で選ばれたベンダーは、土俵の約束を守る。署名が止めた十七本のツールは、仕様書が引き寄せたベンダーによって、設計書付きで戻ってきた。二度目の混乱が、起きなくなった」


関連ファイル

rfp

使用ツール

  • ROI Polygraph — ツール停止による代替コスト・残業コストの可視化
  • ROI Proposal Generator — 段階発注リファクタリングの投資回収シミュレーション

事件の概要をお聞かせください