CodeZine(コードジン)

特集ページ一覧

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

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2011/03/18 14:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

オープンソースに潜むライセンス違反のリスク

 オープンソースの利用は品質保証の責任範囲を広範にしたが、同時にライセンス違反のリスクも潜んでいる。実際、欧米では裁判での係争、ソースコード開示による独自技術の公開、製品・ソフトウェアの使用停止・回収・再開発、風評・ブランドイメージダウンに見舞われた事例が発生している。

 これを防ぐためにはライセンスの内容を理解し、安易なコード利用やマルチソース開発によるコード混入の検出漏れなどを避けるなど、対策を短期間で実施しなければならない。しかし、それらを一企業が行うことは簡単ではない。

 そこで日立ソリューションズのBlack Duck社と提携したオープンソースの適正利用ソリューションでは、オープンソースのデータベースとマッチングさせて混入を検出する。単純に比較するだけではなくコードの特徴を比較するので、たとえば変数名などが変わっていても発見が可能だ。

 最後に田邊氏は「自分たちの品質は大丈夫」と客観的に言うためには定量的な確認が必要だと強調し「コストは、不具合が発生してからの対策に使うか、予防に使うか。最適なソリューションの選択が必要」とアピールしてセッションを閉じた。

お問い合わせ

株式会社日立ソリューションズ 本社別館

東京都港区港南2-18-1(JR品川イーストビル)

【担当】プロダクトソリューション第2営業部 中村(なかむら)

TEL : 03-6718-5891   Mail : inspectpro_os_dm@hitachi-solutions.com


▼ソフトウェア品質向上ソリューション▼

http://www.hitachi-system.co.jp/quality/sp/

 



  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

バックナンバー

連載:デブサミ2011セッションレポート

もっと読む

All contents copyright © 2005-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5