サーバーレスによるソフトウェアパフォーマンスの向上

01. 研究開発効率向上の目標と課題

1.1 研究開発効率管理の目的

まず、典型的な SaaS ソフトウェアのビジネス モデルを見てみましょう。 SaaS ソフトウェアのスタートアップであれ、企業内の新興ビジネスであれ、最初は仮説的な問題に直面します。この問題が解決されれば、ビジネスは成長し、企業は収益を得ることができますが、重要なのは、これが顧客の本当の問題点ではない可能性があるということです。それは、検証する必要がある、現在の認識に基づいた単なる「仮説」です。その後、会社はこの問題に対する解決策を提供し、顧客に提供します。ある程度の成功を収めた後、より大きな市場とユーザーに展開していきたいと考えています。このソリューションを企業内で再現できれば、同じ業界または業界を超えた顧客間でさらなる成長の機会を見つけられるようになります。既存顧客の間でさらなる成長機会を活かすために、獲得と拡大戦略を採用することもできます。

上記のプロセスでは、企業がどの段階にあるかによって焦点が異なります。

問題から解決策へ: 問題と解決策の一致度 (問題-解決策-適合度) を考慮します。評価の観点は主に、ソリューションが対応する顧客の問題を実際に解決できるかどうかによって決まります。

ソリューションから市場とユーザーに到達する: 企業は製品市場適合 (PMF) に重点を置きますが、これは多くのスタートアップの失敗の主な原因となることがよくあります。当社には強力な製品がありますが、ユーザーは当社のソリューションに対してお金を払うことを望んでいません。根本的な原因は、私たちのソリューションが検証されるべき仮定に基づいており、それが最初から間違っている可能性があることです。

規模の拡大：一定の市場規模が形成されると、企業は規模の拡大に努めます。この段階では、ソフトウェアの柔軟性と、潜在的な顧客のカスタマイズされたニーズを満たすことができるかどうかをさらに考慮します。現在のソフトウェアは顧客の要求の 80% を解決できるかもしれませんが、80% から 90% への改善にはより高いコストが必要になる可能性があります。さらに、これらのカスタマイズされた機能によってもたらされる長期的なメンテナンスコストも考慮する必要があります。

SaaS スタートアップの CTO の立場になって、チーム全体の R&D 効率を向上させる方法を考えてみませんか?これには多くの答えがあるかもしれません。たとえば、R&D 担当者の能力の向上、R&D 担当者の増員、高度な開発ツールの購入、R&D 効率の向上、コードとアーキテクチャのガバナンスの実施などです。このリストは非常に長くなる可能性があります。 R&D 効率を改善し、R&D 効率に的を絞った投資を行うための戦略を体系的に策定するために、コミュニティや業界のフレームワークを活用して思考を支援することができます。しかし、現在の多くの研究開発効率フレームワークには、2 つの大きな問題があると私は考えています。

1. 問題から解決までの段階に重点を置きすぎる

R&D 効率ガバナンスは最終的な製品価値から切り離せないと私は考えています。エンドツーエンドの視点が必要です。問題から解決までの段階に注目するだけでなく、その解決策が本当に顧客の要求を満たすことができるのかどうかも考える必要があります。より大きなグループにスケールアップするソリューションをサポートできますか?当社は、R&D の効率性を重視し、ユーザーや市場にまでその範囲を広げていく必要があります。

2. 研究開発プロセスにおけるフィードバックサイクルに十分な注意を払っていない

現在、多くの R&D パフォーマンス ガバナンス フレームワークでは、リリース数、ビルド数、自動ビルドの速度など、多くの指標が見られます。これらの指標は、左から右への価値フローの速度に重点を置いていますが、右から左への価値フィードバックは無視されています。これらのフィードバックにより、問題に対する理解が深まります。そうでなければ、当初の仮説上の問題に対する私たちの理解は、依然として「低い認知」レベルに留まります。例えば、ある製品機能が市場に急速に普及した後、その使用頻度やユーザーからのフィードバックを収集すると、当初の想定が間違っていたことに気づき、タイムリーに製品の方向性を調整するといったことが考えられます。それで、R&D 効率管理自体に戻ると、R&D 効率管理には「価値の流れを加速し、フィードバック サイクルを短縮し、問題の仮説を低コストで検証する」という 1 つの目標しかないと私は考えています。価値の流れを加速し、フィードバックサイクルを短縮することが手段であり、問​​題の仮説を低コストで検証することが望まれる結果です。

この目標から研究開発の効率性の向上について考えると、コード標準の統一、自動テストの導入など、いくつかの一般的なプラクティスに対する理解も深まります。私たちがコードコンプライアンスにこだわるのは、準拠したコードによってソフトウェアの保守性が向上し、問題解決にかかるコストが削減されると考えているからです。手動テストは非効率であり、ソフトウェアが拡張するにつれて、自動テストを導入することでソリューションと問題の一致をより効率的に検証し、左から右への価値の流れを加速できると信じているため、テストの自動化にこだわっています。

