GUI時代の終焉

GUIとシステム管理の世界におけるその役割に関する歴史的な文脈を見ておきましょう。

「昔」は、サーバーはもちろん、コンピューター全般にグラフィカルユーザーインターフェースはありませんでした。エンドユーザー向け機器でGUIが普及し始めてから長い間、サーバーにはGUIがありませんでした。1980年代から1990年代にかけて、GUIを生成するために必要な計算オーバーヘッドはマシンの総コンピューティング能力の観点から見て大きく、わずかな計算リソースをGUIの生成に使うことは実用的ではなく、多くの場合まったく不可能でさえありました。システム管理の世界は、他の選択肢が存在しなかったため、コマンドラインで作業するというこの文脈の中で育ちました。GUIをシステム管理に望む人が多くなかったのは、おそらくまだその発想自体が生まれていなかったからかもしれません。

1990年代中頃、Microsoftは他のいくつかのベンダーとともに、エントリーレベルのサーバー市場向けにGUI駆動のシステム管理というコンセプトを導入し始めました。当初このアプローチはあまり人気がありませんでした。市場での経験豊かな管理者の作業方法と合っていなかったためです。しかし徐々に、新しいWindows管理者や、ある程度はNovell Netware管理者たちが、GUI ベースの管理ツールを使って「育ち」始めると、サーバー市場においてこれらのシステムの受け入れられる場所が生まれ始めました。1990年代中頃から後半にかけては、UNIXやその他の非Windowsサーバーが市場を完全に支配していました。VMSも依然として主要なプレイヤーであり、中小企業やコモディティサーバー側ではNovell Netwareが10年代中頃の主要プレイヤーで、後半でも依然として非常に強力な競合でした。NetwareはGUIを提供していましたが非常に軽量であり、少なくとも1996年以降にWindows NTが提供したリッチなGUI体験と比較するとおそらく「半GUIレベル」と見なされるべきものでした（Windows NT 3.xファミリーではある程度早くから提供されていましたが、Windows NTはNT 4のリリース前は世界に自らの場所をようやく見つけつつある段階でした）。

当時でさえ、GUI駆動の管理市場は主に傍流のままでした。Microsoftと Windowsはサーバー側にまだ大きな位置を占めていませんでしたが、低コストで使いやすい製品が非常に理にかなっていた中小企業市場を通じて進出し始めていました。しかし、Y2K問題への恐慌とドットコムバブル、そしてMicrosoftによる優れた製品開発とマーケティングが重なった1990年代後半に、GUI駆動の管理市場への著しい成長と転換が起きたのは間違いありません。

1990年代後半のIT市場の急激な拡大は、ITに参入する新しい人材を育成するための時間とリソースが不足することを意味していました。SolarisやNetwareを含む多くのシステムの学習曲線は非常に急峻で、業界では既存のプラットフォームで可能だったよりも速く、膨大な数の人材を「ゼロから有能なIT専門家へ」と育成する必要がありました。市場の成長は爆発的で、IT業界で働くことで非常に多くの収益を得られるため、教育的な役割を担えるような人材は教育に携わるよりも業界で働く方が高収入を得られることから、新しい人材を効果的に育成できる利用可能なリソースがありませんでした。市場が拡大するにつれて、成熟した経験豊かな専門家の価値は極めて高くなりました。常に拡大し続ける分野全体において彼らは非常に希少になっていたからです。

市場はさまざまな方法でこの需要に応えましたが、最も大きなものの一つは、ITへのアプローチを根本的に変えることでした。IT専門家を当時市場にあったシステムを効果的に管理するための伝統的な学習曲線を克服し必要なスキルを身につけることに向けてプッシュするのではなく、市場は使用するツールを変えて、経験や知識の少ないITスタッフに対応するようにしました。GUIインターフェースを持つ、よりシンプルで多くの場合より高価なツールが市場に溢れ始め、訓練や経験の少ない人々でも、以前に製品を見たことがなくてもすぐに役立ち生産的に働けるようになりました。

