次の方法で共有

  • [アーティクル]

November 2015

Volume 30 Number 12

Microsoft Azure - SonarQube と TFS による技術的負債の管理

Cesar Solis Solis | 年 11 月 2015

「技術的負債」とは、開発作業中に発生し、作業進行の効率を下げる一連の問題のことです。技術的負債が存在すると、コードが難解かつ脆弱になり、変更に時間がかかり、検証が難しくなるため、生産性が低下します。加えて、進行を妨げる予定外の作業が発生します。また、顧客サポート コストの増大を招き、最終的には、このような問題が相乗効果となってさらに大きな問題につながります。その結果、企業の力が奪われていきます。

技術的負債は気付かないうちに生まれます。最初は小さかった負債も、急ぎで行った変更、状況認識の不足、統制の欠如などによって、徐々に大きくなっていきます。負債は、「クリーン」と称されるプロジェクトであっても、状況の変化が原因になり、どこからともなく生まれます。たとえば、米国市場向けに作られたプロトタイプ コードを国際市場に導入するとします。すると、すぐにローカライズに伴う負債が生まれます。テクノロジが進化すると、その進化に対応できず、負債が発生する可能性があります。

負債の形はさまざまです。コード分析で見つかる問題もあれば、コードが重複している、コードが複雑、テストが不十分、テストが重複している、テストが不透明、複雑怪奇な構造などによって生じる問題もあります。

開発チームが技術的負債を管理するうえで直面する主な問題点は次のとおりです。

  • 負債の内容とコード内の負債の場所の把握と特定。
  • 負債を解決するコストと放置した場合のコストの評価。技術的負債の解決にはコストがかかります。放置しておいてもコストがかかります。放置する方が評価が複雑で、額が大きくなることがあります。
  • 負債の増加防止と管理に注目するポリシーの設定。
  • 開発者の意識付けとポリシーの遵守。負債が手に負えないと感じることがないようにして、開発者が毎日の開発プロセスの一環として自然に取り組めるようにします。また、その取り組みが、非常に時間がかかり面倒な辛い仕事だと感じられないようにします。
  • 継続的な負債の追跡、方向性の確認、定義したポリシーへの遵守の評価。
  • できる限り効率的かつ自動的な負債の解決。

技術的負債は、管理し、評価しなければなりません (取り除くことが必須ではありません)。負債を管理したら、他の新しい機能や目的の機能の中で優先順位を付けます。住宅ローンを組む際に経済的影響を評価するように、技術的負債の影響も評価します。

開発者は、開発中の判断が技術的負債を増やすかもしれないことを意識しなければなりません。実際に技術的負債に管理することで、実現される改善を評価できるようになります。製品所有者 (クライアント、ユーザー、マネージャーなど) の投資を正当化するには、こうした評価が重要になります。

SonarSource の SonarQube などのソリューションを Visual Studio Team Foundation Server (TFS) と連携することで、データ収集を容易にし、技術的負債を管理、削減しやすいかたちでデータを提示する方針を用意できます。SonarQube は、技術的負債を把握して管理するためのオープン ソース プラットフォームです。

今回は、技術的負債を評価し、積極的に管理する方法に注目します。SQALE (Software Quality Assessment based on Lifecycle Expectations) は、ソフトウェア コード ベースの機能以外の部分の品質属性に着目したオープン ソースの品質評価手法です (bit.ly/1JQ96qT、英語)。SQALE 法は、フランスの Inspearit (旧: DNV ITGS France) によって開発されました。

SonarSource のブログによると、技術的負債は、家庭での水漏れのようなものだそうです (bit.ly/1N0Y4A9、英語)。自宅で水漏れを見つけたら、まずどうするでしょう。漏れ口をふさぐのが先か、床を拭くのが先かどちらでしょう。答えは簡単、先に漏れ口をふさぎます。その理由は、先に床を拭いても、漏れが続けば、また水浸しになるからです。

