アジャイル開発における 静的コード解析

アジャイル開発における 静的コード解析 動くソフトウェアを各イテレーションで提供するための 反復可能なプロセスを確立するには ソフトウェアの機能性の向上と製品化までの時間の短縮を望む顧客の需要の高まりを受け、ソフトウェア開発者はコ ードの開発を速度と品質の両面で進化させる必要がありました。 その結果、アジャイル開発がより一般的になりつつあります。しかしながら、アジャイルのメリットを完全に実現するた めには、コードの欠陥やセキュリティ上の脆弱性がないことを保証する反復可能なプロセスが重要です。 このホワイトペーパーでは、静的コード解析がどのようにアジャイル開発プロセスが強化され、アジャイルチームの 権限がどう拡大するかを見ていくことにします。

アジャイル開発における静的コード解析 ソフトウェアの機能性の向上と製品化までの時間の短縮を望む顧客の需要の高まりを受け、ソフトウェア開発者はコ ードの開発方法を速度と品質の両面で進化させる必要がありました。このトレンドの一環として、1990 年代後半に なるとそれまで主流だったウォーターフォール型開発に代わり、より軽量な「アジャイル」というソフトウェア開発方法 が台頭してきました。 そして過去10年間においても、アジャイルの利用は拡大を続け、成熟を遂げつつあります。 ソフトウェア企業はアジ ャイル環境を改善する方法を絶えず模索しており、ソフトウェアのバグを最小限に抑えることが焦点の 1 つとなって います。このホワイトペーパーでは、反復可能なプロセスの実装を通してコードのバグを最小限に抑えない限り、アジ ャイルの基本原理を完全に実現することは不可能であることを論証していきます。このホワイトペーパーで推奨する アプローチは、自動静的ソースコード解析（SCA）技術を利用して、セキュリティ脆弱性、ロジックエラー、実装の不具 合、同時実行違反、まれな境界条件、問題の原因となるその他のコードなど、ソフトウェアソースコードが弱点とする 箇所を特定し、記述するというものです。 まずはアジャイルの概要を説明し、アジリティの実現を妨げているいくつかの障壁について取り上げます。その後 で、SCA 技術の主要機能によってアジャイル開発プロセスがどのように強化され、アジャイルチームの権限がどう拡 大するかを見ていくことにします。 アジャイル開発 — 背景と概要 アジャイルソフトウェア開発とは、簡単に言えば、ソフトウェア開発サイクル全体を通して、絶えまない変化に柔軟に 対応するためのアプローチです。ここで重視されるのは、動くソフトウェアの迅速な提供、開発者の権限の拡大、開発 者とチームの他のメンバー（経営者を含む）とのコラボレーションです。 今なお多くの開発現場で採用されているウォーターフォール開発は、包括的な範囲と要件の定義による先行負担型 のアプローチであり、要件の定義から、設計、コーディング、品質保証にいたる明確な開発フェーズの分割が採用され ています。これとは対照的に、アジャイル開発では開発プロセスのあらゆる段階で継続的に要件が収集されます。リリ ースサイクルの全段階に経営者が関与し、開発中のソフトウェアがエンドユーザとビジネスの両方のニーズを満たし ていることを確認できる仕組みになっています。また外的機会や脅威の発生次第で、要件と機能セット全体に変更が 生じることが見込まれています。 つまり、アジャイルでは変更が発生しうるものであるととらえ、アジャイルチームはビルドプロセスや、他の開発 者、QA、ビジネス上の利害関係者から定期的なフィードバックを受け取り、それらに対応できるよう構成されていま す。 アジャイルは多数の指針に基づいており、すべてのアジャイルチームはそれに従うものとします。この議論を進める にあたり、特に注目すべき 4 つの指針 — あるいは価値 — を以下に挙げます。 • 高品質なソフトウェア開発 • 柔軟な反復 • 継続的な改善 • コラボレーションとコミュニケーション roguewave.com 2

