■サービス化とプロダクト開発の様相変化

昨今、プロダクト形態のサービス化が進展しています。ソフトウェアをSaaSやPaaSなどで提供したり、Webサービスとして運用したりするケースが増えており、パッケージや組み込みソフトウェアに関しても、「納入して終わり、組み込んで終わり」ではなく、継続的なアップデートを通して顧客満足を高めていくスタイルが一般的になりました。車載ソフトウェアでは、OTAで継続的に機能をアップデートしながらユーザー体験を日々更新していくアプローチが定着しつつあります。
またサービス化の流れは、開発ライフサイクルの長大化というもう一つの大きな変化を開発現場にもたらしました。リリースがゴールだった従来の開発とは異なり、サービス化されたプロダクトでは、リリースを中間地点としてその後も永続的に機能を改善・追加していくことになります。

■求められるチームの総合力

さらに開発に携わるチームの在り方も変化しつつあります。
従来は、案件ごとにメンバーを招集し開発が終わったら解散するプロジェクト型が主流でしたが、近年ではサービス化の流れを受け、同じメンバーが開発からリリース後の運用・機能アップデートまで携わり、継続的にプロダクト価値を引き上げていくスタイルが増えています。
このような現代的なプロダクト開発では、チームの総合力が求められます。
では、その総合力とは何か。具体的には次の四つの要素が挙げられます。

1. ・顧客満足を支える品質実現
2. ・開発のスピード
3. ・開発のレジリエンス（問題・困難に対する適応力・回復力）
4. ・開発持続性

これらを強化することによってチームの開発力を鍛え、プロダクト品質を高め、顧客満足を獲得していくことが可能になります。

■総合力をトレードオンで伸ばす

チームの総合力（品質実現、スピード、レジリエンス、開発持続性）はテストアプローチにおいても重要であり、特にこれらをしっかり「共立（トレードオン）」させていくことが不可欠となります。

ポイントは「共立」です。実際に筆者はさまざまなテストの現場を見てきましたが、品質追求を第一義とするあまり、スピードやレジリエンス、開発持続性が二の次になってしまう、あるいは見落とされてしまう（つまり共立できていない）パターンが多々ありました。
例えば、リリース前の最終テスト工程で品質ゲートを重厚化するケースがありますが、バグ対策を最後の工程に集中するアプローチは手戻りとなり、スピードやレジリエンスが犠牲になりがちです。これでは品質を上げようとする施策が逆にサービスの質を下げる結果につながってしまいます。
また、テストの責務を独立性の高い組織に集中（丸投げ）するケースもありますが、実際には開発・テストチーム間でバグピンポンやコミュニケーションロスが発生することも多く、やはりスピードやレジリエンスの低下を招いてしまいます。
こうしたケースでは品質を追求するあまり、トレードオフとして他の三要素が犠牲になっていることが分かります。
現代的なソフトウェア開発では、あくまでも4要素の全てを共立で向上させるテストアプローチを目指すことが重要です。

■品質のシフトレフト

品質実現、スピード、レジリエンス、開発持続性を共立しながら総合力を伸ばすアプローチとして、シフトレフト（品質のシフトレフト）を紹介します。
品質のシフトレフトとは、リスクの検証やバグ対策といった品質に関する活動を早い段階から実施し、早期に品質確保・保証を行うアプローチです。

ここに早期の品質対策・品質確保がいかに重要かを示したグラフがあります（図表1）。
例えば、要求仕様の段階でバグ対応するのに必要なコスト（時間・労力）に比べ、設計段階までバグを放置した場合のコストは5倍、コーディングまで放置した場合のコストは10倍、テストまで放置した場合のコストは20倍となっています。さらに納入時点でバグが見つかった際に要するコストは200倍。バグ対策を後回しにするほど対応に費やされる時間や労力が指数関数的に増えていくことが分かります。