技術的負債の「漏れをふさぐ」場合は、「新しい」コードに注目します。前回のリリース (前回のコミット/チェックイン) 以降に追加または変更されたコードに注目します。

SonarQube と TFS の実装

図 1 は、TFS と SonarQube のエンタープライズ セットアップの参照アーキテクチャです。Visual Studio ALM Rangers CodePlex サイト (aka.ms/treasure5、英語) からダウンロードできる『TFS Planning Guide』(TFS 計画ガイド) と『TFS on Azure IaaS Guide』(Azure IaaS における TFS のガイド) には、オンプレミスおよび Microsoft Azure IaaS (サービスとしてのインフラストラクチャ) での TFS の処理能力、設計、実装、および運用に関する詳しいガイダンスが記載されています。このアーキテクチャとその実装は、データ層ではデータベース クラスターによる高可用性機能、アプリケーション層ではファームによる高可用性機能を検討することで、エンタープライズ レベルのサポートを目指しています。

Team Foundation Server の参照アーキテクチャ (SonarQube を含む)
図 1 Team Foundation Server の参照アーキテクチャ (SonarQube を含む)

スケーラブルな SonarQube サーバー配置を行うには、個々のチームに基づいて複数の SonarQube サーバーをセットアップします。つまり、次のことを考慮したテクノロジを使用します。

SonarQube データベースは、データベース クラスターのインスタンス内にインストールし、可用性の高いサービスを処理する安全な方法を提供します。

SonarQube アナライザー (プラグイン) は、分析の負荷をサーバーごとに処理して、分析データを SonarQube データベースに格納するスケーラブルな方法を実装します。

データベースとアナライザーは同じネットワーク内に配置する必要があります。SonarSource は、SonarQube (バージョン 5.2) が 3 層アーキテクチャを持つよう、リファクタリングに取り組んでいます。このアーキテクチャにより、配置に関する制約がなくなります。

すべてのシステム (データベース、Web サーバー、アナライザー) は、時刻同期している必要があります。

Azure で SonarQube と TFS をホストする前提条件

Azure に TFS と SonarQube 環境をセットアップするには、作成する環境のサイズに十分なクレジットが含まれる Azure サブスクリプションを使用する必要があります。『TFS Planning Guide』(bit.ly/1JzfVJK、英語) を参考にして、仮想マシン (VM) のサイズを判断できます。このガイドには、スタンドアロン モデル、拡張されたドメイン モデル、一方向の信頼モデルの各オプションなど、認証モデルに関する推奨事項も記載されています。環境作成を迅速に進めるのに役立つ Azure の優れた機能は、既成の TFS VM テンプレートが用意されている点です (図 2 参照)。

Microsoft Azure で利用できる仮想マシン テンプレート
図 2 Microsoft Azure で利用できる仮想マシン テンプレート

ネットワーク構成は、TFS アーキテクチャの内部層への外部アクセスを保護するニーズに応じて選択します。VPN を利用して Azure をオンプレミスに接続する各種方法については、企業のインフラストラクチャを拡張し、クラウドの弾力性を得る方法として精査します。ガイドでは、Azure での TFS 環境セットアップに役立つベスト プラクティスやパフォーマンスのヒントが説明されています。SonarQube を使用するには、データベースとアナライザーが同じネットワーク内に配置されている必要があります。

導入を計画する際は、次の推奨手順に従います。

  • Azure IaaS の適合性の判断。クラウド コンピューティングを利用すると、計算能力、ネットワーク、ストレージなどのリソースにアクセスして、コンピューティング機能をサービスとして利用できます。制約が許容可能かどうか、付加価値があるかどうかを判断します。
  • TFS の計画。「TFS Planning and Disaster Avoidance and Recovery Guide」(TFS 計画、障害回避と復旧ガイド) (bit.ly/1JzfVJK、英語) を参考にして、要件に最適なサーバー アーキテクチャを判断します。
  • Azure IaaS のマッピング。コストとスケーラビリティに基づいて、最も近い Azure VM 構成にマップします。
  • Azure プラットフォームのガバナンス。企業の監査要件を満たすように、アカウント、サブスクリプション、および管理とレポートの所有権を定義します。所有権と責任を明確に定義します。
  • ネットワークの計画。ネットワーク (オンプレミス要件を含む)、ネットワーク アドレス セグメント、アフィニティ グループ、名前解決、Azure のトンネリングと監視などを定義します。
  • ストレージの計画。オンプレミス ストレージや Azure ストレージを使用するストレージ戦略を策定します。
  • 検証。マイクロソフトや Azure コミュニティ (azure.microsoft.com/ja-jp/support/forums/) の Azure の専門家に連絡を取り、計画を検証してから実行するようにします。計画する環境は、技術的、財務的に実現可能で、メンテナンス可能なものにします。

