目視のコードレビューまかせにしない！静的解析ツール「Axivion Suite」で業界最高水準のソフトウェア品質を担保

2023/08/30 12:00

　今やあらゆるものがソフトウェアで制御される時代。こうしたソフトウェアの中には、自動車や医療機器など、不具合を起こすと人の命に関わるものもある。そのような状況の中、「ソフトウェア品質の向上」への開発者の関心は、これまでにないほど高まっている。ソフトウェア品質が低下してしまう原因にはどのようなものがあり、どんな対策をすればいいのか。静的解析ツール「Axivion Suite（アクシビオン・スイート）」など、ソフトウェア品質に関連するプロダクトを提供するQt Groupの小幡剛士氏、平井幹生氏に聞いた。

UIフレームワークだけじゃない！ソフトウェア品質もサポートするQt

　「ソフトウェアにバグが多い」「複雑過ぎて読み解くのが困難」「メンテナンス性が悪い」など、ソフトウェア品質に課題を感じている開発者も多い。そんな課題をかかえる開発プロジェクトを支援するソリューションを提供しているのがQt Group（以下、Qt）である。

　Qtと言えば、C++アプリケーションのUIフレームワークを提供しているイメージを持つ方も多いだろう。だが、同社は2021年4月、GUIの動的テストツールを提供する froglogic GmbH社を買収。翌2022年8月には、静的解析ツール「Axivion Suite」を提供するAxivion GmbH社を買収した。

　「Qtはアプリケーション開発フレームワークから品質改善、テスト自動化まで製品ポートフォリオを拡げ、ソフトウェアの開発サイクル全体を一気通貫でサポートし、開発効率と品質を向上させることをミッションに事業を展開しています」と、QtでAxivion Suiteの営業活動に携わる、シニアアカウントマネージャーの小幡剛士氏は説明する。

　Axivionは、ソフトウェアがそのライフサイクルの中で開発や修正が加えられていくことでもたらされる不利益について、過去15年以上にわたり研究していたドイツ・シュトゥットガルト大学の研究チームが、そのアイデアを基にスピンアウトとして設立された企業である。「ヨーロッパではボッシュやシーメンスなど、ソースコードの安全性や妥当性への担保が必要とされる大手企業が導入していることからもわかるように、非常に信頼されているソリューションです」（小幡氏）

ソフトウェア品質が劣化してしまう6つの要因

　一般的に静的解析ツールは、クリティカルな不具合をピンポイントで検出するなど、即効性にフォーカスしたものが多い。Axivion Suiteはそれだけではなく「ソフトウェアの劣化」を防ぐことをミッションに掲げている。なぜならソフトウェアは時間の経過とともに、ビジネス要件から求められる機能の追加や、ソースコードの修正などが繰り返されることで、どうしても複雑度が上がり、品質が劣化してしまうからだ。

　品質が劣化してしまう要因は「大きく6つに分類できる」とソリューションエンジニアの平井幹生氏は言う。

　第一の要因は「アーキテクチャ違反／隠れ依存性」。これはアーキテクチャ仕様に定義されているソフトウェアコンポーネントの依存関係と、実際に実装されている依存関係が一致していなかったり、仕様にない依存性（隠れ依存性）がソースコードに存在していたりする状態を言う。これの何が問題なのか。アーキテクチャ違反や隠れ依存性があると、ソースコードを理解するときに、毎回コードを読まなければならず、新規の変更や不具合の修正を計画する際に、影響箇所の検討などが難しくなるという問題があるからだ。

　第二の要因が「コードクローン」。似たようなソースコードが同じプロジェクトの中に複数存在する状態のことを指す。コードクローンは、既に動いているコードをコピー＆ペーストして使ってしまうことで起こるという。「コピー元のコードにバグがあれば、そのバグが拡散され、それらのバグを修正しなければなりません。バグ修正に工数がかかることに加え、どこにクローンがあるか分からない状態になると、バグが残ったままになってしまうという問題が生じます」（平井氏）。

　第三の要因が「メトリクス違反」。メトリクスはソースコードの複雑性を定量的に把握するための方法だ。例えば1つの関数内のソースコードの行数などを測ることもその一つだ。例えば関数内の行数を150行以下に抑えるなど、測定対象と閾値を適切に設定してモニタリングすることで、ソフトウェアの劣化が防げる。

　第四の要因が「スタイル違反」。これはMISRA（Motor Industry Software Reliability Association）やAUTOSAR C++などの業界で定義されているコーディングスタイルや、プロジェクト独自のコーディングルールに対して違反するコードを指す。「CやC++は、開発者のスキルが如実にコードに表れる傾向があり、ミスしたときの影響も大きいです。プロジェクトで従うコーディングスタイルを決めてしまうことで、コード品質を底上げすることができます」と平井氏は説明する。