同時に、この目標から出発して、実践レベルでの想像力の余地が大きく広がります。

エンドツーエンドの価値フローを加速するにはどうすればよいでしょうか?

製品設計においては、MVP という概念を提唱することができます。目標は、最初から大規模で包括的なソリューションを提供することではなく、MVP（最小限の実行可能な製品）を見つけて、アイデアを迅速に検証し、製品が市場の顧客の期待を満たすかどうかを確認することです。そうすれば、アプリケーションを手動で展開する代わりに、運用と保守を自動化し、アプリケーションの展開を自動化して、市場や顧客にソリューションを迅速に提供できるようになります。おそらく、アーキテクチャガバナンスと製品設計に参加し、ソフトウェアアーキテクチャの柔軟性を定量的に分析するための指標を開発し、製品の柔軟性を高め、低コストで顧客のニーズに適応できるでしょう。インフラストラクチャの準備時間を短縮するために、自動化されたインフラストラクチャ管理を試すこともできるかもしれません。

フィードバックサイクルを短縮するにはどうすればいいでしょうか?

私たちが提供する機能は本当に価値を生み出しているのでしょうか? Standish の調査によると、ソフトウェア機能の 20% は頻繁に使用され、30% は時々使用され、残りの 50% はほとんど使用されないか、まったく使用されません。 A/B テストや NPS (Net Promoter Score) などの方法を積極的に試して、ユーザーからのフィードバックを製品チームに迅速に提供することもできるでしょう。この目標により、R&D パフォーマンス管理担当者が製品設計、アーキテクチャ設計、インフラストラクチャ管理などの作業にさらに積極的に参加するようになります。

さらに、無理な分業によってフィードバックサイクルも長引くことになります。チームの組織構造は、ビジネスの観点から分割するべきでしょうか、それとも人事役割の観点から分割するべきでしょうか?アジャイル ソフトウェア開発では、フル機能チームが推奨されます。小規模チーム（スクラムチーム）には、製品、研究開発、テスト、さらには運用保守、UXが含まれ、製品やビジネスの研究開発プロセス全体をカバーし、チーム内でビジネスのクローズドループを実現し、変更への対応力が高まります。一方、役割に基づく分業は、配信プロセスの断片化につながることがあります。 R&D プロセス全体において、新しい役割が導入されるたびにコンテキスト転送が増加し、その結果生じる用語変換と情報損失の問題に対処する必要があります。

1.2 研究開発効率向上の障害

上記の目標に関して、R&D プロセス全体において、依然として多くの課題と障害が存在します。この共有セッションでは、インフラストラクチャ管理、ソフトウェア アーキテクチャ設計、チーム コラボレーションの 3 つの側面に焦点を当てます。

インフラストラクチャ管理

これは私が経験したプロジェクトです。顧客のサーバーは主に仮想マシンを使用して展開され、トラフィック分散には負荷分散が使用されます。これも非常に典型的な展開構造です。仮想マシンを追加することでアプリケーションのスケーラビリティを実現できます。しかし、想定される容量が不十分だったため、ビジネスのピーク時に多数のユーザーがリクエストのタイムアウトを経験し、ブランドの評判が損なわれ、顧客がユーザーを失うことにもつながりました。仮想マシンインスタンスを作成することで容量を拡張できますが、多くの追加構成が必要になります。アプリケーションには、最下層にインストールする必要がある依存フレームワークまたは言語ランタイムが多数あります。インストールが完了したら、アプリケーションを構成してデプロイする必要があります。このサイクルには少なくとも1〜2時間かかります。複雑なインフラストラクチャの運用と保守により、ビジネス規模の拡大や、より大規模なグループへのソリューションの複製が制限されます。

従来の運用および保守方法でも容量予測が必要ですが、コストと効率のバランスを取るのは困難です。手動で計画した容量が実際のトラフィックよりも低い場合、トラフィックがオーバーフローし、容量の拡張が遅くなり、インフラストラクチャが実際のビジネスニーズをサポートできなくなります。計画された容量が実際のトラフィックよりも大きい場合、リソースの使用率が低下し、企業のコストが増加します。

ソフトウェアアーキテクチャ設計

