画像はホタテの浜焼き(記事と関係ありません)
FigmaはSaaSである以上、サービス停止やデータ消失のリスクが隣り合わせだ。
実際、過去には小規模な障害が複数回発生している。それにもかかわらず、運用を担当者に丸投げしている企業ほどローカルバックアップするルールすら存在しない。
まだ事故が起きていないという奇跡によって成立している危うい運用体制だが、普通に大手企業のWeb運用の現場でよく見かける風景である。
責任転嫁で成立している危うい前提
「障害が起きたらどうするのか」という問いに対して、「Figmaが直すであろう」という反応が返ってくる時点で、責任の所在は完全に外部に転嫁されている。
そもそも、英語の利用規約を一度でも読んだことがあるのかすら怪しい。いや、100%ないだろう。
利用規約を確認すれば明白であるが、SaaSは免責が前提であり、復旧の保証も損害補償も限定的である。それにもかかわらず「なんとかしてくれるはずだ」という期待で業務を回している状況は、リスク管理ではなく思考停止に近い。
大手企業でも崩壊している実務レベルの管理
問題はこの種の運用が中小企業に限らない点である。
日本の大手企業においても、ガバナンスや内部統制を掲げながら、実務では「バックアップポリシーが存在しない」という状態が放置されている。形式だけ整え、実態が伴っていない典型例であり、管理体制そのものが空洞化している。
最低限すら実装されないバックアップ運用
本来、SaaSを利用するならば「可用性は高いがゼロではない」「データの最終責任は自社にある」という前提で設計すべきである。
定期的なエクスポート、バージョンのスナップショット保存、障害時の代替フローの定義といった基本動作は最低限必要である。
しかし、現実にはそれらすら実装されていないケースが多い。
ここで典型的なやり取りを挙げる。
デザイナー「Figmaのファイル、バックアップ取っておいた方がいいですか?」
上司「クラウドだし不要でしょ」
デザイナー「でも消えたら困りますよね」
上司「そのときは復旧してもらえばいいよ」
デザイナー「誰に?」
上司「……Figma?」
この時点で、誰も具体的な障害対策をしていないことが露呈する。結果として、障害発生時に業務が完全停止する。これは想定外の事故ではなく、準備不足がそのまま表面化しただけである。
実際に起きている障害とその現実
Figmaは高い可用性を前提に設計されているが、それでも過去に複数回の障害が発生している。
2022年前後には一部ユーザーでファイルが読み込めない、またはアクセス不能になる事象が報告され、作業が一時停止したケースがある。
さらに2023年前後にもログイン障害やパフォーマンス低下が発生し、編集作業が実質的に進まない時間帯が生じた。いずれも長期停止ではないが、「業務時間中に使えない」という一点だけで見れば十分に致命的である。
こうした障害時、多くの現場では「復旧を待つ」以外の選択肢が存在しない。ローカルにエクスポートされたデータもなく、代替手段も定義されていないため、障害が発生した瞬間に業務が停止する構造になっている。
短時間で復旧した場合でも、それは運が良かっただけであり、運用の正しさを示すものではない。それにもかかわらず見直しが行われないまま同じ状態が維持され、次の障害時に同じ問題が再現される。この循環こそが、最も現実的なリスクである。
運用体制そのものの問題
これはツールの問題ではない。運用設計の問題である。
クラウドは利便性を提供するが、責任までは引き受けない。この前提を無視した運用は、いずれ確実に破綻する。
