【連載特集】エンタープライズアジャイルにおける品質担保をどう実現するか ― 第3回 ツールで品質管理を始める

前回は、アジャイル開発のテストの分類について、説明させていただきました。今回は、品質を支えるツールについての説明をいたします。
アジャイル開発では、ツールよりもコミュニケーションが重要視されます。それは、ツールによって、アクティビティの自由が制限されるのを嫌うからです。従来型では、ツールや規定によって、アクティビティを縛って、それによって、一定の品質を担保してきました。アジャイルでは、ツールではなく、プラクティスで縛りをかけています。
アジャイル開発でツールがプロジェクトに最も貢献するのは、生産性です。アジャイル開発では、テストを何度も繰り返し行います。ただ、そのときに、手動で行っていては時間がかかって仕方がありません。こういうときに、ツールを使って自動化しておけば、繰り返し作業が省けます。このように、生産性を上げるためには、必要不可欠です。
テストや品質関連のツールは、数多くありますが、ここでは多くの開発で利用されているSonarQubeを採り上げます。

第1回 アーキテクチャーの変化
第2回 品質を支えるアジャイルテストとは
第4回 エンタープライズシステムに必要な品質管理

特約執筆者:長瀬 嘉秀

1.ツールによる支援項目

それでは、SonarQubeを例にとって、品質に関する支援機能を見ていきます。

ダッシュボード

 はじめに、全体を見渡せるのがダッシュボードです。プロジェクト管理ツールなどにも備えられていますが、ほとんどのツールにダッシュボードと呼ばれる機能があります。

 具体的に、ダッシュボードの画面を見ていきます。図3.1では、プロジェクトのサマリーが表示されています。

【図1. ダッシュボード】

プロジェクトの名前は、HAPI FHIR Examplesというサンプルアプリケーションです。このアプリケーションの各数値が表示されています。問題がない項目については緑、問題がある項目は赤の文字になっています。この中で、一つ項目見てみます。duplicationsというのはコードの重複という意味で、それが23.9%となっています。この意味は、23.9%のコードに重複があるということです。アジャイル開発では、コードの変更が容易にできる必要があるため、コードの重複は極力少なくします。共通化したり、抽象化したり、様々な設計技法で効率化を図ります。23.9%もの重複があるというのは、許されません。そのため、赤くなっています。もちろん、基準値は設定によって決められます。プロジェクトや品質の管理という側面では、ダッシュボードは不可欠です。また、その管理情報をプロジェクトメンバー全員が見れて把握できるようにすることも重要です。管理者が指摘するのではなく、メンバー各自が考えられるようにします。

Issue

 次に、Issueという機能を見ていきます。これは、問題のあるコードを指摘するものです。問題のレベルをBlocker(修正不可欠)、Critical(問題)、MajorMinorなどに切り分けています。

 たとえば、図で示されている、Criticalのひとつをみてみましょう。「Change this “try” to a try-with-resource.」は、try文をtry with resourceに変更しなさい、という意味です。Java7より、入出力などのリソースを扱うときに、例外で問題が起こらないように、try with resourceが導入されました。より、安全で品質の良いコードにするようにように、アシストしてくれます。

 また、管理面でも、良くないコードが混入することを防ぐことができます。今日のソフトウェアにおいて、コードの品質を上げることがとても重要だからです。プログラムは動けばよい、ということではなく、変更や機能拡張がやりやすいように、常に良いコード、すなわち、わかりやすく拡張可能性のある状態に保つことが大切です。

【図2. Issue】

カバレッジ

図3.1のダッシュボードのサマリーに、Coverageという項目があります。カバレッジは、テストコードが通ったロジックのコードの割合になります。すべてのコードがテストされるべきなので、100%にすることが必要です。ただし、画面系のテストはテストコードを用意しない可能性もあるので、現実的には100%にならないかもしれません。図にあるサンプルアプリケーションでは、カバレッジが59.5%なので、かなり低い状態です。この割合では、品質確認が十分とは言えません。

 通常、TDD(テスト駆動開発)では、ユニットテストを書いていきますが、このテストは品質のための網羅性テストではありません。そのため、TDDだけで、100%にすることはできません。なぜなら、TDDは、設計のためのテストを作っていくからです。

 品質という観点だと、カバレッジは100%に近づけるべきです。そのために、TDDでユニットテストが出来上がった後に、網羅性のテストを追加していくのです。そうすることによって、コードの品質が従来型の開発と同様になります。もちろん、リリースまでには、結合テストと総合テストなど、いくつかのテストを行います。これらのテストも自動化しておけば、繰り返し使えて、テストも迅速に行えます。