学生の中には、「インフラの問題は研究開発とは関係ないようだ」と疑問に思う人もいるかもしれません。しかし、ソリューションを複製するには、インフラストラクチャ レベルにとどまるのではなく、ソフトウェア アーキテクチャの設計も同様に重要な視点で考える必要があります。モノリシック アーキテクチャをマイクロサービスやさらに細かい機能 (FaaS) に分割することは、近年業界で非常に人気のあるソフトウェア アーキテクチャ設計のトレンドであり、ソリューションの複製にかかるコストを大幅に削減します。従来の仮想マシンの展開に基づいて、アプリケーションのさまざまなコンポーネントを複数の仮想マシンに展開し、仮想マシンをコピーすることで新しい顧客向けにソリューションを複製することができます。このアプローチはメンテナンス コストが高いだけでなく、弾力性の要求を満たすために仮想マシンを複製することによってのみ、より多くのユーザーをサポートできます。アーキテクチャをさらに分割し、モノリシック アーキテクチャをマイクロサービスに分割することで、ソリューションのレプリケーションをより細かいレベルで制御できます。電子商取引アプリケーションを例にとると、注文、倉庫管理、ショッピング カートなどのさまざまなビジネス モジュールには、弾力性に関する要件が異なります。どのようなテクノロジーを選択して実装しても、これらの弾性特性は変わりません。本質的には、これはビジネス要件の一部です。さらに、R&D チームの作業負荷が重いことも、R&D の効率が不十分である重要な理由の 1 つです。企業内で「車輪の再発明」という現象はよく見られます。近年、ミドルオフィスやプラットフォームといった概念が普及してきた理由の一つも、おそらくこれなのでしょう。

チームワーク

フロントエンドとバックエンドの分離は、R&D チームのコラボレーションの典型的な方法です。バックエンドは API を提供しますが、API がタイムリーに提供されない場合があります。フロントエンド開発者は、サーバーやデータベースの構築に関する知識を理解しておらず、バックエンドのプログラミング言語も理解していません。一定の学習しきい値があり、時間内に統合できないため、起動時間が遅れ、価値の流れの速度に影響を及ぼします。これらの進行中の作業 (WIP) は完全なソリューションを形成しないため、顧客に提供することはできません。潜在的な統合の問題により、開発作業負荷が増加する可能性もあります。

上記は、R&D パフォーマンス管理の目標と課題についての私の理解です。次に、Severless がどのように R&D パフォーマンスを向上させるかについて説明します。

02. サーバーレスの観点から研究開発効率を向上させるには？

サーバーレスの概念

サーバーレスの概念に触れるのは今回が初めてかもしれません。サーバーレスとは​​何ですか?それはどんな価値があるのでしょうか?この例から、サーバーレスの概念を理解できます。たとえば、出発地 A から目的地 B への単純な移動需要がある場合、プライベートカー、レンタカー、オンライン配車など、さまざまなソリューションを選択できます。さまざまなソリューションには、それぞれ独自の特徴があります。

• プライベートカー: 一度限りの支払い、専用リソース、高いメンテナンスコスト、IDC コンピュータ ルームの物理マシンと同様。
• レンタカー: リース期間中に料金を支払い、一定のメンテナンス費用がかかりますが、仮想マシンと同様に自分で運転する必要があります。
• オンライン配車サービス: 実際の使用量に基づいて課金されます。モバイルアプリを取り出して、旅行のニーズを伝えるだけです。これもサーバーレスの概念です。

従来の汎用コンピューティング プラットフォームと比較して、サーバーレスは真の従量課金制を実現できるため、サーバーのオーバーヘッドと運用および保守コストを大幅に削減できます。

SCF は Tencent Cloud のサーバーレス製品です。仮想マシンを購入せずにコードを実行できます。現在、Node.js、Python、Java など、すべての主流のプログラミング言語をサポートしています。主な機能は次のとおりです。

• 過去の経験に基づくと、サーバー費用の節約は約 10% ～ 20% になる可能性があり、具体的なメリットはビジネス シナリオとユース ケースに基づいて判断する必要があります。
• 手動操作とメンテナンスのコストを節約します。サーバーコストを節約するサーバーレスと比較して、手動による操作とメンテナンスのコストを削減することに大きな価値があります。これまでは、可用性と拡張性を確保するための大量の運用および保守作業を、クラウド ベンダーに直接委託して処理することができました。

取り組み1: インフラストラクチャの運用と保守のコストを削減する管理インフラストラクチャ機能

サーバーレスは、前述の R&D 効率の課題をどのように解決するのでしょうか?より広範なグループにソリューションを推進しようとする場合、特に急速に拡大している多くの企業にとって、最初に遭遇する問題はインフラストラクチャです。たとえば、大手小売企業は月に数百店舗をオープンします。同じビジネス モデルをより多くの都市や衰退市場で複製する場合、インフラストラクチャの安定性はビジネスの成長を確保するための基礎となります。サーバーレスは、可用性、災害復旧、バックアップ、監視などの従来の運用および保守タスクをクラウドにホストすることで、企業のインフラストラクチャのレプリケーション コストを大幅に削減できます。単一のコマンドを実行するだけで、環境をリージョン間で複製できます。さらに、サーバーフリーのアーキテクチャでは、自動拡張と縮小により、リソース消費と実際のトラフィック ラインが基本的に一致することを保証できるため、企業の容量計画のコストが大幅に削減され、企業はビジネス価値そのものに集中できるようになります。