シフトレフトはこういった事態を回避し、最初からバグ・不具合の発生を予防する、あるいは早めに発見して早期に対策することで開発スピードを早め、併せてリソース効率を上げていくアプローチと言えます。
早期に保守性をしっかり確保することで、以降の開発における保守活動の効率も向上します。さらに、バグのモニタリング・監視・特定の手段をしっかりインフラとして強化することで、レジリエンスの向上にもつながります。
このようにシフトレフトを推進することで、開発の四つの要素（品質、スピード、コスト、リスク）をバランス良く向上させることが可能になります。

シフトレフトを推進するためのテストアプローチとして、以下の五つの施策を紹介します。

■スパイラル型品質作り込み

シフトレフトを推進するための施策、一つ目は「スパイラル型品質の作り込み」です。
これは正当な反復型開発プロセスを推進し、反復ごとに有効なリリースを行い、その度に得られる有効なフィードバックを品質改善に反映させることでスパイラル状に品質を向上させていくアプローチです。
図表2は,、その概念を示したもので、左側が従来のウォーターフォール型開発における品質の推移（シーケンシャル型）、右側がスパイラル型の品質の推移を示しています。横軸は時間（時系列）、縦軸は品質レベルを表しています。

シーケンシャル型では、要件定義・設計を通してバグなどの品質問題が埋め込まれ（テストを動かすまで見えないバグが増えていく）、開発が進展するほど品質が下がります。
そして、開発の中盤以降、テスト工程が本格化するところから問題の検出・デバッグによって品質を向上させていきます。妥当なレベルまで品質を確保したところでリリースとなります。グラフの曲線（品質レベル）は開発中盤にかけて落ち込んでいき、テスト工程に入ってから巻き返します。一方のスパイラル型は動く有効なソフトウェアを早期に確保しつつ、品質フィードバックを繰り返しながら継続的に品質を高めていきます。品質レベルの落ち込みがなく、右肩上がりで品質を作り込んでいくスタイルと言えます。

スパイラル型品質の作り込みを実現するには、正当な反復型プロセスを採用することが基本となります。「正当な」とは、単純にタスクをイテレーションごとに分割するのではなく、反復ごとに妥当性を確認できる"動くソフトウェア"をリリースして、これに対する包括的な品質のフィードバックを得ることを指しています。

具体的にはどうするのか。まず挙げられるのがシフトレフトテスト（テスト実行のシフトレフト）の推進です。これは"動くソフトウェア"に対するテスト実行をできる限り前倒していくもので、単純なアプローチですが非常に有効です。例えば、ウォーキングスケルトンを実現して、開発早期から動的なシステムテストを回していきます。
早い段階からユーザー視座のフィードバック機会を確保・充実させることも重要です。顧客満足観点のテストやプロダクトオーナーなど（ユーザーの代弁者）のスプリントレビューを早期に行う、あるいは包括的な品質確認を反復ごとにしっかり行います。
他にも、自動テストの充実、CI/CDの充実、疎結合アーキテクチャーの推進、ブランチ戦略など、さまざまなエンジニアリング手法を積み重ねることで、効率的かつ安全に反復型プロセスを推進することが容易になっていくのです。

■開発者テストの充実

二つ目の施策は「開発者テストの充実」です。開発者のテスト力を鍛えてユニットテスト・統合テストを充実させます。このユニットテスト・統合テストで早期からしっかりとバグを検出し品質を確保します。また、ユニットテスト・統合テストを満遍なく行きわたらせることで以降の機能追加・変更をサポートしていく。そういった形でシフトレフトを支えます。

図表3は、自動テストにおける望ましいテストケース比率を示したテストピラミッドと呼ばれるものです。一般に上位のテスト（UIテストなど）ほど開発速度は遅くなります。そして、UIテストや手動テストよりも実行速度の速い自動化された統合テストやユニットテストを充実させることが重要になります。これらは早期からテスト実行でき、かつ実行速度が早く実行制約も少ないためスピードと品質を両立させた開発を可能にします。
また「開発者テストの充実」を実現するには、開発者が責任を持って良い自動テストを書く、かつその習慣を定着させることが不可欠となります。

