【CNDW2025】CloudNative時代に品質を後回しにしないための開発プロセス再設計とLeading Qualityの実践

CloudNative Days Winter 2025で行われたセッション「CloudNative時代の開発プロセス再設計、速さと品質を両立するには」では、クラウドネイティブ化が進む開発現場において、スピードと品質を両立させる開発をどうやって実現するかがテーマとして語られた。マイクロサービス化やCI/CDの普及により開発の柔軟性は高まった一方で、従来の品質保証の考え方では限界が見え始めている。株式会社Voicyのエンジニアリングマネージャ兼QAリーダの森田麻沙美氏は、QAエンジニアとしての実体験をもとに、品質を「最後に確認するもの」から「最初から作り込むもの」へと捉え直し、クラウドネイティブ時代に適合した開発プロセス再設計の考え方を示した。

プロセス再設計が問われる理由とその全体像

クラウドネイティブの浸透は、開発の前提条件そのものを大きく変えた。マイクロサービス化やCI/CDの普及により、開発スピードとアウトプット量は飛躍的に向上したがその一方で、従来型の品質保証プロセスはその変化に追随できず、テスト工程がボトルネックとなる場面が増えている。森田麻沙美氏は、このギャップこそが「いま開発プロセス再設計が必要とされる理由」であると指摘する。

かつてのモノリシックな開発では、設計から実装、テスト、リリースまでを長いサイクルで回すことが一般的であり、品質保証は最終工程でまとめて行われてきた。しかしクラウドネイティブ時代においては、小さなサービスを継続的に開発・デプロイすることが前提となり、品質保証のアプローチも開発ライフサイクル全体に組み込まれることが求められる。品質は「最後に確認するもの」ではなく「初期段階から作り込むもの」へと役割を変えつつあるのである。

「開発のスピードやアウトプットの量は確実に上がりましたが、従来の品質保証のやり方だと、どうしても最後のテスト工程がボトルネックになってしまいます」と森田氏は語る。

このセッションが扱う「開発プロセス再設計」とは、特定のテスト手法やツールの紹介にとどまらない。クラウドネイティブ化によって変化した開発の当たり前を前提に、速さと品質を両立させるために、開発全体の設計思想や役割分担を見直す試みである。QAはもはや最後の砦ではなく、開発チームとともに品質を作る存在へと位置づけ直される。その全体像を理解することが、以降で紹介される具体的な事例を読み解く前提となるのである。

クラウドネイティブがもたらす開発の変化と新たな課題

クラウドネイティブの普及は、開発のスピードと柔軟性を大きく向上させた。マイクロサービス化やCI/CDの導入により、機能は小さな単位で実装・検証・リリースされ、以前と比べてアウトプットの回転は格段に速くなっている。森田氏は、この変化そのものは開発にとって明確な前進であるとしつつも、「速く作れるようになった結果、品質をどう担保するのか」という新たな問いが顕在化している点を強調した。

従来のモノリス型開発では、設計から実装、テスト、リリースまでを長いサイクルで進め、品質保証は最終工程で集中的に行われることが一般的だった。しかし、サービスを分割し継続的にデプロイする開発スタイルにおいて、こうした後工程依存の品質保証は機能しにくい。リリース頻度が高まるほど、テストが最後に滞留し、結果としてスピードを阻害する要因になりやすいからである。

この構造的な課題により、テスト工程が「ボトルネック化」し、リリース直前で不具合の発見が集中する状況が生まれる。品質を確保しようとすれば開発が止まり、スピードを優先すれば品質リスクが高まるという二項対立が、現場に強い負荷を与えてきた。森田氏は「最後にまとめてテストをしようとすると、どうしてもリリース直前で不具合が見つかり、大きな手戻りが発生してしまいます」と語り、これは個々のテスト手法や努力の問題ではなく、開発プロセス全体の設計がクラウドネイティブ時代に適合していないことに起因すると位置づける。

