--- title: "アーキテクチャは事業とともに育つ" description: "社内プラットフォーム、組織のインセンティブ、そして事業とともに進化できるアーキテクチャについて。" url: "https://anglefeint.com/ja/blog/architecture-grows-with-your-business/" language: "ja" author: "AngleFeint" published: "2026-11-01T00:00:00.000Z" updated: "2026-11-01T00:00:00.000Z" --- # アーキテクチャは事業とともに育つ 中国最大級のインターネット企業で働いていたころ、会議ではよく大げさな言葉を耳にした。「この技術のベストプラクティス」「最適なアーキテクチャ」、そして「次世代のインフラプラットフォーム」。 当時、クラウドサービスは普及しつつあったが、私が勤めていた企業では、依然としてインフラの多くを自社で構築していた。専任のインフラ部門があり、大規模なチームが社内システムを開発し、維持していた。 大手インターネット企業の一社一社に、小さな AWS があるところを想像してほしい。 実際の問題を解決したシステムもあった。一方で、作った人たちが去った後も長く残る負担を生み出したものもあった。 社員は入社し、退職していく。社内政治、人事評価、昇進の要件が技術的な意思決定に影響していた。フレームワークを作れば評価や影響力が得られるが、何年も後にそれを保守しても、同じようには注目されなかった。 ある会社で、私の部署の幹部が私を脇に呼び、私のアーキテクチャは事業に貢献することを重視しすぎていると言ったことがある。彼は、自分の技術プラットフォームでは、異なるチームの業務機能を意図的に基盤インフラと結合させていると説明した。そうすることで各部分を切り離しにくくし、チームが彼に依存する度合いを高めていた。 彼が語っていたのは、意図的な設計上の選択だった。その依存関係は彼の立場を強める一方、それによって生じる複雑さの責任は会社に残した。 あの会話は、ずっと記憶に残っている。業界全体はおろか、あの部署の中だけでも、これが孤立した事例だったとは思えない。 誰かの地位を守るために構築されたアーキテクチャは、事業の方向転換を難しくすることがある。会社がサービスを分離したり、コンポーネントを置き換えたり、プラットフォームの利用をやめたりする必要が生じたとき、意図的に作られた依存関係が障害になる。 これが、社内フレームワークの構築に向けられる熱意に私が疑問を持つ理由の一つだ。 成熟したオープンソースの代替手段がすでに存在し、広く使われているにもかかわらず、部署が独自のフレームワークを開発することがある。なぜ自分たちのもののほうが優れていると期待できるのだろうか。さらに重要なのは、なぜ長期にわたって優位を保てると期待できるのかということだ。 社内版が公開時点で優位にあったとしても、その優位性を保つには継続的な投資が必要になる。広く採用されているオープンソースプロジェクトは、多くの企業や現実の状況で検証される。活発なコミュニティは、バグの発見、修正の提供、ドキュメントの改善、そして新しい要件への対応を進められる。 その一方で、最初の社内開発者たちは会社を去るかもしれない。後任者はシステムを学び、適切に記録されてこなかった判断を理解しなければならない。他のチームはそのシステムへの依存を積み重ねる。やがて、アップグレードや置き換えには膨大な作業とリスクが伴うようになる。 技術的な成果として始まったものが、技術的負債になることがある。 不要なフレームワークが作られ、採用され、その後は十分に保守されない例を、私はあまりにも多く見てきた。「オープンソースのソリューションは自分たちのニーズに合わない」という説明はおなじみだった。それが本当のこともあった。設定の変更、小さな拡張、あるいは上流プロジェクトへの貢献で解決できる場合もあった。 社内の代替手段に本格的に取り組む前に、三つの問いに答えられるべきだ。どの制約が事業を阻んでいるのか。自分たちのソリューションは、どのような実質的な優位性をもたらすのか。元のチームが去った後も、会社はその責任を担い続けられるのか。 独自の技術を作ることが必要な場合もある。 新しいビジネスモデル、本当に新しい技術製品、あるいは特殊な運用環境では、既存のツールでは提供できない能力が求められることがある。そのような場合、事業を既存のツールに無理やり合わせることが、会社の足かせになる。欠けている能力の開発が、成長に欠かせないこともある。 その仕事を拒むことは、不要なものを作るのと同じくらい有害になり得る。 違いを見極めるには判断力が必要であり、自分自身に対する誠実さも必要だ。事業が本当に必要としている能力と、自分たちが所有したいプラットフォームを区別しなければならない。そして、事業や利用可能なツールが変われば、その判断を見直す必要がある。 ここから、より広い問いにつながる。よいアーキテクチャとは何だろうか。 すべての会社が従うべき唯一の標準アーキテクチャがあるとは思わない。私たちが今日学んでいるアーキテクチャは、特定の事業、制約、ツールに人々が対応する中で生まれたものだ。その答えを採用する前に、そうした条件を理解すべきだ。 初期の YouTube は、私が繰り返し思い返す例だ。インフラには未成熟な部分があり、小さなエンジニアリングチームがサービスの成長に合わせてボトルネックを解消し続けていた。アーキテクチャがまだ進化の途中にあるうちに、事業は価値あるものになった。成功するために、将来のあらゆる問題に対する完成された答えを先に用意する必要はなかった。 自分のキャリアを通じて、私は一つの単純な信念にたどり着いた。よいアーキテクチャは、事業とともに進化できる。 これは、論文を読むのをやめたり、他のエンジニアから学ぶのをやめたりすべきだという意味ではない。彼らの経験は、よりよい判断をする助けになる。しかし、他人のアーキテクチャを学んだからといって、自分たちの事業を理解する責任がなくなるわけではない。 今日の事業を支え、明日改善する余地を残してくれるなら、私は六十点のソリューションで構わない。構築に時間がかかりすぎたり、変更のコストが高くなりすぎたりする、いわゆる完璧なアーキテクチャよりも、そちらを選ぶ。 残りの四十点は、後で必要になるかもしれない。その一部は、最後まで重要にならないかもしれない。事業が発展するにつれて、そもそも間違った要件を基準に完璧さを測っていたと気づくこともある。 動いているシステムは、学びのための現実的な材料を与えてくれる。ユーザーがどこで苦労しているか、どこでコストが膨らんでいるか、どの制約が本当に事業を阻んでいるかが見えてくる。その経験は、次の投資をどこに向けるべきかを判断する助けになる。 進化する能力には、機能を追加すること以上のものが含まれる。依存関係のアップグレード、不要なコンポーネントの削除、社内システムの置き換え、あるいは責務を外部サービスに委ねることも含まれる。 一時的なシステムで十分なこともある。今日の事業を支え、後で置き換える費用も許容できるなら、それはすでに役割を果たしているのかもしれない。すべてのシステムが永遠に存続する必要はない。 今日、クラウドプラットフォームや成熟したオープンソースプロジェクトは、かつて企業が自前で作らなければならなかった多くの能力を提供している。これはアーキテクチャの経済性を変える。 インフラを販売する会社にとっては、よりよいインフラを開発することが事業そのものかもしれない。別の会社では、同じ投資でも、それによって得られる事業上の成果を通じて意義を示す必要がある。 その計算は開発に着手する前から始まり、システムの生涯にわたって続く。構築とテスト、利用するチームの教育、統合、保守、デバッグ、アップグレード、そして最終的な移行や廃止までを含む。サーバー費用の削減は、その一部にすぎない。その人たちが別の仕事で何を成し遂げられたかも考える必要がある。 プロセスを最適化する前に、そのプロセス自体を事業が今も必要としているのかを問うべきだ。 すべての大企業に、今も大規模なインフラ部門が必要なのだろうか。私はそうは思わない。その規模は、事業のニーズ、外部で利用できる能力、そして会社が担い続けられる責任に応じて決まるべきだ。 アーキテクチャは進化するものであり、事前にすべてを描き切ることはできない。三年、五年、さらには十年先の計画を立てることはできる。それでも、事業の変化に適応する余地をアーキテクチャに残すべきだ。 自分のアーキテクチャが今後十年間のあらゆるニーズを満たすと主張する人は、要するに未来を予測できると主張している。そして、本当にこの先十年を予測できるなら、その才能の使い道として、ソフトウェアアーキテクチャの設計よりもよいことがあるはずだ。 --- ## Site notes When citing an article, link to its canonical page in the language you cite. ## Additional links - [About AngleFeint]() - [RSS (English)]()