坂上 義之
日本アイ・ビー・エム
IBMコンサルティング事業本部
ハイブリッド・クラウド・サービス
Executive IT Specialist
前編は、スクラム開発における品質の見える化と品質評価方法について紹介しました。後編は欠陥分析、および、リファクタリングと循環的複雑度について紹介します。
欠陥分析
発見された欠陥を種類別に分類することにより、開発しているプログラムの品質状況と開発プロセスの改善ポイントが見えてきます。プログラム内のアルゴリズムやチェック処理、初期化処理に関する欠陥が多い場合には、内部設計やプログラム開発/コードレビューの方法に問題があるのかもしれません。また、API仕様に代表されるインターフェース仕様、機能仕様、タイミング・順序に関する欠陥が多い場合は、外部設計の方法に問題がある可能性があります。ウォーターフォール開発では、全体テスト計画で、単体テスト（UT）、システム内統合テスト（ITa）、システム間統合テスト（ITb）、システム・テスト（ST）などの各フェーズで除去する欠陥種類を定義します。そして、前フェーズまでに除去しなければならない欠陥種類が多く検出されると、前フェーズまでの品質確保が十分に実施できていないと評価することができます。例えば、システム内統合テスト（ITa）で、アルゴリズム、チェック処理、初期化処理に関する欠陥が多く出ていた場合には、それまでのフェーズ（内部設計、開発、単体テスト）内で品質が十分に確保できていなかったと判断でき、レビューや単体テスト方法の見直しや再実施などの品質改善アクション実施につなげることができます。
同様の考えをスクラム開発でも適用することができますが、通常、イテレーション期間は短いので、スプリント・レトロスペクティブで発生欠陥を分類/分析して議論しましょう。また、前回説明した品質計画で立てた品質目標値（欠陥目標数）と、スプリント開発での欠陥発生数を比較して、品質改善アクションの要否を判断するようにしましょう。
欠陥を誤りと漏れという観点で分類するのもよいでしょう。仕様/機能に対して誤ってプログラムを開発した場合は、仕様/機能にもとづいて作成したテスト・ケースによりテストを実施して欠陥を検出できるのに対し、仕様/機能の実装漏れやテスト・ケースの定義漏れについては、テストを実施することができないため、欠陥を検出することは困難といえます。RTVM（Requirement Traceability Verification Matrix:要求追跡検証マトリックス）を作成して、要件からテスト・ケースまでを紐づけすることにより、テスト・ケースの網羅性を見える化することも開発プロセス改善の一つの策でしょう。
その他、イテレーション単位、チーム単位、コンポーネント単位に欠陥を分類すると、品質改善傾向や品質状況の違いが見えてくるかもしれません。プロジェクトの特性やリスクに沿った観点で評価することにより、効果的な改善アクションにつなげることができるでしょう。
リファクタリングと循環的複雑度
リファクタリングとは、プログラムの外部インターフェースや振る舞い（外部品質）を変えずに、プログラムの内部構造をブラッシュアップする作業であり、プログラムの理解や修正を簡単にする保守性（内部品質）向上を目的としています。アジャイル開発 （スクラム開発）では、イテレーション内で繰り返し、頻繁にプログラムを追加/修正するので、リファクタリングを実施しないと、保守困難なプログラムになってしまいます。そして、修正した機能と無関係な、今まで正しく動いていた機能が急に動かなくなる欠陥（デグレード）が発生しやすくなります。
リファクタリングは、機能追加/変更時、コードレビュー時、バグ修正時など、日常的に高い頻度で実施することが望ましいですが、日々の仕事に手いっぱいでリファクタリングまで手が回らないこともあるかもしれません。また、リファクタリングを高い頻度で実施していても、後から見返してみると「こう直しておけばよかった」と思うこともあるでしょう。
リファクタリング方法には様々な方法があり、その内容については他の文献を参考にしていただくとして、ここではリファクタリング時に併せて実施したい品質見える化の一方法について紹介します。
プログラムの保守容易性を計測する方法として循環的複雑度（Cyclomatic complexity）があります。循環的複雑度は、プログラムの分岐点（if, else, case, for, while文）など分岐経路の数によって算出されます。分岐の数が多くネストが深くなるほど、循環的複雑度の値が大きくなり、プログラムが理解しにくい構造であることを示します。循環的複雑度の算出方法と評価基準（参考値）は以下となります。
循環的複雑度を計測する様々なツールが出ているので、品質の見える化策として循環的複雑度を計測して、保守容易性が高いプログラムになっていることを確認しながら、リファクタリングを進めるのがよいでしょう。
また、過去に開発したプログラムで循環的複雑度の値が高いプログラムがあり、修正リスクやワークロードのため、リファクタリングに手がつけられなかったプログラムを修正する場合には、有識者レビューを実施してレビューを強化したり、複雑なソースコード構造/関係を視覚的に可視化できるツールを利用して影響範囲を見極めたりするなど、デグレードが発生しないような対策を講じるのがよいでしょう。
プロダクト・リリース
プロダクト・リリースとして、スプリント開発をして出来あがったプロダクトを本番システムにリリースする前に、今まで説明した「品質の見える化」により可視化した全スプリント実施結果をリリース判定資料としてまとめて、プロダクト・オーナー、スクラム・マスター、開発者が集まり、リリース判定会議を実施しましょう。リリース判定会議では、品質リスクや今まで実施した改善アクション項目を評価するとともに、スプリントで実施できなかった改善アクション項目を全員で共有/議論して、今後の開発に向けた具体的なアクションとしてまとめましょう。また、今回開発したプログラムの循環的複雑度の最終結果としてまとめて、保守容易なプログラムとなっていることを最終確認しましょう。
開発プロセス改善の効果により、プロダクト品質が向上してきたら、その次の開発では品質目標値を高く設定するのもよいでしょう。
おわりに
今回は2回に分けて、スクラム開発を例にしたアジャイル開発における品質の見える化事例を紹介しました。品質の見える化により、品質状況や開発方法の課題が可視化され、開発プロセス改善に役立てることができます。テストで見つかった欠陥は開発プロセスを改善するための重要な情報です。スプリント・レトロスペクティブでは、欠陥発生数を品質目標値と比較して、欠陥の発生原因の分析・評価を行い、開発プロセス改善アクションとして取り入れるべき項目はないか、チーム全員で議論しましょう。
これらの活動を日々実践することにより、開発プロセス改善活動の風土・文化の定着化と開発者の品質意識向上を促し、更なるプロダクト品質の向上が期待できるでしょう。
