迷宮へ – 複雑さの源

全5回からなる このブログ・シリーズの最初の記事 では、企業ネットワークにありがちな複雑さについて掘り下げ、シンプルであることの必要性を強調しました。そして 2回目では、これらの複雑さに伴う複数のコストを取り上げ、財政面と人的資源への負担の両方に焦点を当てました。

前回の記事で明らかになった複雑性によって引き起こされる問題の解決について話す前に、そもそもなぜこのようなもつれた混乱に陥ってしまったのかを理解する必要があります。私たちが巻き込まれているこのテクノロジーの迷宮を構成している複雑性の原因を探ってみましょう。

内在する複雑性

単純なシステムが拡大し、融合し、より多くの仕事を引き受けることで複雑さが生じることを想像するのは難しくありません。時間が経つにつれて複雑さが生じるように思えます。これは、どのようなシステムであれ、成長の自然で期待される結果です。それは必然的であり、望ましくさえあり、成熟の証なのです。このことは、単純であることは洗練されていないこと、デザイン性に欠けること、あるいは複雑であることを意味するのかもしれません。しかし、その逆だとしたらどうでしょう？

複雑さの落とし穴について論じるとき、私は単純化を擁護しているのではありません。企業ITのような広範で多層的なシステムは、当然ながら基礎的なレベルの複雑性を持っています。要件、制約、利害関係者は多数存在し、頻繁に対立します。どのような具体的な結果が望まれても、多様な基礎技術に根ざして実装できるバリエーションは無限にあります。システムをインテリジェントにアーキテクトすることは、習得するのに何年もかかる熟練した学問であり、孤立して存在するシステムはありません。

テクノロジースタックとベンダーが絡み合うシステム間のタッチポイントは、出現する複雑性の温床です。システムは静的なものでもありません。時間の経過は、設計時には予測できなかった変化をもたらし、要件の進化に伴う調整を必要とします。全体的に観察すると、単一組織のITフットプリントは、設計図に従って建設されたタワーとは対照的に、絶えず移り変わる地質学的景観によく似ています。

さらに、より大きなシステムを構成する個々の技術は、本質的に複雑です。高度な数学、応用物理学、多層的な抽象化、多言語で実装されることが多く、技術スペクトルのほんの一片をマスターするのに一生を費やすかもしれません。とはいえ、システムが本質的に複雑であっても、その多くを単純化し、ユーザーエクスペリエンスと効率を優先させることは可能です。

インテント・トランスレーター

最後に電気のスイッチを入れたときのことを考えてみてください。その単純な動作の背後には、広大で複雑なインフラが存在します。電気の供給源や発電方法について考えたことがあるでしょうか。電力を供給するために必要な送電システムや蓄電システムについては？もしかしたら、料金を決定する多段階の計量、請求、市場システムについて考えたでしょうか？考えていませんか？運用チームや、相互運用性を保証する規制・標準化機関についてはどうでしょうか？おそらく、考えていない可能性が高いでしょう。私が何を言いたいかはお分かりだと思います。

照明スイッチの背後にあるシステムは、あなたの意図を簡単に伝え、望ましい結果を得られるように作られています。部屋を照らしたいというあなたの意図を、とてつもなく複雑なシステムを流れる、組織化された複雑なプロセスに変換してくれます。

実際、よく考えてみると、私たちが毎日使っているシステムの多くは、複雑に絡み合った厄介な網の目のようなものであり、多くの場合、私たちはその内部構造を知りません。自動車、交通網、金融機関、そしてあなたがこのブログを読むために使っているデバイスでさえも、その複雑なプロセスを隠しながらシームレスに機能しています。人間である私たちは、訓練された専門家チームによって何世代にもわたって構築された非常に複雑なシステムを、素人でもその恩恵を享受できるように単純化する技術を習得してきました。

問題は複雑ですが、解決策はできるだけシンプルであるべきです。しかし、なぜ情報技術（IT）領域はこのアプローチを採用しないのでしょうか？普通の電灯のスイッチの奥で作動する、エレガントに単純化されたシステムの対極にあるものは何でしょうか？

創発的で習慣的な複雑性

「人生は実に単純なものなのに、我々はそれを複雑にしようとする。」- 孔子