アジャイル開発における静的コード解析 高品質なソフトウェア開発 アジャイル開発の主要目標は、一定の期間内（通常は数週間以内）に顧客のニーズを満たす — つまり使える機能や 能力を提供する — 高品質なソフトウェアの開発を実現することです。この期間はスクラム用語で「イテレーション（ 反復）」や「スプリント（短距離走）」と呼ばれます。理論的には、アジャイル環境で開発される製品は、1 つのイテレー ションが終わった時点で市場に出せる状態になっていなければなりません。 市場に出せる一連の製品を、それぞれわずか数週間で提供するには、アジャイル開発サイクルに厳格な品質プロセ スを組み込む必要があります。イテレーションごとの成果物は、開発が完了した — つまり、テスト済みで、不具合が なく、ドキュメンテーションがすべてそろっている — 状態でなければなりません。 柔軟な反復 アジャイルはスピードと回転の速さに重点を置いており、開発サイクルのあらゆる段階でいや応なく発生する変更に 対応できるようになっています。最初の要件が顧客の需要や市況などさまざまな理由によって変更される可能性が あるということを前提に、柔軟なイテレーションプロセスが設定されています。プロセス全般に経営者が関与してお り、またそれぞれのイテレーション期間が短いことから、新しい要件を極めて迅速に導入し、優先順位付けすること ができます。 継続的な改善 アジャイル環境は、新しいスキルを習得し自主的に業務を遂行する機会を開発者に提供します。テスト実行/品質保 証を定期的もしくは長いプロセスの最後に実行する場合、コーディングの不具合を修正したり、作業中に得た教訓を 組み込むことが難しかったり、コスト効率が悪いことが少なくありません。しかし、イテレーションフレームワークでは テスト実行/品質保証がイテレーションプロセスの中に組み込まれているため、継続的な改善が可能です。またアジ ャイルでは、テスト実行と QA のプロセスがコードを記述する開発者に対して透過的であることから、開発者に学習 の場が提供され、将来の改善やコーディングの効率化が促進されます。 コラボレーションとコミュニケーション 一般的にソフトウェア開発ではコミュニケーションとコラボレーションが重要とされますが、アジャイル開発環境では これらは最優先事項となっています。実際、「アジャイルマニフェスト」（アジャイルの事実上の定義として広く認識さ れています）では、個人と相互作用をキーコンセプトとして重要視しています。最終的に、開発プロセスの効率化を促 進するのは、オープンなコミュニケーションとコラボレーションです。必要なときに適切な個人、データ、フィードバッ クにアクセスできる環境があることで、アジャイルプロセスで求められるとおり、動くソフトウェアを短いイテレーショ ンで提供することが可能になります。 アジャイルの円滑な進行 開発チームがアジャイルマニフェストにある基本原則を取り入れようとする際、バグ負債、開発者によって異なるス キルセット、コードの複雑さといった障害を避けて通ることはできません。真のアジャイル開発プロセスを実現するに は、これらの障壁を認識し、「アジャイルの円滑な進行」を支援する有効な戦略を採用する必要があります。 バグ負債への対応 アジャイルマニフェストで示されている開発原則の 1 つに「動くソフトウェアこそが進捗の最も重要な尺度である」と いうものがあります。動くソフトウェアとはつまり、ビルドを壊したり、想定外の動作の原因となるような、製品の要件を 満たさない問題、ならびに一般的なプログラミングの不具合（バグ）が一切ないソフトウェアのことです。 roguewave.com 3

アジャイル開発における静的コード解析 この原則はアジャイルだけに限定されたものではありません。CMMI や Six Sigma などの公式プロセスを含む多く のソフトウェア開発プロセスでも、バグのないコードの作成を基本原則として奨励しています。これらのプロセスで は、インフェーズのバグの封じ込め、つまりバグが発生したフェーズから下流工程に移動するのを防止することを推 奨しています（図 1 参照）。アジャイル開発においてもインフェーズのバグの封じ込めの重要性が暗に強調されてい ます。アジャイルプロセスでは短いイテレーションを前提としていることから、チーム全体が次のイテレーションに移 行できるように潜在的なソフトウェア品質の低下をすばやく特定し、修正しなければなりません。つまり、機能的に完 全な、動くソフトウェアの作成時に、それらすべての作業を行う必要があるのです。 図１バグ封じ込めのコスト 各イテレーション内においても、アジャイルチームは継続的なインテグレーションとリグレッションを通してこの考え 方を適用します。このやり方はビルドやリグレッションテストスイートを破壊する可能性のある不具合の解消には効 果的ですが、以下の 7 種に大別される、一般的なプログラミングバグのクリーンアップには有効ではありません。 • メモリとリソースの管理 • プログラムデータ管理 • バッファオーバーフロー • 無効なユーザインプット • 脆弱なコーディング手法 • 同時実行違反 • さまざまな長期保守の問題 roguewave.com 4

