AWS Startup ブログ

【セッション紹介】フェイズ別スタートアップ企業の技術選定 -ソリューションアーキテクトが課題解決策を解説 / AWS Summit Online 2021

フェイズ別スタートアップ企業の技術選定（画像クリックで動画にとびます）

5万人の技術者およびビジネス関係者が参加する日本最大の AWS イベント「AWS Summit Online 2021」が、2021年5月11日・12日に開催されました。本記事では基調講演やセッションのなかから、スタートアップに関連するものをご紹介します。

今回ピックアップするのは、スタートアップソリューションアーキテクト 齋藤 祐一郎 (@koemu) による
「フェイズ別スタートアップ企業の技術選定」
です。

このセッションでは、創業期からシリーズ A までの企業の草創期の段階ごとに求められる、適切な技術選定の方法が語られました。

 

企業の成長と技術選定の指針

最初のテーマは、スタートアップ企業の成長フェイズごとに技術選定の方針が異なるという点。フェイズごとにとるべき技術選定の方針について、齋藤は次のように解説していきました。

まずは企業の創業直後。少ない資金、例えば100万円から1,000万円ほどを元手に、MVP (Minimum Viable Product) の開発が始まります。このフェイズでは、開発は少人数で行われ、技術選定では「すぐにアプリを動かせる」「学習コストが最小限」「開発・運用の手間が最小限」といった要素が重視されます。

次はシード期。数百万円から数千万円の資金を調達し、MVP をリリースしてフルタイムのエンジニアが徐々に参画し始める頃です。技術選定では創業時から重視してきた要素だけでなく「軽量な機械学習を用いた事業グロース施策」「簡単なデータ分析」なども検討材料に加わります。

そして、シリーズ Aでは調達額が数千万円から数億円となり、PMF (Product Market Fit) に到達。開発組織は、責任者の配下に複数名のエンジニアがつくような体制になります。技術選定としては「スケーラビリティ」「可用性」「機能の拡張性」などが重要な観点になり始める時期です。

なかでも、シード期に考慮しておくべき要素として挙げたのは、自社の MVP が成功・ピボットいずれのパターンにもなりうることを前提に、開発を進める必要がある点です。

2018年のスタートアップ創業数は約1,800社ですが、一方で2017年の M&A・上場などの Exit 数は133件と、成功は非常に狭き門。だからこそシード期においては、仮に事業がうまくいかなくても途中で軌道修正・変更できることが重要です。

Amazon には「One-way and Two-way Door Decisions」という考え方があります。One-way door とは一度進むと元に戻しにくい決断および状況であり、Two-way door とは一度進んでも元に戻しやすい決断および状況です。企業の意思決定において Two-way door の割合を増やすには、人・物・金・時間そして情報という経営資源を必要最小限かつ効率的に使うことが重要だといいます。

ただし注意すべきは、使用リソースを短期的に抑えるために、将来的にマイナス影響が生じるような行動をしてはならないこと。例えば、テストコードを書かずに開発を進めるなどすると、中長期的に見たシステム改修コストが増大してしまいます。

流行りの先例ではなく、自分たちに合った事例を参考にすることも重要だと齋藤は述べます。例えば流行しているマイクロサービスは、シード期の企業には適していないことも多いのです。企業のアーリーステージでは機敏性*と回復力*のある技術選定が重要になります。

* 機敏性 (Agility) … 日々変化する状況に応じて、素早く判断して行動できる特性
* 回復力 (Resiliency) … 問題が発生したときも、煩雑な手続きや作業を経ずに、解決するために行動できる力

また、フィンテックやヘルスケアなど規制業界を扱うスタートアップは、法務面を学んでおくことも重要だと言及しました。

 

MVP 開発後の状況に応じた技術選定の基準

大前提として MVP の成功と技術選択の成功との間には相関関係はありません。ビジネスとして成功したものの、ソースコードがスパゲッティになっているケースもあります。一方、緻密に設計・構築されたシステムがユーザーから受け入れられないケースもあるでしょう。

そのため、MVP 開発後の状況としては下図の黄色部分の3パターンが考えられます。それぞれどのような技術選定をすべきなのでしょうか。

