ソリューションのエレガンス

ITの仕事をしていると、大規模で複雑なソリューションに焦点を当てやすくなります。大きなソリューション、多くのソフトウェア、最新のガジェット―そこに優れたソリューションがあるように思えます。私たちの仕事は刺激的で、その勢いに乗ってしまいがちです。やりがいのある大きなプロジェクトは楽しいものです。他のITプロが何をしているか、他の企業がどのように課題を解決しているか、そして大規模なシステムを売り込もうとするベンダーとの会話はすべて興奮を高め、スコープや目標の感覚を失いやすくなります。単純な問題に対して大げさなソリューションを見かけることがあまりにも多いため、これがITのあり方だと思ってしまいがちです。

しかし、そうである必要はありません。複雑さは、信頼性とセキュリティの両方にとって敵です。不必要に複雑なソリューションは、導入・実装・保守のコストを増大させ、一般的に遅く、脆弱で、理解や保護が難しい広大な攻撃対象領域を持ちます。シンプルな、より適切に言えばエレガントなソリューションが最良のアプローチです。これはすべての設計がシンプルであるべきという意味ではありません。複雑な設計が必要な場合も多くあります。ITは複雑さを欠く分野ではまったくありません。実際、ソフトウェア開発はあらゆる規模で行われる人間の営みの中で最も複雑なものかもしれないとさえ言われています。典型的なITインフラには数百万行のコード、数百から数千のプロトコル、多数の相互接続されたシステム、重層的な独自のソフトウェア設定、どのチームも把握しきれないほどの設定項目があり、そこに加えて数百、数千、あるいは数十万の予測不可能で非合理的な人間がそれぞれ独自の方法でシステムを使おうとする複雑さがあります。ITは疑いなく複雑です。

重要なのは、ITが複雑であること、それを完全には避けられないことを認識しつつも、ソリューションをできる限りシンプルに、優雅に…エレガントに設計・構築することに集中することです。このデザイン思想は、少なくとも私の考えでは、ソフトウェアエンジニアリングから来ています。そこでは複雑なコードは失敗とみなされ、読みやすく理解しやすいシンプルで美しいコードが成功とみなされます。ソフトウェアエンジニアに与えられる最高の賞賛の一つは、そのコードが「エレガント」と評されることです。1970年代から1980年代にかけて最も人気のあったプログラミング言語の一つの名前の由来となったBlaise Pascalに帰せられるこの有名な言葉（フランス語からの拙訳）がいかに適切なことか：「こんなに長い手紙を書いてしまって申し訳ありません。短い手紙を書く時間がなかったのです。」

複雑で入り組んだソリューションを設計する方が、どのようなシンプルなアプローチで十分かを見極めるよりもはるかに簡単なことが多いです。急いでいるときも、どこから調査を始めればよいかわからないときも、エレガンスは常に難題です。業界の勢いはより困難な道を推進する方向に向かっています。ベンダーにとっては、最初の販売だけでなく、より多くの機器を売ることで保守・サポートの収入も増えるため、それが利益になります。また、十分な量の新しい複雑な機器が売れると、サポートの必要性は直線的ではなく指数的に増加します。機器やソフトウェア自体のサポートだけでなく、システム間の相互作用の設定・サポートや追加のカスタマイズも必要になるからです。複雑さの背後にある財務的な力は大きく、それはベンダーだけにとどまりません。ITプロフェッショナルも、他のITプロフェッショナルに簡単には引き継げない大規模なハードウェアやソフトウェアを管理することで、多くの雇用の安定（またはその幻想）を得ています。

複雑さはあまりにも当然視され、期待されているため、ソリューション選択のプロセスが、より複雑でないソリューションで十分かもしれない、あるいは複雑さやコストの問題を超えても優れているかもしれないという可能性を一切考慮せずに、大きな複雑さを既定の結論として始まることがよくあります。複雑さが特定の概念と完全に結びついていることさえあり、シンプルなソリューションが価格・性能・信頼性において複雑なソリューションを上回る可能性があるという考えに対して、実際に信じられないという反応に直面したこともあります。

言葉は簡単ですが、現実の例は何でしょうか？今日私が見る最良の例のほとんどは、ストレージに関するものであれ、クラウド管理レイヤーに関するものであれ、ソフトウェアに関するものであれ、あるいは単に仮想化そのものに関するものであれ、仮想化に関連しています。一人のための仮想化だけを含む会話が、ネットワーク接続された共有ブロックストレージ、高価な仮想化管理ソフトウェア、多数の冗長な仮想化ノード、複雑な高可用性ソフトウェアを即座に連想させることをよく見かけます。これらはいずれも仮想化に固有のものではなく、そのほとんどは実装される企業のビジネスを支援するためのものでも、実際にはその企業の利益のためのものでもめったにありません。ビジネス要件から出発するのではなく、これらの概念は主にテクノロジーの先入観から生じています。複雑さを指摘して問題を解決しているように見せることは簡単です―複雑さは安心感をもたらします。多くの議論を絞り込むと「どうして機能しないんだ、こんなに複雑なのに？」という声が聞こえてきます。複雑さは完全性の幻想、問題を解決したという幻想を提供しますが、これは解決策が実際には完全でなかったり機能さえしていなかったりするという事実を隠しやすく、複雑さの度合いがそれを見えにくくします。そして、複雑なソリューションでは解決できないのに、よりシンプルなアプローチがより完全で問題を解決するという考えを私たちの心は容易には受け入れません。直感に反するように感じるからです。