不必要な複雑さは、テクノロジーのライフサイクル全体に摩擦をもたらします。しかし、その原因はどこにあるのでしょうか？問題の原因を調べることで、対症療法ではなく原因に対処する方法をよりよく理解することができます。では、IT業界における不必要な複雑さの主な原因をいくつか探ってみましょう。

システム・マッチング組織

プログラマーの間では「コンウェイの法則」という有名な格言があります。それは次のようなものです：

“システム（広義に定義）を設計する組織は、その組織のコミュニケーション構造をコピーした構造を持つ設計を生み出す”

これがどのように物事を複雑にするのでしょうか？企業の縦割り組織や官僚主義が特定の領域を優先し、顧客の問題解決を見失うと、それは製品やサービスに顕著に現れます。私がシステム管理者だった頃、大きなフラストレーションのひとつは、自社製品が相互運用できない大手ベンダーを相手にすることでした。さらに、重複する機能が複数の製品に分散しているにもかかわらず、どの製品も目の前のタスクに完全に適していないものもありました。これでは、異種のデバイスやサービスが不必要に蓄積され、管理のオーバーヘッドが増大し、相互作用のポイントが増えることになります。

従業員全員が顧客の問題を解決することに全力を注いでいる小さな新興企業とは対照的です。彼らは、確立されたインストールベースと安定したキャッシュフローという贅沢を持ち合わせていません。このような社内の気晴らしのなさが、素晴らしい実績と優秀なエンジニアを数多く抱える大企業に、新興企業がしばしば勝ることができる理由のひとつです。それは集中することです。

有機的成長とそれ以外の成長

企業やシステムが成長すればするほど、その複雑さが増すことは自明の理です。急成長すればするほど、組織設計と相互作用の長期的な帰結を熟考することは難しくなります。新興企業は、当初は急成長を遂げますが、後に肥大化し、かつてスリムで集中的だった時代に勝利したのと同じような無秩序な官僚主義に陥ることで悪名高い。

合併や買収は、事態をさらに複雑にします。それぞれが長年にわたって技術を蓄積してきたバラバラの組織が、突然、ひとつのまとまった組織として機能することを求められるのです。ウォール街はしばしば迅速な結果を求め、技術的な冗長性や各企業の技術的枠組みの長所と短所を十分に評価することなく、先を急ごうとする衝動を強めます。多くの場合、「後で整理する」つもりで、元の両組織の既存のシステムが残っているのです。収益と成長を重視するあまり、こうした問題への対処が遅れるのが常であることは想像に難くありません。

この成長の逆説は、組織が組織的であろうとなかろうと、速く拡大すればするほど、複雑な層を積み重ねることになり、やがてその成長の妨げになるということです。

アーキテクチャ vs 企業の現実

私はキャリアを通じて、素晴らしいシステムアーキテクトやエンジニアに出会う機会に恵まれてきました。これらのプロフェッショナルは、複雑さをどう克服するかについて非常に強い意見を持ちながら、深く考察して仕事に取り組んでいます。彼らは、ビジネスが求める俊敏性と成果を最も効率的な方法でもたらすシステムを構築するための、持続可能で体系的な戦略を考えることに時間を割いているのです。

残念ながら、こうした計画が思い描いたとおりに実現することはほとんどありません。なぜでしょうか？オフィス内の政治、優先順位の変化、購買部門が「氷山モデル」の重要でない側面に集中することなどが、直面する課題の一部です。さらに、広範囲に焦点を当てた意思決定が広く行われていないことが、問題をさらに複雑にしています。通常起こるのは、設計の断片的な採用、応急処置的なアプローチ、あるいは異なる部門による競合的な導入です。これは、作業の重複、互換性のないデータサイロ、時間の浪費につながります。広い視野で考えなければ、複雑さはたちまち制御不能に陥ります。一旦、複雑さが定着してしまうと、それを修正するのはずっと難しくなります。

思いのままに

コンシューマーテクノロジーの世界では、アプリケーションやサービスは通常「そのまま」で販売されます。アプリのインターフェイスのアップデートに不満があっても、それを変更することはできません。イーロン・マスクのようにプラットフォームを買うという思い切った手段を取らない限り、私が望む機能を実装するのは望み薄です。

