IT予算の60〜80%がレガシーシステムの維持管理に費やされているという現実は、多くのCTOやITアーキテクトが日々直面している深刻な課題です。ガートナーの2025年調査によれば、日本企業におけるIT投資の平均74%がシステム維持費として消費されており、新機能開発やDX推進に充てられる予算はわずか26%に過ぎません。この「維持費の罠」に加え、DORA規制（デジタル運用レジリエンス法）やNIS2指令への対応要求、AIシステム統合の加速という三重の外圧が、システムリアーキテクチャを経営の最優先課題へと押し上げています。

しかし、システムリアーキテクチャは単なる技術刷新ではありません。過去のマイクロサービス化の失敗から生まれた「分散型モノリス」の教訓、Amazon Prime Videoがマイクロサービスからモジュラーモノリスへ回帰して90%のコスト削減を達成した事例、そしてAIモダナイゼーションツールが主張する「50%の工数削減」の裏側にある現実的なリスクまで、成功するためには正確な情報と実践的な判断基準が不可欠です。本記事では、SIパートナーとして中堅企業から大規模エンタープライズまで数多くのリアーキテクチャプロジェクトを手がけてきた知見をもとに、2026年における最新の進め方を体系的に解説します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・システムリアーキテクチャの完全ガイド

システムリアーキテクチャとは――2026年に求められる再定義

システムリアーキテクチャとは、既存システムの根本的なアーキテクチャ構造そのものを再設計し、新たな技術基盤と組織能力に適合させるプロセスを指します。単に古いコードを新しい言語で書き直す「リプレース」でも、個別の問題箇所を修正する「リファクタリング」でもなく、システムが担う責務の分離方法、サービス間の通信パターン、データの所有権と境界、デプロイメントの単位といった設計原則の全体を見直す根本的な取り組みです。2026年時点では、この定義自体が進化を遂げており、単なる技術的移行から「ビジネスの俊敏性を回復する組織変革」として位置づける企業が増えています。

リファクタリング、リプレース、リアーキテクチャの三者は、しばしば混同されますが、適用すべき状況と期待できる効果が根本的に異なります。リファクタリングは、外部から見た機能やインターフェースを変えずに内部の実装を改善する手法です。コードの可読性向上や技術的負債の局所的な解消には有効ですが、アーキテクチャの構造的問題、たとえばデータベースの密結合やモジュール間の循環依存には対処できません。リプレースは、既存システムを新しいシステムに全面移行する手法であり、スクラッチ開発によるゼロベースの再構築が代表例です。プロジェクト期間が長大になりやすく、IPAの調査では大規模リプレースの失敗率が約40%に達するという統計もあります。これに対してリアーキテクチャは、ビジネス継続性を維持しながら段階的に構造を変革する手法であり、後述するストラングラーフィグ・パターンのような漸進的アプローチによって、リスクを分散させながら価値を継続的に生み出すことができます。

2026年にシステムリアーキテクチャが経営アジェンダとして急浮上している背景には、三つの強力な外圧があります。第一の外圧は規制対応の急務化です。EUが2025年1月に完全施行したDORA規制は、金融セクターのITシステムに対してリスク管理・インシデント報告・デジタルレジリエンステストを義務化しており、モノリシックなレガシーシステムではこれらの要件を満たすことが技術的に困難です。NIS2指令も重要インフラを持つ企業に幅広く適用され、コンプライアンスの不備は売上高の最大2%または1,000万ユーロを上限とする制裁金のリスクを生じさせます。第二の外圧はAI統合の加速です。生成AI・機械学習モデルをビジネスプロセスに組み込もうとしても、密結合したCOBOLやJ2EEベースのシステムではAPIを通じたAIサービスとの連携が著しく困難です。McKinseyの試算では、レガシー制約によるAI導入の遅延が2026〜2030年の期間に企業の競争力格差を平均23%拡大させると警告しています。第三の外圧は技術債務の臨界点到達です。2000年代に構築したJ2EEシステムや1990年代のCOBOLシステムを維持するエンジニアの高齢化が進み、2030年には国内でCOBOL保守エンジニアが約35%不足すると予測されています。この三重の外圧が重なる2026年は、多くの企業にとってリアーキテクチャを「いつかやること」から「今すぐ始めること」へと転換させる臨界点となっています。