アジャイル開発における静的コード解析 バグが混入したままのコードは、1 つのイテレーションだけでなく、後続のイテレーションにおいてもバグ負債という 形で、下流工程にリスクを生み出します。コードの欠陥をイテレーション内で解消しないでおくと、その欠陥は 1 つの マイルストーンから次のマイルストーンへと移行し、下流工程でバグ負債が蓄積することになります。バグ負債が生 じると、開発速度が低下し、イテレーションごとの実装の質の低下や、影響力のある変更の減少へと発展することか ら、アジャイルプロジェクトが失敗に終わる可能性があります。また「蓄積された」（つまり、さらに先の下流工程まで発 見されることのない）バグの場合、修正が難しく多額のコストがかかる場合が多く、フィールドで製品に不具合が発生 したり、顧客を失望させることになりかねず、ブランドの低下につながります。 以上のような理由から、アジャイルプロセスにはフェーズ内でのバグ封じ込めが極めて重要になってきます。できる だけ早い段階でバグを駆除するには、バグの特定、除去プロセスを制御すると同時に、開発者間のコラボレーション を強化することが不可欠です。 多様なスキルセットに対応 仲間同士で積極的に話し合い、顧客から頻繁にフィードバックを受け取ることを厭わない、そんな優秀で明晰なソフ トウェアエンジニア達で構成される開発チームはまさに理想的です。しかし残念ながら、現実には必ずしもこのよう なチームを編成できるとは限りません。一般的な開発チームはさまざまな人材の集まりであり、ロックスターのような 人材もいれば経験の浅い開発者もいます。共同作業が得意な人もいれば、目立たずにコツコツ作業するのが好きな 人もいます。経験の浅い開発者がベテランの同僚から学ぶ機会を作り、コミュニケーションとコラボレーションが容 易に行える環境を整えることで、バランスのとれたチームが出来上がり、結果として、動くコードのアウトプットを最大 化できます。 コードの複雑化の抑制 以下の要因により、コードベースは複雑化の一途をたどっています。 • コードベースのサイズ 能力の拡張、およびより高度な機能と性能に対する需要の高まりに伴い、コードベースのサイズが拡大し、 変数と制御パスの増加、および言語構造の多様化につながっています。 • コードの再利用 業界のベストプラクティスとして認められているコードの再利用を行うことで、開発の効率化が進むと同時 に、新しい開発に伴うコストが最小化されることから、製品化までの時間が短縮されます。さらには、開発組 織が既存のコードベースから学んだ教訓を活かすこともできます。ただし、そのコードを新しいシステムに統 合することで、予想外の結果が生じる場合もあります。 • 複数のコーダー コードベースは 1 つのバージョンやイテレーションだけで寿命を終えるわけではありません。アジャイルプ ロセスでは、開発者は元々自分が作成していないコードを編集することがよくあります。モジュールを受け継 ぐというのは、つまり開発者が元のコードの意図や、変数、使用されている言語構造を完全には理解してい ないことを意味します。 これらの要因によりコードベース全体の複雑さが増し、ひいてはソフトウェア開発プロセスの複雑化を招くことにな ります。このような複雑さは、日常の単純なタスクの遂行により多くの時間がかかってしまい、リリーススケジュールの 遅延、不具合発生率の向上、生産性の低下につながる可能性があります。開発チームは、コードの複雑さから生じる 問題の兆候を見逃さないように注意する必要があります。 roguewave.com 5