エンタープライズITの世界では、その逆が当てはまります。企業は、製品だけでなく、関連する「接着剤」やミドルウェアにおいても、大規模なカスタマイズを頻繁に要求します。なぜでしょうか？通常、あるツールを最も効率的に使うためにビジネスの方向性を変えるよりも、組織の構造や方針にソフトウェアを合わせることを要求する方が簡単だからです。

しかし、手を加えたり、カスタムに手を加えたりするたびに、私たちはしばしば複雑さを増していきます。これは、私たちの仕事をより困難なものにしています。システム構築者の設計や意図から逸脱することは、サポートがより困難になることを意味します。操作にはより専門的な知識が必要となり、外部システムとの相互作用は計画通りに機能しないかもしれません。

誰が得をするのか？

「シンプルであることは素晴らしい美徳だが、それを達成するには努力が必要であり、それを評価するには教育が必要だ。さらに悪いことに、複雑な方が売れる。」 – エドガー・ダイクストラ

誰もが簡単なことを望んでいるわけではありません。圧倒的な複雑さ、あるいは少なくともそのような認識は、ある種の利益をもたらすことがあります。例えば、難解なトレーニングや認定資格を何層にも重ねたベンダーであれば、その価値を下げるようなことはしたくないはずです。直感的で考え抜かれた設計により、練習生がすぐにシステムを把握できるのであれば、高価で時間のかかるトレーニングに投資する必要はないでしょう。

さらに、資格取得のための学習やテストに時間を割いてきたITプロフェッショナルであれば、資格の価値が下がることは避けたいはずです。ベンダーとその手法に対する親しみは、ロイヤリティを育み、さらなる購入につながります。もちろん、これらの製品もまた、さらなるトレーニングや認定を必要とし、相互依存のサイクルを永続させます。たとえあなたが精通している技術的ソリューションが、ビジネス上の問題を解決する最良の方法でなかったとしても、あなたはそれを選択する可能性が高いでしょう。そのような選択は、そのソリューションの操作に熟練した人物として、組織にとってのあなたの価値を高めることになります。

また、システムインテグレーターとして設計や導入のサービスを提供する場合、どちらの方が請求可能な作業時間が長いでしょうか。複雑な技術をうまく組み合わせる必要があるソリューションと、箱から出してすぐに使えるオールインワン・システム、どちらが請求可能な作業時間が長くなるでしょうか？

何年も前のことだが、私はあるベンダーのもとで働き始めました。その製品は、設置から始まり、破壊的なまでにシンプルに設計されていました。月曜日の朝、私はシアトルの顧客を訪ね、彼らのラボでデモをセットアップをしました。オンボーディング・プロセスは非常にうまく設計されており、私たちは昼食前にすべてのデモを完了させました。帰り際に、かつての同僚とばったり会いました。彼らは、私が紹介したソリューションと競合するつもりで、3つの異なるベンダーから寄せ集めたデモ・システムをセットアップしていたのです。彼らは、翌日中には設計段階を終え、順調にいけば週明けには設置を完了する予定だと言いました。

あの出来事は、シンプルであることの力を私に教えてくれました。考え抜かれた設計のおかげで、他のソリューションがダンボール箱から出されていない間、彼らはほぼ丸一週間生産的でした。これを本格的な配備に置き換えて考えてみると、これらのスケジュールを10倍に延ばすことで、なぜこのようなことが重要なのかがわかるでしょう。この動きの速い世界では、価値を生み出すまでの時間を短縮することが真の財産となります。

私たちはいつもこうやってきた

専門的な知識と高価なカスタマイズを必要とする半互換システムの寄せ集めで、使うのにイライラし、修正するのも複雑です。そしておそらく、これらすべてがそのままになっている最大の理由は、惰性によるものでしょう。

慣れ親しんだものに固執する衝動は強いものです。特に大規模な変化は難しい。ゼロから始めて、思い描いたとおりのグリーンフィールド・システムを構築できる機会はめったにありません。その場合でも、注意深く保守していかなければ、時間の経過とともに流れていってしまいます。ITプロフェッショナルの大半は、受け継いだシステムと格闘し、変更を主張するよりも、確立された方法を継続する方が簡単だと考えることが多いでしょう。

このブログシリーズの次回の記事では、そのような考え方を転換し、個人として、そして業界として、どのように変わっていくことができるのか、いくつかの方法を探ってみたいと思います。