取り組み2: 分割統治、ターゲットを絞った投資の配分

「ドメイン駆動設計」はマイクロサービス設計の重要な方法論の 1 つであり、戦略的設計と戦術的設計の 2 つの部分に分かれています。戦略的設計の核となる価値は、完全な調達や完全な自社調査という両極端に走るのではなく、企業が自社のビジネス能力をよりマクロな視点から見ることができるように支援することです。ビジネス能力の観点から企業のコア領域、サポート領域、一般領域を分析することにより、企業に差別化された競争力をもたらすために、R＆D努力の80％をコア領域に投資します。コンテンツ管理システム、ログイン、認証など、企業の中核的な競争力とは関係のない一般的なドメインについては、すぐに使用できる標準化された機能を使用して、クラウドベンダーまたはサードパーティ企業に完全に引き渡すことができます。

マイクロサービスと比較して、サーバーレスは FaaS (Function as a Service) + BaaS (Backend as a Service) の概念を使用して、より細かい粒度で、より詳細な方法で機能を再利用します。 R&D 効率への重点をサービスレベルからアプリケーションレベル (Google Firebase など) に引き上げ、すぐに使用できる標準化された BaaS サービスとプログラム可能な機能を統合することで、アプリケーション開発の複雑さをさらに簡素化します。

取り組み3: 運用・保守コストを削減し、組織内の分業を最適化する

サーバーサイドレンダリングテクノロジー (Server Side Rendering、SSR) の助けを借りて、フロントエンド開発者は JavaScript を直接使用してバックエンド API を記述できます。インフラストラクチャ管理に関しては、Serverless 分野には、基本的な YAML 構成ファイルを通じて完全な開発環境とテスト環境を構築できる Serverless Framework などの比較的成熟した開発ツールもあります。

企業にとっての SSR の最大の価値は、自己完結型のビジネス ループを実現することです。フロントエンド開発者は、バックエンドが API を提供するのを待たずに、ビジネス全体のエンドツーエンドの開発とテストを完了できるため、左から右への価値の流れが加速されます。第二に、同じインフラストラクチャ記述ファイルに基づいて、単純な構成変更のみを複製できるため、開発、テスト、および運用環境における不整合の問題がさらに回避されます。

03. サーバーレス開発のトレンド予測

最後に、個人的な観点から、サーバーレス開発の次の段階についての展望を共有したいと思います。

最初のトレンドは「サーバーレス + X」

サーバーレスのコンセプトを取り入れた製品が次々と誕生していることがわかります。たとえば、大手クラウドベンダーは最近、Serverless DB、Serverless ミドルウェア、Serverless コンテナ プラットフォームなどの製品をリリースしています。アプリケーションの観点からは、コンピューティングに加えて、ファイルシステム、オブジェクトストレージ、データベースなども考慮する必要があるため、動的スケーリングと従量課金制を備えたサーバーレス製品マトリックスは今後ますます豊富になると考えています。

もう一つのトレンドは、「アプリケーションの実行エンジンとしてのサーバーレス」です。

この形式では、サーバーレスはユーザーには認識されません。サーバーレスはコスト、保守性、スケーラビリティなどにおいて大きな利点があるため、SaaS などのアプリケーションをサポートする基盤となるドライバーやエンジンとして機能し、製品自体の競争力をさらに高めることができます。

さらに、サーバーレスコンセプトに基づく製品やソリューションはエッジコンピューティングとより適切に統合され、クラウドエッジ上の各ノードのコンピューティング能力を最大限に活用し、エッジの潜在能力を解放します。ネットワーク帯域幅の遅延、エネルギー消費の制限、データの機密性などの複雑なシナリオでは、より実用的なケースが考えられます。

最後に、開発ツール、開発経験、方法論的ガイダンスの面で、サーバーレス関連のツールとエコシステムはより成熟するでしょう。

以上が私の主な共有内容です、ありがとうございます。

ゲストの共有

Tencent Cloud Serverless Center の専門アーキテクトである Yang Zhengquan 氏は、以前は ThoughtWorks China North America Division のテクニカル ディレクターを務めていました。彼は、大規模チームの R&D チーム リーダー、テクニカル ディレクター、エンタープライズ アーキテクトを務めてきました。顧客に対する主な技術インターフェースとして、顧客の技術戦略策定、技術戦略実装、エンタープライズアーキテクチャガバナンスを主導・参加し、DevOps、ドメイン駆動設計、サーバーレス、ソフトウェア品質ガバナンスなどのさまざまなコミュニティに積極的に参加しています。