アジャイル開発における静的コード解析 ソフトウェアの場合、業界でよく知られたメトリクスを使って、ソフトウェアビルドの複雑度を監視することができます。 たとえば、McCabe の循環的複雑度の監視をビルドごとに行うことが可能です。この数値は標準からどのくらい「外れ て」いるかを示すものです（McCabe の複雑度では、値が 20 を超えると非常に複雑であるという判定になります）。さ らに重要なこととして、チームはこのメトリクスのトレンドを監視する必要があります。あるバージョンで前のバージョ ンと比べて値が急上昇している場合、複雑度の問題がプロセスに影響を与えていることが考えられます。 複雑度を緩和し、（保守作業を行うのが誰であれ）コードの保守をしやすくするための機会を探るためには、これらの メトリクスの追跡を検討するべきです。コードの複雑度の問題を放っておけば、ソフトウェアプロジェクトのスピード に悪影響がおよび、アジャイル開発環境の混乱につながりかねません。 図2：ソフトウェアビルドの複雑度など、主要なソフトウェアメトリクスを監視することで、開発プロセスに影響を与える問題の特 定、修正が容易に行えます。 従来の開発プロセスアプローチの適用 従来の開発プロセスは、開発速度の向上やクリーンなコードの作成の支援などによってプロセスに価値をもたらすこ とから、ベストプラクティスとして認められるようになっています。ただ残念なことに、それらのすべてがアジャイルに 適しているわけではありません。 ピアコードレビューを例にとって見てみましょう。コードレビューの効果については議論の余地はありません。今日の ソフトウェア開発チームの実に 53% がコードレビューを義務化しているのはそのためです。1 しかし、アジャイルの 場合、上級開発者との対面式のミーティングの日程を調整しなければならない従来のコードレビューは極めて非効 率で、時間のかかるやり方だと言えます。開発速度を低下させることなく、開発チームがこのような従来のプロセスか らメリットを享受できるように、プロセスをうまく適応させることが必要です。 roguewave.com 6

アジャイル開発における静的コード解析 ツールとプロセスの適用によりアジャイルを実現 「プロセスとツールよりも個人と相互作用を尊重する」というアジャイルマニフェストの理念は、一見ツールの必要 性を軽視しているように見えます。しかしその一方で、アジャイルチームは、ソフトウェア構成管理ツールや、ビルド管 理ツール、要件追跡ツール、テスティングツール、プロジェクト管理ツールなど、多くのツールを使って開発をサポー トしています。 ただ残念なことに、これらのツールのほとんどは生産プロセスの部分的な管理を目的としており、開発者がコーディ ングフェーズで直面する問題の解消を目的としたものではありません。適切に選ばれた開発者向けのツールを導入 することで、開発プロセスの早い段階で高品質なコードをアウトプットできるようになります。コラボレーティブなピア コードレビューと自動コードリファクタリングに高度なバグ検出を組み合わせるという、最新のソースコード解析技術 を採用することで、開発チームはバグ負債とコードの保全性の問題を回避し、効果的なアジャイルプロセスの実現を 円滑に進めることができます バグ検出の自動化 SCA(静的コード解析)はテストケースが不要で、アジャイルプロセスの一般的なマイルストーンに適した、完全自動 型のバグ検出ソリューションです。同技術は現在普及が進んでおり、プロのソフトウェア開発者がコード内のバグを減 らしつつ、コストを削減し、ソフトウェア開発を順調に進めるための主要な選択肢となりつつあります。 最新の静的コード解析ソリューションは、メモリとリソースの管理、プログラムデータ管理、バッファオーバーフロー、 検証されていないユーザ入力、脆弱なコーディング手法、同時実行違反、さまざまな長期保守といったソフトウェアソ ースコードの弱点となっている部分を特定し、対処する、洗練された高価値の解析を提供することが可能です。静的 コード解析 は、ユニットテストや侵入テストといった従来の動的な解析技術とは違い、問題となっているプログラム やモジュールのソースコードのみを使ってビルド時に解析作業を実行します。このため、ランタイムに観察される動作 という、必然的に制限される一部の側面ではなく、考えられるあらゆる実行パスを完全に把握して生成された結果が 報告されることになります。 静的コード解析は基本的にビルド時に解析が実行されることから、個々の開発者や開発チームが統合ビルドレベル もしくは開発者ビルドレベルでビルドを実行する際のビルドマイルストーン活動として利用するのが、最も効果的で す。 統合ビルド（別名「システムビルド」または「プロジェクトビルド」） 今日の SCA ツールによる解析は、ソースコード解析によく使われる構文解析や意味解析よりもはるかに効果的で す。現代の優れた SCA 技術には、フォルスパスの除去、変数の値の推測、想定されるランタイム動作のシミュレーシ ョンを可能とする最新のアプローチを使った、高度なプロシージャ間制御とデータフロー解析が含まれることが期待 できます。数百万行のコードと実質的に無限の実行可能なコードパスを持つ大規模なシステムを対象に、このような 解析を行うとなると、その複雑さは相当なものです。 解析を有効なものにし、「誤検知」（ツールにより誤って報告されるバグ）と「検知漏れ」（ツールで見落とされるバ グ）の数を減らすため、ベンダーは自然の流れとしてプロジェクトのシステムビルドとの統合 — make、ant、Visual Studio、あるいは Electric Cloud や BuildForge などその他の継続的統合ツール — を利用して、ソースコードベース

