fallback（フォールバック）とは、元々使おうとしていた手段が利用できない状況において、代替手段を使うことを言います。最近では名詞としての用法も多いようですが、元々は動詞（＋副詞）であることに気を付けて下さい。
contingency-plan（コンティンジェンシープラン、緊急事態における対処計画）も非常に近い意味を持ちます。
work-around（ワークアラウンド、回避策）も似たような意味ですが、fallbackは事前に代替手段を用意している状況での代替手段を指すのに対して、work-aroundは実際に問題に直面してから考える対策のことを指すことが多いようです。
なお、この文脈では「元々使おうとしていた手段」は優れているものであり、「代替手段」は性能面や機能面などで劣っていることがほとんどです。
fallbackの例
さて、ソフトウェアに限らず、製品や制度、法律などを設計する際には当然ながらfallbackのことを考えなければなりません。具体的には次のようなものが挙げられるでしょう。
不適切なfallback
最近見かけたものの中に、次のような通信プログラム（クライアント）がありました。
最初は SSL(TLS) を用いた通信を試みるが、通信の相手先の証明書がオレオレ証明書であるなど、SSL(TLS)の機能を十分に活かすことができない状況であれば、 SSL(TLS) での通信を諦めて平文での通信を試みる、というものです。
通信相手がオレオレ証明書を使っていればその通信は疑って当然である、という意見には大いに同意します。しかし、オレオレ証明書を避けた結果として平文で通信するのは、いかがなものでしょうか。
| まともな証明書でのSSL(TLS) | オレオレ証明書でのSSL(TLS) | 平文での通信 | |
|---|---|---|---|
| 暗号化 | ○ | ○ | × |
| 改ざんや成り済ましの検知 | ○ | めっちゃ面倒臭い事前準備をやっていれば、それなりに。 | × |
| 実在性証明 | ものによる | × | × |
やり取りする情報の機密度合いにもよるでしょうけれども、平文への通信にfallbackするのが常に得策であるとは思えません。通信の安全性だけを考えると、オレオレ証明書であったとしても、使った方がマシなのです。
一つだけ、このfallbackを支持する理由があります。それはユーザ教育です。オレオレ証明書に基づいた通信を日常茶飯事だと捉えさせてはいけないのです。言葉を変えると、上記の「実在性証明」や「改ざんや成り済ましの検知」などの価値をユーザに知ってもらわなければなりません。
ただ、これも、多くのWebブラウザの実装がそうであるように、オレオレ証明書に遭遇したらユーザに警告を発するようにすれば（実装は大変だけど）問題の大部分をクリアできる話ではあります。
まとめ
「オレオレ証明書、ダメ、絶対！」は、的を得た意見です。しかし、それを鵜呑みにして適当なfallback戦略を立てていては、ダメなものよりももっとダメなものを選択してしまう危険性があるのです。
そんな選択をしないように、気を付けて生きていきたいものです。
さいごに
文句言うんやったらパッチ書いて送れよ、という声がどこからか聞こえてきました。はい、その通りです。。