今回は、デモと評価用に SonarQube サーバーをセットアップすることが目的なので、これ以上の手順はここでは説明しません。運用環境の計画やプロビジョニング、または既存の環境からの移行を計画している場合は、ガイドでその他の手順を参照して計画を完成させてください。ガイドには、スムーズに導入するための配置チェックリストも用意されています。

Azure IaaS 参照アーキテクチャと、ここで実行した導入方法は、『TFS on Azure IaaS Guide』に付属している概念実証 (POC) に基づいており、サンプル実装に使用できます。このガイドで説明しているのは、TFS POC 環境をセットアップするための詳細手順です。しかし、独自の POC 環境を使用する場合や、運用環境を使用する場合に同じ手順に従うことに制約はありません。

SonarQube のインストール要件

SonarQube のインストールには、同じ IaaS SQL Server インスタンスを使用することをお勧めします。ただし、SonarQube データベースを作成する際の SQL Server 構成要件だけは気を付けてください。『SonarQube Installation Guide for Existing Team Foundation Server 2013 Single Server Environment』(既存の Team Foundation Server 2013 単一サーバー環境における SonarQube インストール ガイド) (bit.ly/1itxhS9、英語) には、Azure のリージョン (SonarQube サーバー VM が TFS と同じ地域に配置されるようにする) と SQL Server のセットアップ方法に関する詳細情報と参考資料が豊富に記載されています。SonarQube を使用するには、SQL Server 構成とデータベース作成で、特定の要件を満たす必要があります。たとえば、SQL Database は大文字と小文字を区別し、アクセントを区別しますが、これは既定の設定ではありません。また、SonarQube が機能するには、SQL 認証を有効にして、SQL ユーザーを構成する必要があります。Azure でホストする際は、特定の手順に従って SQL Server のネットワーク プロトコルを変更して、VM 外部からデータベースにアクセスできるようにする必要があります。まず、SQL Server 構成マネージャーを使用して、SQL Express データベースの名前付きパイプと TCP/IP プロトコルを有効にします (図 3 参照)。

SQL Express の名前付きパイプと TCP/IP プロトコルの有効化
図 3 SQL Express の名前付きパイプと TCP/IP プロトコルの有効化

引き続き、SQL Server 構成マネージャーで TCP/IP のプロパティを編集し、[IP アドレス] タブで [TCP 動的ポート] を探してポート (ここでは 49419) をメモします (図 4 参照)。この値は、外部からデータベースに接続できるようにするために使用します。

TCP 動的ポートの番号をメモして外部からデータベースに接続できるようにする
図 4 TCP 動的ポートの番号をメモして外部からデータベースに接続できるようにする

図 5 に示すように、[SQL Server のサービス] を選択し、一覧に表示される SQL Server Express を右クリックして [再起動] をクリックし、SQL Server を再起動します。SQL Server Browser を開始します ([サービス] タブで開始モードを [自動] に変更してから開始します)。

SQL Server Browser の開始
図 5 SQL Server Browser の開始

次に、ファイアウォールでポートを開いて、データベースに TFS コンピューターからアクセスできるようにします。cmd.exe を管理者として実行し、プロンプトに次のコマンドを入力します。

