2010年11月17日、コベリティは「2010年度オープンソース品質評価レポート」の結果や、12月に出荷するソースコード解析ツール「Coverity 5.3」などの発表を行った。CodeZineでは、来日した米Coverity CEOのセス・ハレム（Seth Hallem）氏にインタビューを行い、オープンソースソフトウェア（OSS）の品質調査プロジェクト「Scan Project」の現状や、ソフトウェア開発のトレンドと課題、そしてCoverity 5.3をはじめとする同社の今後の展開について聞いた。
複雑化するソフトウェア開発と開発者にかかる品質への責任
ソースコードの解析ツールなど、ソフトウェア開発支援を行うコベリティ。同社は米国でLinux、Apache、Androidといった人気の高いオープンソースソフトウェア（OSS）プロジェクトの品質を無償で評価し、情報提供を行う品質調査プロジェクト「Scan Project」を展開している。このプロジェクトは、米国国土安全保障省の資金提供のもと、2006年にスタンフォード大学との協業により発足したものだ。
ハレム氏は、Scan Projectの目標は2つあるとし「1つは、オープンソースの品質をさらに改善するメカニズムを提供することです。というのは、今ではオープンソース自体が重要なアプリケーションやインフラなどで頻繁に使われるようになっているからです。もう一つは、（ソースコードの）静的解析の研究を継続するためです。これまで291のOSSプロジェクトを解析し、各OSSコミュニティ側で解決したバグの数は12,000件を超えます」と、趣旨と成果について語った。
ハレム氏は、ソフトウェア開発で目立ってきたトレンドとして、ソフトウェアのサプライチェーンの複雑化について挙げた。スマートフォン1台のソフトウェアを考えてみても、Broadcom社 やQualcomm社のような半導体チップメーカーの部品、AndroidやLinuxなどのOS、NOKIAやMotorolaといったデバイスメーカーが独自に開発したものなどが含まれる。これらに加え、開発者が作ったアプリケーションが入った上で消費者に提供される。さらにそのアプリケーションは、クラウドコンピューティングのように、端末以外の要素とも関わるようになっている。
「これまで開発者は、自分たちが作ったソースコードだけの品質を見ていればよかったのかもしれません。しかし、もはやそれだけでは十分ではなく、それぞれ異なるソフトウェアのコンポーネントがどのような相互作用をするのかなど、全体の仕組みを把握したうえで、品質のテストをしなければならなくなってきました」とハレム氏は語る。
ハレム氏は、複雑化だけでなく、熾烈な市場競争による開発サイクルの短縮も1つのトレンドとなっているとし、こうした流れの中、開発者にはより多くの品質に対する責任が生じるようになっていると語る。
「ソフトウェアがさらに複雑になると、システム全体をテストすることが難しくなります。ですから、開発者は、早い段階で各コンポーネントをテストしなければならないのです。Scan Projectの結果を見ると、OSSのコードで直面する課題に大きな変化はなく、トレンドと関係なく人為的なミスが最も大きいことが分かります。この課題を未然に解消するための開発ツールやテストの自動化の必要性が今後も高まると考えています」とハレム氏は説明した。
今回発表された「2010年度オープンソース品質評価レポート」では、調査したOSSで見つかった11,201のバグの45%が、メモリ破損や、リソース・リーク、未初期化変数など高リスクであるとしている。こうしたバグは、セキュリティ違反やシステムのクラッシュ、データ破損など、安全上の問題を生じる可能性がある。OSSを活用するなど、開発元の異なるソフトウェアコンポーネントから構成される製品を提供する企業、業界からは、OSSに対する可視性が求められるようになっているという。
こうした背景から、同社では、Scan Projectの結果をOSSの開発者だけでなく、開発者に一定の調査期間を与えた上で、一般にも公開する予定だ。無修正のまま放置されているバグの修正を促進するとともに、OSSを活用する開発者には、品質の可視性を提供し、ソフトウェアの完全性向上を推進するのが狙いだ。
OSSの品質を見極め、製品の完全性を向上する「Coverity 5.3」
では、同社が提供する静的解析ツールは、競合製品と比べてどういった優位性があるのだろうか。ハレム氏に聞くと、「私たちは、継続的に技術革新を図り続けています。まず大きな違いは、高精度の解析技術です。深刻な不具合をピンポイントで検出しますし、誤検出率も業界で一番低いです。次に、不具合やバグがビジネスにどう影響を及ぼすかの洞察も、コード間の相互関係を理解して解析を行うことができるのも競合他社製品との大きな違いです。例えば、複数のバージョンでコードが共通だったり、複数の製品間で共通のコードがあったりする場合に、あるコードでバグがあると、それによって製品のどこに影響が及ぶのかを開発者に伝えることができます」と説明した。
Coverityの解析ツールでは、Scan Projectや1,000以上の顧客をサポートしてきた経験を踏まえ、バグの程度を高リスク、中リスク、低リスクといった形で分類して開発者に示すことができるため、開発者は修正の優先順位をつけることができる。また、解析ツール自体が開発環境に統合化できるというメリットもあるという。これまで80の異なる開発環境をサポートし、最新バージョンであるCoverity 5.3では、Androidプラットフォームの開発環境も新たにサポートできるようになった。他にも、Visual Studio 2010／.NET 4のサポート、Androidアプリ開発のサポート、Javaの解析機能の拡充なども行われている（開発言語はC、C++、Java、C#の4つに対応）。
続けてハレム氏は、最新バージョンの特長として、品質を可視化できるオープンソース品質評価レポート（Coverity Software Integrity Report）の出力機能を挙げ、「この機能により、開発者は、コードの品質をスナップショット的にただちに見ることができ、またコードにまつわるリスクがどこにあるのか、それを見極めることができます。例えば、サードパーティから入手できるコードが、自分たちの製品に組込むに値する品質を満たしているかどうかを見極めることができます。また、バグ密度などに関して特定のコードが業界の標準より下回っているか、上回っているかといったベンチマーキングツールとして使うこともできます」と解説した。
オープンソース品質評価レポートをAndroidカーネル（2.6.32「Froyo」）に対して適用した結果は「2010年度オープンソース品質評価レポート」にも記されている。このレポートでは、Android固有のソースコードのバグ密度が、基になったLinuxカーネル・コンポーネントと比較して2倍であったとしている。Androidカーネルのバグ密度は、業界平均値（1,000行あたり1つのバグ）よりも低いことが判明したが、解析対象となった端末「HTC Droid Incredible」では359件のバグが検出され、そのうち高リスクなものは88件であった。このことから、高リスクなバグを伴ったAndroid端末が出荷されている可能性が少なからずある。
ハレム氏はまず「Androidカーネルの解析過程で驚いたのは、Googleやデバイスメーカーだけでなく、多くの人々が貢献していることです。非常に数多くの半導体メーカーやOSF（オープンソースファウンデーション）が貢献しているのです」と説明した。
また、「Androidは、Linuxと比較して特異的な問題・不具合が高いことも分かりました。これは2006年度のScan Project発足時より、Linux開発者が弊社製品の解析結果をもとにバグを検出、修正してきた経緯を考慮すると当然です。一方、今回Androidで検出されたバグは、Linuxと同様に静的解析で検出可能で、恐らく開発者が開発早期段階で検出、修正したいであろうバグとも言えると思います」と見解を述べている。
Androidプラットフォームにおいても他のOSSと同様に、責任の所在を明確にしにくいため、品質の可視性が重要であるという主張だ。
なお、Androidの解析結果は、GoogleとHTCに対して情報提供を行った60日後に詳細な結果を公表し、再テストしたレポートも発表する予定だ。
最後に、今回の発表の総括として、デバイスメーカーなど、ソフトウェア開発社向けのメッセージをいただいた。
「最終製品の品質やユーザーのブランドに対する評判は、自社で開発したコードだけでなく、複数の調達元から納品されたコードの品質にも依存します。私たちの製品を使うことで、さまざまなコードの品質をしっかり検証できるメリットを知っていただきたいです」
なお、オープンソース品質評価レポートと同様の分析を、自社製品に対して行える試用の申し込みもコベリティ社のWebページから受け付けている。