　第五の要因は「デッドコード」。文字通り、死んでいる＝使用されていないコードのことを指す。単純に動くべきコードが動いていないのは単純なバグだが、「問題はそれだけではない」と平井氏は指摘する。

　開発者はソースコードを読むのに多くの時間をかけている。研究結果によると「作業の40％は自分で書いたコードを読むのに使っている」と報告されているという^[1] 。デッドコードを読む時間はもちろん、デッドコードに対して単体テストを記述する工数も無駄である。それだけではない。意外と見過ごされているのが、他の部分が進化することでデッドコードが復活してかみ合わなくなり、新たなバグになってしまうこと。デッドコードには復活のリスクもある。

　[1] 参照：Zelkowitz et al (1979), Eastwood (1993), Marliss, Ben-Menache (1997), Erlikh (2000)

　第六の要因が「循環依存性」。これは依存関係が循環している状態を指す。例えば関数Aが関数Bをコールし、関数Bも関数Aをコールしたり、関数Bがコールする関数Cが、関数Aをコールしていたりするようなケースである。環境依存性のあるコードは無限ループのリスクがあるだけではなく、読むのも大変で、必然的に時間もかかってしまう。

　ではこれらの要因をなくし、ソフトウェア品質を保つために開発の現場ではどういった対策がとられているのか。現在、多くの開発現場で行われている手段は、「目視でのコードレビューです」と平井氏は言う。

　Axivion Suiteは、これら6つの要因に加え、他のテストでは発見が難しいバッファオーバーフローやリソースリークといったランタイムエラーを検出します。

Axivion Suiteの事例を公開中

　Axivion Suiteは、世界的な大企業で広く採用されています。以下より、自動車関連、エレクトロニクス、医療業界の4社の事例をまとめたPDFをダウンロードいただけます。ぜひご覧ください！

Axivion Suite 事例集

コードレビューやリファクタリングの落とし穴とは？

　しかし、目視のコードレビューにも問題がある。一つは人力で行うので工数がかかること。そして正確性に劣ることだ。

　特に急ぎの案件では、ルールチェックに時間をかけられず、おざなりになってしまうこともある。「人間関係の問題も絡んでくる」と平井氏。前職で車載システムのアプリケーション開発に従事していた平井氏は、「例えばチーム内でコードレビューをする際、先輩のコードに指摘をするのには、心理的抵抗感も生まれやすいのでは」と言う。

　もう一つの方法として挙げられるのがリファクタリングだ。だがリファクタリングにも課題がある。リファクタリングはソースコードの挙動を変えずに内部構造を整理することだが、「その作業もやっぱり時間がかかり、大変。それに、大規模なリファクタリングには新たな不具合を作りこむリスクもあります」と平井氏は言う。小幡氏も「時間がなくて、そこまで手が回わらないことが多い。また意思決定者の視点でも、リファクタリングは機能追加やバージョンアップなどのような、市場に対して魅力を提供するものでもないので、どうしても後回しにしがち」だと付け加える。リファクタリングも手直しの作業なので、さらに不具合を作り込んでしまうリスクもある。年数を経たコードだと複雑すぎて、リファクタリングに手を付けられない場合もある。

Axivion Suiteでコードレビューとリファクタリングを自動化

　これまで挙げたようなソフトウェアの劣化を防ぎ、長期間にわたって健康的なソースコードを保てるようにするのが、Axivion Suiteである。Axivion Suiteを使用すると、これまで目視で行っていた確認を自動化できるようになる。

　検知された問題はWebブラウザベースのAxivionのGUI上で確認される。ソースコードの変更によって新しく追加された問題が表示され、さらに誰がいつその問題を作り込んだのか、誰がいつその問題を直したのかなども見ることができる。

　一般的な静的解析ツールとの大きな違いは、検知された問題の差分のみを表示できることだ。他のツールは一度解析にかけると、大量の問題が表示され、どこから対処すればよいのかわからなくなることも多い。

　だがAxivion Suiteなら、「この時点で追加したもの」というように時間軸を絞って確認できるという。Axivion SuiteはVisual StudioやVisual Studio Code、EclipseなどのIDEのプラグインを提供しており、IDEと統合することもできる。これを使うとローカルのIDE上で開発者自身が解析を実行できるようになる。

Axivion SuiteのCI（継続的インテグレーション）への連携例。解析結果はWeb画面のほか、IDEでも確認ができる