netsh advfirewall firewall add rule name="SQL" dir=in action=allow
  protocol=TCP localport=49419 49590

SonarQube では、JVM の完全なインストールは必要なく、Java SE Runtime Environment (JRE) で十分です。このセットアップ方法には固有の推奨事項があり、たとえば x64 プロセッサ アーキテクチャの利用が推奨されています。

『SonarQube Installation Guide for Existing Team Foundation Server 2013 Single Server Environment』の SonarQube サーバーのセットアップに関するセクションには、SonarQube を構成および開始する際の、ダウンロード、インストールおよび構成手順が、Windows ファイアウォール設定を含めて記載されています。

Azure でホストする場合は、外部からアクセスできるように、SonarQube サーバーへのアクセスを有効にする必要があります。そのためには、まず匿名アクセスを無効にします。ユーザー認証を強制するには、システム管理者としてログインし、[Settings] (設定)、[General Settings] (全般設定)、[Security] (セキュリティ) の順に移動して、[Force user authentication] (ユーザー認証を強制する) プロパティを [true] に設定します。

ファイアウォールで、Web サーバー用のポートを開きます。ここで、ファイアウォールでポートを開いて、インターネットから Web サーバーにアクセスできるようにする必要があります。cmd.exe を管理者として実行し、次のコマンドを入力します。

netsh advfirewall firewall add rule name="Sonar Web" dir=in action=allow
  protocol=TCP localport=9000

Azure で Sonar Web とデータベース用にエンドポイントを追加します。差し当たりは、リモート デスクトップで SonarQube コンピューターにログインして、データベースと Web サイトにアクセスできます。これらの 2 つのリソースにコンピューターからインターネット経由で接続できるようにする必要があります。そのために、Azure でエンドポイントを作成する必要があります。

  • portal.azure.com にアクセスします。
  • SonarQube のセットアップ先の仮想マシンを見つけます。
  • この VM を表すブレードで、[すべての設定] をクリックします。
  • この設定で、[エンドポイント] をクリックします。
  • [エンドポイント] ブレードで、[追加] をクリックします。
  • Sonar Web という名前のエンドポイントを追加し、TCP パブリック ポート 9000 をプライベート ポート 9000 にマップします。
  • SQL という名前のエンドポイントを追加し、TCP パブリック ポート 1433 をプライベート ポート 49419 にマップします (ポート 1433 は SQL Server Management Studio または Visual Studio で SQLEXPRESS を検出するために必要です)。この手順は、SonarQube 5.2 リリース後には不要になることに注意してください。

SonarQube では、さまざまな言語の分析ができます。それにはまず、分析するプロジェクトの言語に対応したプラグインを SonarQube プラグイン ライブラリ (bit.ly/1NdhnYF、英語) または SonarQube Update Center (bit.ly/1NPKZet、英語) からインストールします。次に、プロジェクトの種類に応じていくつかの前提条件をビルド エージェントにインストールして構成します。.NET ベースのプロジェクトでは MSBuild.SonarQube.Runner (bit.ly/1LOYzM3、英語)、Java Maven プロジェクトでは SonarQube Maven Plugin ランナー、それ以外のすべてのプロジェクトの種類では SonarQube Runner (汎用ランナー) を使用します。

チーム ビルドと統合して、変更したビルド定義をテストします (図 6 参照)。SonarQube Runner ツールはビルド エージェントとうまく統合するため、TFS で作業してきた開発チームは簡単に受け入れることができます。

ビルド エージェントを使用した SonarQube の分析
図 6 ビルド エージェントを使用した SonarQube の分析

技術的負債の管理方針

これで、SonarQube 環境のセットアップが完了しました。ここからは、アジャイルな好循環の中で技術的負債の評価を活用して、製品所有者とビジネスにとっての価値を向上する方針について説明します。SQALE 法の説明で触れたように、今回の目的は、技術的負債の原因を明確に定義し、この負債を正確に見積もり、技術的/ビジネス的観点から負債を分析し、優先順位付けのさまざまな方針を紹介して、最適な負債解消計画を策定できるようにすることです。

