詳細を見る

トッド・ランドリー | ホワイトペーパー | 2011 年 1 月
シニアプロダクトマネージャ、
アジャイル環境での
ソースコード解析
動くソフトウェアを各イテレーションで提供するための
反復可能なプロセスを確立するには
ソフトウェアの機能性の向上と製品化までの時間の短縮を望む顧客の需要の高まりを受け、ソフト
ウェア開発者はコードの開発方法を速度と品質の両面で進化させる必要がありました。このトレン
ドの一環として、1990 年代後半になるとそれまで主流だったウォーターフォールメソッドに代わり、
より手軽な「アジャイル」というソフトウェア開発方法が台頭してきました。
2000 年代に入ってもアジャイルの利用は拡大を続け、成熟を遂げつつあります。ソフトウェア企業は
アジャイル環境を改善する方法を絶えず模索しており、ソフトウェアバグを最小限に抑えることが焦点
の 1 つとなっています。反復可能なプロセスの実装を通してコードのバグを最小限に抑えない限り、
アジャイルの基本原理を完全に実現することは不可能です。このホワイトペーパーでは、そのことにつ
いて論証していきます。本稿で推奨しているアプローチは、自動ソースコード解析（SCA）技術を利
用して、セキュリティ脆弱性、ロジックエラー、実装欠損、同時実行違反、まれな境界条件、問題の
原因となるその他のコードなど、ソフトウェアソースコードの脆弱な箇所を特定・解説するというもの
です。
まずはアジャイルの概要を説明し、アジリティの実現を妨げているいくつかの障壁について取り上げ
ます。その後で、SCA 技術の重要機能によってアジャイル開発プロセスがどのように強化され、
アジャ
イルチームの権限がどう拡大するかを見ていくことにします。
アジャイル開発 – 概歴
アジャイルソフトウェア開発とは、簡単に言えば、ソフトウェア開発サイクル全体を通して絶えず繰り
返される変化に柔軟に対応するためのアプローチです。ここで重視されるのは、動くソフトウェアの
迅速な提供、開発者の権限の拡大、開発者とチームの他のメンバー（経営陣を含む）とのコラボレー
ションです。
今なお人気の高いウォーターフォール開発は、広範なスコープと要件定義を持つ先行負担型のアプ
ローチであり、要件の定義から、設計、コーディング、品質保証までの一連の明快なハンドオフが採
用されています。これとは対照的に、アジャイル開発では開発プロセスのあらゆる段階で継続的に要
件が収集されます。リリースサイクルの全段階に経営陣が関与し、開発中のソフトウェアがエンドユー
ザとビジネスの両方のニーズを満たしていることを確認できる仕組みになっています。また外部の機
会や脅威が発生した場合は、要件と全機能セットに変更が生じることが予想されます。
つまり、アジャイルでは変更が完全に受け入れられ、アジャイルチームはビルドプロセスや、他の
開発者、QA、ビジネス上の利害関係者から定期的なフィードバックを受け取り、それらに対応でき
るよう構成されています。
アジャイルは多数の指針に基づいており、全てのアジャイルチームはそれに従うものとします。この
議論を進めるにあたり、特に注目すべき 4 つの指針――あるいは価値――を以下にあげています。
»
高品質なソフトウェア開発
»
柔軟な反復
»
継続的な改善
»
コラボレーションとコミュニケーション
高品質なソフトウェア開発
アジャイル開発の主要目標は、一定の期間内（通常は数週間以内）に顧客のニーズを満たす――つまり使える機能や性能を
提供する――高品質なソフトウェアの開発を実現することであり、
このような期間は「イテレーション（反復）」や「スプリント（短
距離走）」と呼ばれています。理論的には、アジャイル環境で開発される製品は、1 つのイテレーションが終わった時点で市
場に出せる状態になっていなければなりません。
市場に出せる一連の製品を、それぞれわずか数週間で提供するには、アジャイル開発サイクルに厳格な品質プロセスを組み
込む必要があります。イテレーションごとに提供される成果物は、開発が完了した――つまり、テスト済みで、不具合がなく、
ドキュメンテーションが全て揃っている――状態でなければなりません。
柔軟な反復
アジャイルはスピードと回転の速さにフォーカスしており、開発サイクルのあらゆる段階でいや応なく発生する変更に対応でき
るようになっています。最初の要件が顧客の需要や市況などさまざまな理由によって変更される可能性があるということを前提
に、柔軟なイテレーションプロセスが設定されています。プロセス全般にビジネスユーザが関与しており、またそれぞれのイ
テレーション期間が短いことから、急に新しい要件が発生し、優先順位が決まることも考えられます。
継続的な改善
アジャイル環境は、新しいスキルを習得し自主的に業務を遂行する機会を開発者に提供します。テスティングや品質保証を定期
的もしくは長いプロセスの最後に実行する場合、コーディングの不具合を修正したり作業中に教訓を得ることは難しく、十分な
コスト効果が得られないことも少なくありません。これに対して、イテレーションフレームワークではテスティング / 品質保証が
イテレーションプロセスの中に組み込まれており、継続的な改善が可能なことから、自立した作業が行えます。またアジャイル
では、テスティングと QA プロセスがコードを記述する開発者に対して透過的に行われることから、開発者に学習の場が提供さ
れ、将来の改善やコーディングの効率化が促進されます。
コラボレーションとコミュニケーション
一般的にソフトウェア開発ではコミュニケーションとコラボレーションが重要とされますが、アジャイル開発環境ではこれらは最
優先事項となっています。実際、「アジャイルマニフェスト」（アジャイルの事実上の定義として広く認識されています）では、
個人と相互作用をキーコンセプトとして重要視しています。最終的に、開発プロセスの効率化はオープンなコミュニケーション
とコラボレーションによって促進されます。必要なときに適切な個人、データ、フィードバックにアクセスできる環境があること
で、アジャイルプロセスで求められるとおり、動くソフトウェアを短いイテレーションで提供することが可能になります。
アジャイルの円滑な進行
開発チームがアジャイルマニフェストにある基本原則を取り入れようとする際、バグ負債、開発者の多様なスキルセット、コー
ドの複雑さといった障害を割けて通ることはできません。真のアジャイル開発プロセスを実現するには、
これらの障壁を認識し、
「アジャイルの円滑な進行」に向けた有効な戦略を採用する必要があります。
バグ負債への対応
アジャイルマニフェストで示されている開発原則の 1 つに「動くソフトウェアこそが進捗のもっとも重要な尺度である」という
ものがあります。動くソフトウェアとはつまり、ビルドを壊し、想定外の動作の原因となるような、製品の要件を満たさない問題、
ならびに一般的なプログラミングの不具合が一切ないソフトウェアのことです。
この原則はアジャイルだけに限定されたものではありません。CMMI や Six Sigma などの公式プロセスを含む多くのソフトウェ
ア開発プロセスでも、バグのないコードの記述を基本原則として推奨しています。これらのプロセスでは、インフェーズのバグ
の封じ込め、つまりバグが発生したフェーズから下流工程に移動するのを防止することを推奨しています（図 1 参照）が、
アジャ
イルでもインフェーズのバグの封じ込めの重要性を暗示的に強調しています。アジャイルプロセスでは短いイテレーションを
前提としていることから、チーム全体が次のイテレーションに移行できるように潜在的なソフトウェア品質の低下をすばやく特
定・修正しなければなりません。つまり、機能的に見て完全な動くソフトウェアの構築時に、それら全ての作業を行う必要があ
るのです。
Source Code Analysis in an Agile World | Klocwork White Paper | 2
現在の
source
code
ソースコード解析
analysis today
不具合のコスト
cost of defects
No. of Code Defects Found
コ
ー
ド
不
具
合
の
検
出
数
図 1 バグ封じ込め
のコスト
Design
設計
Implement
実装
Build
ビルド
ユニッ
ト
Unit Test
テスト
Check-in
チェックイン
System
システム
Build
ビルド
System Test
システムテス
QA
ト&&QA
Release
リリース
Software
Development Life Cycle
Phase
ソフトウェア開発のライフサイクル
フェーズ
イテレーション内においても、アジャイルチームは継続的なインテグレーションとリグレッションを通してこの考え方を適用しま
す。このやり方はビルドやリグレッションテストスイートを破壊する可能性のある不具合の解消には効果的ですが、一般的なプ
ログラミングバグのクリーンアップには有効ではありません。これらのバグは以下の 7 種に大別されます。
»
メモリとリソースの管理
»
プログラムデータ管理
»
バッファオーバーフロー
»
無効なユーザインプット
»
脆弱なコーディングプラクティス
»
同時実行違反
»
さまざまな長期保守の問題
バグ入りコードは、1 つのイテレーションだけでなく、後続のイテレーションにおいてもバグ負債というリスクを生み出します。
コードの欠陥をイテレーション内で解消しないでおくと、その欠陥は 1 つのマイルストーンから次のマイルストーンへと移行し、
下流工程でバグ負債が蓄積することになります。バグ負債が生じると、開発速度が低下し、イテレーションごとの実装の質の低
下や、影響力のある変更の減少へと発展することから、アジャイルプロジェクトが失敗に終わる可能性があります。また「蓄
積された」（つまり、さらに先の下流工程まで発見されることのない）バグの場合、修正が難しく多額のコストがかかる場合が
多く、フィールドで製品に不具合が発生したり、顧客を失望させることになりかねず、ブランドイメージの低下につながります。
以上のような理由から、アジャイルプロセスにはインフェーズのバグ封じ込めが極めて重要になってきます。できるだけ早い
段階でバグを駆除するには、バグの特定・除去プロセスを制御すると同時に、開発者間のコラボレーションを強化することが
不可欠です。
多様なスキルセットに対応
仲間同士で積極的に話し合い、顧客から頻繁にフィードバックを受け取ることを厭わない、そんな優秀で明晰なソフトウェア
エンジニア達で構成される開発チームはまさに理想的です。しかし残念ながら、現実には必ずしもこのようなチームを編成で
きるとは限りません。一般的な開発チームはさまざまな人材の集まりであり、スターのような人材もいれば経験の浅い開発者
もいる、共同作業が得意な人もいれば、影でコツコツとやるのが好きな人もいます。経験の浅い開発者がベテランの同僚か
ら学ぶ機会を作り、コミュニケーションとコラボレーションが容易に行える環境を整えることで、バランスの採れたチームが出
来上がり、結果、動くコードのアウトプットを最大化することができます。
コードの複雑化の抑制
以下の要因により、コードベースは複雑化の一途をたどっています。
»
コードベースのサイズ
性能の拡張とより高度な機能に対する需要の高まりに伴い、コードベースのサイズが拡大し、変数と制御パスの
増加、ひいては言語構造の多様化につながります。
Source Code Analysis in an Agile World | Klocwork White Paper | 3
コードの再利用
業界のベストプラクティスとして認められているコードの再利用を行うことで、開発の効率化が進むと同時に、新
しい開発に伴うコストが最小化されることから、製品化までの時間が短縮されます。さらには、開発組織が既存
のコードベースから学んだ教訓を応用することも可能です。ただし、そのコードを新しいシステムに統合すること
で、予想外の結果が生じる場合もあります。
»
複数のコーダー
コードベースは 1 つのバージョンやイテレーションだけで寿命を終えるわけではありません。アジャイルプロセ
スでは、開発者は自分が作成したのではないコードを編集することがよくあります。モジュールを受け継ぐという
のは、つまり開発者がもともともとのコードの意図や、変数、使用されている言語構造を完全には理解していな
いことを意味します。
これらの要素によりコードベース全体の複雑さが増し、ひいてはソフトウェア開発プロセスの複雑化を招くことになります。こ
のような複雑さのせいで日常の単純なタスクの遂行により多くの時間がかかってしまい、リリーススケジュールの遅延、不具合
発生率の向上、生産性の低下につながる可能性があります。開発チームは、コードの複雑さから生じる問題の兆候を見逃さ
ないように注意する必要があります。
»
ソフトウェアの場合、業界でよく知られたメトリクスを使って、ソフトウェアビルドの複雑度をモニタリングすることができます。
たとえば、McCabe の循環的複雑度の監視をビルドごとに行うことが可能です。この数値は標準からどのくらい「外れて」い
るかを示すものです（McCabe の複雑度では、値が 20 を超えると非常に複雑であるという判定になります）。さらに重要なこ
ととして、チームはこのメトリクスのトレンドを監視する必要があります。あるバージョンで前のバージョンと比べて値が急上昇
している場合、複雑度の問題がプロセスに影響を与えていることが考えられます。
複雑度を緩和し、（保守作業を行うのが誰であれ）コードの保守をしやすくするための機会を探るために、これらのメトリクス
の追跡を検討するべきです。コードの複雑さの問題を放っておけば、ソフトウェアプロジェクトのスピードに悪影響がおよび、
アジャイル開発環境の混乱につながりかねません。
図 2 ソフトウェアビルドの複
雑度など、主要なソフトウェア
メトリクスを監視することで、
開発プロセスに影響を与える
問題の特定・修正が容易に行
えます。
従来のプロセスアプローチの適用
従来の開発プロセスは、開発速度の向上やクリーンなコードの作成の支援、およびその他の要素によってプロセスに価値をも
たらすことから、ベストプラクティスとして認められるようになっています。ただ残念なことに、それらの全てがアジャイルに適
しているわけではありません。ピアコードレビューを例にとって見てみると、その効果については議論の余地はありません。
今日のソフトウェア開発チームの実に 53% がコードレビューを義務化しているのはそのためです。1 しかし、アジャイルの文
脈で見た場合、上級開発者との対面式のミーティングの日程を調整しなければならない従来のコードレビューは極めて非効率
で、時間のかかるやり方だと言えます。開発速度を低下させることなく、開発チームがこのような従来のプロセスからメリット
を享受できるように、プロセスをうまく適応させることが必要です。
1
The Value and Importance of Code Reviews, a commissioned study conducted by Forrester Consulting on behalf of Klocwork, February 2010
http://www.klocwork.com/resources/research/klocwork-paper-code-review-study
Source Code Analysis in an Agile World | Klocwork White Paper | 4
ツールとプロセスの適用によりアジャイルを実現
「プロセスとツールよりも個人と相互作用を尊重する」というアジャイルマニフェストの理念は、一見ツールの必要性を軽視し
ているように見えます。しかしその一方で、アジャイルチームは、ソフトウェア構成管理ツールや、ビルド管理ツール、要件
追跡ツール、テスティングツール、プロジェクト管理ツールなど、多くのツールを使って開発をサポートしています。
ただ残念なことに、
これらのツールのほとんどはプロダクションプロセスの管理に利用されており、開発者がコーディングフェー
ズで直面する問題の解消を目的としたものではありません。適切に選ばれた開発者向けのツールを導入することで、開発プロ
セスの早い段階で高品質のコードをアウトプットできるようになります。コラボレーティブなピアコードレビューと自動コード
リファクタリングに高度なバグ検出を組み合わせるという、最新のソースコード解析技術を採用することで、開発チームはバ
グ負債とコードの保全性の問題を回避し、効果的なアジャイルプロセスの実現を円滑に進めることができます。
バグ検出の自動化
SCA はテストケースが不要で、アジャイルプロセスの一般的なマイルストーンに適した、完全自動型のバグ検出ソリューショ
ンです。同技術は現在普及が進んでおり、プロのソフトウェア開発者がコード内のバグを減らしつつ、コストを削減し、ソフトウェ
ア開発を順調に進めるための、メインストリームの選択肢となりつつあります。
SCA 関連の基礎技術に「静的解析」があり、現世代の技術ソリューションはメモリとリソースの管理、プログラムデータ管理、
バッファオーバーフロー、無効なユーザインプット、脆弱なコーディングプラクティス、同時実行違反、さまざまな長期保守
の問題といったソフトウェアソースコードの脆弱な部分を発見・解説する、洗練された高価値の解析を提供することが可能で
す。SCA は、ユニットテストや侵入テストといった従来の動的な解析技術とは違い、問題となっているプログラムやモジュー
ルのソースコードのみを使ってビルド時に解析を実行します。したがって、限定的に観測されたランタイムの動作ではなく、
あらゆる実行パスの全体像から生成された結果が報告されることになります。
SCA は基本的にビルド時に実行されることから、個々の開発者や開発チームが統合ビルドレベルもしくは開発者統合レベル
でビルドを実行する際のビルドマイルストーンアクティビティとして利用するのが、もっとも効果的です。
統合ビルド（別名「システムビルド」または「プロジェクトビルド」）
今日の SCA ツールによる解析は、ソースコード解析によく使われる構文解析や意味解析よりもはるかに効果的です。現代の優
れた SCA 技術には、フォルスパスの除去、変数の値の推測、ランタイムの動作のシミュレーション用に、最新のアプローチを
使った高度なインタープロシージャルコントロールとデータフロー解析が含まれることが予想されます。数百万行のコードと基
本的に無限の実行可能なコードパスを持つ大規模なシステムを対象に、このような解析を行なうとなると、その複雑さは相当
なものです。
解析を有効なものにし、「誤検知」（ツールにより誤って報告されるバグ）と「検知漏れ」（ツールで見落とされるバグ）の数を
減らすために、ベンダーは自然の流れとしてプロジェクトのシステムビルドとの統合――make、ant、Visual Studio、あるいは
Electric Cloud や BuildForge などその他の継続的統合ツール――を利用して、ソースコードベースの全体像が分かるようにし
ます。もちろん、統合ビルドレベルだけに限定して SCA を実行する場合、デスクトップで発生したバグがメインのコードストリー
ムに入り込み、チームの他のメンバー――同僚開発者と QA チームの両方――に影響を与えかねないというマイナス面がある
ことも事実です。下流工程でバグが見つかった場合、たとえそれが統合ビルドの実行頻度がはるかに高い継続統合であっても、
バグトリアージプロセスを追加して（E メールや Web レポートなどを使って）開発者にエラーを知らせる必要があります。そ
の結果、ワークフローとプロセスの数が増えることになり、これはアジャイル開発の考え方に反しています。
SCA を開発者のデスクトップに統合し、ユニットテストの前であってもビルドと共に解析を実行できるようにすることで、この
問題を解決することができます。
開発者ビルド（別名「パーソナルビルド」または「サンドボックスビルド」）
開発者のデスクトップでの SCA の実行は同技術を採用するあらゆる組織に多大なメリットをもたらし、特にアジャイルチーム
の受ける恩恵は極めて大きなものです。コードチェックイン前にほとんどのバグを発見できれば、組織はインフェーズのバグ
封じ込めに成功し、メインのコードストリームや統合ビルドでのバグ発生数が減少します。これによって、顧客の擁護に集中
できることから、QA の効率化が可能になり、最終的により短期間で高品質のソフトウェアを開発できるようになります。
開発者のデスクトップで SCA を実行するには、開発者の普段の作業環境（お気に入りの IDE、テキストエディタ、コマンド
ラインなど）内にツールを設置し、コードストリームの全体像から成果を得る集中型の解析と同じように、正確でインテリジェ
ンスな解析を行なう必要があります。アジャイルにおいてコードのチェックイン（またはコミット）は重要なマイルストーンであり、
Source Code Analysis in an Agile World | Klocwork White Paper | 5
継続統合の文脈において業務を行っている多くの組織には開発者がコードをチェックインするために通り抜けなければならな
い一連のゲート（スモークテスト、ユニットテスト、その他）が存在します。このチェックイン前の一連の品質ゲートに SCA
を追加するようにします。
インフェーズのバグ封じ込めを目的として SCA を導入する場合、本稿の最初で述べたアジャイルの基本原理が完全に実現さ
れることになります。
コラボレーティブなピアコードレビューの促進
ピアコードレビューはソフトウェア開発プロセスにおける必要悪と言っていいでしょう。多くの組織ではリリース前のコードレ
ビューが義務付けられていますが、レビュープロセスは時間がかかるだけでなく、自分のコードがレビューされていると思うと
誰でもいい気持ちはしないものです。しかし、そのメリットは絶大です。
»
コードレビューを行うことにより、開発チーム内で整合性が生まれ、品質重視の文化が育まれます。コーディング
基準とベストプラクティスを満たしていることを確認しながら、バグや設計上の不具合を特定することにより、より
高品質の製品が市場に投入されることになります。
»
経験豊富なチームメンバーがコードをレビューし、評価を行うことから、コードレビューは開発者にとって学びの
場となります。
アジャイルの文脈で見ると、これらのメリットは重要です。しかし、対面型のミーティングの日程を調整するという従来のコード
レビューのやり方は、アジャイル環境においては効果的ではありません。開発プロセスにコードレビューを組み込みたいと考
えているアジャイルチームは、コードレビュー機能が内蔵された SCA ツールの導入を検討するべきです。これらのツールに
よって、非同期的なコードレビューを可能にする、シンプルな web ベースのピアレビューを容易に実行できるようになります。
このアプローチでは、特定の人々が決まった時間に会議室に集まり、コードレビューを行う必要がありません。代わりに、地
域やスケジュール、職位に関係なく、さまざまなチームメンバーが都合のいいときにコードをレビューし、評価を行うことが
できます。ピアコードレビュー機能にソースコード解析を組み合わせれば、コーディングの不具合を特定した上で、レビュアー
がそれらを確認し、コメントを書き、必要なアクションを割り当てることが可能です。
複雑なリファクタリングを簡素化
リファクタリングとはプログラムの動作を変えることなくコードを整理し、より簡潔なものにするプロセスですが、時間と手間が
かかり、特に C や C++ など頻繁に使用される言語での開発の場合は困難な作業となります。リファクタリングプロセスを自
動化するツールがないことで、リファクタリングを断念する開発者も少なくありません。しかし、コードリファクタリングを容易
にするプロセスを早い段階で実行することで、アジャイルチームに重要なメリットがもたらされることがよくあります。
「アジャイルマニフェスト」の著者の 1 人、マーティン・ファウラー氏は、リファクタリングはコードに対してささいな変更を行
うことだが、それが積み重なることで重要な結果が得られると書いています。リファクタリングは以下のようなエリアで効果を
発揮します。
»
変更への適応
継続的な変更はアジャイルの基本的な側面の 1 つです。開発プロセスの途中で頻繁にリファクタリングを行うよう
にすることで、コードが扱いやすくなり、チームはより効果的に変更に適応することができます。
»
不具合の検出
コードを簡素化し、全体的な設計を改善することで、コードはよりクリーンなものになります。クリーンなコードで
作業を行なえば、品質欠陥やセキュリティ脆弱性を容易に発見できます。また不具合の発見と修正にかかる時間
が短ければ短いほど、プロセスへの影響（開発者の仕事の妨害、テストチームの作業の停止、プロセス全体の
スピードの低下など）も少なくてすみます。
»
開発者の生産性
さまざまな人々が自分が作成したのではないコードに携わる、というのはよくあることです。リファクタリングを使
えば、コードの引き継ぎが容易に行えます。つまり、開発者は既存のコードのレビューや解釈、
「修正」にイテレー
ションを費やす代わりに、新しいコードの記述に集中的に時間を使うことができるというわけです。
チームがアジリティを実現する上で、リファクタリングが重要な役割を果たすことは明らかです。リファクタリング機能が装備さ
れた最新のソースコード解析ツールを使うことで、アジャイルチームはリファクタリングプロセスを自動化し、プロセスの複
雑化を緩和しつつ、リファクタリングのメリットを享受することができます。
Source Code Analysis in an Agile World | Klocwork White Paper | 6
真のアジリティの実現
バグ検出、コードレビュー、リファクタリングの機能を備えたソースコード解析技術をアジャイル開発サイクルに組み込むこと
で、開発チームはインフェーズのバグ封じ込めに対応できるだけでなく、本稿の最初で取り上げたアジャイルの基本原則を完
全に実現することが可能です。
バグをなくすことでセキュリティと信頼性を確保
ソフトウェアバグは非常に厄介な存在です。深刻なバグは下流工程での効率の低下、製品のリコール、フィールドでの障害と
いった問題を引き起こしかねません。ソースコード解析は、NULL ポインターの逆参照やメモリ管理の問題といったシステム
クラッシュにつながる不具合、あるいはバッファオーバーフローや無効なユーザインプットといったシステムをハッカーに狙わ
れやすくしてしまう問題など、コード内の深刻なバグを自動で検出します。製品出荷の前にこれらの問題を取り除いておくこと
は非常に重要であり、対応が早ければ早いほど効果的です。これによって、イテレーション内で深刻な問題が QA に渡される
ことや、イテレーション間で問題が移行することを防止できます。これらの問題の移行を止めることができなければ、バグのあ
るソフトウェアが出荷されるリスクが大幅に高まることになります。加えて、コードチェックインの前にバグの数を大きく削減で
きれば、メインのコードストリームがバグの影響を受けずにすみ、テスティングと QA プロセスが実行しやすくなります。発見・
報告されるバグの数が少なければ、テスト担当者はその分、機能やパフォーマンスを調べるテストに集中でき、製品を顧客
や市場に提供できる状態にすることが可能です。
バグをなくすための柔軟性
アジャイル環境で開発されたソフトウェアのテストと品質保証を適切に行うために、テスティングプロセスには、反復が可能で
あること、および頻繁に変わる要件に適応できることが求められます。すなわち、テスティングフェーズにはプログラミングバ
グに対応するための余地はほとんどないということです。QA でこれらのバグが発見された場合、開発サイクルに深刻な遅れ
が生じることになります。テスト担当者からバグの報告を受けた開発者は、今の仕事を中断して気持ちを切り換え、そのコード
を書いていたときに後戻りしなければなりません。開発者がバグのないコードをチェックインできるようになれば、チェックイン、
バグの検出、デバッグ、やり直しという時間のかかる「rinse and repeat（洗浄と繰り返し）」のサイクルを大幅に短縮するか、
もしくは完全になくしてしまうことが可能です。アジャイル環境で SCA ツールを利用することで、開発者は報告されたバグを
短時間で修正し、新しい核心的なソフトウェアの記述により多くの時間をかけることができます。すなわち、開発者は新規の開
発で作成したコードの信頼性とセキュリティを、統合ビルドを実行する前に柔軟に制御できるというわけです。
バグをなくすことで継続的な改善を実現
重要なのは、将来の開発の観点から見たイテレーションの進行状況がどうなっているかではありません。高品質コードに対す
る開発チームのコミットメントを測ることができなければ、ビルドやイテレーションごとにプロジェクトの下流リスクが蓄積して
しまうことになります。移り変わりが速く流動的な開発環境では、アジャイルチームは以下のような強力な自動測定機能を導
入する必要があります。
»
開発ビルドでのバグ修正率の測定・追跡
»
統合ビルドに漏出しているバグの特定
»
夜間ビルドの品質マイルストーン（もしくは継続的なビルドスケジュール以外の頻度）の設定
»
次第に改善しているチームまたはコンポーネントの追跡
これらの回答が得られることで、アジャイルチームは狙い通りの継続的改善プログラムを実施できることから、支援やトレーニ
ングが必要な箇所を瞬時に見極め、開発チームのメンバー全員がクリーンコードを統合ビルドにサブミットできるようになり
ます。イテレーションプランが適切かどうか、
またイテレーションの終了時に出荷可能な製品を提供できるかどうかを知るには、
ボトムアップ方式による品質の測定・追跡が不可欠です。
バグをなくすことでコラボレーションとコミュニケーションを強化
アジャイル開発における短期のイテレーションプロセスを成功させるには、持続的なコミュニケーションとチーム間のコラボ
レーションが必要です。これによって、遭遇する問題をただちに解決し、不要な遅延を招くことになる作業の重複を回避するこ
とができます。ソースコード解析ツールを利用することで、報告されるあらゆる問題を共同作業によって緩和することが可能
です。開発者やアーキテクト、その他のチームメンバーは報告された問題のステータスを変更したり、コメントを追加するこ
とができ、それらが他の開発者に自動で同期されるようになっています。この機能を利用することで、
さまざまなチームメンバー
が複雑な問題に共同で取り組むことができ、同じバグに対して何度も同じ作業を行わずにすみます。このような継続的な可視
性とデータおよびフィードバックの共有機能により、プロセスの早い段階で問題を緩和することが可能になります。
Source Code Analysis in an Agile World | Klocwork White Paper | 7
アジャイル開発のための Klocwork® ツール
総合的な静的解析エンジンを用いて、Klocwork は開発者がアジャイルと開発の速度を向上させることができるツール一式を
提供いたします。アジャイル開発の基本方針を次の方法によって弊社ツールがサポートします。
オンザフライなソースコード解析 – Klocwork Insight のデスクトップ解析は開発者にとっての「スペルチェック」のようなも
のです。コード作成時に、コードに混入してしまうセキュリティ上の脆弱性および重大な不具合に対して、即座に、正確か
つ継続的なフィードバックを提供します。コード作成段階において開発者の IDE 内で重大なコーディング上の問題点を浮
き彫りにすることで、開発ワークフローに不具合の修正作業を自然な形で取り入れ、チェックインするまでに、もっともセ
キュアで信頼性の高いコードが作成されていることを確実にします。このアプローチで、開発サイクルの最終段階で報告され
る問題点の数、そして開発者がソースに戻り問題を修正するために費やす時間の両方を削減します。こういった生産性におけ
るブーストはアジャイル環境において重要な要素です。
図 3 オンザフライなソースコー
ド解析により、開発者がチェッ
クイン前に、開発環境内で重大
なコーディング上の問題点を発
見・修正することができるよう
になります。
これにより、開発プ
ロセスの最終段階まで検出で
きない問題点のために再びソ
ースに戻り修正するために費
やす時間を削減できます。
共同コードレビュー – Klocwork Cahoots は、ピアレビュープロセスを簡略化するための柔軟性がある使いやすいコードレ
ビューツールです。他のコードレビューツールや従来の対人プロセスにおけるオーバーヘッドや複雑性を排除することで、
Klocwork Cahoots は開発チームがコードレビューを迅速かつ効果的に行うことができます。開発者は自分にとり重要である
コードレビューに参加、従い、コードがレビュー可能になると通知を受け取り、容易にコードの変更点を特定、それら変更点
に関するスレッド化されたディスカッションに参加、アクションの割り当て、潜在的な不具合のレビューをすることができます。
図 4 カスタマイズ可能なフィー
ド、無制限のウォール、およびリ
アルタイムの通知を活用して、
チェックイン前およびチェック
イン後のコードレビューを作
成・参加します。
Source Code Analysis in an Agile World | Klocwork White Paper | 8
ソフトウェアのメトリクスとレポーティング – Klocwork Review は 100 以上の客観的かつ実用的な製品指標からなる強力なメ
トリクススイートを提供します。これらの指標は、ソフトウェアコードから直接導き出されるものです（図 5 参照）。開発チー
ムのマネージャは、ドラッグアンドドロップのレポーティング機能を利用して、組織のソフトウェア開発プロセスに関する主要
な質問にすばやく簡単に回答することができます。たとえば、
アジャイルについての主要な質問には、バグが開発者のデスクトッ
プ上で発見・修正されているかどうかや、バグが統合ビルドに漏出していないかといったものがあります。Klocwork Review は、
どういったものがデスクトップ上で検出・修正されているのかという情報がソースストリームに伝搬されていない場合でも、そ
れらを自動的に集約します。この独自機能によって、チームはコードチェックインの前に行われるバグ削減処理についてより明
確に把握でき、不具合の封じ込めの成果をボトムアップで見ることが可能です。この機能に、個人、グループ、地域、コンポー
ネントなど、組織にとって意味のあるあらゆる属性ごとにメトリクスを設定することが可能なカスタムオーナーシップモデルを
組み合わせることによって、コードベース内の特にリスクの高い領域をイテレーションの早い段階で特定することができます。
図 5 Klocwork Review により
自動作成される充実したレポ
ート。
これによってアジャイルチ
ームは、デスクトップでのバグ
修正率を追跡しながら、統合ビ
ルドの状態を監視することがで
きます。
C/C++ の自動リファクタリング – アジャイル開発チームのベストプラクティスで推奨されているように、リファクタリングの目的は
クリーンで分かりやすく変更が容易なコードを記述することにあります。Klocwork Insight は、開発者がエディタから C/C++ コー
ドを抽象化し、理解可能で再利用できるコードに変えるための、強力なリファクタリング機能を提供します。つまり、開発者は
個別のビューやダイアログにアクセスしなくても、コードの状態をすばやく把握し、設計を改善することができるというわけです。
図 6 Klocwork Insight では、エ
ディタ内でリファクタリングオプ
ションが提供されることから、
個別のビューやダイアログにア
クセスしなくてもコード設計を
改善することが可能です。
Source Code Analysis in an Agile World | Klocwork White Paper | 9
まとめ
今日のソフトウェアの持つユビキタス性と、市場に出せる機能や製品をわずか数週間で開発しなければならないというプレッ
シャーにより、以下の 2 つの現象が生じています。
»
アジャイルソフトウェア開発原則の広範囲での採用
»
アジャイルチームにおける、開発プロジェクトの合理化とリスク軽減のために設計されたツールの採用
アジャイルチームによる導入が可能なツールの中でも特に重要なものとして、より高品質なコードの記述を支援するものが挙
げられます。ソースコード解析ツールを使えば、コードが統合ビルドやテスティングチームに送られる前に、大量のソフトウェ
アバグやセキュリティ脆弱性を開発者のデスクトップ上で、自動で検出することが可能です。これに共同ピアコードレビューを
組み合わせることで、リファクタリングが自動化されることから、コードの保全性が向上します。また、アジャイルチームはプ
ロジェクトの遅れを最小限に抑え、効率的な作業を行うことが可能です。開発者が革新的なコードの記述に集中的に取り組め
るようになる一方で、テスティングチームはありふれたコードの問題を見つけ出し何度も繰り返しテストを行うのではなく、プ
ロジェクトの機能の働きを調べるために時間を使うことができます。
品質の問題やセキュリティ脆弱性がプロセスに影響している、プロセスがアジャイルに対応していない、コードの保守が困難
であるといった場合には特に、アジャイルチームで SCA を利用することをお勧めします。アジャイル環境内でソースコード
解析を実行しても、混乱が生じることは一切ありません。まずは小規模から始め、小さなプロジェクトやプロジェクトの一部の
解析を行なうようにするといいでしょう。そうして得られた結果を、それらのツールを利用しなかった同じようなプロジェクトと
比較してみてください。アジャイル開発プロセスでソースコード解析を利用することで、時間とコストを大幅に削減できる機会
がもたらされることは間違いありません。
著者の紹介
トッド・ランドリーは Klocwork のシニアプロダクトマネージャであり、製品の方向性を見極め、それがお客様の望む開発プ
ロセスに合ったものであることを確認する役割を担っています。ソフトウェア製品管理分野で 12 年以上の経験を持ち、これま
でに多数のアジャイルチームおよびプロジェクトに携わってきました。ランドリーはプロフェッショナルエンジニアであり、認
定スクラムプロダクトオーナーの資格を持っています。
Klocwork について
Klocwork® はデベロッパーがより安全で信頼性の高いソフトウェアを作成するのに役立ちます。弊社のツールはソースコー
ドをオンザフライで解析し、ピアコードレビューを簡素化し、複雑なソフトウェアの寿命を延ばします。モバイル機器、家庭
用電化製品、医療技術、通信、自動車、軍事、航空宇宙部門の最大ブランドを含む 1100 社を超えるカスタマーが、既に
Klocwork を自社のソフトウェア開発プロセスの一部に組み込んでいます。数多くのソフトウェア開発者、設計者、そして開発
マネージャーが弊社ツールを日々活用して、生産性を高めると同時によりよいソフトウェアの開発を行っています。詳細に関し
ては、www.klocwork.com または [email protected] にて Klocwork までお問い合わせください。
米国：
15 New England Executive Park
Burlington, MA 01803
© Klocwork Inc. All rights reserved.
カナダ：
30 Edgewater Street, Suite 114
Ottawa, ON K2L 1V
t: 1.866.556.2967
f: 613.836.9088
WWW.KLOCWORK.COM

Download Report