「組み込みソフトウェア開発におけるソースコード品質評価のススメ」

１．はじめに

　組み込みソフトウェア開発の現場では、ソフトウェアの大規模/複雑化、短納期化が進んでいます。
　多くの現場では、過酷な状況の中で、いかにソフトウェア品質を改善していくかが課題となっています。
　改善活動を進めていく上で「どのように成果物を改変するか」という改善の中身が重要なことは言うまでもありません。加えて、筆者は改善前後に実施する「品質評価」も同様に重要だと考えています。
　本稿では、「ソフトウェア品質」の定義を紹介した上で、「品質評価」の重要性と、数多くの成果物の中で何を評価すれば良いのか、という点について考察していきます。

２．ソフトウェアの品質

　ISO/IEC9126-1では、以下のように6つの品質特性と27の品質副特性でソフトウェアの品質を定義しています。

表 1 ISO/IEC9126-1で定義されているソフトウェア品質モデル

　「ソフトウェアの品質」というと「機能性」や「信頼性」といった、いわば「製品利用者視点の品質」をイメージする方が多いのではないでしょうか。ISO/IEC9126-1では、「製品利用者視点の品質」だけでなく「保守性」や「移植性」といった、いわば「開発者視点の品質」も含んでいる点が特徴的です。
　かつてのように小規模なソフトウェアを少人数で開発することが主流だったときには、「開発者視点の品質」をそれほど意識する必要はなかったのかもしれません。そのため、「ソフトウェア品質＝製品利用者視点の品質」という認識でも問題はなかったでしょう。しかし、既存ソフトウェア成果物の活用が一般的になり「開発者視点の品質」の重要性が高まってきている昨今では、品質特性を網羅的に正しく評価することが求められます。

３． 改善に向けた品質評価の重要性

　次に、品質改善のために品質評価がなぜ重要なのかを考察していきます。
　「改善」や「リファクタリング」というキーワードが飛び交う現場では、どうしてもその実践に注目が集まります。皆さんも「開発者個人の気になっている箇所だけをスポット的に修正する」、「変更してみたものの何がどの程度良くなったかがわからない」といった経験はありませんか。
　このように、問題の分析や改善の評価が手薄なままで、改善活動はうまくいくでしょうか。
　まず、品質の観点でどのような問題があるかを把握しないまま手をいれても、変更後にどのように品質が改善されたかがわかりません。
　 さらに、品質上の問題ではない箇所を変更するといった無駄な作業が発生する可能性もあります。
　 問題の分析や改善の評価を怠ると、残念ながら改善活動としては失敗するリスクが高くなります。

　では、失敗しないために必要なことは何でしょうか。身近な例から探っていくために、体の改善であるダイエットの場合にどのような手順で進めるかを考えてみましょう。
　最初に今の体重や食生活などを確認するはずです。そして、今の状態をベースに目標を立てて、その実現に向けたアクションプランを考えることでしょう。仮に今の状態を把握しないまま進めたとして、いざ体重計に乗っても「どれだけ痩せたか」という成果がわかりません。
　ソフトウェアの改善も同じように、まず品質を評価して、今の品質がどうなっているかを知ることが大切です。そうすることで問題点を的確に把握することができます。正しい問題認識に基づいた改善施策を立てれば、品質上の問題ではない箇所を変更するような無駄な作業の発生を防ぐことができます。
　そして改善後にも品質を評価し、改善前後の評価結果を比べることで「どれだけ改善したか」という成果を知ることができます。成果を正しく把握できれば、実施した改善がどの程度効果的なものであったかがわかり、次の改善活動の計画立案や施策検討に役立てることができます。
　改善前後の品質評価を組み入れた品質改善のプロセスをまとめると以下の図のようになります。

図 1 品質評価を盛り込んだソフトウェア品質改善のプロセス

　継続的で有益な改善活動を進めていく上で、改善前後の品質評価が重要なポイントになります。

４． 評価する対象

　品質評価には、改善活動を有益なものにするメリットがありますが、現場で一般的に実施されているとは言い難い状況です。
　これは品質評価を実施する上で以下の2つのハードルがあるからだと筆者は考えています。

• どの成果物を評価すればよいかがわからない・・・評価対象の問題。
• どのように評価すればよいかがわからない・・・評価方法の問題。

　本稿では、１つ目のハードルについて考察していきます。
　品質を評価するにあたり、ソフトウェア開発に関する全ての成果物を評価対象とすることは、工数の関係上、現実的ではありません。従って、評価対象とする成果物を絞り込む必要があります。
　どのような成果物が評価対象として望ましいでしょうか。まず、継続的に評価することを考えれば、どのようなプロジェクトであっても必ず製作される成果物であることが望まれます。さらに、できるだけ定量的に評価できる成果物であることが望まれます。
　このような条件に最もフィットする成果物は、ソースコードではないでしょうか。
　ソースコードはソフトウェア開発で必ず製作される成果物であると同時に、実際に製品に搭載される唯一の成果物です。また、有効なメトリクスが世の中に多数提案されていますので、他の成果物よりも定量的な評価がしやすいと考えられます。
　以上から筆者は、まず、ソースコードを対象に品質評価をすることが、現場で実施できる効果的かつ現実的なソフトウェア品質評価の形態だと考えています。

　次回は、2つ目のハードルであるソースコードの品質評価方法についてご紹介する予定です。