象限①：MVP の開発後、お客様はつき始めたが技術的な問題が出ている

この象限にいる企業様から、AWS のソリューションアーキテクトは以下のようなご相談を受けるケースが多くあります。

課題解決に適した AWS サービスがいくつか挙げられます。まず、開発におけるリリースサイクル改善のためには、AWS CodeStar が有用です。これは CI（Continuous Integration）と CD（Continuous Delivery）環境構築のサポート・自動化を行うサービスで、リリース工数の削減やリリース作業の標準化、ミスの軽減などの効果があります。

運用におけるサーバー運用の手間の軽減のためには、AWS の2種類のサーバーレスサービスが有効になります。1つ目はコンテナ向けのサーバーレス実行環境である AWS Fargate。AWS Fargate を活用すれば、ハードウェア管理だけではなくインスタンスや OS の運用監視、各種ライブラリのアップデートが不要になります。

2つ目は AWS Lambda です。Amazon EC2 や AWS Fargate と AWS Lambda との決定的な違いは、ユーザーがミドルウェアの管理・運用を行う必要がないこと。AWS Lambda もインスタンスや OS の運用監視、各種ライブラリのアップデートが不要です。また、実行した計算資源の分だけ課金される料金体系となっています。

運用におけるシステムのパフォーマンス改善のために有効なツールが Amazon CloudWatch Container Insights で、コンテナのパフォーマンスをモニタリングできます。とりわけ、Amazon Cloudwatch のデフォルト設定では確認が難しい、コンテナごとの負荷を測定可能であることは、このツールの大きな利点です。

もう1つ Amazon RDS Performance Insights も有効で、データベースのパフォーマンスをモニタリングできます。処理に時間がかかっている SQL や CPU 負荷などを検出し、ソフトウェアのパフォーマンス改善に役⽴てることが可能です。

また、専任の IT インフラエンジニアがいないアーリーステージのスタートアップに向けて、AWS のサービスを柔軟に取り込みながら⾼速で Web・モバイルアプリをリリースできる開発プラットフォームの AWS Amplify を、齋藤は強く推奨しました。

自社の事業が成功を収めていても、多くの技術的負債が残ったままでは、それ以上の成長が困難になってしまいます。言うなれば、技術課題の解決は会社の未来のために行う“投資”です。より大きな事業成長を実現するため「どうすれば自社の開発・運用体制をさらに良くできるか」という視点を、常に持ち続けましょう。

象限②：MVP の開発後、お客様がつかない

MVP を出したもののお客様がつかない場合、考えられる事業上の選択肢は以下の3つです。

  • 改修して続⾏
  • ピボット
  • 別の事業で稼ぎつつ続⾏

このうち「サービス改修しての事業続行が、本当に可能かどうか」は慎重に考える必要があると齋藤は説明しました。事業を継続するには、資金面を含めた企業の体力が求められます。企業として⾝動きが取れるうちにピボットするのもひとつの策です。

また、素晴らしいアイデアであり将来的に成功する可能性が高いものの、プロダクトが今の世の中にはフィットしないケースもあるかもしれません。そのため、別の事業で資金を稼ぎつつ、良いタイミングが来るまで⾒定めるのも有力な選択肢です。

方針を見定めず、闇雲に事業運営を続けてしまえば、社員は疲弊し貴重な資金も失われてしまいます。機をみて方針転換を行い、改めて戦いに挑むのが最上の策というケースもあるのです。例えば、Slack の創業者であるスチュワート・バターフィールドは、もともと Tiny Speck というゲーム会社を経営していましたが、同社はゲームの販売不振による経営難に陥りました。しかし、資金を使い切らない段階でピボットを行い、Slack を生み出したのです。

象限③：MVP の開発後、サービスも開発も順調に進んでいる

MVP の開発後、すべてがうまくいっている素晴らしい企業様もいらっしゃいます。そうした企業様からは、AWS のソリューションアーキテクトは以下のような相談を受けることがあると話しました。

これらの課題の解決策を紹介していきました。まずは、開発における企画の強化・検証をサポートしてくれる AWS のサービスを2つ取り上げます。