　よって、まず各開発者がローカルにおいて自身がコーディングした範囲の解析を実行し、問題がないかどうか確認する。問題がなければ全体のリポジトリにプッシュして、システム全体としてAxivion Suiteで解析する。そこで問題があれば再度ローカルに戻し、各開発者が修正を行うという運用方法を採れるようになる。これにより、毎回毎回すべての開発者のコードが揃うまで解析を実行することができない、ということもなくなり開発効率が向上する。解析結果のレポートはPDFやCSV、Excelなどさまざまな形式で出力できる。

　またAxivion Suiteは、Gravis（グラビス）というアーキテクチャモデリングツールを提供していることも大きな違いといえよう。そのツールを使ってソースコードからアーキテクチャモデルを作ることで、変更要求がでた際に、影響の検討と変更の反映を計画。エンジニアはそれを見て実装し、最後に実装結果がアーキテクチャモデルと一致しているかを自動チェックできるようになる。こうすることで「あるべきアーキテクチャ」と「実装されたコード」が常に一致した状態となるので、アーキテクチャモデルを基にしたソフトウェア変更の計画やソフトウェアの理解が容易になる。アーキテクチャ違反が防げるわけだ。

Axivion Suiteが提供するアーキテクチャモデリングツール「Gravis」を使用することで、アーキテクチャの作成とソースコードへのマッピングが可能になる

　メトリクス違反であれば、Axivion SuiteならHIS（Hersteller Initiative Software）で推奨されているメトリクスやオブジェクト指向のメトリクスなども自動でチェックでき、違反があればすぐ修正可能だ。スタイル違反についても、Axivion Suiteならスタイルを設定することで、違反を自動でチェックする。開発者のスキルを平準化し、コード品質を高い水準で担保できるようになる。

Axivion Suiteの事例を公開中

Axivion Suite 事例集

各業界のソフトウェア安全基準に積極的に対応、機能安全プロジェクトにも使用可能

　Axivion Suiteは開発現場でどのように活用されているのか。「基本的にCIシステムと統合して使用されることが多い」と平井氏は語る。CIシステムと統合することで、頻繁に解析を行い、問題が検知され、都度、対応していくことができるようになる。つまり開発プロセスの中にリファクタリングのフローを組み込むことが可能になるというわけだ。さらにGUI自動テストも組み込むと、ソースコードに変更が入るたびに、ソースコードの品質確認が自動で行えるようになるという。

　Axivion Suiteが対応している開発言語は、C／C++、C#、QML（QMLはQtのGUIを記述する言語）。これらの言語を使っている企業はもちろんだが、業界別に見てフィットするのは「ソフトウェアの品質について長期間の担保が求められる企業」と小幡氏は話す。いくつか例を挙げると、ファクトリーオートメーション、自動車関連、防衛など、そのライフサイクル自体が長い製品を開発する企業などだ。

　またソフトウェアをクリーンに保つために、AUTOSAR、MISRA、ISOなど、様々な業界のコーディング規約に沿ったソフトウェアを開発しなければならない業界、例えば医療や自動車、防衛産業に携わる企業にもAxivion Suiteは大きな効果をもたらすことが期待できる。

　Axivion Suiteは、ISO 26262（自動車）、EN 50128やEN 50657（鉄道）、IEC 62304（医療）など各安全基準において最高レベルまで認証を受けており、機能安全プロジェクトにも使用可能だ。

　例えばAxivion Suiteは、ドイツの大手医療機器メーカー、シーメンス・ヘルシニアでも導入されている。

　シーメンス・ヘルシニアでは世界中の拠点において開発を行っており、使う言語や習慣、時間帯の異なる開発者の間で、IEC 62304 など様々な規約に準拠したソフトウェアを開発する必要があった。例えば設計はドイツ、開発はインドで行われるようなケースでは、やり取りは英語で行うが、いずれもネイティブではないこと、しかも遠隔なのでコミュニケーションに齟齬が生じることが多かったという。そこでAxivion Suiteを導入。Axivion Suiteにより独自のコーディングルールや品質の閾値（チェッカー）を共有、また、実際のソースコードが設計とあっているかを機械的にチェックできるようなり、コミュニケーションも円滑に進むようになったという。また、Axivion Suiteは異なる開発環境でも統合が容易であり、これも開発効率の向上に貢献したという。

　またドイツの自動車部品メーカー、シェフラーは、ISO 26262に対応する工数を大幅に削減するため、Axivion Suiteを導入した。シェフラーでは従来はFFI（Freedom From Interference）の確認は目視で行っていたが、現在はAxivion Suiteでチェックを自動化している。Axivion Suiteから得られたフィードバックにより、開発者自身が自分のミスを把握できるようになったことに加え、全体のアーキテクチャを考えて設計するようになったので、「開発者のスキルも向上した」と平井氏は説明する。