インフラ運用を少人数で担うSaaS企業の皆様へ。開発を止めない体制をつくる3つの打ち手

SaaSの成長に伴って、システム運用の負荷は増していきます。とくにインフラ運用を少人数で担う組織では、障害対応や技術調査が特定の担当者に偏りやすく、実質1人で担っている場合はそのすべてが集中します。新機能のリリースや設計変更のなかには、設定変更や権限設計、監視調整、データ連携など、インフラ側の確認や対応を前提に進むものがあります。そのため、基盤まわりの対応が滞ると、それに依存する開発や改善は進めにくくなります。

さらに近年は、生成AI活用を見据えた再設計の必要性も高まっています。しかし、過去に最適化されたシステム構成やデータの持ち方が、現在の要件には合わず、新たな取り組みの足かせになる場面も出てきます。

本記事では、インフラ運用を少人数で担い、障害対応が特定の担当者に集中しているSaaS企業が直面しやすい課題を整理したうえで、開発を止めない体制をどうつくるかを解説します。後半では、弊社のお客様でもある株式会社ZENKIGENの取り組みをもとに、Google Cloud移行、データ基盤整備、運用改善の進め方を紹介します。

インフラ運用を少人数で担うSaaS企業が直面しやすい3つの課題

成長期のSaaS企業で開発が停滞する背景には、システム構成の複雑化、データ活用の遅れ、運用の属人化といった複数の要因が絡み合っています。ここでは、現場で起きやすい課題を3つに分けて整理します。まずは、現場で起きやすい課題を3つに分けて整理します。

課題1：障害対応と不具合調査が優先され、新機能開発が後回しになる

立ち上げ期にはスピード重視で成立していたシステムでも、機能追加や運用年数の積み重ねにより、徐々に複雑化していきます。システムが複雑になればなるほど、一部の変更が思わぬ不具合を招きやすくなり、障害対応や調査の頻度が増えてしまうことは少なくありません。

インフラ運用を少人数で担っている場合、障害調査や復旧対応、問い合わせ対応の負荷は一部の担当者に偏りやすくなります。なかでも実質1人で担っている場合は、それらすべてがその担当者に集中します。そうなると、その担当者の確認や作業を前提とする設定変更、監視調整、基盤改善、データ連携の準備は後回しになりやすくなります。すべての開発が止まるとは限りませんが、インフラ側の対応を前提に進む開発や改善は、計画どおりに進めにくくなります。

課題2：データは蓄積されているのに、分析や生成AI活用までが遠い

SaaS企業の多くは、ログ、テキスト、動画など、すでに価値の高いデータを保有しています。
ただし、そのデータが分析基盤やAI基盤とつながっていなければ、活用までの距離は想像以上に長くなるでしょう。

特に、データ抽出や前処理に時間がかかる構成では、分析担当者やデータサイエンティストが着手する前に多くの工数が使われています。生成AI活用でも同様で、「データはあるのにすぐ使えない」状態では、検証や実装にすばやく着手できません。

課題3：運用の属人化が進み、事業継続の不安が高まる

障害対応、問い合わせ、調査、改善提案までを特定の担当者が抱え込むと、その人がいないと回らない状態が生まれます。これは現場の負荷だけでなく、事業継続の観点でも大きなリスクです。

さらに厄介なのは、忙しいからこそ自動化や改善に着手できず、属人化が固定化していくことです。運用体制の見直しが進まないまま、プロダクト成長だけが先に進むと、開発現場はますます不安定になります。

開発を止めない体制をつくるための3つの打ち手

こうした課題を解消するには、目の前の障害を減らすだけでは足りません。システム、データ、運用の3つをまとめて見直し、開発に集中できる状態をつくる必要があります。ここでは、そのための3つの打ち手を整理します。

打ち手1：クラウド移行を“引っ越し”で終わらせず、基盤を再設計する