1つ目は Amazon Pinpoint。メールや SMS、Push 通知などを利用できるインバウンドマーケティングコミュニケーションサービスです。メッセージ送信だけではなく、送信後のパフォーマンス測定機能も充実しており、施策の成果を確かめることができます。2つ目として、インタラクティブなダッシュボードを作成できる Analytics サービスの Amazon QuickSight も、施策の検証に役立ちます。

運用における耐障害性の向上という課題の解決策は、複数の Availability Zone (AZ) に Amazon EC2 のインスタンスや AWS Fargate のコンテナを配置して可用性を高める Multi-AZ 対応や、負荷に応じてインスタンスやコンテナ数を増減させる Auto Scaling の設定が有効です。

また、運用における監視強化のためには、サービス監視として Amazon CloudWatch を、システム利用料金監視として AWS Budgets の予算超過アラートの機能を有効活用することも可能です。なお、Amazon CloudWatch には以下の4つの主な機能があります。

  • Amazon CloudWatch
    • AWS 上で稼働するシステム監視サービス
    • 状態監視・性能監視・キャパシティ監視など
  • Amazon CloudWatch Logs
    • ログ管理プラットフォームサービス
    • Amazon EC2 上の OS、APP のログ
    • AWS のマネージドサービスのログ
  • Amazon CloudWatch Logs Insights
    • ⾼速でインタラクティブなログ分析
  • Amazon CloudWatch Events (Amazon EventBridge)
    • AWS リソースの状態監視サービス
    • AWS リソースに対するイベントをトリガーにアクションを実⾏する機能

続いて、組織の課題を解決する方法について。メンバーを増やしてもスケールする開発組織にするために大切なキーワードは「標準化」「⾃動化」「統⼀化」です。自社の各種施策が、これらを実現できるものになっているかをご確認ください。

また、コンテナなどを用いた開発環境のパッケージ化や、自社の事業やシステムにおける Why・What（プログラムのソースコードからは読み取れない情報）のドキュメント化の重要性を説き、入社した人がすぐに開発を始められる体制づくりについても言及しました。

自社のより良い体制づくりに役立てるには、先人達が築き上げてきた知見を学ぶことも効果的です。これまで数多くのスタートアップが、自社の事業や開発体制を改善するために様々な取り組みを行ってきました。そうした各社の事例を知ることで蓄積された知識を習得できます。

また、AWS もアーキテクチャ構築のベストプラクティス集である AWS Well-Architected フレームワークなど、各種のノウハウを公開しております。ぜひ、こうした知見を学んでいただき、自社の業務にお役立ていただければ幸いです。

 

AWS の支援プログラム

セッション終盤では AWS の支援プログラムも紹介されました。まずは AWS Activate について。これは、スタートアップや起業家に対して AWS の使用を開始する際に必要なリソースの提供を目的とした特別な無料プログラムで、以下のようなサポートを受けることができます。

AWS Activate クレジット
AWS サービス使用料の支払いに充てられるクレジットが付与されます。

AWS サポート（クレジット）
後述する、AWSの各種サポートにおいて「ビジネスサポート」を受けられるクーポンを受け取ることができます。

AWS トレーニングとリソース
AWS の専門家からトレーニングを受けてクラウドのスキルと知識を強化できます。学習のために AWS が提供する各種資料をご利用いただくことも可能です。

また、AWS には各種サポートプランが存在しています。「ベーシック」「開発者」「ビジネス」「エンタープライズ」の4段階があるため、事業上のニーズに応じたプランを選択してください。手厚いサポートを受けられるため、まるで社内に AWS エンジニアが1人増えたかのような感覚で、事業改善にお役立ていただけます。

おわりに

以上の内容で、齋藤によるセッションは終了しました。企業のフェイズごとに、求められる技術選定の基準は異なります。自社の状況にマッチした選択を行うことで、技術的な投資の費用対効果を最大化できるのです。

ぜひ本セッションの内容を参考にしていただき、自社がどういったフェイズにあるのかをご確認ください。そして、今回語られた知見や AWS の各種サービスをご活用いただき、みなさんの事業成長やプロダクト開発にお役立てください。私たち AWS が、日本のスタートアップ各社のさらなる発展に貢献できれば幸いです。