2026年のアーキテクチャトレンド――モジュラーモノリスの台頭

2023〜2025年にかけて、テクノロジー業界に一つの重要な認識転換が起きました。「マイクロサービスが常に正解」という神話の崩壊です。Kubernetes上に何十個もの小さなサービスを分散展開したものの、サービス間の依存関係が複雑に絡み合い、デバッグに通常の3〜5倍の時間がかかるという「分散型モノリス」に悩む企業が相次ぎました。この反省を受けて、2026年のリアーキテクチャ議論では「どのアーキテクチャが最先端か」ではなく「自社の規模と成熟度に最適なアーキテクチャはどれか」という実用主義的視点が主流となっています。

2023年にAmazon Prime Videoが公開したブログ記事は業界に衝撃を与えました。同社のビデオ品質監視システムを分散マイクロサービスからモジュラーモノリスに移行した結果、インフラコストが90%削減され、オペレーションの複雑さも大幅に低減されたというのです。同様に、Shopify、Stack Overflow、Basecamp（37signals）なども、過度に細分化されたサービス群を統合する方向へと舵を切っています。Istioを開発したLyftも、サービスメッシュのオーバーヘッドについて率直な反省を公表し、適切なサービス粒度の見直しを推奨するようになりました。日本国内でも、ECプラットフォームや金融系Fintechを中心に、2020〜2022年のマイクロサービス化投資が「分散型モノリス」という最悪の状態を生み出してしまったケースが増えており、リアーキテクチャの対象がこれらの「失敗したマイクロサービス群」になっているというケースが少なくありません。マイクロサービスが失敗する典型的なパターンは、ドメイン境界の設計が不十分なまま機能単位でサービスを分割してしまうことであり、結果として「画面を一つ追加するために5つのサービスのデプロイが必要」という状態になります。この教訓から、2026年のベストプラクティスでは、チーム規模とデプロイ頻度を基準としたアーキテクチャ選定が強調されています。

モジュラーモノリスとは、単一のデプロイ単位を維持しながら、内部をドメイン境界に沿った明確なモジュールに分割するアーキテクチャです。開発チームの規模が50名以下、1日のデプロイ回数が10回未満、ドメインの複雑さが中程度という条件では、モジュラーモノリスがマイクロサービスより優れた選択肢となります。採用のメリットとして、サービス間のネットワーク通信オーバーヘッドがなくなること、デバッグのためのトレース収集が単一プロセス内で完結すること、インフラコストと運用負荷が大幅に削減されることが挙げられます。しかし、モジュラーモノリスが最も注意を要するのは、時間の経過とともに「モジュール境界が劣化する」という問題です。開発速度を優先するあまり、異なるドメインのモジュールが互いの内部実装に直接依存するようになり、最終的に「普通のモノリス」に逆戻りしてしまうリスクがあります。この劣化を防ぐためには、ArchUnitやjQAssistant（Java系）、あるいはGoのパッケージ依存関係検査ツールを用いたアーキテクチャテストをCI/CDパイプラインに組み込み、モジュール境界の違反を自動検出する仕組みを構築することが不可欠です。具体的には、「受注ドメインのコードが在庫ドメインの内部クラスに直接アクセスしている」といった境界違反をPull Requestの段階で検出し、ビルドを失敗させるルールを設定します。この「アーキテクチャの番人」をCI/CDに組み込んでいるかどうかが、モジュラーモノリスの長期的な維持を可能にするかの分岐点となります。

システムリアーキテクチャの進め方――5つのフェーズ