アジャイル開発における静的コード解析 の全体像がわかるようにします。もちろん、統合ビルドレベルだけに限定して SCA を実行する場合、デスクトップで発 生したバグがメインのコードストリームに入り込み、チームの他のメンバー（同僚開発者と QA チームの両方）に影響 を与えかねないというマイナス面があることも事実です。下流工程でバグが見つかった場合、たとえそれが統合ビル ドの実行頻度がはるかに高い継続統合であっても、バグトリアージプロセスを追加して（電子メールや Web レポー トなどを使って）開発者にエラーを知らせる必要があります。その結果、ワークフローとプロセスの数が増えることに なり、これはアジャイル開発の考え方に反しています。 SCA を開発者のデスクトップに統合し、ユニットテストの前であっても開発者のビルドと共に解析を実行できるよう にすることで、この問題を解決することができます。 開発者ビルド（別名「パーソナルビルド」または「サンドボックスビルド」） 開発者のデスクトップでの SCA の実行は、同技術を採用するあらゆる組織に多大なメリットをもたらします。特にア ジャイルチームの受ける恩恵は極めて大きなものです。コードチェックイン前にほとんどのバグを発見できれば、組 織はフェーズ内でのバグ封じ込めに成功し、メインのコードストリームや統合ビルドでのバグ発生数が減少します。 これによって、カスタマーアドボケートに集中でき、より品質の高いソフトウェアをより迅速に開発できることから、QA がより効率的になります。 開発者のデスクトップで SCA を実行するには、開発者の普段の作業環境（お気に入りの IDE、テキストエディタ、コマ ンドラインなど）内に配置し、コードストリームの全体像を見ることができる集中型の解析と同じように、正確でインテ リジェントな解析でなければなりません。アジャイルにおいてコードのチェックイン（またはコミット）は重要なマイル ストーンであり、継続統合の観点から業務を行っている多くの組織には、開発者がコードをチェックインするために 通り抜けなければならない一連のゲート（スモークテスト、ユニットテストなど）が存在します。このチェックイン前の 一連の品質ゲートに SCA を追加するようにします。 フェーズ内でのバグ封じ込めを目的として SCA を導入する場合、本稿の最初で述べたアジャイルの基本原理が完 全に実現されることになります。 コラボレーティブなピアコードレビューの促進 ピアコードレビューはソフトウェア開発プロセスにおける必要悪と言っていいでしょう。多くの組織ではリリース前の コードレビューが義務付けられていますが、コードレビュープロセスは時間がかかるだけでなく、自分のコードがレビ ューされていると思うと誰でもいい気持ちはしないものです。しかし、そのメリットは絶大です。 • コードレビューを行うことにより、開発チームにおいて一貫性が生まれ、品質重視の文化が育まれます。コー ディング基準とベストプラクティスを満たしていることを確認しながら、バグや設計上の不具合を特定するこ とにより、より高品質の製品が市場に投入されることになります。 • 経験豊富なチームメンバーがコードをレビューし、フィードバックを提供することから、コードレビューは開発 者にとって良い学習機会になります。 アジャイルの観点で見ても、これらのメリットは重要です。しかし、対面型のミーティングの日程を調整するという従来 のコードレビューのやり方は、アジャイル環境においては効果的ではありません。開発プロセスにコードレビューを組 み込みたいと考えているアジャイルチームは、コードレビュー機能が内蔵された SCA ツールの導入を検討するべき です。これらのツールでは、非同期的のコードレビューが可能であり、シンプルな Web ベースのピアレビューが提供 されます。このアプローチでは、特定の人々が決まった時間に会議室に集まり、コードレビューを行う必要がありませ ん。