つまり、クラウドネイティブがもたらしたのは「速く作れる環境」だけではなく「品質保証の考え方そのものを変えなければならない状況」である。本章で整理したこの課題認識が、次章で語られるプロセス再設計の実践、すなわちQAの早期参加やテスト自動化、品質文化の醸成へとつながっていくのである。

クラウドネイティブ時代の品質保証とは？

Voicyにおけるプロセス再設計の実践

次に森田氏は、株式会社Voicyで取り組んできたプロセス再設計の実践を、三つの観点から整理した。いずれも速さと品質を対立させるのではなく、両立させるための具体的な試行錯誤である。

プロセス再設計の3つの事例

一つ目は、QAの早期参画である。従来、QAはリリース直前のテスト工程を担う存在であり、開発の上流工程には関与していなかった。しかし森田氏は、QAを「最後の砦」ではなく「品質を一緒に作る協創者」と再定義し、要件定義や設計段階からQAが関与する体制へと移行した。実際には、当初キックオフミーティングに呼ばれない場面もあったが、粘り強く参加を続けることで、設計段階でテスト観点を共有し、受け入れテストに反映できるようになったという。「後工程で不具合を見つけるのではなく、早い段階で防ぐことができるようになりました」と森田氏は振り返る。結果として、リリース直前の手戻りは減少し、全体のリードタイム短縮につながった。

二つ目は、テスト自動化の再設計である。森田氏は、「E2E（End to End）テストでやりたかったのは、最低限のユーザー体験が提供できているかを確認することでした。すべてを自動化しようとは考えていませんでした」と語る。E2Eテストを導入する前提として、自動テスト全体の役割整理から着手した。ユニットテスト、統合テスト、E2Eテストの責務を明確にし、E2Eテストは「最低限のユーザー体験を担保する」ことに目的を絞った。すべてを自動化するのではなく、重要度の高い機能から小さく始める方針を採り、段階的に導入を進めた点が特徴である。「完璧を目指すより、小さな成果を積み重ねることを重視しました」という言葉の通り、定量的なコスト削減以上に、チームに心理的な余裕が生まれたことが大きな成果として語られた。

そして三つ目は、品質文化の醸成である。森田氏は、MissionとVisionを明確にし、QAチームの存在意義と目指す姿を言語化した。品質は特定の職種だけが担うものではなく、開発チーム全体で向き合うべき課題であるという認識を共有するため、ロードマップを策定し、継続的に取り組みを可視化していった。「QAがいなくても品質が保たれる組織を目指したい」という発言に象徴されるように、最終的なゴールは役割の固定化ではなく、文化として品質を根付かせることにあった。

これら三つの実践は、いずれも単独で完結するものではない。QAの早期参画、自動化の整理、文化づくりが相互に作用することで、速さと品質を両立するプロセス再設計が現実のものとなっていったのである。

Leading Qualityが示すプロセス再設計の本質

セッションを通じて示されたプロセス再設計の成果は、単なる効率化やコスト削減にとどまらない。QAの早期参画やテスト自動化の整理、品質文化の醸成を進めることで、リリース直前の手戻りが減少し、結果として開発スピードと品質の双方が向上した。加えて、森田氏が強調したのは、チームに生まれた心理的な余白である。追われるようにテストをこなす状態から脱し、品質について考え、議論する時間を確保できたことが、継続的な改善を可能にした。

ここから得られる示唆は、品質は仕組みやツールだけで担保できるものではないという点にある。品質をどこで、誰が、どのように作るのかという設計思想そのものを見直すことが、クラウドネイティブ時代には不可欠である。森田氏の語る「Leading Quality」とは、QAという職種に限らず、各自が自分の立場で品質をどうリードするのかを問い続ける姿勢にほかならない。森田氏は「QAだけが品質をリードするのではなく、それぞれが自分の立場で品質をリードしていくことが大切だと考えています」と語った。

I'm Leading "__"

速さと品質を両立するために、何を改善するかではなく、何をLeadingするのか。本レポートが、読者自身の開発現場を見つめ直すきっかけとなれば幸いである。