デブサミ2011セッションレポート（AD）

デブサミ2011レポート
ソースコード品質、大丈夫ですか？～静的検証のススメ～

2011/03/18 14:00

　プログラムの大規模化や高機能化が進み、開発の現場では第三者が作成したソースコードも利用するケースが増えている。その中には外部委託分や、誰が書いたのか不明になっているコードまでも含まれ、品質保証の責任範囲も広範かつ重大になっている。また、オープンソースの利用に対しては「ライセンス違反」のリスクにも対処していかなければならない。本セッションでは、日立ソリューションズがソフトウェア開発を取り巻く諸問題に対して、ソースコードの品質を高めるためのポイントなどを、アウトソーシングのサービスを含めて紹介した。

株式会社日立ソリューションズデジタルメディアソリューション本部
デジタルメディア第1部主任技師田邊照雄氏

機能するコーディングルールの策定でバグ作り込みを防止

　何故、ソースコードにバグを作り込むのか。日立ソリューションズの田邊照雄氏が要因として挙げたのは、言語に認められている自由度と、言語仕様の理解不足の問題だ。一つの実装に様々なロジックが考えられ、一つのロジックに対し色々な書き方ができる。また文法など言語仕様を一通り学んでいても、コンパイラの処理系定義の動作等まで理解しているエンジニアは多くない。

　そこでコーディングルールを策定し、開発を標準化する試みが行われている。田邊氏が紹介したルール作成のポイントはまず、既存のものをベースにすることだ。たとえばESCR「組込みソフトウェア向けコーディング作法ガイド」が有用だ。また、身近なプロジェクトで作成されたものも参考にするのもいい。ただし、ルール数は必要最小限にする。またルールの目的、ルールからの逸脱時のリスクを明確にしておくことだ。

図：さまざまなコーディングルール

静的検証ツールとレビューを有効化するポイントとは

　ただ、機能するコーディングルールを策定しても、作り手のミスをすべて防ぐことはできない。そこで機械的にチェックアウトするため、ツールを使うと効果的だ。

　ではツール選定時のポイントは何か。まずカバーしている言語とチェック項目が必要条件を満たしているか。一方で、自分たちにとっては不具合では無いのに、ツールが指摘するノイズの量も確認したい。さらにルールのカスタマイズが可能か、品質のデータ（バグ率など）の取得が可能かなどは副次的な要素だが、検討のポイントになる。

　チェックツール運用時のポイントとして田邊氏が挙げるのは、どの工程からやるのか、適用頻度、ツールの指摘への対処の方針を定めること。また運用の体制、過去の資産（母体のソース）をどう扱うかも決めておく必要がある。

　自身の組織や契約条件などにより有用であると判断すれば、アウトソーシングサービスを利用してもいい。日立ソリューションズのソースコード検証サービスInspectProは、顧客のソースプログラムを独自の高精度なツールにより全パス組み合わせをチェックし、セキュリティや信頼性について解析する。加えて日立ソリューションズの専門アナリストが一件ずつ検討し、本当に修正が必要な不具合をレポートする。

　そうしたツールによる検証と同時に品質向上に寄与するのが、開発メンバーが集まってのピアレビューだ。ここでは統一されたプロセスを確立することがポイントになる。まずレビューの目的、範囲を明確化する。レビュー後に効果を統計分析し、プロセス改善に生かすことが望ましい。

　日立ソリューションズでは組織レベルで目標を設定しており、例えばレビュー速度とか指定密度、レビュー前倒し指摘率、レビュー効率について目標を設定している。「欠陥を見つけることは良いことだ、という意識で参加者のモチベーションを上げるよう仕向けることが大切で、責任追及や犯人捜しは避けなければならない」（田邊氏）。