坂上 義之
日本アイ・ビー・エム
IBMコンサルティング事業本部
ハイブリッド・クラウド・サービス
Executive IT Specialist
高度/複雑化するサイバー・セキュリティー対策、CO2削減などのサステナビリティーへの取り組み、国際情勢リスクを考慮したオフショア開発先の見直し、IT人材不足への対策/要員スキル強化など、多くの企業は難しいシステム対応課題に直面しています。
特に「DXを活用したビジネス価値創出と業務生産性/効率化向上」と「ITシステムの安定化」は、社会から信頼され、成長を持続する企業になる上で避けられないシステム対応課題と言えるでしょう。しかし、DXを活用したシステム開発とシステム安定化をどのように両立したらよいでしょうか？
従来のシステム開発では手作業で実施していた業務プロセスをシステム化するケースが多く、ゴールが明確であったため、ウォーターフォール開発が適していました。それに対し、DX時代のシステム開発は、開発前にゴールを明確にすることが困難であるため、多くのプロジェクトでアジャイル・ソフトウェア開発（以降、アジャイル開発）を採用しています。
アジャイル開発は、優先度の高い要件から開発に着手し、短期間で動くソフトウェアを早期段階で確認することにより、要件を洗練することができます。また、プロジェクトに変更はつきものという前提で開発するため仕様変更に強く、プロダクトの価値を最大化することに重点を置いています。開発終盤になるまで稼働確認することができず、開発途中に要件を変更することが難しいウォーターフォール開発と比較し、アジャイル開発はビジネスの変化を取り込みながら開発できるため、利用者から高い満足度を得ることができます。
アジャイル開発には「エクストリーム・プログラミング（XP）」など様々な開発手法がありますが、現在、最も普及しているアジャイル開発は「スクラム開発」でしょう。ここではスクラム開発を例にして、システム安定化を実現する上で重要となるソフトウェア品質向上の取り組み事例を紹介します。
スクラム開発におけるソフトウェア品質の検証
現在のスクラム開発におけるソフトウェア品質を確保する代表的な方法は、要件（スプリント・バックログ）を元に機能仕様を作成し、機能仕様を確認するテスト・ケースを作成して、機能テストとして実施/検証する方法でしょう。更に、パフォーマンス・テスト、ストレス・テスト、ロングラン・テストなどの非機能テストを実施し、全てのテスト・ケースがパスすることを、プロダクト・リリースの条件とすることが多いようです。
ただし、全てのテスト・ケースをパスしても、品質は本当に大丈夫なのでしょうか？テスト・ケースの漏れは本当にないでしょうか？
スクラム開発に限らず、どの開発手法を採用しても、テスト・ケースの漏れをなくしてすべての欠陥を除去することは難しいのですが、過去のプロジェクトと品質レベルを比較して品質状況を把握していれば、すこし安心して本番リリースに臨めるかもしれません。
品質見える化のススメ
開発中のソフトウェア品質を可視化（見える化）することにより、品質レベルとリスクを把握することができます。
不具合曲線
従来の品質見える化の方法として不具合曲線があります。不具合（=欠陥）の発生が少なくなってくると、曲線の傾きが小さく緩やかになってくることから、品質が安定してきたことが視覚的にわかります。曲線の傾きが小さくなることを「サチる」と呼ぶことがあります。（Saturation［＝飽和］が語源のようです）
不具合曲線は視覚的にわかりやすく簡単に作れるため、多くのプロジェクトで採用されていますが、以下の注意が必要です。
- 横軸は日付でなく、テスト・ケース数をとるのがよいでしょう。横軸に日付を採用した場合、テストを実施しない日が続くと、欠陥が発見されないため、曲線の傾きが小さくなり、不具合発生がサチったように見えてしまいます。そのため、横軸には日付よりもテスト・ケース数にすることをお勧めします。
- 機能テストでの使用はお勧めしません。新たな機能のテストを実施すると、新たな欠陥が発見されるので、曲線の傾きはサチりません。不具合曲線は全ての機能テストが完了してから作成する方がよいでしょう。サブシステム間統合テスト（ITb）、システム・テスト（ST）、ユーザー受入テスト（UAT）がある長期のウォーターフォール開発のようなケースでは利用しやすいかもしれませんが、短期のイテレーション開発を繰り返すスクラム開発では不具合曲線の適用は困難でしょう。
品質目標の設定
それではどのように品質を見える化したらよいでしょうか？一つの方法としては，過去の類似プロジェクトを参考に、欠陥発見目標数を品質目標値とし、実際に発生した欠陥数と比較する方法です。過去の類似プロジェクトが10,000LOC（Line of Code：コメント行や空白行などを除いたソースコード行）の開発量で欠陥数が100件であれば、1,000LOC当たりの欠陥数は10件/KLOCとなります。（KLOCは1,000LOC）そして、今回のイテレーションの開発量が8KLOCの場合は80件の欠陥を発見することが品質目標値となります。
テスト・フェーズだけではなく、設計フェーズで品質を見える化するのもよいでしょう。一般的に欠陥はできるだけ上流で除去するのがプロジェクト・リスクやコストの面でよいとされています。設計フェーズではドキュメント・レビュー時の欠陥発見数を品質目標値として設定しましょう。品質目標値の例としては1ページあたりのレビュー指摘欠陥数などがよいでしょう。ただし、ソフトウェアの振る舞いとして欠陥にならないような（ソフトウェア品質とは直接関係ない）単純な日本語の記述誤りは含めない方がよいでしょう。（もしくは別管理にして計上する。）
開発ボリュームはイテレーション単位で違いますので、欠陥数と比例関係にある項目（設計におけるページ数や、テストにおけるLOC数）を品質目標に設定するとよいでしょう。チーム内で議論して、入手しやすく、欠陥数と比例関係にある項目を品質目標として設定します。
このように、品質目標値を設定して、開発実績値と比較することにより、品質状況が見えてきます。
品質評価
イテレーション開発が終わり、欠陥数が出ました。品質目標値80件と比較して、どのように評価したらよいでしょうか？
- 欠陥数が品質目標より多くなった場合
- 欠陥数が品質目標より少なくなった場合
欠陥数が品質目標より多くなった場合（例えば、品質目標値80件に対して120件発生）には、なぜ多くなったかチーム内で議論しましょう。多くなったのには理由があるはずで、要員のスキルや開発プロセスに問題があり、追加テストや再レビューが必要かもしれません。品質目標より悪くなったとがっかりするのではなく、改善項目の宝の山を掘り当てるのだと前向きにスプリント・レトロスペクティブで議論し、次のイテレーション開発に品質改善策として取り入れるようにしましょう。
欠陥数が品質目標より少なくなった場合（例えば、品質目標値80件に対して50件発生）には、品質が良くなったと喜ぶ前に、なぜ少なくなったのか評価しましょう。もしかしたらテスト・ケースの設定漏れで網羅性が十分でなかったため、欠陥が検出できていないのかもしれません。テスト・ケース網羅性検証の追加アクションの要否をチームで検討しましょう。
このような品質見える化の方法は従来から用いられてきたものではありますが、スクラム開発でも効果を発揮できるでしょう。
次回は後編として、その他の品質見える化手法を紹介します。