複雑度

 Issueで指摘されている箇所で、複雑度に関するコードがあります。

【図3. 複雑なコード】

Issueとしては、「Refactor this method to reduce its Cognitive Complexity….」という指示になっています。内容は、複雑度を下げるために、このメソッドをリファクタリングしてください、になります。コードを良く見てみると、if文の入れ子が多くて、一見して、処理の内容を把握できません。要するに、複雑なコードになっています。

 従来型では、設計書に条件分の細かい記述があり、それをプログラムコードにしていくだけでした。設計書に書かれているので、どんな複雑なコードを書いても、設計書を読めば理解できます。ところがアジャイル開発では、詳細設計書を作成することはあまりしません。それは、コードを読めば、設計がわかるからです。設計書とコードの二重管理にすると、変更の手間がかかり、保守できなくなる可能性があるからです。それよりも、わかりやすいコードを書いて、詳細設計書をなくす方が良いと考えています。そのため、可読性の高いコードを書くようにします。また、可読性が低いコードは、リファクタリングによって、改善されます。

【図4. リファクタリング(前)】

 

 リファクタリング前のコードは、図3.4になります。これをリファクタリングして、図3.5のように、スッキリとしたコードになりました。

【図5. リファクタリング(後)】

同じようなifの条件式は、別メソッドに押し込めて、さらにどのような処理をしているかをメソッドの名前につけます。これにより、意味のよく汲み取れないifの条件式は、わかりやすい処理の名前をつけることになります。アジャイル開発は、このように、可読性などへの対応など、ソフトウェア工学をベースに、成り立っており、理論に裏打ちされた方法と言えます。

リファクタリング

 SonarCubeの機能で、コードの問題点を洗い出して、それに対応していくと、コードが自然にきれいになっていきます。もちろん、そこには、問題のあるコードをリファクタリングするからです。もちろん、Code Smellsの指摘を対応して、リファクタリングすることも必要です。Issueの対応をしていくと、図3.6のように、ダッシュボードの数値は改善されていきます。

【図6. ダッシュボード(後)】

 さらに、多くのIssueへ対応していくと、数値はもっと良くなっていくでしょう。このように、ツールを利用して、コードをきれいに、さらにテストを充実していくこともできます。

2.その他

 SonarQubeを例にとって、品質に関するコードの改善を見てきました。コードに関する指標はメトリクスと呼ばれています。メトリクスは、数多くありますが、その中からプロジェクトで必要なものを始めに決めておくのが良いです。品質に対応した改善はコストを伴います。常にコストとのトレードオフです。よって、どこまでおこなうかが重要です。今回取り上げなかったメトリクスに、凝集性や結合度というものがあります。コードの複雑度に関するものです。このようなメトリクスを測り、問題が大きいようであればリファクタリングで改善することになります。

 従来型の開発では、大人数などの原因で、一回限りの開発で保守性は犠牲になりがちでした。ところが、アジャイル開発では、繰り返し型の開発なため、保守性を重視します。よって、コードの品質は、特に重要です。長年プログラマーをやっていると、忘れてしまっている良いコードを書く、ということをアジャイル開発では意識しています。それは、アジャイル開発のリファクタリング、ペアプログラミングなどの多くのプラクティスが縛りになっているためです。ソフトウェア開発のContinous IntegrationContinious Deliveryなどのビルドの後のパイプラインに、メトリクスのチェックを入れると、問題のあるコードをデプロイ、リリースすることはなくなります。このように、最新のソフトウェア工学を使って、変化に対応していくのがアジャイル開発の真髄です。そのために、ツールは欠かせません。

3.次回へ

 次回は、まとめとして、エンタープライズアジャイル開発では、ゲームやネットサービスとは違った品質確保の視点があることを中心に話をしていきます。それは、エンタープライズシステムの開発では、すでに、多くの基準ができてしまっているので、品質確保の視点を蔑ろにすることはできません。

全編をまとめてお読みたい方、下記より全文をダウンロードできます。

全文ダウンロード

おすすめ記事