既存システムをそのまま別環境に移すだけでは、複雑さや運用負荷は残り続けます。大切なのは、移行を機に、どの構成が今後の運用や拡張に適しているかを見直すことです。

たとえば、マネージドサービスを活用しやすい構成に寄せる、依存関係を整理して変更の影響範囲を小さくする、将来的なAI活用も見据えた柔軟な設計にする。こうした再設計によって、障害が起きにくく、変更にも強い基盤へ近づけます。

打ち手2：データを“保存しているだけ”の状態から“すぐ使える”状態へ変える

生成AI活用や高度な分析を進めるうえでは、データの保存先そのものよりも、「どれだけ速く、安全に使えるか」が重要です。必要なデータに必要な人が適切にアクセスできる状態をつくることで、分析やモデル開発の立ち上がりは大きく変わります。

その際には性能だけでなく、権限管理やデータガバナンスも欠かせません。センシティブな情報を扱うからこそ、利便性と統制の両立を前提にした設計が必要です。

打ち手3：運用を個人依存から仕組み化へ移し、開発リソースを取り戻す

障害対応や問い合わせ対応を人の頑張りだけで支えるのには限界があります。必要なのは監視、調査、改善、エスカレーションの流れを仕組み化し、担当者が変わっても同じ品質で回せる運用体制へ変えていくことです。

運用をエンジニアリングで改善し続ける体制が整えば、インフラ担当者は日々のトラブル対応から少しずつ解放されます。その結果、本来取り組むべき開発や改善業務に時間をあてやすくなります。

株式会社ZENKIGENは、3つの打ち手をどう進めたのか

ここまで見てきた課題は、実際に多くの成長企業で起きています。採用DXプラットフォーム「harutaka（ハルタカ）」を展開するZENKIGENも、そのひとつでした。同社では、サービス開始から7年が経過するなかでシステム構成が複雑化し、新しい機能を追加しようとしても、思わぬ不具合への対応に追われやすい状態になっていたといいます。

また、生成AI活用を進めるうえで、動画データがAWS S3に保存されており、分析基盤へつなぐまでに時間を要することも課題でした。加えて、現場ではインフラ担当者が実質1人で運用から社内問い合わせ対応までを抱え込み、営業部門からは1日に12件以上の技術的な調査依頼が寄せられていたとクラウドエースの導入事例インタビューで語られています。

こうした複合的な課題に対し、クラウドエースはGoogle Cloudへの移行を前提としたリアーキテクチャ、1,500万件超の面接動画データを扱う分析基盤の整備、BREによる運用保守体制の刷新を伴走支援いたしました。クラウドエースは、システム構成の見直し、BigQueryやDataplexを活用したデータ基盤の整備、運用改善と自動化の推進までを一気通貫で支援し、ZENKIGENが開発に集中しやすい環境づくりを後押ししました。

基盤刷新によって、開発現場はどう変わったか

基盤刷新の成果は、システムが新しくなったこと自体ではなく、現場の判断と開発スピードにどのような変化が生まれたかに表れます。ZENKIGENでは、刷新前は、システムの制約や不具合への懸念から、フロントエンドエンジニアのデザイン変更などの要望に対してもすぐには応じづらい状況があったといいます。しかし刷新後は、同様の要望に対して「即座に対応可能です」と答えられるようになり、チーム全体の機動力が向上したと語られています。

また、1,500万件超のデータを分析やAI活用に取り組みやすい土台をつくったことで、データが即座に活用可能な資産へ。今回のポイントは、単にクラウド移行をしたことではなく、開発を止めていた要因を、システム・データ・運用の3方向からまとめて解消したことにあります。

もし今、障害対応や技術調査に時間を取られ、新機能開発が思うように進まない状態にあるなら、システム構成や運用体制を見直すタイミングかもしれません。

クラウドエースではGoogle Cloud移行、データ分析基盤の整備、運用改善までを一気通貫でご支援しています。現状の課題整理からご相談いただけますので、まずはお気軽にお問い合わせください。