■開発工程へのテストの視座の注入

三つ目の施策は「開発工程へのテストの視座の注入」です。
さまざまな開発工程がある中で、要求分析や仕様定義、アーキテクチャー設計といった初期段階からテストの視座を注入しフィードバックを与えていくアプローチです。これにより仕様・設計バグを予防・早期検出でき、リスクの早期コントロールが可能になります。

実践プラクティスの一つにWモデルがあります（図表4）。これは各上流工程と一緒にテストの分析や基本設計の工程を一緒に行うアプローチです。
例えば、要求分析を行う際には対応する受け入れテストの分析・設計、アーキテクチャー設計を行う際には対応する結合テストの分析・設計を行い、仕様の漏れやアーキテクチャーの矛盾を検出します。その過程で「テストのしにくさ」や「テスト容易性の要件」を明確化できるため、テスト容易性の確保につながります。

■テスト容易性の充実

テスト容易性（試験性、テスタビリティー）を確保していくこともシフトレフト推進のための重要なアプローチになります（図表5）。適切なテスト容易性を確保することで、後のテスト設計と実装・実行・保守を各段に効率化でき、結果的に開発の総合力を高めることができます。
例えば、アーキテクチャーレベルでテスト自動化容易性を確保して自動化率を上げることでリグレッションテストを拡充し、差分開発をスピードアップすることができます。結果的に開発持続性も確保できます。
あるいは、網羅容易性（テストでの網羅のしやすさ）を確保してDefect Localization（不具合の原因特定）を容易にし、障害の特定・修正をスピードアップする、こういった効果も期待できます。
重要なのは、①コードレベルではなく、アーキテクチャー設計レベルでしっかりテスト容易性を確保すること、②テスト実行の難しさや問題点を実体験で早く知るために、できるだけ早くテスト実行を行うこと（シフトレフトテストの推進）の二点です。

■品質リスクの分離

最後の施策が「品質リスクの分離」です。ハイレベルな品質リスクを特定コンポーネントに閉じ込め、コンポーネントの変更や不具合が他に波及しないようにリスクを局所化する開発アプローチになります。この前提は、疎結合設計（アーキテクチャーレベルにおいてコンポーネント間の結合性を下げる設計）を推進することになります。
具体的には、マイクロサービスアーキテクチャーやマルチプロセッサアーキテクチャーを採用し、サービスごとにサーバーやプロセスを分け、疎結合設計にすることで各サービスを独立して開発・変更可能にします。

一連の概念をまとめたものが図表6です。
リスク分析の結果、高リスクと認められたものを特定のサーバーやプロセッサに閉じ込めます。例えば、Webサービスにおける課金、個人情報、著作権保護など、バグの混入で多大なリスクをもたらす機能がこれに当たります。
次に、品質の積み上げというアプローチを取っていきます。コンポーネントレベルでの品質担保を行います。高リスクなコンポーネントに対してはユニットテスト・統合テストでしっかりとバグ出しを行うなど重厚な品質確認を実施する一方、低リスクのコンポーネントではスピード重視のテストを行い、手間のかかるシステムテストを緩和するなどのアプローチを取ります。
このように、品質リスクの分離には、テストでメリハリを付けられる点、コンポーネント単位での品質の積み上げができる点などのメリットがあります。テストのメリハリが生まれることで、テストレベル全体での工数を緩和し、総体として品質と開発スピード、レジリエンス、開発持続性を共立させることができます。

今や開発チームの総合力の強化が不可欠です。これを実現するための施策として主にシフトレフトについて紹介し、併せてその実現のためのアプローチを解説しました。品質の問題点やリスクを早期に検出し対策することが開発の効率化のみならず、プロダクト価値を支え顧客満足を獲得する重要な手段となるのです。