アジャイル開発における静的コード解析 代わりに、地理的条件や日程、職位に関係なく、さまざまなチームメンバーが都合のいいときにコードをレビューし、 フィードバックを返すことができます。ピアコードレビュー機能とソースコード解析を組み合わせれば、コーディング の不具合を特定した上で、レビュアーがそれらを確認し、コメントを書き、必要なアクションを割り当てることが可能 です。 複雑なリファクタリングを簡素化 リファクタリングとはプログラムの動作を変えることなくコードを整理し、より簡潔なものにするプロセスですが、時間 と手間がかかり、特に C や C++ などよく使用される言語での開発では困難な作業となります。リファクタリングプロ セスを自動化するツールがないことで、リファクタリングを断念する開発者も少なくありません。しかし、コードリファ クタリングを容易にするプロセスを早い段階で実装することで、多くの場合、アジャイルチームに重要なメリットがも たらされます。 「アジャイルマニフェスト」の著者の 1 人、マーティン・ファウラー氏は、リファクタリングはコードに対してささいな変 更を行うことだが、それが積み重なることで重要な結果が得られると書いています。リファクタリングは以下のような 分野で効果を発揮します。 • 変更への適応 継続的な変更はアジャイルの基本的な側面の 1 つです。開発プロセスの途中で頻繁にリファクタリングを行 うようにすることで、コードが扱いやすくなり、チームはより効果的に変更に適応することができます。 • 不具合の検出 コードを簡素化し、全体的な設計を改善することで、コードはより明解なものになります。明解なコードで作 業を行えば、品質欠陥やセキュリティ脆弱性を容易に発見できます。また不具合の発見と修正にかかる時間 が短ければ短いほど、プロセスへの影響（開発者の仕事の妨害、テストチームの作業の停止、プロセス全体 のスピードの低下など）も少なくてすみます。 • 開発者の生産性 元々自分が作成していないコードを扱わなければならないケースはよくあります。リファクタリングを使え ば、コードの引き継ぎが容易に行えます。つまり、開発者は既存のコードのレビューや解釈、修正にイテレー ションを費やす代わりに、新しいコードの記述に集中的に時間を使うことができるようになります。 チームがアジリティを実現する上で、リファクタリングが重要な役割を果たすことは明らかです。リファクタリング機能 が装備された最新のソースコード解析ツールを使うことで、アジャイルチームはリファクタリングプロセスを自動化 し、プロセスの複雑性を緩和しつつ、リファクタリングのメリットを享受することができます。 真のアジリティの実現 バグ検出、コードレビュー、リファクタリングの機能を備えたソースコード解析技術をアジャイル開発サイクルに組み 込むことで、開発チームはフェーズ内でのバグ封じ込めに対応できるだけでなく、本稿の最初で取り上げたアジャイ ルの基本原則を完全に実現することが可能です。

