PDCAによる継続的改善
PDCAによる継続的改善
品質保証（QA）において、テストとデリバリーのプロセスを継続的に改善することは重要な役割の一部です。組織の主要メンバーとして、コスト、時間、範囲というクラシックな課題の中で、チームと自分が最適なバランスを見つけるために、さまざまなワークショップや会議、トレーニングに参加する必要があります。
PDCAとは？SQAとは？
Wikipediaによると、PDCA（Plan–Do–Check–ActまたはPlan–Do–Check–Adjust）は、ビジネスでのプロセスや製品の管理と継続的改善のために使用される反復的な4ステップの管理手法です。デミングサークル、コントロールサークル、またはPlan–Do–Study–Act（PDSA）とも呼ばれています。
ソフトウェア品質保証（SQA）は、品質を確保するためにソフトウェア工学プロセスと方法を監視する手段です。これを実現する方法は多岐にわたりますが、ISO 9000などの基準に準拠することや、CMMIなどのモデルを使用することが含まれる場合があります。
上記の定義に基づくと、PDCA手法は組織の戦略に関わらず、提供される製品を改善するための全体的な品質保証アプローチに適していることが明らかです。
PDCAサイクル
以下に、各サイクル「計画（Plan）」「実行（Do）」「確認（Check）」「改善（Adjust）」の説明をします。
計画（Plan）
最初に行うべきことは、複数のプロジェクトから情報を収集し分析して、各プロジェクトの各フェーズ（設計、開発、テストなど）のポジティブおよびネガティブなポイントを特定することです。ネガティブポイントごとに、根本原因分析を行い、問題の発生源を特定します。その後、問題の発生源をリストアップし、「管理」「スキル」「コミュニケーション」などのカテゴリに分類します。
問題のリストが確定したら、それについての詳細な提案を議論する別の会議を開催します。多くの場合、解決策の影響が大きくない場合に投資を少なくするため、短期的なステップを定義することが推奨されます。
この時点で、各問題は根本原因にリンクされ、アクションまたは解決策にリンクされます。これで、予定された目標と期限を持つアクションリストが完成します。
おめでとうございます、重要なステップを通過しました。
実行（Do）
このステップには、各解決策の実装に関するステークホルダーとのコミュニケーションが多く含まれます。アクションプランに関与するすべての役割と人物が、提案された解決策やアクションを実行し、ドキュメントに基づいて実施します。
「実行（Do）」のステップは、アクションがどのフェーズに考慮されているかによって通常は時間がかかる場合がありますが、参加者はすべて、アクションが実施されていることを確認するために他の人物またはチームに監督される必要があります。
確認（Check）
ここでは、実施されたアクションと解決策が問題を解決したかどうかを確認します。新しいパフォーマンスや効率を、計画ステップで収集されたデータの古いものと比較するために、正確なKPIで測定することが必須です。
結果を比較する前に、これらの結果が新しいアクションの実施に基づいていることを確認し、外部条件やアクションプランからの逸脱によるものでないことを確認してください。
改善（Adjust）
すべてのデータとアクションが検証されると、通常はOKまたはKOの結果が得られます。ポジティブな結果の場合は、マネジメントがドキュメントを標準化し、これらのアクションを全体のプロセスに適用し、必要に応じてこれらのアクションが実施されることを確認します。
KOアクションについては、次回または最初のステップとして再度「計画」に戻り、改善および強化を行います。
完全な例
サイクルをマスターするためには、完全な例が最適です。以下の例を考えてみましょう。クライアントがプロジェクトで多くのバグを発見したが、テストチームでは発見できなかったため、問題は「クライアントによって発見された高いバグ率」とします。
計画（Plan）
根本原因分析とバグレビューを行い、バグがどのフェーズで検出されるべきかを決定しました。結果、開発者による最後の瞬間の修正によってテストチームがソフトウェアの制御を部分的に失っていること、特定の条件でランタイムバグがシステムのクラッシュを引き起こしていることがわかりました。
計画セクションの結果をまとめると：
- 問題 1: 完全にテストされていない納品 -> 主要な最終コミット -> アクション 1: 自動回帰テストの実施。アクション 2: プロジェクトマネージャーは、開発の最後での主要な修正を避けるためにタスクと計画を整理する必要があります。
- 問題 2: 特定の入力でシステムがクラッシュ -> 機能テストのみ実施 -> アクション 3: コード分析ツールの使用。アクション 4: コードレビューの義務化。アクション 5: データ駆動テストプロセスの実装。
実行（Do）
アクション 1 とアクション 5 をテストチームに伝え、フォローアップを確実にするためにモデレーターを任命します。
- アクション 2 はプロジェクトマネージャーが実行し、開発チームと品質部門またはオペレーションマネージャーによって検証される必要があります。
- アクション 3 とアクション 4 は開発チームが担当し、シニア開発者またはソフトウェアアーキテクトが監督します。
確認（Check）
この時点でソフトウェアがクライアントに納品され、フィードバックが受け取られます。これにより、新しいアクションを実施したこのバージョンでのクライアントによって発見されたバグの率を、以前のバージョンでのバグと比較して測定することができます。
例えば、クライアントがまだいくつかの欠陥を発見しましたが、分析の結果、特定の入力に関連するバグのみが見つかりました。基本的には、アクション 3、アクション 4、アクション 5 が問題を解決せず、50%の問題しか解決できなかったことがわかりました。これは開始としてはある程度良い結果です。
改善（Adjust）
この時点で、マネジメントとテストリーダーは、同様のプロジェクトに対して自動回帰テスト（アクション 1）を標準化し、マネジメントはアクション 2 に従って計画に準拠し、最後の瞬間の主要なコミットを防ぐ必要があります。
残りのアクションについては、次の「計画」フェーズで再度取り組むことになります。
結論
最高の品質を最も低いコストで、最短の納期で達成するための完璧なガイドラインはありません。しかし、複数のワークショップと現在のプロセスを「掘り下げる」ことによって、コスト、時間、範囲を考慮しながら、会社にとって達成可能なバランスまたはリファレンスプロセスに達することができるでしょう。