組み込みソフトウェア開発者に贈る「静的解析・動的解析」の必要性：いま求められるソフトウェア静的解析・動的解析 第1回（1/3 ページ）

組み込みソフトウェア開発における「静的解析」「動的解析」を、“なんとなく”行っていないでしょうか。開発効率の向上や品質改善に欠かせないこれらを活用するため、まずはその必要性について解説します。

[井上樹（豆蔵），MONOist]

はじめに

　組み込みソフトウェア開発における「静的解析・動的解析」という言葉（技術）を聞いたことがあるでしょうか？

　本連載ではこの静的解析・動的解析を使った開発効率の向上や品質改善について取り上げていきます。まずは初回ということで、静的解析・動的解析の紹介とその必要性について説明していきたいと思います。

静的解析・動的解析の必要性

　近年、組み込みソフトウェアの大規模化・複雑化が進み、その品質向上にはますますの技術と時間が必要とされています。そうした品質向上のための活動を行っている時に、「ムダ」を感じることはないでしょうか。

　例えばテストでバグ出しをしている時、見つかったバグが < と <= の誤りのような単純なミスで、そのバグを見つけるのにかけた工数（再現性を確認するためのテスト実施、原因解析、修正後の確認テスト工数など）と見合わないなと感じたり、性能が出ない時に、プログラムのいろいろな場所に実行時間計測用のコード（コンソールやファイルにタイムスタンプを出力するようなものなど）を差し込んで、実行時間の計測とコードの修正を行うトライアンドエラーを延々と行っているような時です。こうしたムダを解消することができたら、ソフトウェアの生産性も品質も、もっと向上するはずです。

　ソフトウェアの品質を向上するための活動として、一般的には、テストやレビュー、前述のトライアンドエラーが行われています。しかし、ソフトウェアの欠陥にはさまざまな種類があり、テストやレビューがいつでもその検出に最適な方法であるとは限りません。

　例えばメモリリークはソフトウェアを動作させないと気が付きにくいため、レビューでは発見しにくいですし、テストで発見するにしても、メモリリークを発見するようなテストケースを考えたり、場合によっては長時間の連続実行が必要になったりと手間が生じます。また、当たり前の話ですが、トライアンドエラーは大きな時間のムダを生じやすい開発方法です（戦略性のない場当たり的なプログラムの書き直しは高コスト・高リスクです）。

　静的解析と動的解析は、そうしたテストやレビューでは見つけにくい欠陥を効率的に発見することができます。つまり、この導入は、テストやレビューの効率向上につながり、トライアンドエラーによるムダなコード修正も減らすことができるのです。

　ちなみにソフトウェアの品質を向上させるための技法には、前述したテスト、レビュー、静的解析、動的解析以外にもあり、それらを整理すると以下のようになります。

分類	技法
静的技法	静的解析、レビュー、形式手法（形式検証、モデル検査）
動的技法	動的解析、テスト、シミュレーション
表 1 ソフトウェア品質管理技法（SWEBOK v3.0 より）

　これらの技法にはそれぞれ得手不得手があるため、適材適所にて実施していくことで、効率的な品質向上を実現していくことができます。ここでは静的解析と動的解析を取り上げていますが、興味のある方は、是非、他の活動も見てみてください。

　では、静的解析、動的解析とはどんな技術なのかを見ていきましょう。