その良い例として、私たちは信頼性ではなく冗長性について話してしまいがちということがあります。信頼性は測定が難しく、冗長性は定量化が簡単です。レンガは単体でも非常に信頼性が高いです。レンガが安定して頑丈であるために冗長性は必要ありません。その設計はシンプルです。多くの冗長な棒で支持構造を作っても、単一のレンガほど信頼性は高くないでしょう。信頼性―構造が失敗しない確率―で語れば、レンガが数本の棒より優れた選択であることは明らかです。しかし「冗長性がない、レンガは壊れる可能性があり、代替物がない」と言っても馬鹿げています。しかしコンピューターやコンピューターシステムについて話すとき、システムが非常に複雑すぎて、自分がレンガを持っているのか棒を持っているのかを見分けられる人はまれです。そのため、重要なはずの信頼性を判断できず、簡単に定量化できる冗長性に焦点を当てるのですが、冗長性は実際にはそれほど重要ではありません。システム全体が複雑すぎますが、問題の核心に直接対処するシンプルなソリューションを探し求めることで複雑さを減らし、最終的にはるかに優れた答えを提供できます。

これはRAIDにも見られます。ミラーRAIDはシンプルで、一つのディスクまたはディスクセットが別のセットの完全なコピーであるだけです。とてもシンプルです。パリティRAIDは複雑で、多くのデバイスにまたがる可変ストライプの計算があり、書き込み時にエンコードされ、デバイスが故障した場合にデコードされなければなりません。ミラーRAIDはこの複雑さを持たず、非常に信頼性が高く十分に理解されているシンプルでエレガントなコピー操作によりディスクの信頼性の問題を解決します。パリティRAIDは不必要に複雑でそれ自体を脆弱にします。しかしそうすることで、また設計された目的を解決する能力を損なうことで、同時に、その複雑さ以外の要因に基づかず、より信頼性が高いように見えてしまいます。人の心はすぐに「複雑だから、より高度だ、だからより信頼性が高い」と飛びつきますが、どちらの進展も論理的ではありません。複雑さはより高度であることを示唆せず、高度であることは信頼性を示唆しません。しかし人の心自体が複雑で騙されやすいのです。

シンプルさを見つけるためのシンプルな答えはありません。複雑さが本質的に悪いが時に避けられないことを知ることで注意深くなれますが、過剰な複雑さを疑うべき時を教えてくれるわけではありません。常に注意を払い、よりエレガントな答えが存在するかどうかを判断しようとし、単に複雑だからという理由だけで複雑さを正しい答えとして受け入れないようにしなければなりません。提案されたソリューションと自分自身に問いかける必要があります。「このソリューションは本当に必要なほどシンプルか？」「この複雑さは必要か？」「私が想定したほどの複雑さが本当に必要か？」

私が行うほとんどのシステム設計の推奨において、解決すべきビジネスニーズを問い合わせるステップの後に、私が通常最初に行う技術的な判断ステップは複雑さに疑問を呈することです。複雑さが正当化できない場合、それはおそらく不必要であり、選択された目的を積極的に損なっています。

「そのドライブを多くの別々のアレイに分割することは本当に必要か？もしそうなら、そうするための技術的な根拠は何か？」

「共有ストレージは、あなたが提案しているタスクに本当に必要か？」

「ビジネスは分散型高可用性テクノロジーの使用を本当に正当化しているか？」

「昨日は十分だったシンプルなシステムを、明日劇的に複雑なシステムに置き換えているのはなぜか？シンプルなまま大きな改善を行うことでは十分ではないとして、以前は正当化されなかった桁違いに多くの複雑さと支出を必要とする何が変わったのか？」

これらはよくある例にすぎません。複雑さは私たちの業界のあらゆる側面に存在します。シンプルさを求めてください。エレガンスを目指してください。複雑さを厳密に精査することなく受け入れないでください。比喩的な洗礼をくぐらせてください。正当化されていない場所に複雑さが忍び込まないようにしてください。複雑さの方向に誤らないでください―迷ったときはシンプルに失敗してください。ソリューションを過度にシンプル化すると通常は軽微な失敗で終わりますが、過度に複雑にすると、はるかに大きな失敗の余地が生まれます。よりシンプルなソリューションの方が安全な賭けです。そしてシンプルなソリューションが選ばれて不十分であると証明されても、複雑さを取り除くよりも複雑さを追加する方がはるかに簡単です。