システムリアーキテクチャを成功させるためには、一足飛びに理想状態を目指すのではなく、明確なフェーズに区切って段階的に進めることが重要です。以下に示す5フェーズのアプローチは、リアーキテクチャを完全停止リスクなく、かつROIを測定しながら実行するための実践的なロードマップです。全体の期間は、中堅企業（開発者30〜100名規模）で18〜36か月が目安となりますが、スモールスタートを重視することで最初の成果を6か月以内に出すことも可能です。

最初のフェーズでは、現行システムの技術的負債を定量化し、リアーキテクチャの優先度と方向性を決定します。このフェーズで行うべき作業の核心は「アーキテクチャ・フィットネス関数」の測定です。具体的には、コードカバレッジ、循環的複雑度、モジュール結合度、デプロイ頻度（DORAメトリクス）、変更障害率といった指標を計測し、現在のシステムがどの程度「変更に強い」構造になっているかを数値で把握します。2026年においては、AIを活用した静的解析ツール（GitHub Copilot Workspace、Amazon CodeGuru、SonarQubeのAI機能）がこの分析を大幅に効率化しており、従来の手作業による依存関係マッピングと比較して最大50%の工数削減が報告されています。ただしAI分析には重要な限界があります。ツールはコード上に明示された依存関係は検出できますが、「この処理は年度末の決算バッチが終わってから実行しなければならない」といった暗黙のビジネスルールや、ベテランエンジニアの経験知として文書化されていない制約は検出できません。このため、AI分析の結果を5〜10年の業務経験を持つドメインエキスパートと突き合わせるヒューマン・イン・ザ・ループのレビューセッションが不可欠です。分析結果をもとに、「ストラングラー優先度マトリクス」を作成します。縦軸に変更頻度（月次変更回数）、横軸にビジネスインパクト（売上・顧客影響度）を置き、四象限に既存機能をプロットすることで、最初にリアーキテクチャすべきターゲットを客観的に選定できます。

フェーズ2では、フェーズ1の診断結果をもとに「将来あるべきアーキテクチャ」を設計し、採用技術を選定します。2026年の技術選定において最も重要な判断軸の一つが、ベンダーロックインとマルチクラウド対応のトレードオフです。たとえば、AWS Lambdaを全面的に採用すれば開発速度は上がりますが、AWSへの依存度が高まり、将来的なマルチクラウド化の際に抽象化レイヤーの追加コストが発生します。Kubernetesを中心とした抽象化レイヤーを設けることで移植性は高まりますが、Kubernetesの運用スキルを保有するエンジニアの採用・育成コストが追加で必要になります。このトレードオフを定量的に評価するために、TCO（総所有コスト）の5年試算を行うことを推奨します。マネージドサービスを活用したオプションAと、抽象化レイヤーを設けたオプションBを比較すると、多くの中堅企業ではオプションAのほうが3〜5年の期間では20〜30%低コストになるという試算が出ます。アーキテクチャ選定にあたっては「アーキテクチャ選定マトリクス」を活用することが有効です。チームサイズ（1〜5名、6〜15名、16名以上）、デプロイ頻度（月次、週次、日次）、変更の独立性要求（低・中・高）、スケーリング要求（均一・部分的・個別）の4軸で評価すると、モノリス、モジュラーモノリス、マイクロサービスのどれが最適かが明確に導かれます。

実際の移行フェーズでは、ストラングラーフィグ・パターンを中心的な手法として採用します。この手法は、熱帯植物のストラングラーフィグ（絞め殺しの木）が既存の木を外側から包み込みながら徐々に置き換えていく様子になぞらえたもので、レガシーシステムを一度に全面停止させることなく、機能ごとに新しいアーキテクチャへ段階的に移行していきます。具体的な実装パターンとして、まず「ファサードレイヤー」をレガシーシステムの前段に配置します。このファサードがすべてのリクエストを受け付け、移行済みの機能は新システムへ、未移行の機能はレガシーシステムへとルーティングします。移行の順序は、フェーズ1で作成したストラングラー優先度マトリクスに基づき、変更頻度が高くビジネスインパクトが中程度の機能から着手するのが最もリスクが低いアプローチです。しかしこのフェーズで最も難しい課題となるのがデータマイグレーションです。特にダウンタイムゼロでの移行は、理論上は可能でも実装の複雑さが大幅に増します。ダウンタイムゼロ移行の実装パターンとして「ダブルライト」手法があります。移行期間中は旧データベースと新データベースの両方にデータを書き込み、新システムの読み取りは新DBから行いながら、旧DBとの一貫性を定期的に検証する仕組みです。また、10年以上稼働してきたレガシーデータには、文字コードの混在（Shift-JIS・UTF-8の混用）、NULL値とブランク値の混在、事業変更により意味が変わったカラム、削除されたはずの参照整合性の欠落といった、データクレンジングの難題が必ず潜んでいます。この問題に対処するために、移行前のデータプロファイリングに最低4〜8週間を確保し、データ品質の問題を事前に洗い出すことを強く推奨します。