SQALE 法 (図 7 参照) は、機能以外でコードの品質に関連する要件を系統立てて表し、整理するために使用します。要件は、特性、サブ特性、およびコードの内部属性に関連する要件の 3 つの階層レベルに整理されます (通常、これらの要件はソフトウェアのコンテキストと言語によって変わります。これらの要件に違反すると、技術的負債が発生します)。

SQALE 法
図 7 SQALE 法

SQALE 法は、ソース コード分析ツールの結果レポートを、負債を解決するコストと放置する場合のコストに変換して正規化します。また、これらのコストを集計する規則 (SQALE 法のツリー構造に従う、またはソース コードの成果物の階層構造に従う) を定義します。ソフトウェア プロジェクトの技術的負債を管理するには、負債を目に見えるかたちにします。製品所有者とマーケティング担当者に技術的負債の存在を認識させ、「技術的負債を解消する時間をスケジュールに組み込まないと、必要なすべての機能を実装できない可能性がある」ことを頻繁かつ繰り返し説明します。

水漏れの例は、現在の技術的負債を先送りすることを推奨しています。ただし、セキュリティ問題のような非常に重要で早急に解決が必要な問題は例外です。このように、基準値を取得して、新しい負債が発生したら認識できるようにし、新しい負債を発生させない (水漏れを止める) ようにします。また、コードの記述およびリファクタリングをする際には、既存の負債を解決する時間をとるようにします。コードには単体テストを行うので、危険はありません (濡れたらふき取ります)。

技術的負債の管理を予算に含める必要はありません。これは、組織全体の行動が変わることです。

図 8 に示すように、SonarQube では、ソフトウェア プロジェクトの品質の状態についてチームが共通の説明をできるように、SQALE に基づくダッシュボードが表示されます。

プロジェクト有効期間内の SQALE 法に基づく SonarQube ダッシュボード
図 8 プロジェクト有効期間内の SQALE 法に基づく SonarQube ダッシュボード

図 9 に Technical Debt Pyramid ウィジェットを示します。グラフは下から上へ縦方向に読み取ります。まず、テスト可能である必要があります (40 分)。テストできない場合、コードを変更するときに新たな問題が発生しないという保証はありません。次に、信頼できる必要があります。そのためにはさらに 42 分が必要です。つまり、信頼できるようになるまで、1 時間 22 分かかります。このように、グラフを読み取っていきます。

Technical Debt Pyramid ウィジェット
図 9 Technical Debt Pyramid ウィジェット

技術的負債の管理方法

技術的負債を管理するための主な手順を以下に示します。

手順 1: プロジェクトの目標を設定する。技術的負債の原因を定義します。開発チームが見積もった平均解決作業量に基づいて、指標を計算します。いくつかのグラフと図を使用して、評価したソース コードの長所と短所を効率的に視覚化します。次の問いに答えます。

  • リスク発生の最大の原因となっているソフトウェアの部分はどこか。
  • 最も影響を受ける品質基準は何か。
  • 準拠しないと、プロジェクトやユーザーにどのような影響があるか。

この答えが、プロジェクトの目標になります。SonarQube により、コード内の特定の問題を掘り下げることができるため、その理由や影響を理解して、負債を解消するタスクを計画できます。この分析はアジャイル計画中に行い、可能であれば、プロダクト バックログ項目 (PBI) の優先順位に沿って進めることをお勧めします。PBI は、速度などのアーキテクチャ特性のバランスを取ったり、それらを向上したりするために定義および評価されます。特性は、移植性や再利用性など、製品ユーザーにとって重要性の高いものから、潜在的なビジネス価値をもたらすものの順に定義します。

手順 2: 技術的負債の量を継続的に監視する。実行したタスクの結果や、実装されているベスト プラクティスの結果をチェックできるようにします。ここでの問いは、前日/前回のスプリント/前回のバージョンから技術的負債が増えているかどうか、およびプロジェクトに設定した目標との開きがどの程度あるかです。