アジャイル開発における静的コード解析 バグをなくすことでセキュリティと信頼性を確保 ソフトウェアバグは非常に厄介な存在です。深刻なバグは下流工程での効率の低下、製品のリコール、フィールドで の障害といった問題を引き起こしかねません。SCA は、NULL ポインタの逆参照やメモリ管理の問題といったシステ ムクラッシュにつながる不具合、あるいはバッファオーバーフローや検証されていないユーザ入力といった、システ ムをハッカーに狙われやすくしてしまう問題など、コード内の深刻なバグを自動で検出します。製品出荷の前にこれ らの問題を取り除いておくことは非常に重要であり、対応が早ければ早いほど効果的です。これによって、イテレーシ ョン内で深刻な問題が QA に渡されることや、イテレーション間で問題が移行することを防止できます。このような問 題の移行を止めることができなければ、バグのあるソフトウェアが出荷されるリスクが大幅に高まります。加えて、コー ドチェックインの前にバグの数を大きく削減できれば、メインのコードストリームがバグの影響を受けずにすみ、テス トおよび QA プロセスが円滑に進みます。 発見、報告されるバグの数が少なければ、テスト担当者はその分、機能やパフォーマンスのテストに集中でき、製品 を顧客や市場に提供できる状態にすることが可能になります。 バグをなくすことで柔軟性を実現 アジャイル環境で開発されたソフトウェアの適切なテストと品質の保証には、テストプロセスが反復可能であること、 および頻繁に変わる要件に適応できることが求められます。すなわち、テストフェーズにはプログラミングのバグに対 応する余地がほとんどないということです。QA でこれらのバグが発見された場合、開発サイクルに深刻な遅れが生じ ることになります。テスト担当者からバグの報告を受けた開発者は、今の仕事を中断して気持ちを切り換え、そのコー ドを書いていたときに後戻りしなければなりません。開発者がバグのないコードをチェックインできるようになれば、 チェックイン、バグの検出、デバッグ、再作業という時間のかかるサイクルを大幅に短縮するかもしくは完全になくして しまうことが可能です。アジャイル環境で SCA ツールを利用することで、開発者は報告されたバグをより短時間で修 正し、新しい革新的なソフトウェアの記述により多くの時間をかけることができます。すなわち、開発者は新規の開発 で作成したコードの信頼性とセキュリティを、統合ビルドを実行する前に制御できるという柔軟性を備えることにな るのです。 バグをなくすことで継続的な改善を実現 重要なのは、機能開発の観点からイテレーションの進行状況がどのように見えるかではありません。高品質なコード に対する開発チームの取り組み状況を測定できなければ、ビルドやイテレーションごとにプロジェクトの下流工程に おけるリスクが蓄積してしまうことになります。移り変わりが速く流動的なアジャイル開発環境では、チームは以下の ような強力な自動測定機能を導入する必要があります。 • 開発ビルドでのバグ修正の測定、追跡 • 統合ビルドに漏出しているバグの特定 • ナイトリービルド（もしくは継続的なビルドスケジュールを超えるその他の頻度）の品質マイルストーンの設 定 • 経時的に改善しているチームまたはコンポーネントの追跡 これらの課題を解決できれば、アジャイルチームは狙いどおりの継続的改善プログラムを実施できます。支援やトレ ーニングが必要な箇所を瞬時に見極め、開発チームのメンバー全員がクリーンなコードを統合ビルドにサブミットで きるようになります。イテレーション計画が適切かどうか、またイテレーションの終了時に出荷可能な製品を提供でき るかどうかを知るには、ボトムアップ方式による品質の測定、追跡が不可欠です。

アジャイル開発における静的コード解析 バグをなくすことでコラボレーションとコミュニケーションを強化 アジャイル開発における短期のイテレーションプロセスを成功させるには、持続的なコミュニケーションとチーム間の コラボレーションが必要です。これによって、遭遇する問題を迅速に解決し、不要な遅延を招くことになる作業の重複 を回避することができます。SCA ツールを利用することで、報告されたあらゆる問題を共同作業によって緩和すること が可能です。開発者やアーキテクト、その他のチームメンバーは報告された問題のステータスを変更したり、コメント を追加したりすることができ、それらは他の開発者に自動的に同期されます。この機能を利用することで、さまざまなチ ームメンバーが複雑な問題に共同で取り組むことができ、同じバグに対して何度も同じ作業を行わずにすみます。この ような継続的な可視性と、データおよびフィードバックの共有機能により、プロセスの早い段階で問題を緩和すること が可能になります。 アジャイル開発のための Klocwork 総合的な静的解析エンジンを用いて、Klocwork は開発者がアジリティと開発の速度を向上させることができるよう に支援します。アジャイル開発の基本方針を次の方法によってサポートします。 オンザフライのデスクトップ解析 Klocwork のデスクトップ解析は開発者にとっての「スペルチェック」のようなものです。コード作成時に、コードに混 入してしまうセキュリティ脆弱性および重大な不具合に対して、即座に、正確かつ継続的なフィードバックを提供しま す。 コード作成段階において開発者の IDE 内で重大なコーディング上の問題点を浮き彫りにすることで、開発ワークフ ローに不具合の修正作業を自然な形で取り入れ、チェックインするまでに、最もセキュアかつ信頼性の高いコードが 作成されていることを確実にします。このアプローチで、開発サイクルの下流工程で報告される問題点の数、開発者 が後戻りして問題を修正するために費やす時間の両方を削減します。こういった生産性向上効果はアジャイル環境 において重要な要素です。 図 3：オンザフライのデスクトップ解析により、開発者がコードチェックインの前に、IDE 内で重大なコーディング上の問題点を発 見、修正することができるようになります。これにより、開発プロセスの後半まで検出できない問題点のために開発者が後戻りして 修正する時間を削減できます。