フェーズ4は、旧システムと新システムが並行稼働する「過渡期」です。このフェーズの実態は、プロジェクト計画で最も過小評価されやすい工程であり、多くのリアーキテクチャプロジェクトがここで予算超過と期間延長を経験します。並行稼働にかかるコストは初期見積もりの1.5〜2倍になるケースが多く、その主な理由は三つあります。まず「二重管理の複雑さ」として、同じデータを二つのシステムで整合性を保ちながら管理するためのオペレーション負荷が想定以上に大きいことです。本番データで不一致が発生した場合の調査・修正対応は、通常のバグ対応より格段に工数がかかります。次に「ロールバックのコスト」として、新システムで問題が発生した場合に旧システムに切り戻すためのデータ同期処理が複雑になります。そして「ユーザートレーニングと運用ルールの二本立て」として、移行期間中は旧システムを使うユーザーと新システムを使うユーザーが混在するため、サポート体制と操作マニュアルを二系統維持する必要が生じます。これらのコストを事前に見積もりに含めるとともに、「機能別カットオーバー計画」を詳細に策定しておくことが成功の鍵です。具体的には、月次で移行完了した機能リストを確認し、全体の移行率をパーセンテージで追跡するダッシュボードを設けることで、プロジェクトの進捗と残リスクをステークホルダーに可視化します。

旧システムのシャットダウンが完了しても、プロジェクトは終わりではありません。フェーズ5では、新アーキテクチャの恩恵を持続させるためのガバナンス体制を確立します。最重要の施策は、前述したアーキテクチャテストのCI/CDへの組み込みです。これに加えて、「アーキテクチャ決定記録（ADR：Architecture Decision Record）」の文化を組織に定着させることが長期的な成功を左右します。ADRとは、「なぜこのアーキテクチャを選んだのか」「どのような選択肢を検討してこれを採用したのか」「この決定の前提が変わった場合はいつ見直すか」を1〜2ページの軽量なドキュメントに記録するプラクティスです。ADRがなければ、3年後には誰も現在の設計判断の理由を知らなくなり、同じ議論を繰り返す「アーキテクチャの健忘症」に陥ります。DORAメトリクス（デプロイ頻度、変更リードタイム、変更障害率、MTTR）を定期的に計測し、リアーキテクチャのROIを定量的に評価することも、経営層へのコミュニケーションと予算確保の観点から不可欠です。リアーキテクチャに成功した企業では、プロジェクト完了後2年以内にデプロイ頻度が平均4.7倍に向上し、障害復旧時間（MTTR）が平均60%短縮されたというデータがあります。

失敗しないためのポイント――競合記事が語らないリアルな課題

システムリアーキテクチャに関する多くの記事は、成功事例と理想的な手順を解説するにとどまります。しかし現場では、計画通りに進まない要因が必ずいくつか存在し、これらへの事前準備が成否を分けます。ここでは競合記事がほとんど語らない「リアルな課題」を四点取り上げます。