この変化はコンピューターハードウェアのパフォーマンスの自然な進歩とも一致していました。この時代に初めて、GUIが依然としてパフォーマンスにかなりの影響を与えるほど多くのシステムのパワーがあったものの、サポートスタッフの低コストとシステムのデプロイ・管理の速さが、GUIによるコンピューティング能力の損失を一般的に補うようになりました。GUIは、数年前にはGUIが搭載されることなど考えられなかったシステムへの標準的な追加機能として急速に定着しました。

これらの新しいIT専門家の能力を向上させ、市場に早期投入するために、業界はまた、当時としては新しいイノベーションであった資格認定に大きくシフトしました。資格認定により、実際の実務経験がまったくない新しいIT専門家でも、大学プログラムが必要とするような既存のIT専門家との重大なやり取りや投資を必要とせずに、ある程度の能力を証明できるようになりました。GUI ベースの管理市場と資格認定業界の両方が急成長し、ITの顔は大きく変わりました。

その結果、確かに新しい、未熟または軽度に訓練されたIT専門家が記録的なペースで市場に参入する洪水のような状況となりました。短期的にはこの変化は業界にとって機能しました。この分野は劇的な人材不足から比較的良好な人材供給状態へと、他の方法よりも何年も早く移行しました。しかし、この急速な新人材の取り込みによるペナルティが現れるまでには長くはかかりませんでした。

業界への最も大きな影響の一つは、業界全体での「ベビーブーム」であり、それに伴うすべての成長痛が生じたことです。IT専門家の世代全体が1990年代後半のブートキャンプや急速な「資格認定トレーニング」プログラムの中で育ちました。これにより、その時代に一般的だった経験則や一般的なアプローチが、その前の世代や後の世代のアプローチとは異なる方法で、ほぼ宗教的な信念と言えるほどに成文化されるという長期的な影響をもたらしました。多くの場合、教育が迅速かつ浅く行われたため、多くのコンセプトをその背後にある基本の理解なしに暗記によって学ばなければなりませんでした。「1998年の世代」が時間をかけて社内のシニアIT専門家に成長するにつれ、彼らは新世代のメンターになり、その昔の丸暗記による学習が同様のアプローチを通じて以降の年月に非常に目に見える形で引き継がれ、その知識が時代遅れまたは非実用的になった後もずっと続いており、多くの場合、誤って解釈され、生まれた時代においてさえ予測可能な形で誤っています。

この時代の学習の一部は、GUIが単に受け入れられるだけでなく、実用的で期待されるものだという一般的な受け入れでした。ベビーブーム効果により、以前の時代からのメンタリングがほとんどなく、以前に確立された慣行や規範はしばしば一掃されました。ベビーブーム効果により、業界は自らを再発明したというよりも、単純に自らを確立しました。情報技術という概念が特定の産業として現在の形を取り、これが起きた世代交代の中でその存在が公共の意識に根付いたのも、このころです。他の部門や分野の痕跡ではなく独自のものとなったITですが、より有機的な成長があった場合に存在していたであろう実践の成熟と継続性なしにそのような形となり、連続的な方法で発展していた場合よりも悪い状況になった可能性があります。

1990年代後半のITブームの長引く影響は非常に長い間感じ続けられるでしょう。その時代のトレンド、信念、仮定が最終的に一掃されるまでには多くの世代がかかるからです。ゆっくりと、新しいコンセプトやアプローチが定着しつつあります。それが起こるのは多くの場合、古い技術が消え、新しいものが導入されて伝統の強固な締め付けが解かれた時だけです。そのうちの一つが、GUIがシステム管理の主要な方法であるという考え方です。

前述のように、GUIはその登場時に古いシステムと1990年代後半の新世界との間の差別化ポイントでした。しかしその後、GUI管理ツールはその可用性において遍在するものとなりました。すべての主要なプラットフォームにはグラフィカルな管理オプションがあり、長い間そうでした。そのためGUIはもはやいかなるプラットフォームも重要な方法で際立たせることはありません。これは、GUIというコンセプトを推進する明確な議題を持つベンダーがもはや存在しないことを意味します。GUIのマーケティング価値は事実上消え去りました。同様に、以前は強力なGUIを欠いていたシステムがほぼすべて一つ（またはそれ以上）を開発しただけでなく、強力なコマンドラインツールを持っていなかったGUIベースのシステムも戻ってそれらを開発し、それらを中心に新しい専門的エコシステムを発展させました。潮流は確実に変わりました。