アジャイル開発における静的コード解析 ソフトウェアのメトリクスとレポート Klocwork は、100 以上の客観的かつ実用的な製品メトリクスからなる強力なメトリクススイートを提供します。これ らのメトリクスは、ソフトウェアコードから直接導き出されます（図 4 参照）。開発チームのマネージャは、ドラッグアン ドドロップによるレポート機能を利用して、組織のソフトウェア開発プロセスに関する主要な質問にすばやく簡単に 回答することができます。たとえば、アジャイルについての主要な質問には、バグが開発者のデスクトップ上で発見、 修正されているかどうかや、バグが統合ビルドに漏出していないかといったものがあります。Klocwork は、何がデス クトップ上で検出・修正されているのかという情報を、元のストリームに伝搬されていない場合でも、自動的に集約し ます。この独自機能によって、チームはコードチェックインの前に行われるバグ削減作業についてより明確に把握で き、不具合の封じ込めの成果をボトムアップで見ることが可能です。この機能に、個人、グループ、コンポーネント、そ の他の組織にとって意味のあるあらゆる属性ごとにメトリクスを編成することが可能なカスタムオーナーシップモデ ルを組み合わせることによって、コードベース内の特にリスクの高い領域をイテレーションの早い段階で特定するこ とができます。 図 4：Klocwork により自動作成される充実したレポート。これによってアジャイルチームは、デスクトップでのバグ修正率を追跡し ながら、統合ビルドの状態を監視することができます。 C/C++ の自動リファクタリング アジャイル開発チームのベストプラクティスで推奨されているように、リファクタリングの目的はクリーンでわかりやす く、変更が容易なコードを記述することにあります。Klocwork は、開発者がエディタから C/C++ コードを自動的に抽 出し、再利用可能かつ理解可能なコードに変えることができる、強力なリファクタリング機能を提供します。つまり、開 発者は個別のビューやダイアログにアクセスしなくても、コードの状態をすばやく把握し、設計を改善することができ るのです。

アジャイル開発における静的コード解析 図 5：Klocwork では、エディタ内でリファクタリングオプションが提供され、個別のビューやダイアログにアクセスしなくてもコード 設計を改善することが可能です まとめ 今日のソフトウェアの持つユビキタス性と、市場に出せる機能や製品をわずか数週間で開発しなければならないと いうプレッシャーにより、以下の 2 つの相関した現象が生じています。 • ジャイルソフトウェア開発原則の広範囲での採用 • アジャイルチームにおける、開発プロジェクトの合理化とリスク軽減のために設計されたさまざまなツールの 採用 アジャイルチームによる導入が可能なツールの中でも特に重要なものとして、より高品質なコードの記述を支援する ツールが挙げられます。SCA ツールを使えば、コードが統合ビルドやテストチームに送られる前に、大量のソフトウェ アバグやセキュリティ脆弱性を開発者のデスクトップ上で自動的に検出することが可能です。これに自動化されたリ ファクタリングを組み合わせることで、コードの保全性が向上します。また、アジャイルチームはプロジェクトの遅れを 最小限に抑え、効率的な作業を行うことが可能です。開発者が革新的なコードの記述に集中的に取り組めるようにな る一方で、テストチームはありふれたコードの問題を見つけ出し何度も繰り返しテストを行うのではなく、プロジェク トの機能の動作テストに時間を費やすことができます。 品質の問題やセキュリティ脆弱性がプロセスに影響している、プロセスがアジャイルに対応していない、コードの保 守が困難であるといった場合には特に、アジャイルチームで SCA を利用することをお勧めします。アジャイル環境内 でソースコード解析を実装しても、必ずしも混乱は生じません。まずは小規模から始め、小さなプロジェクトやプロジ ェクトの一部の解析を行うようにするといいでしょう。そうして得られた結果を、それらのツールを利用しなかった同 じようなプロジェクトと比較してみてください。アジャイル開発プロセスで SCA を利用することで、時間とコストを大 幅に削減できる機会を見いだすことは間違いありません。

アジャイル開発における静的コード解析 Rogue Wave helps thousands of global enterprise customers tackle the hardest and most complex issues in building, connecting, and securing applications. Since 1989, our platforms, tools, components, and support have been used across financial services, technology, healthcare, government, entertainment, and manufacturing, to deliver value and reduce risk. From API management, web and mobile, embeddable analytics, static and dynamic analysis to open source support, we have the software essentials to innovate with confidence. roguewave.com © 2017 Rogue Wave Software, Inc. All rights reserved.