2025〜2026年にかけて、AWS、Google Cloud、Microsoftがそれぞれ「AIによるレガシー自動モダナイゼーション」ツールを競って提供し始めました。これらのツールは、COBOLやJ2EEのコードをAIが解析してJavaやGoのコードに変換するもので、分析フェーズで最大50%の時間削減を謳っています。実際にコード変換の自動化率は50〜70%に達するケースもあり、一定の効果は認められます。しかし、現場で必ず直面するのがAIハルシネーションのリスクです。AIが生成した変換コードは「構文上は正しいが、ビジネスロジックを誤って解釈している」というケースが全変換コードの15〜25%程度発生します。特に問題になるのが、COBOLの計算処理における「精度（小数点以下の桁数と丸め方法）」の解釈差異や、会計処理の端数計算ルールです。これらの誤りをテストで全て捕捉するためには、テストケースの設計者が元のCOBOLの意図を深く理解していなければなりません。このため、AI変換を活用したとしても、ドメイン知識を持つ人間によるコードレビューとテストシナリオの設計を組み合わせた「ヒューマン・イン・ザ・ループ」の運用体制を設計することが不可欠です。具体的には、全変換コードに対して元の処理との数値一致テストを100ケース以上用意し、境界値（最大値・最小値・ゼロ除算など）での挙動を徹底的に検証するプロセスを標準化しておく必要があります。AIはあくまで「たたき台を高速に生成するツール」であり、「検証を省略できるツール」ではないという認識を組織全体で共有することが、AIモダナイゼーションを安全に進める前提条件です。

リアーキテクチャの技術的課題として語られることが少ないのが、人材の転換（リスキリング）です。20年以上COBOLやJ2EEでシステムを支えてきたベテランエンジニアは、最も貴重なドメイン知識の保有者ですが、Kubernetes・Go・Rustといった現代的な技術スタックには不慣れなケースが多いです。このギャップをどう埋めるかが、リアーキテクチャの人的リスクの核心です。経験豊富なエンジニアを新技術に転換するための現実的なロードマップとして、まずフェーズ1（3か月）でクラウドの基礎概念（AWSの主要サービス、コンテナとVMの違い、CI/CDパイプラインの仕組み）を習得します。この段階では、既存のレガシーシステムの知識と新技術を「つなぐ」橋渡し役として活躍してもらいながら学習を進めます。フェーズ2（3〜6か月）では、Dockerとコンテナ化の実践、GoやTypeScriptを用いたAPIサービス開発の基礎を習得します。フェーズ3（6〜12か月）では、Kubernetesの運用、GitOpsワークフロー、オブザーバビリティツール（Datadog、Jaeger等）の実践的な活用に取り組みます。重要なのは、このリスキリングプロセスを「既存業務と並行して自己学習で行う」という設計にしないことです。実務時間の20〜30%を学習・実践に充てることを組織として公式に認定し、学習成果をパフォーマンス評価に反映させる仕組みを設けることで、エンジニアの主体的な参加を促すことができます。COBOLエンジニアが保有するビジネスドメイン知識は、新しいシステムを設計する上で代替不能の資産です。テクノロジーのキャッチアップを支援しながら、その知識を新アーキテクチャに転写することが、組織としての最大の競争優位になります。

システムリアーキテクチャのROI証明は、多くのCTOが頭を悩ませる課題です。McKinseyの調査によれば、モダナイゼーションプロジェクトの平均コストは290万ドルに達し、経営層がそのビジネス価値を実感できるまでに平均18か月を要するとされています。このギャップを埋めるために、「フィーチャーベロシティ指標」と「インシデントコスト削減指標」の二軸でROIを測定することを推奨します。フィーチャーベロシティとは、新機能を企画から本番リリースまで届けるリードタイムのことで、リアーキテクチャ前後でこの数値がどれだけ改善したかを月次で追跡します。あるBtoB SaaS企業の事例では、リアーキテクチャ完了後12か月でリードタイムが平均47日から9日に短縮され、年間リリース回数が12回から156回に増加したことをROIの根拠として取締役会に報告しています。インシデントコスト削減指標は、障害1件あたりの平均復旧時間（MTTR）と影響を受けたユーザー数の積として算出し、月次の損失コストを可視化します。これらの指標を月次で経営報告に組み込むことで、「リアーキテクチャは費用ではなく投資」という認識を経営層に定着させることができます。ROI計算テンプレートとして、（年間インシデントコスト削減額）＋（フィーチャーベロシティ向上による機会収益）＋（インフラコスト削減額）を分子に、（プロジェクト総コスト）÷（5年間）を分母に置いた投資回収率を算出し、プロジェクト開始前・進捗報告時・完了後の三点で計測することを標準プロセスとして設計することを推奨します。