さらに、過去約20年の間にGUI以外の世界のレトリックが定着し始めました。あらゆるプラットフォームでコマンドラインを習熟した立場から作業するシステム管理者は、一般的に同業者を上回るパフォーマンスを発揮し、より多くのキャリアの機会、より挑戦的な役割、より高い収入につながっています。コマンドラインの管理に重点を置いている企業は、より熟練した労働者と高い管理密度を持ち、その結果全体的なコストが低下します。

これだけでGUIの地位が揺らぎ始めるには十分でした。しかし、1990年代後半でさえGUIは少量のシステムリソースを使用し、非常に少量の追加的な攻撃対象面を加えるだけだという古い議論が常にありました。たとえ使用されなくても、なぜ「念のために」インストールしておかないのかと。CPUが高速化し、メモリが大容量化し、ストレージが安くなり、システム設計が改善されるにつれてGUIの影響は年々少なくなり、GUIを利用可能にしておくというこの議論は強まりました。特に強力な提案として、GUIにより初級スタッフが同様のタスクを実行できるようになり、より有用になるというものがありました。しかし、このような状況でシニアスタッフがGUIを松葉杖として保持することはあまりにも一般的でした。

コモディティサーバー空間への仮想化の登場により、これがすべて変わり始めました。GUIのコストが突然再び目立ち始めたのです。20台の仮想マシンを実行しているシステムは、突然1つのGUIインスタンスのCPUリソースの20倍、メモリの20倍、ストレージ容量の20倍を使用するようになりました。GUIのフットプリントが再び目立つようになりました。仮想マシンの密度が上昇するにつれて、GUIの相対的な影響も上昇しました。

仮想化はクラウドコンピューティングを生み出しました。クラウドコンピューティングは仮想マシンのデプロイメント密度を増加させ、主にインスタンスのビルド時間の長さとより複雑なリモートコンソールアクセスという観点からGUIの他のパフォーマンスへの影響を露わにしました。GUIを必要とするシステムは、GUIを持たない対応システムと比較して採用と機能において目立って遅れを取り始めました。

しかし、さらに大きな要因はクラウドコンピューティングの標準的な課金方法のアーティファクトでした。クラウドコンピューティングは一般的にインスタンスごとのコストを生の、完全に見える形で明らかにするため、IT部門はGUIデプロイメントのコストをごまかしたり見落としたりする手段がなく、その追加オーバーヘッドがしばしば単一のクラウドインスタンスのコストを倍増させることもありました。非技術的なチームでさえ、管理コストを考慮する前であっても、GUIシステムの請求書がGUIを持たない対応システムよりもはるかに高いことを明確に見ることができました。

このコストは、コンテナ技術に向かって進むにつれて増加し続けています。個々のインスタンスの規模が小さくなればなるほど、GUIの相対的なオーバーヘッドはより重要になります。

しかし、実際の影響、おそらくGUI駆動のシステムに関する問題の最大の露呈は、業界のDevOpsシステム自動化モデルへの移行です。今日、フルクラウド対応の弾力的にスケーラブルなDevOpsモデルのシステム管理へ積極的に移行している企業はまだ比較的少ないですが、トレンドは確かにあり、そのモデルはGUI管理者とそのシステムを完全に置き去りにします。DevOpsモデルでは、マシンへの直接アクセスはもはや標準的な管理方法ではなく、システムはコマンドラインのみで作業するだけでなく、完全にコードで構築されるようになっています。つまり、DevOpsの世界で作業するシステム管理者はコマンドラインでシステムと対話する必要があるだけでなく、プログラム的にそうする必要があります。

市場は急速に、少数のより高度にスキルを持ったシステム管理者が以前のいかなる時代よりも「管理者あたり」多くの多くのサーバーで作業する方向に向かっています。1人のシステム管理者が数十台のサーバーしか管理できないという考え方はGUIの世界での一般的な信念であり、伝統的な「スノーフレーク」コマンドラインシステム管理においてさえ数百台の範囲に簡単に上昇する数字で、長い間疑問視されてきました。しかしDevOpsモデルや同様の自動化モデルは、その数字を管理者あたり数千台のサーバーに引き上げます。GUIのオーバーヘッドはますます明らかになっています。

