はじめに

ソフトウェアの品質を上げることは、ソフトウェア開発現場では常に存在する課題です。
V字プロセスにおいても、各工程で不具合が作りこまれる可能性があります。どの工程の不具合でも、作りこまれた工程で発見・修正を行うことが理想的です。後工程で発見・修正となると、手戻りが発生し、納期遅れのリスクも高まります。
品質に関する課題にはさまざまな課題がありますが、本稿では、「コーディング工程で作りこまれる不具合」に着目し、品質を向上させるための方法、品質向上に役立つツールをご紹介します。

コードレビュー

「コーディング工程での不具合」を発見・除去する方法として、コードレビューという手法がよく用いられます。コードレビューとは、ソースコード中の誤りを検出・修正するために、プログラムを実際に動作させることなくソースコードの体系的な検査を行う技術です。コードレビューを取り上げる理由は以下の2つです。

• 単体テストと比較して費用対効果が高い
• 手順やツールが成熟していて導入しやすい

コードレビューを行い、コーディング工程で作りこまれた不具合をいち早く検出・修正することで、下流工程（単体テスト、結合テスト…）からの手戻りを減らし、開発の効率化を図ることができます。
しかし、レビューを行うことにも、いくつか課題があります。
昨今の規模が大きくなっているソフトウェアをすべてレビューすることは時間がかかります。また、レビューを行う人のスキル・経験によって、レビュー結果にばらつきが出ることがあります。
このような問題点を解決するためには、コーディングガイドラインを策定、もしくは、既存のコーディングガイドラインを利用することが一つの手段となります。
また、安定なコードレビューをするための手段の一つとして、静的解析ツールを利用する方法もあります。
静的解析とは、コードを実行することなく、解析を行うことです。
ツールを利用することで、客観的に収集した情報を用いて、統計的に分析することができ、品質の良し悪しを判断する基準を作ることができます。

静的解析ツールの特徴

当社では、C言語用静的解析ツール：QA・C、C++言語用静的解析ツール：QA・C++ を取り扱っています。
以下に、これらのツールの特徴をあげます。

1300個のチェック観点

ソースコードの中には、次に示すような不安を抱えるコードが数多く存在します。

（1）

明らかに問題を起こすコード配列の領域外アクセス など

（2）

意図して書かれているかどうかをレビューする必要があるコード
if文内に記述された代入式 など

（3）

現時点では問題を起こさないが、デグレードを起こしやすいコード
外側のスコープの変数を無効にしている変数 など

（4）

ISO C/C++言語仕様の中で、動作が保証されていないコード
同一の式内で何度も読み書きされている変数 など

QA·C/QA·C++は、これらすべての種類のコードを検出するために、「約1300個」のチェック観点を備えています。
豊富なチェック観点を備えることで、コードの改善活動を全般的にカバーすることができます。

• 観点（1）を用いて、重大な問題を早期に検出する
• 観点（2）を用いて、重点的にレビューする箇所を簡単に抽出する
• 観点（3）を用いて、将来的な保守の負担を軽減する
• 観点（4）を用いて、一見して気づきにくい問題を簡単に抽出する

可読性強化のためのチェック機能

何らかのルールが定められていない状態で、コーディングをしてしまうと、ソースコードの記述スタイルが、開発者ごとにまちまちになってしまいます。
このような状態で開発されたソースコードは、非常に読みにくくなり、

• 似通った名称の変数（例:var1とvar2）を扱っている箇所で、両者を取り違えていた。
• if 文にかかっていると思っていた文が、if文にかかっていなかった。

などの問題を発生させる恐れがあります。また、機能変更や不具合修正をする際に、既存の処理フローを誤解した結果、新たな不具合を作りこんでしまう可能性もあります。
QA·C/QA·C++は、このような可読性に関する問題を検出するための「可読性チェック機能」を備えています。
可読性チェック機能を用いることで、

• 紛らわしい名称の変数や関数が使用されている箇所
• インデントの付け方が統一されていない箇所
• 演算の優先順位が明確でない箇所
• 命名規約に違反している箇所

などを特定することができます。
これらの箇所を早期に検出し、後工程に持ち込まないよういすることで、ソースコードの読みにくさに起因する問題を解消し、コードレビューやテストをより効率的に実施することができます。

可搬性（移植性）チェック機能

通常、C/C++コンパイラはISO C/C++準拠の機能に加えて、コンパイラ独自の拡張機能も備えています。
このような拡張機能は、開発者が意識せずに使用していることもあり、移植性を大きく損ねることがあります。
また、開発者が拡張機能を十分に避けてISO C/C++準拠のソースコードを記述していたとしても、それだけで移植性の高いコードが書けるわけではありません。 ISO C/C++には、処理系の自由度を高めるために、次のようなコードの振る舞いを処理系で決定して良いものとしています。

• char型をsigned char型とunsigned char型のどちらで表現するか。
• 整数除算の余りを正の数と負の数のどちらで表現するか。

など
これらは残念ながら移植性が保証されていないため、可搬性（移植性）を損なうコード
になります。
QA·C/QA·C++は、このような移植性に関する問題を検出するための「可搬性 （移植性）チェック機能」を備えています。
移植性チェック機能を用いることで、

• ISO C/C++に準拠していないコンパイラ独自の機能を使用している箇所
• ISO C/C++に準拠しているがコンパイラによって動作が異なる箇所

を特定することができます。
これらの箇所を早期に検出することにより、移植時の生産性を上げるとともに、信頼性の高いコードを記述することができます。

メトリクス計測

例えば人の場合、健康状態をより正確に把握するためには、「γ-GTP」などの「客観的な指標」を計測する必要があります。ソフトウェアの場合も、品質を正確に把握するための「客観的な指標」 として、「関数の行数」や「関数内の分岐の数」などがあります。
これらはメトリクスと呼ばれます。 メトリクスを計測 /分析することで、ソフトウェアの弱点をより具体的に、かつ正確に把握することができます。
その結果、品質改善のための指針を得ることができます。
QA·C/QA·C++では、以下のようなメトリクスを計測できます。以下のような代表的なメトリクスをはじめ、様々な観点からソフトウェアを数値化します。（QA·C：69 種類、QA·C++：26種類）

MISRA コンプライアンスモジュール

アドオンツールであるMISRAコンプライアンスモジュールを用いることで、ソースコードがMISRA-C/MISRA-C++コーディングガイドラインに適合しているか評価することができます。
MISRA-Cコーディングガイドラインに対応したQA·CのオプションとしてQA・MISRAを用意しております。
MISRA-C/MISRA-C++は自動車業界ではデファクトスタンダードとして使用されているコーディングガイドラインです。近年では、車載用のソースコードのみならず、様々なソースコードのコーディングガイドラインとして採用されています。MISRA-C/MISRA-C++のような実績があるコーディングガイドラインを利用することも、品質向上のための有効な方法となります。

Webベースコード支援レビューツール：QA Verify

QA·C/QA·C++の解析結果を統合管理し、レビュー情報や修正方法の情報をWebベースで共有することで、インタラクティブなコードレビューの実現手段を提供します。
また、過去から現在までのプロジェクト品質の推移を見える化する手段も提供します。
QA･Verify を使用することで今まで以上に効果的なコードレビュープロセスを実施できます。

おわりに

今回は、静的解析ツールに関してご紹介させていただきました。当社では、今後も静的解析ツールをはじめとしたソフトウェア開発支援ツールをご紹介してまいります。