マルチクラウドにしたいと言われたときの話し方

「うちもマルチクラウドにしよう」——役員会や事業側から降りてくる、この一言。悪気はないし、むしろ前向きな提案として持ってこられることが多い。だからこそ厄介だ。頭ごなしに否定すると「エンジニアは保守的だ」と思われ、かといって額面通り受けると、開発チームは数ヶ月分の工数を別クラウドのアカウント管理やネットワーク設計に溶かすことになる。

この記事では、そんな場面で「否定せずに、実態に落とし込む」話し方を、たとえ話を軸に整理する。

1. 状況（非エンジニアからの要望）

典型的なきっかけはこんな感じだ。

• 「AWSに障害があったとき全部止まるのは怖い。GCPも使えるようにしておこう」
• 「特定のベンダーに依存するのは経営リスクだと聞いた」
• 「他社はマルチクラウドで運用してるらしい。うちも検討しよう」

どれも一見もっともらしい。実際、ベンダーロックインへの懸念や可用性への不安は、事業側として当然の関心事だ。問題は、「マルチクラウド」という言葉が指す範囲が、言う人によって全然違うことにある。ある人にとっては「障害時に別クラウドに切り替えられる保険」であり、別の人にとっては「全サービスをAWSとGCPの両方で常時稼働させる」ことだったりする。後者は、単純計算でインフラの複雑さと運用コストがほぼ倍になる話だ。

エンジニア側からすると、これは「新しい技術を試したい」という願望ではなく、「今動いているものを、二重に、しかも継続的にメンテナンスする」というコミットメントの話に聞こえる。この温度差をまず埋めないと、会話は噛み合わない。

2. たとえ（日常・ビジネスの比喩）

マルチクラウドは、よく「引っ越し先を二軒契約して、家具も生活動線も両方に揃えておく」ことに似ている。

一軒だけ借りて住むなら、家具の配置も、電気やガスの契約も、鍵の管理も一箇所で完結する。何かあれば大家に連絡すればいい。これがシングルクラウドの状態だ。

これを「もしもの時のために」ともう一軒契約するとどうなるか。家具は両方の家に置かなければ意味がない。電気・ガス・水道の契約も二重にいる。しかも住んでいる部屋の間取りが微妙に違うので、同じソファが片方の家には入らない、といったことも起きる。「保険として二軒目を持つ」つもりが、実際には「二軒分の家賃と管理の手間を毎月払い続ける」ことになる。

もう一つ近いのは、車の予備タイヤの話だ。トランクに一本積んでおくのはコストが低く、いざという時に助かる。だが「予備のエンジンを積んでおく」となると話は別で、重量も燃費もメンテナンス頻度も変わってしまう。マルチクラウド化の議論では、この「予備タイヤ」と「予備エンジン」のどちらを求めているのかを、まず言葉にしてもらう必要がある。

3. 提案の型（受け取り→たとえ→言い換え→段階案）

受け取り

「特定のベンダーに依存するリスクを減らしたい、というのはその通りですね。実際、障害やアカウントのトラブルで業務が止まると困るので、その懸念は開発チームとしても大事にしたいです」

まず要望の裏にある正当な動機（可用性、ベンダーリスク）を認める。ここを飛ばすと、次の話がどれだけ論理的でも「否定された」という印象だけが残る。

たとえ

「イメージとしては、二軒の家を契約して家具も生活動線も両方揃えておくようなものです。片方が使えなくなった時にすぐ住み替えられる安心感はありますが、毎月の家賃も、鍵の管理も、模様替えの手間も全部二倍になります」

言い換え

「全部を二重化するのではなく、まずは『本当に止まったら困るもの』だけ絞り込みませんか。例えば決済まわりだけ別クラウドにバックアップを置く、といった形なら、予備タイヤを積むくらいのコストで安心感を得られます」

ここで「マルチクラウド化」という抽象的な要望を、「どのサービスを、どの粒度で」という具体的な選択肢に変換する。全否定ではなく、範囲の合意形成に持っていくのがポイントだ。

段階案

1. まず、現状どのクラウドのどのサービスに障害が起きたら本当に困るか、影響範囲を洗い出す（コスト増なしでできる）
2. 最も重要な1〜2機能について、別クラウドへのフェイルオーバー、あるいはバックアップ体制を検討する（小さく試す）
3. その結果と運用コストを見て、対象を広げるかどうかを判断する（本格展開は実績を見てから）

いきなり「全社マルチクラウド化」を決めるのではなく、小さく検証してから広げる、という順番を提示する。

4. ミーティングで使える一文

「マルチクラウド全体を目指す前に、まず『止まったら本当に困るもの』を一つ決めて、そこだけ二重化する形で試してみませんか。全部を二軒持ちにするより、必要な部屋だけ増築する方が、コストも見えやすいと思います」

5. 例外（このたとえを使わない／肯定すべきケース）

このたとえがいつでも正しいわけではない。以下のようなケースでは、むしろマルチクラウド化を積極的に肯定すべきだ。

• 契約上・法規制上の要求がある場合：金融や公共系の案件で、特定クラウドへの依存を制限する契約条件がある場合は、コスト論より優先される。
• すでに単一障害点で実際に事業影響が出た場合：過去に大規模障害で長時間サービスが止まった実績があるなら、「予備タイヤ」レベルの備えは既にリスクとして顕在化している。たとえ話で説得を試みるより、事実として対応の必要性を認めるべき場面だ。
• 特定機能がそもそもマルチクラウド前提で設計されている場合：例えばグローバルCDNや一部のマネージドサービスは、複数クラウドにまたがる構成の方が自然なこともある。この場合は「二重化のコスト」という前提自体が成立しない。

こうしたケースでは「たとえ話で穏便に落とす」のではなく、「その通りです、優先度を上げましょう」とストレートに合意する方が信頼を得られる。たとえ話は、あくまで要望の解像度が粗い時にすり合わせるための道具であって、正当な理由がすでにある要望を薄める言い訳に使ってはいけない。

6. まとめ表