翻訳記事 -「インフラ基盤部門は本当に必要か」に関する議論
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は中国語インフラ技術者コミュニティ内で流行っていた二記事の翻訳です。
たまたま中国語のITブログを読んでいた時に、「インフラ基盤部門が要らない」という論点を持つ文章と、それに反論する文章を見かけました。論点の一部には根拠が弱い箇所もありますが、インフラ基盤部門のような部門に所属する者として、中国IT業界のトレンドや課題、そしてインフラ技術者への啓示を感じ取ることができたので、翻訳してみました。
問題提起: インフラ基盤部門は本当に必要か？問題1: コア技術がない問題2: 事業価値を提供できない問題3: 技術理念の遅れ問題4: DevOpsへ意図的な阻害反論: インフラ基盤部門は死なず、単に消えゆくのみインフラ基盤部門の価値とは？インフラ基盤部門にコア技術はない?インフラ基盤部門はどのようにビジネス価値を提供するのか？技術理念の遅れについてインフラ基盤部門は技術進歩を阻害する要因になっているのか？消え去る運命終わりに
問題提起: インフラ基盤部門は本当に必要か？
作者: 馬馳
TencentとHuaweiでDBエンジン開発、CloudComputingプロダクト開発などにPMを歴任、現在はPayPalスウェーデンでシニアインフラエンジニアを務める
過去20年間、中国のインターネット企業は大きな成果を上げてきました。インフラ基盤部門（あるいは技術プラットフォーム部門、運用開発部門、アーキテクチャプラットフォーム部門）は、インターネット企業の技術基盤を支える存在として、大きな貢献をしてきました。しかし、技術の進歩とともに、こうした部門の古い経験はクラウド時代においてますます適用されなくなり、新たな問題に対応できないことが一般的になっています。この2つの要因が重なり、次のような疑問が浮かびます：インフラ基盤部門には、果たしてまだ価値があるのでしょうか？
インフラ基盤部門の価値は、事業部門に技術を提供すること
インフラ基盤部門は、企業のインフラ基盤やアーキテクチャの人材を集約し、事業部門に技術支援を提供することを目的に設立されました。
この目的を達成するためには、インフラ基盤部門は以下の2つの条件を満たさなければなりません。
- 優秀な技術を持っていること
- 事業部門を導き、優秀な技術を活用できるように促進すること
残念なことに、過去数年間で、インフラ基盤部門はこの2点での得点がますます低くなっています。以下では、インフラ基盤部門の一般的な問題点をいくつか挙げ、読者の皆様に議論をお願いしたいと思います。
問題1: コア技術がない
インフラ基盤部門の年次プレゼンテーションでは、自分たちが何々プラットフォームを構築し、事業部門にビッグデータ管理、運用、可観測性、セキュリティ強化といった汎用的な機能を提供していることを強調するのが常です。
一部のインフラ基盤部門の技術エキスパートは、事業部門の開発者を「CRUDプログラマー」と揶揄し、自らの技術蓄積を誇りに思っています。
しかし、蓋を開けてみると、インフラ基盤部門の達人たちは実際にはOSSを組み立てる職人に過ぎないことが分かります。彼らの主な仕事は、GitHubでなんらかのOSSを見つけ、いくつかのベンチマークテストを行い、技術選定したものを自分たちのデータセンターに展開することです。このプロセスでは、堅実な人は直接コミュニティ版のパラメータを少し調整したら、そのままデプロイしてしまいました。賢い人はそれを魔改造して他人が引き継げないようにしています。さらに賢い人は、選定したOSSを模造し、他人が引き継ぎたがらないようにしています。私はこれらの人をそれぞれ「パラメータチューニング職人」、「魔改造職人」、「模造職人」と呼びます。
- パラメータチューニング職人
パラメータチューニング職人は低く見られがちですが、実際には最も信頼性の高い職人です。少なくとも、職人が辞めた後も、雇用者は引き継げる人を見つけることができます。Tencent CloudのCLBのドキュメントを見てみましょう。
レイヤー7の負荷分散は主にを基盤として実現されています。STGWはNginxをベースにしてTencentが独自に開発したもので、大規模な同時接続をサポートする7層負荷分散サービスです。これはTencent内部の多くの7層ビジネス(Tencent News、Tencent Games、WeChatなど)のトラフィックを処理しています。
このCLBは、Nginxを基盤にしているのに、何を「独自に開発した」というのでしょうか。インストールスクリプトの開発でしょうか。
- 魔改造職人
魔改造職人は改造を楽しんでいるでしょうが、ほとんどの場合、これらの魔改造プロジェクトは未完成で終わってしまいます。の事例を思い出せばわかります。
訳者による補足: AliSQLはAlibaba Cloudによって開発されたMySQL 5.6をベースにしたDBエンジンです。最後のリリース日時は 2018年5月 です。現在AliSQLのGithubリポジトリはメンテナンスされておらず、コミュニティからのPRも完全に放置されています。そのため、GithubのIssue内では批判の声が多く見られます。https://github.com/alibaba/AliSQL/issues/112
Alibaba CloudのOSSプロジェクトは、中国系IT技術者の間で「KPIのためのオープンソース」と揶揄されることがあります。
- 模造職人
例えばTecent CloudのCDN NWSです。
Tecent CloudのCDNエッジノードはすべてサーバを採用し、顧客に最適なサービスパフォーマンスを提供しています。NWSはTencentが独自に開発した高性能HTTPサーバで、一般的なNginxなどのサーバに比べて、機能とパフォーマンスの両方で明確な向上があるとされています。
実際、NWSはNginxの模造品に過ぎません。パフォーマンスの向上はでたらめで、比較対象のNginxのパラメータが最適化されていなかったからだけでした。
訳者による補足: NWSとNginxのベンチマーク結果の根拠となる情報は現在見つかっていません
問題2: 事業価値を提供できない
過去数年、ビッグデータの分野ではパラメータのチューニングや改造、模造がもっとも得意とされているでしょう。初めは皆がHadoopを使っていましたが、インフラ基盤部門はImpalaやPresto、あるいはSpark StreamingやStormを比較して技術選定を行い、CTOに対してビッグデータ技術を完全に理解していると主張していました。そして、ビッグデータプラットフォームの構築に着手しました。予算を確保して1年間取り組んだ結果、出来上がったのはWeb UIだけで、名付けて「統合ビッグデータ管理プラットフォーム」としています。人員がもっと多かった事例では、ユーザ管理プラットフォームまで作成しましたが、SSOすらサポートしていないことがよくあります。
数年が経ち、Hadoopのエコシステムが欧米で諦められ、これらの職人たちは今度はClickhouseを救いの綱として掴みました。同じ手法が再び繰り返されます。
過去10年間、全中国には少なくとも数百のインフラ基盤部門（またはビッグデータプラットフォーム部門）がこのようなことをしてきました。これらの職人たちが集まると、「あなたは600台のマシンが必要だけど、私は300台で済む」とか、「5TBのデータを処理するのに私は1時間で済むが、あなたは70分かかる、14％も速い」といった幼稚な競争を繰り広げます。これはまるで、2人の中学生が「君は2メートルしかおしっこが飛ばないけど、僕は3メートル飛ばせる」と競い合っているようなものです。
実際には、事業部門が気にしているのは、使っているマシンの台数ではありません。彼らが本当に関心を持っているのは、そのビッグデータプラットフォームがビジネス価値を生み出せるかどうかです。例えば、こういう課題です。
- そのビッグデータプラットフォームは新しいデータソースを自動で取り込むことができるのか？
- BIツールと簡単に連携できるのか？
- 細かいアクセス制御やアクセス監査が可能なのか？
- 事業部門に対して正確に課金できるのか？
- 個人情報保護のコンプライアンスに対応できるのか？
しかし、インフラ基盤部門の運用文化のせいで、彼らはこうした問題にはほとんど目を向けません。日々、自分たちの快適な領域で、マシンのパフォーマンスをいじることに集中しています。時には、「3人のエンジニアが半年かけて、会社に5万円分、マシン半台分のコストを削減しました」といった奇妙な成果報告をすることもあります。
現在、業界のビッグデータは次のステージに進んでおり、、、といった代表的なプラットフォームは、使いやすさを強調し、全プロセスでデータ活用のハードルを下げ、より多くの社員がビッグデータを活用できるようにしています。これによりデータの価値を最大化しようとしています。しかし、これらはすべてクラウドサービスであり、OSSではありません。これらの職人たちはうまく使いこなせないのです。
問題3: 技術理念の遅れ
過去十数年、ソフトウェアエンジニアリング業界ではゆっくりとではありますが確実に一連の技術革新が進行し、現在のソフトウェア業界は15年前とは大きく異なっています。しかし、これらの技術革新はiPhoneやChatGPTのように劇的な効果を持つものではないため、多くの従事者がその進歩を感じていません。この中には、アーキテクチャプラットフォーム部門の意思決定者やエンジニアも含まれています。理念の遅れが技術の遅れを引き起こし、彼らは事業部門との技術的な優位性を失い、場合によっては逆転される状況さえ生じています。
解決済みのスケーラビリティ問題に固執する
インフラ基盤部門の技術エキスパートたちは、高並行処理の問題について語るのが大好きです。Alibabaのエンジニアは「双十一・（中国の大型セールイベント）でどれだけの取引が行われるか」を話し始め、Tencentのエンジニアは「QQ(中国のLineのようなChatツール)のユーザが10億人いる」と豪語し、Baiduのエンジニアは「中国ユーザが1日にどれだけ検索を行うか」を強調します。これらの話は、初心者を驚かせるのには十分です。
正直に言えば、20年前はLAMP構成が一般的で、多くのチームがC10K問題に悩まされていました。その時期に、BAT（Baidu、Alibaba、Tencent）企業は大規模なサービスのエンジニアリング実践を模索し、それが企業のビジネス成長を支えたことには価値がありました。
しかし、それから20年が経ち、スケーラビリティは既に解決された問題となっています。基本的なアプローチはほぼ同じです。
- マイクロサービスを使用し、各サービスが独立したリソースを持つ
- Webサーバをステートレスに保ち、自動的にスケールアウト/インできるようにする
- 負荷分散を使用して外部リクエストを処理する
- コンテナを利用してバイナリの手動デプロイを避ける
- 拡張が難しいファイルシステムを使わず、コンピューティングノードと分離されたオブジェクトストレージを利用する
- 各Podが交換可能であることを保証する
- 自動スケーリング対応の分散データベースを使用し、必要に応じてキャッシュを追加する
- メッセージキューを使用して異なるシステム間の処理能力の差を埋める
- を使用して、これらのシステムをイミュータブルに保ち、複製可能にする
- コード、配置ファイル、シークレットを含むCI/CDパイプラインを構築し、コードの品質を保証する
- 各マイクロサービスに標準の可観測性ダッシュボードを提供する
- 必要に応じて、ビジネスレイヤーでユーザのパーティション分けを行う
基本的に、これらのベストプラクティスで大半の負荷に対応できます。そして、各ステップに対応するツールも存在し、どのエンジニアも自分のチームで実践できます。
それに対して、インフラ基盤部門のエキスパートたちは、高並行処理の話をする際、スレッドやプロセスの細かい点に終始するか、あるいは「アクティブ-アクティブ構成」などの半端な言葉を持ち出します。少しでも突っ込んで質問すると、「双十一の処理をしたことがあるのか？」「私が管理しているマシンの数を知っているのか？」「あなたのユーザが10億人いるか？」と怒り出す始末です。正直に言えば、こういった話は要するに、信者たちが儀式をしているようなものです。
ClickOpsに固執する
中国のソフトウェアエンジニアたちが長年にわたり過労状態にあることはよく知られています。過労死のニュースがあまり話題にならなくなってしまうほどです。その一因には、業界全体で自動化が十分に普及していないことが挙げられます。
この現象は非常に皮肉です。エンジニアたちは、年末調整や入学申請、PCR検査といったユーザ向けの業務を自動化するためのソフトウェアを開発している一方で、自分たちの業務には自動化を拒み、多くの作業を手作業で行っています。
例えば、のソフトウェアエンジニアたちは、旅行の自動化を実現するための大量のソフトウェアを開発していますが、彼ら自身が新しいHBaseのクラスタを必要とする場合、依然としてWeb UIでクリックを繰り返してチケットを生成しています。その後、運用エンジニアがそのチケットを受け取り、伝家のスクリプトを実行してクラスタを作成します。そして、IM（インスタントメッセージ）で申請者に結果を通知します。このプロセス全体が非常に煩雑で、ミスが起こりやすく、どちらのエンジニアも残業を強いられる結果となります。
原文で引用された写真
このようなClickOpsは、15年前なら受け入れられましたが、今では業界はすでにIaCという概念に移行しています。エンジニアは、IaCコードを使用してリソースプロバイダーと直接通信し、運用の中間工程を排除すべきです。
訳者による補足:
LY.COMは中国の旅行予約サイトです。
LY.COMのPlatformエンジニアは上記に対して、反論を行いました。
上記のプロセスはすでに大幅に改善され、現在では、ワークフローの承認後にKubernetes OperatorによってHBaseクラスタの作成が自動的に行われるようになっています。
LY.COM: 実際のところ、LY.COMのHBaseクラスタサービス申請のバックエンドでは、申請ワークフローの設定パラメータとHBaseクラスタ設定テンプレートを統合し、Kubernetesによるクラスタインスタンスを自動的に立ち上げるプロセスが実装されています。この自動化プロセスは非常にスムーズに動作しており、「運用エンジニアがそのチケットを受け取り、伝家のスクリプトを実行してクラスタを作成する」といった状況はもう存在しません。
問題4: DevOpsへ意図的な阻害
技術の遅れに加えて、インフラ基盤部門は時にチームの利益(予算と存続)のために、意図的にチームの効率を妨げることがあります。例えば、一部の部門は様々な名目で全ての基盤リソースを独占的に管理し、開発者がオブジェクトストレージバケットを必要とするたびに申請書を提出させます。開発者がデータベースを必要とする場合も申請書が必要で、SQL文を1行更新するだけでもDBAの承認を待たなければなりません。
インフラ基盤部門が主導するCI/CDパイプラインでは、CIの部分だけが機能し、意図的にCDの部分が切り離されることがよくあります。「本番環境の安定性を確保するため」という名目で行われますが、実際にはCDを開放すると、事業部門の開発チームが中間の手続きがなくても、効率よく高品質な仕事ができることに気づかれてしまい、自分たちの部門が不要になることを恐れているのです。
ベンダーへの疑念
同じ会社の部門であっても、事業部門とインフラ基盤部門との関係は、実際にはユーザとベンダーのようなものです。自然なことですが、ベンダーは他のベンダーを排斥しがちです。外部に優秀な可観測性ツールを提供するベンダーが存在しても、インフラ基盤部門はそれを使わず、自分たちで使いにくいELKを構築しようとします。外部に信頼性の高いRDSがあったとしても、インフラ基盤部門はMySQLを自前で構築しようとします。
LarkやDingTalkが流行する前は、中国のTop500企業のうち少なくとも200社が、内部のIMツールを開発するためにチームを抱えていました。多くの人材が劣悪な車輪を再発明することに浪費されていたのです。こうした、企業の特殊なニーズに合わせたとされるIMツールは、使いにくく、セキュリティも脆弱で、使っているうちにチーム全体が退職してしまうこともよくあります。
訳者による補足:
LarkとDingTalk中国のエンタープライズ向けIM/Chatツールです。
さらに言えば、ゲーム会社が自前のHRシステムを開発したり、フードデリバリ企業が独自のコード管理ツールを開発したり、通信設備の企業が独自の出張管理システムを開発したりするのは、暇だから雇用主の資金で自分たちの部門の勢力を広げているようなものです。
事業部門との関係の歪み
多くのインフラ基盤部門は、自分たちの価値を「社内の人間だからこそ、ビジネスのニーズをよく理解している」と主張します。一見するともっともらしく聞こえます。
しかし、実際には多くのインターネット企業において、技術はコアコンピタンスではなく、一般的なソフトウェア技術で十分ですし、特別なニーズもそれほど多くありません。逆に、もし事業部門に多くの業界では一般的にサポートされていない特別なニーズを持っている場合、ソフトウェア選定に問題がある可能性があります。
典型的な例として、ZabbixでMySQLを使って時系列データを保存する場合、MySQLに多くの要件が生じますが、これらの要件は満たすべきではありません。なぜなら、MySQLはそもそも時系列データの処理を目的に設計されたものではないからです。
もう一つの典型例は、中国国内でよく見られるKubernetesの固定IPニーズです。実際には、固定IPが必要なビジネスはKubernetesを使うべきではなく、どうしてもコンテナを使いたいなら、仮想マシン上に直接デプロイするべきです。しかし、インフラ基盤部門がこのニーズに迎合した結果、この要求は国内で広まり、Ciliumプロジェクトにまで波及しました。Ciliumプロジェクトはこの要求に応じず、3年間もissueが放置されています。https://github.com/cilium/cilium/issues/17026
訳者による補足: なお、本中国語記事の公開後、早速中国系コミッタのレスポンスがありました。
運用チームの保守的な考え方
多くの企業のインフラ基盤部門は、運用チームから派生しており、信頼性を非常に重視しています。これは強みではある一方、同時に保守的な文化を形成することにもなっています。運用のベテランたちの口癖は「動いているものは触るな」です。
多くの先進的なIT企業の技術スタックを覗いてみると、MySQL 5.7、CentOS、Python 2.X、GCC 4.9といった、すでにメンテナンスが終了した古いソフトウェアが多数使用されているのを目にするでしょう。これらのソフトウェアは、セキュリティホールが発見されてもパッチが提供されないため、互換性や安全性の面で非常にリスクが高いものです。本来、このような古いソフトウェアの更新に責任を持つべきインフラ基盤部門ですが、可用性を最優先するあまり、技術のアップグレードには最も消極的な姿勢をとることが多いのです。
原文で引用された写真
反論: インフラ基盤部門は死なず、単に消えゆくのみ
作者: 李令煇（Leo Li）
DiDi社チーフアーキテクト、MeiQia社CTOなどを歴任、現ClapDB.comのCo-FounderとCEO
訳者による補足: ClapDBはデータ分析向けのサーバレスDB SaaSを製品とするスタートアップ企業です。
昨日、Paypalの馬さんが書いた「インフラ基盤部門は本当に必要か？」という記事で、インフラ基盤部門の存在意義が疑問視されていました。私はインフラ基盤に長年携わってきた者として、比較的客観的な立場からこの記事の問題提起に答えたいと思います。そして、この文章をもって、インフラ基盤のベテランたちに敬意を表したいと思います。
インフラ基盤部門の価値とは？
馬さんが述べたように、インフラ基盤部門は事業部門に技術を提供するために存在し、そのために以下の2つの前提条件が必要です。
- 優秀な技術を持っていること
- 事業部門を導き、優秀な技術を活用できるように促進すること
技術の「優秀さ」はシーンによって異なる
しかし、「優秀さ」に唯一の基準があるわけではありません。優秀な技術とはどういうものか？技術には必ずトレードオフが伴います。例えば、ある技術が最高のパフォーマンスを提供できるとしても、その機能がシンプルすぎたり、コストが高すぎる場合、多くの企業にとっては意味がありません。
それぞれのビジネスシーンにおいて優秀の基準が異なります。企業間は同じフィールドで競争しているわけではないので、企業のビジネスを支えるインフラ基盤部門も、統一された目標を持つべきではありません。
例えば、最高の並行処理能力を追求するという目標を話しましょう。SaaS業界で世界的に有名なSalesforceは、長年にわたり「脱IOE（IBM、Oracle、EMCストレージを排除する）」と呼ばれる流れに逆らって、Oracleを基盤ストレージとして使用しています。Salesforceの並行処理能力も低いですが、だからといってSalesforceの技術が優れていないとは言えません。単に、Salesforceの分野ではその技術が適切であり、他の分野の要件には合わないというだけです。猫がペンギンと競走する必要はないのです。ペンギンは泳ぎが得意なのですから。
事業部門を「導く」？
インフラ基盤部門は、横断的な部門として存在し、部門間の重複した開発や誤った開発を減らす役割を果たしています。実際、インターネットの時代やモバイルインターネットの時代、インターネット企業は「成長」を最重要指標として掲げ、その過程で多くの未熟なプログラマーを大量に採用し、新しいビジネス領域での試行錯誤を繰り返しました。もし、横断的な部門が「導き」や「規範化」を行わなければ、ビジネスがあまりにも「野蛮」に成長してしまう可能性があります。
インフラ基盤部門にコア技術はない?
本当に「パラメータチューニング職人」、「魔改造職人」、「模造職人」なのか？
馬さんの記事では、インフラ基盤部門にコア技術があるかどうかについて議論し、エンジニアを「パラメータチューニング職人」、「魔改造職人」、「模造職人」に分類しています。
この点については、私も完全に同意します。しかし、それがどうしたというのでしょうか？
中国のインターネット企業の多くはアメリカの企業をモデルとしており、アメリカの同業者とほぼ同じビジネスを行っています。そのため、アメリカの同業者とほぼ同じ技術を使うことは全く問題ありません。それが最も確実で、リスクが少ない技術選定だからです。CTC()の本来の意味は、アメリカ(踏み石)を探って川を渡ることです。ビジネスモデルをコピーできるなら、技術スタックにも問題はありません。
訳者による補足:
Copy To China: 中国の企業が成功した外国企業のビジネスモデルを模倣することを指します。模倣の程度は様々で、単に直接競争するサービスを提供するものから、UIや商標の外観や類似した発音の名称を模倣するものまであります。このようなやり方は、日本を含めた中国以外の国々では批判されることが多い一方で、中国では民間企業から政府まで、成功のモデルとして広く認識されています。
さらに、アメリカのシリコンバレー企業、例えばTwitter（現在のX）、Facebook（現在のMeta）、Airbnbなどの大手企業は、基本的にオープンソース技術を基盤にして成長してきました。そして、その過程で問題が発生した際にそれを解決するのが「パラメータチューニング」や「魔改造」なのです。ただし、「模造」は大企業病の表れです。
「模造」は大企業病の象徴
企業が大きくなると、個人の昇進や評価の「尺度」が変わり、貢献度から「貢献度✖️難易度」に変わります。しかし、企業が大きくなり、ビジネスが安定すると、大部分の貢献は目立たないものになります。その結果、社員はより良い評価や昇進の機会を得るために、無理に難易度を上げて自己アピールを図るようになります。
「模造」の現象は、企業が大きくなるとチームの目標が企業全体の目標と乖離することに起因します。企業がKPIやOKRを導入しても、この問題を防ぐことはできません。現実には、「模造」は何らかの立派な理由で正当化されることが多く、模造によって解決できる課題が見つかるものです。模造か、それとも超越かは本人次第ですが、このようなグレーゾーンがなければイノベーションも起こらないでしょう。何事も一度模造してみるまでは、その核心を理解することはできません。悪魔は細部に宿るとは言いますが、実際に手を動かしてみないと、どの細部が重要で、どれが悪魔なのかはわからないものです。
要するに、大企業病が必ずしも悪いことではなく、むしろ大企業の資源と利益がイノベーションに一定の余地を与えているのです。しかし、投資にリスクはつきものだが、投資しなければ何も得られないこともまた事実です。
OSSを改造することの何が悪いのか？
OSSは、以下のような開発者によって開発されていることは知られています：
- 大企業が市場シェアを獲得し、競合他社を打ち負かすために、自社の商業目的でオープンソース化したソフトウェア（Android、Chrome、Kubernetes、VSCodeなど）
- 企業がOSSを経営し、オープンソース化を通じて有料顧客を獲得する（ElasticSearch、Nginx、MySQL、Cassandraなど）
- オープンソース財団が提供するソフトウェア（GNU、Linuxなど）
一般的に、1のタイプは自社のロードマップに従い、ニッチなニーズにはあまり関心を持たないでしょう。2のタイプは企業向け機能を意図的に弱めます（そうでなければ、商用版をどうやって販売するのでしょう？）。3の場合は、「welcome to your PR」といったスタンスで、商用ソフトウェアのようなサービス感はありません。
世界中のインターネット企業は、社員にOSSの改造（魔改造）を奨励しています。そして、FacebookはHBaseの主導権を社内に取り込み、GoogleはLinuxの上流にcgroupのパッチを提出しました。このように、OSSの改造が罪ではなく、技術的な未熟さこそが問題なのです。
訳者による補足: 原文の表現は、技術的な未熟さだけでなく、組織の体制や文化、認識といった幅広いニュアンスを含んでいます。
インフラ基盤部門はどのようにビジネス価値を提供するのか？
インフラ基盤部門は一般的に横断的な部門として機能しており、自らのROIを計算できるビジネス収益を持たないことが多いです。しかし、インフラ基盤部門は、可用性、スケーラビリティ、ビジネスのイテレーション速度など、より一般的な指標を通じてその価値を示します。鼠を捕るのが良い猫です。たとえその猫が最新のネイルポリッシュを塗っていなくても。インターネット企業では技術はビジネスに奉仕するものであり、大多数の企業はFAANGではありません。普通の企業の警備員にスターウォーズの装備を発明しろと要求するのは不公平ですし、現実的でもありません。
技術理念の遅れについて
遅れかどうかは相対的なものです。Appleはサーバサイド技術においても特に革新をしているわけではなく、Googleや他の会社からのコピー()です。しかし、Appleが遅れた会社であるというわけではありません。各企業にはそれぞれ得意な分野があり、その分野で技術が遅れていなければ十分です。例えば、フードデリバリーやチケット販売、Eコマース、マーケティングなどの分野で技術自身が大幅に遅れていなければ問題ありません。逆に、すべての企業がプロキシやKubernetesの展開に力を入れるのは、技術の発展には逆効果です。
なぜ私たちはスケーラビリティに固執するのか？
インフラ基盤部門の責任は可用性やスケーラビリティです。それ以外のことを言えば本業を疎かにしているように見えてしまいます。
インフラ基盤部門は技術進歩を阻害する要因になっているのか？
どんなチームであっても、組織内で自分たちの価値を証明することは欠かせない仕事です。横断的な部門であればなおさらです。インフラ基盤部門がその価値を発揮できるのは、問題が発生して責任を問われるときだけです。そのため、全体として開発の基盤が保守的になるのは当然であり、それが部門の役割と存在意義に合致しているのです。インフラ基盤チームは、しばしば事業チームの要求や行動を規制する役割を果たすため、努力が報われないように見えることが多いです。しかし、それでもなお、社内には欠かせない制約力を提供しています。
組織の慣性
これは歴史上すべての組織に見られる慣性であり、ほとんどの組織が内部から進歩や革新を遂げることはなく、外部の力によって駆動されます。例えば、ソ連の赤軍はドイツ軍の戦車に直面した際にも、未だにコサック騎兵に希望を託していました。インフラ基盤チームも他のチームと変わりはなく、彼らの使命は企業のビジネスを支えることです。もしその使命を達成しているのであれば、自己改革の動機はほとんど生まれません。しかし、これはコサック騎兵(古い思想)のせいではありません。
非テック企業の参入障壁は技術ではない
中国市場の多くのインターネット企業は技術駆動型ではなく、継続的に進化するインフラ基盤部門を必要としません。むしろ、ビジネスが急成長していない場合、コストを抑える方が現実的です。
なぜインフラ基盤部門は外部のベンダーを排除するのか？
インフラ基盤部門は多くの場合、社内の技術提供者であり、外部の競合相手を排除するのは自然なことです。結局のところ、外部のベンダーもインフラ基盤部門とほとんど同じアプローチを取っているのです。彼らもオープンソースシステムを基盤にして魔改造やパラメータチューニング、さらには模造を行っています。そんな中で、インフラ基盤部門が自分たちの武器を放棄して、他人の武器を買うというのは難しいことです。ユーザもベンダーも、それぞれに問題を抱えています。
消え去る運命
老兵は死なず、単に消え去るのみ。
新たな生産力は必ず新たな生産関係を生み出します。
インフラ基盤チーム自体は、「過剰なリソースを使って成長を実現しようとする」という過去の時代のインターネット企業の縮図です。
しかし、どの時代にも終焉のときがあり、インフラ基盤部門も他の成長時代における過剰なリソースと同じように、徐々に削減されるでしょう。インターネット企業は、高投入から高ROI志向の理性的な投入へとシフトしていきます。自主性とコントロールを求める姿勢から、より合理的なコストでコントロールを実現する方向へと転換されます。
訳者補足: 「過剰なリソースを使って成長を実現しようとする」というのは中国インターネット企業によく見られた成長戦略の一例です。スマホ(特に)とインターネットの普及から始まったモバイルインターネット時代では、多くの企業はリソースを過剰に投入し、できるだけ多くの機能を一つのアプリに詰め込むことで、ユーザの囲い込みと市場シェアの迅速な拡大を狙いました。ユーザの離脱を防ぎ、他のサービスへの移行を抑えるという目的もあります。
例えば、天気アプリのような単機能アプリであっても、ニュース、ショート動画、フードデリバリー、支払い機能まで追加する万能Appが中国ではよく見られます。このようなやり方は、効率よりも規模の拡大を重視する「野蛮成長」と呼ばれ、中国インターネット企業の文化と体制を反映しています。 (最近の日本でも見られる現象です)
インフラ基盤チームは次の2つの方向のいずれかに進むことになります：
- クラウドを受け入れ、人的コストを削減する
- 市場を受け入れ、製品を市場に提供して競争に参加する
ROIの観点からインフラ基盤という役割を再評価し、再配置することで、無駄に存在していた者たちがチームから排除されるでしょう。時代の産物は当然、時代の流れに従って発展していくのです。
終わりに
これら二つの記事は、企業の技術基盤を支える「インフラ基盤部門」の存在意義と将来性について、異なる視点から議論しています。インフラ基盤部門が企業内で果たす役割は、技術の進化とともに変化しているという現実があります。馬氏が指摘するように、過去のやり方に固執していると、時代の流れに取り残される危険があるでしょう。一方で、李氏が述べるように、インフラ基盤部門には技術的な価値と、ビジネスを安定して支える重要な役割が依然として存在しています。
今後、インフラ基盤部門とインフラエンジニアは、クラウド技術の進化やビジネスニーズの変化に対応しつつ、その役割の再評価、効率化と価値の提供をどう両立させるかなどが課題となるでしょう。
ところで、中国のIT業界の「Copy To China」という概念や、シリコンバレーに対抗する目標には驚きました。これからも良い中国語の記事があったら翻訳したいと思います。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
SRG では最近出たホットなIT技術や書籍などについてワイワイ雑談するポッドキャストを運営しています。ぜひ、作業のお供に聞いていただければ幸いです。