テックジャイアントの事例は参考になりますが、開発者500名規模の事例がそのまま開発者30名の中堅企業に適用できるわけではありません。中堅企業がリアーキテクチャで最初に選ぶべきは、「最も痛みが大きく、最も境界が明確な一つの機能」です。たとえば、「ユーザー認証と権限管理」は多くのレガシーシステムで変更頻度が高く、かつ他の機能との依存が整理しやすい領域です。この単一機能を新アーキテクチャで実装し、ストラングラーフィグで切り替えるというパイロット実験を3か月以内に完了させることが第一目標になります。あるIT部門が10名の製造業企業では、約20年稼働してきたJ2EEの在庫管理システムのうち、「入出庫記録の登録・照会」機能だけを先行してSpring Boot＋Vue.jsで再実装し、nginxをファサードとしてルーティングを切り替えました。この3か月のパイロットで得られた成果（デプロイ時間が4時間から8分に短縮、テストカバレッジが0%から72%に向上）を社内で共有したことで、経営層の追加予算承認が得られ、残り機能の移行プロジェクトへと発展した事例があります。スモールスタートの成功体験を社内に蓄積し、それを次のフェーズの投資承認に活用するというサイクルを回すことが、リソースに限りがある中堅企業においてリアーキテクチャを前進させる最も現実的な戦略です。

まとめ

本記事では、システムリアーキテクチャの定義から2026年の最新トレンド、5フェーズの具体的な進め方、そして競合記事では語られないリアルな課題と対策まで、実践的な観点から体系的に解説しました。2026年のシステムリアーキテクチャを成功させるための核心は、以下の四点に集約されます。

第一に、アーキテクチャの選定は「最先端技術」ではなく「チームの規模・成熟度・デプロイ頻度」を基準として行うことです。Amazon Prime Videoの事例が証明したように、マイクロサービスからの回帰も時として最善の判断であり、モジュラーモノリスが多くの中堅企業にとって2026年における最適解になりえます。第二に、ストラングラーフィグ・パターンによる段階的移行を実装し、データマイグレーションのリアルな困難（ダウンタイムゼロ移行、レガシーデータクレンジング）に対して十分な時間とリソースを確保することです。過渡期の並行稼働コストは初期見積もりの1.5〜2倍になると想定して計画を立てることが現実的です。第三に、AIモダナイゼーションツールの限界を正しく理解し、ヒューマン・イン・ザ・ループのレビュー体制と徹底的なビジネスロジック検証テストを組み合わせることです。AIは強力な補助ツールですが、暗黙のビジネスルールの解釈と検証は人間の責任として残ります。第四に、アーキテクチャの品質をCI/CDパイプラインで継続的に監視するガバナンス体制と、フィーチャーベロシティおよびインシデントコストによるROI測定の仕組みを構築することです。これによって経営層への説明責任を果たしながら、長期的に新アーキテクチャの価値を維持することができます。

riplaは、中堅企業から大規模エンタープライズまで、システムリアーキテクチャの現状評価から段階的移行の実行支援、アーキテクチャ・ガバナンスの確立まで一貫してサポートするSIパートナーです。「どこから始めればよいかわからない」「過去のマイクロサービス化の失敗を乗り越えたい」「COBOLシステムのモダナイゼーションでAI活用を検討している」という方は、ぜひriplaにご相談ください。貴社のシステムの現状と目標に合わせた最適なリアーキテクチャ戦略をご提案します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・システムリアーキテクチャの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。