クラウド、コンテナ、DevOps自動化モデルなどの新技術が普及するにつれて、ワークロードの自然な「スプロール」も広がります。これは、あらゆる規模の企業が管理が必要なワークロードの数の増加を目撃していることを意味します。従来2〜3台のサーバーしか持っていなかった企業が今日10〜20台の仮想インスタンスを持っているかもしれません！1〜2台の仮想マシンのみを必要とする企業の数は減少しています。

これはすべて、GUI管理が近い将来、あるいは遠い将来においても消えていくことを意味しているわけではありません。「一回限り」のシステム管理の必要性は残り続けるでしょう。しかし、GUI管理の「一回限り」モードで作業できる管理者と、コマンドラインを通じて、特にスクリプト化されたまたは完全に自動化されたシステム（PuppetやChef、Ansibleのような）を通じて作業する必要がある管理者の比率は、すでに非GUI系システム管理とDevOpsの実践の方向へと信じられないほど急速に傾いています。

これは現場の私たちにとって何を意味するのでしょうか？それは、従来コマンドラインで作業する必要性がほとんどまたはまったくなかった中小企業Windows管理などの役割でさえ、仕事のためにローカルサーバーGUIへの依存を再考する必要があることを意味します。コマンドラインツールとプロセスはますます強力で知名度が上がっており、私たちが作業することを期待されている方法になりつつあります。UNIXの世界ではコマンドラインは常に残存しており、GUIツールに頼る必要があることはほぼ常に大きなハンデとして見られてきました。同じ印象がWindowsの世界にも適用され始めています。GUIツールのみに頼る人々はゆっくりと二流市民として見られ始め、ますます初級の役割や小規模な組織に追いやられています。

スクリプティングと自動化ツールの改善はまた、スケールの価値が向上していることを意味し、少数のサーバーを管理するコストはワークロードあたりで非常に高くなりつつあります。これは小規模企業が、より大きなビジネスが今日経験し始めているのと同じスタイルのコンピューティング上の利点を得ながら、IT ニーズでコスト競争力を保つために、大規模なシステム管理に特化し、スクリプティングと自動化技術を活用してコストをより大企業のコストに合わせることができる外部ベンダーを通じて管理の統合を検討する非常に強い奨励があることを意味します。スケールまたはその近似を確立するために外部ベンダーを使用する能力は、時間をかけて小規模ビジネスにとって引き続き非常に重要になるでしょう。

この業界のコマンドラインと自動化ツールへのシフトと並行して、より現代的で強力でほぼリモートのGUIへの移行も起きていることに注意すべきです。これはあまりドラマチックな転換ではありませんが、見落とすべきではありません。MicrosoftのRSATやサーバー管理者のようなツールは、内部でコマンドラインとAPIインターフェースを活用するGUIビューを提供しています。同様にCanonicalのUbuntu世界にはLandscapeがあります。これらのツールはエンタープライズではあまり人気がありませんが、より大規模なSMB市場がGUI依存を維持しながら、より多くのサーバーインスタンスのセットを管理できるようにし始めています。これらのタイプのGUIツールの進歩は、全体的にコマンドラインツールの採用を遅らせる最も強力な力かもしれません。

コマンドラインからGUI、そして再びコマンドラインへの移行に、情報技術という産業の歴史の興味深いアーティファクトとして関心があるのか、あるいはシステム管理が自分自身の用途のためのキャリアパスやビジネスアプローチとしてどのように進化しているかを理解する手段として見ているのかにかかわらず、それが起こった要因と業界の干満が再び私たちをコマンドラインの海に戻しつつある理由を理解することは良いことです。これらの力を理解することで、未来が私たちをどこへ連れて行くか、潮流がいつ再び変わるかを、より実際的に評価し、自分のキャリアへのアプローチを最善化し、または組織のための技術と人材の両方を決定する際の参考にすることができます。