英国の家電量販 Currys が、Microsoft と Accenture を組んでIT基盤の刷新を進めている。データセンター9拠点・サーバー2,000台超・アプリケーション200本を Azure へ移す規模の案件だが、その途中で英国のオンプレミスサーバー移行を繁忙期の手前で一度止めている。この記事では報じられた事実を整理したうえで、「止めた」という判断のほうを実務目線で読む。
要点
- 体制は、業務側の意思決定を Currys、クラウドとAIの基盤を Microsoft (Azure / Azure OpenAI Service)、全社変革とシステム近代化を Accenture、デリバリーに両社の合弁である Avanade。提携の公表は2024年5月9日。
- 移行対象はデータセンター9拠点、サーバー2,000台超、アプリケーション200本。契約金額・期間・費用対効果の詳細は非公表。
- 2025年夏、英国のオンプレミスサーバー移行を、2025年の繁忙期を前に一時停止した。理由は遅延と顧客体験への影響。結果として新旧環境の並行稼働が延び、二重稼働コストが追加で発生している。
- 外部委託先関連で狙う削減額は600万ポンド。ただしこれは広範なコスト効率化プログラムの一部で、Microsoft・Accenture 案件だけの効果ではないとされる。
- AI側の成果 (2026年7月時点) は、返品診断で40%が物理的な返品なしに解決、コールの書き起こしの半分をAIが分析 (人手で同じ量を見るなら80人分の追加工数に相当)、修理の現場技術者への故障診断・部品準備の支援など。最初のユースケースとして2023/24年にアフターサービス (返品・修理) を選んでいる。
- 9拠点すべての移行完了は、公開情報では確認できていない。
「繁忙期の手前で止めた」ことが一番の学び
刷新案件の記事は成功した数字だけが切り取られやすいが、この件で実務的に価値があるのは、移行を止めた判断が公開されていることだ。
受託開発の現場で移行案件をやると、必ず同じ場面が来る。予定より遅れていて、このまま押し切れば期日には間に合うかもしれないが、繁忙期に不具合が出れば売上に直撃する。ここで押し切る意思決定をした現場を何度か見たが、うまくいった記憶がない。遅延のコストは後から回収できるが、繁忙期に顧客体験を壊したコストは回収できない。
小売なら年末商戦、BtoBなら決算期や年度末が同じ位置にある。だから移行計画を引くとき、私は最初に「この期間は絶対に切り替えない」というブラックアウト期間をカレンダーに置いてから逆算する。工程を積み上げて最後に日付が出てくる作り方をすると、必ずピークに突っ込む。基幹刷新全体の進め方は基幹システム刷新の必要性・進め方・失敗しないためのポイントに整理している。
二重稼働コストは「事故」ではなく計画変数
止めた結果として二重稼働コストが追加で出た、と報じられている。ここを失敗と読むかどうかで、移行計画の作り方が変わる。
新旧環境の並行稼働は、移行では必ず発生する。問題はそれが見積もりに入っているかだ。並行期間の費用 (両系のインフラ費・運用要員・データ同期の作りこみ) を最初から予算に積んでいれば、期間が延びても意思決定は「予定より高くなる」で済む。積んでいないと、延長した瞬間に「想定外の追加費用」になり、稟議のやり直しが発生して、結果として止めるべき場面で止められなくなる。
実務でやっているのは、並行稼働の月額を出したうえで、「何か月まで許容できるか」を先に合意しておくことだ。この上限が決まっていれば、止めるか進めるかの判断が感情論にならない。制度対応のように期日を動かせない案件でも、稼働を分割してリスクを時間に分散する考え方は同じである (アズビルの新リース会計基準の早期適用)。
AIのユースケース選びが堅い
もう一点、地味だが良い判断だと思ったのが、最初のAIユースケースにアフターサービス (返品・修理) を選んでいることだ。
返品診断で40%が物理的な返品なしに解決した、という数字は、効果がコストとして直接数えられる種類の成果である。返品1件あたりの物流費と手間が分かっていれば、削減額はそのまま計算できる。コール書き起こしの分析を「人手なら80人分」と換算しているのも同じ発想だ。
AI活用の入口を「全社の生産性向上」に置くと効果が測れないが、返品や修理のような単位あたりのコストが決まっている業務を選べば、投資判断の議論が数字で回る。効果を率ではなく単位あたりで見る話はAirbnbの予約1件あたりのサポートコストにも書いた。評価の設計を先に作る重要性についてはLinkedInの自己進化型サポートエージェント論文を参照してほしい。
開発会社・SIerにとって、この案件が意味すること
同業として読むなら、示唆は3つある。
- 「止められる契約」になっているかが、実は品質より効く。 一括請負で期日を握った契約は、遅延時に止める判断とベンダーの利益が正面から衝突する。ピーク期を跨ぐ移行では、中断と再開の条件・費用負担を契約に書いておくほうが、双方にとって安全だ。ここを曖昧にしたまま受けると、止めるべき場面で「間に合わせます」と言う羽目になる。
- 並行稼働の設計が提案の差別化になる。 移行の提案書はどこも似た絵になるが、並行期間の月額と上限、切り戻し手順、データ同期の方式まで書いてある提案は少ない。ここは顧客の意思決定を直接助ける情報で、価格勝負を避ける材料になる。
- 大手SIとの座組では、どこで価値を出すかを先に決める。 この案件のように Microsoft・Accenture・Avanade が並ぶ体制で、汎用の開発会社が同じ土俵に立つ意味は薄い。既存システムとの接続、データ移行、業務側の受け入れテスト支援といった、現場に近くて泥臭い領域に回ったほうが取り分が残る。外注と内製の切り分けの判断軸はシステム開発を外注する7つのメリットと判断スコアシートにまとめている。
まとめ
この事例から取り出せる教訓は3つある。移行計画はブラックアウト期間を先に置いてから逆算すること。並行稼働コストは事故ではなく最初から積む計画変数であること。そしてAIの入口は単位あたりのコストが数えられる業務に置くこと。止めた判断を公開していること自体が、この案件のいちばん実務的な情報である。