手順 3: プロセスと影響を分析する。さまざまなプロジェクト、チーム、協力会社の手法を調査して、技術的負債を比較できるようにします。手法を調査することで、各チームの手法を洗練すると同時に、ベスト プラクティスをより効果的に適用できるうえ、技術的負債の結果をより正確に測定できます。

「現在の負債のどの部分が前日/前回のスプリント/前回のバージョン以降に発生したか」、「現在の負債のどの部分がレガシ コードに由来しているか」、および「プロジェクトのどの部分に最も技術的負債が存在するか」という問いに答えることで、技術的負債の発生源を分析します。

チームは、結果を最適化するために、技術的負債の特定の部分に集中します。そのためには、「コード内で最も早急に解決が必要な問題は何か」、「次に解決が必要な問題は何か」、および「解決コストがあまりかからず、ビジネスへの影響の減少幅が大きい、"正しいコード" 違反は何か」という問いに答えます。

最後の問いは、技術的負債を減らすために 100 時間費やした場合に、「速度がどの程度早くなるか」、および「ユーザーが感じるアプリケーション品質はどの程度向上するか」です。

これらの問いに答えることが、自然なフィードバック メカニズムとなり、改善の余地を見つけ、足りない部分を補ってよりよい製品に近づける糸口になります。

SQALE 法では、技術的負債に対処する 3 つの方針をサポートしています。

  1. 技術的なロジックに従う (無駄なやり直しを避ける)。SQALE ピラミッドを使用する。
  2. ビジネスに対して大きな影響を持ちながらもロジックに従っていない部分を解決して、ビジネスへの負債の影響を減らす。
  3. 高い ROI を持ちながらもロジックに従っていない部分を解決して、ROI を最適化する。

まとめ

技術的負債は、管理、認識および評価する必要があります (取り除くことが必須ではありません)。まずは、負債を防止するのが正しい出発点です。負債を管理するには、さまざまな方法があります。たとえば、コードに手を加えてバグを修正したり、新しい機能を追加して、既存の負債を取り除く方法があります。また、セキュリティや準拠の問題に対しては、解決行動を取ることが重要だと判断する場合もあります。おそらく、企業ではこのように、問題に対処する必要があると考えるでしょう。その場合、結果に対する影響を評価して、他の新しい機能や目的の機能の中で、対処作業の優先順位を決定する必要があります。

開発者は、自身の決定が技術的負債を増やす可能性を意識し、負債を実際に管理することで達成される改善を評価します。

SonarQube と TFS の統合コンポーネントを利用すると、Microsoft Build Engine (TFS と Visual Studio Online) のビルドからデータを容易に収集できます。SonarQube は、理解しやすく、解決のための有効な投資方法を計画しやすいかたちで技術的負債を提示します。マイクロソフトと SonarSource では、この統合をさらに強化して、プラットフォームの技術的負債管理の優れたソリューションを提供するための取り組みを継続中です (bit.ly/1OeqftX、英語を参照)。

Cesar Solis Britoは、マイクロソフトに 20 年以上勤める金融および医薬分野のソフトウェア開発専門のコンサルタントです。現在は、マイクロソフトで Azure プラットフォームのエスカレーション エンジニアをしています。ALM とそれに関連するマイクロソフト開発テクノロジに携わっています。連絡先は Cesar.Solis@microsoft.com (英語のみ) です。Twitter は @cesarsolis (英語) でフォローできます。

Hosam Kamelは、マイクロソフトのシニア プレミア フィールド エンジニアであり、10 年以上のソフトウェア開発経験を持つ Visual Studio ALM Ranger でもあります。彼は現在 Visual Studio ALM と Team Foundation Server を専門としています。彼には、ブログ blogs.msdn.com/HKamel (英語) から連絡を取ることができます。Twitter は @HosamKamel (英語) でフォローできます。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Mathew Aniyan、Brian Blackman、Harysh Menon、Duncan Pocklington、および Jean-Marc Prieur に心より感謝いたします。