MISRA-C導入のススメ　――実運用のためのQ＆A

　C言語における「危険なプログラミング」を避けるため，「MISRA-C（正式名称は"Guidelines for the Use of the C Language in Vehicle Based Software"）」というコーディング規約が自動車業界で注目されている．ここでは，MISRA-Cに造けいが深いエンジニアの方々に，こうしたコーディング規約の必要性，また実設計に生かすための考えかたなどを聞いた．聞き手は本誌編集部．

【答えていただいた方々】
岩崎保氏： NECエレクトロニクス．MISRA-Cを含む車載関連のソフトウェア開発環境の顧客サポートに従事．JasParの活動に参加
舘伸幸氏：NECマイクロシステム．組み込みソフトウェア開発者．MISRA-C準拠の車載ソフトウェアの開発を経験
中村さおり氏：NECエレクトロニクス．ソフトウェア開発ツール担当．MISRA-C研究会^注1に参加
吉澤智美氏：NECエレクトロニクス．ソフトウェア開発ツール担当．「組込みソフトウェア管理者・技術者育成研究会（SESSAME）」に参加

――Q1：車載ソフトウェア設計者にMISRA-Cは必須ですか？

岩崎氏：規約に精通しておけとは言いませんが，少なくとも「MISRA-Cって何？」などと言わない程度にはなっていてほしいです．

舘氏：私が開発した車載ソフトウェアについて言えば，「ソース・コードはMISRA-C準拠か」という問い合わせや，開発の請負時に「MISRA-Cもしくはそれに相当するコーディング規約に準拠してほしい」という要求が近年は顕著です．

――Q2：ルールをすべて覚えてから設計するものですか？

舘氏：基本的にはそうです．ただし，MISRA-Cの項目^注2を一字一句覚えるというわけではありません．MISRA-Cをもとに社内でコーディング規約を作り，それに目を通しておきます．規約を読んでみると経験的に納得できることが多く，そんなに苦労しなくてもなんとなく頭に入るものです．ある程度規約を理解したうえでコーディングし，チェッカを通してみて，そこでだめな記述のしかたがわかれば，それを踏まえて後2，3回コーディングしていけば自然と身につきます．

――Q3：作業効率は落ちませんか？

舘氏：コーディングだけを見ると，確かに（ルールに合っているかどうかの）チェックの分だけ手間はかかります．ただし，コーディング規約によって防げるバグというのは少なくありません．そもそもコーディング規約は二つ目的があって，ケアレス・ミスをなくすこと，そして可読性の向上です．ケアレス・ミスによるバグほど見つかりにくいのです．また，記述がバラバラだと読みにくく，レビュー効率が落ちます．ある程度記述がそろっていれば他人のコードでも腹を立てずに（笑）読めるようになります．結果として，コーディングには確かに時間はかかりますが，開発の全工程で見ると効率は上がると思います．

――Q4：「MISRA-C準拠」とは「すべてのルールを絶対に守る」という意味ですか？

中村氏：MISRA-Cのルールは，すべてを絶対に守らないといけないということはありません．守っていると逆に（プログラムの）品質が落ちかねないようなルールもないとは言えません．また，可読性という面でも問題になります．そのため，MISRA-でも場合によってはルールを逸脱^注3してもよいということになっています．

吉澤氏：でも，「逸脱してはならない」と悩んでいる人もいるみたいです．規約にのっとることを重視して，「逸脱しないとするとかえってソフトウェアの品質や保守性が落ちるけど，どうすればいいんだろう」と．

中村氏：それは逆にMISRAの精神に反することになります．正しい逸脱手続きを踏めば（理由が明確ならば），かならずしも規約を守る必要はないのです．

舘氏：また，実際にMISRA-Cを使おうとするとテーラリングが必要です（図1）．つまり，MISRA-Cをそのまま使うのではなく，それをベースに"きちんと"社内でコーディング規約を作らないといけないと思います．社内でコーディング規約を作るときにMISRA-Cのルール（逸脱）の矛盾を，ある程度吸収できます．「こっちのルールには引っかかるけど，こっちのルールを優先しようね」とか．

[図1] MISRA-Cの項目のタイプの例（クリックすると拡大します）
MISRA-Cの項目にはいくつかのタイプがある．実際の現場では，実装は扱うシステムや設計手法に大きく依存する．したがって，MISRA-Cの「知恵」を基本に，組織に合った規約を作成し，運用するという姿勢が現実的．

――Q5：「正しい逸脱手順」とは？

舘氏：私のところでは，（コーディングしたプログラムがMISRA-Cのチェッカに）引っかかったら，どういうワーニングが出たか，それに対してどういう処置（逸脱手続き）をとったか，みんなでレビューしています．

中村氏：まっとうな手続きですね．逸脱理由は文書として（ソフトウェアの発注側に）提出するのですか？

舘氏：それは設計書など（必要に応じて逸脱理由単体の文書）に記載したりします．

岩崎氏：ソフトウェアを作った側から「ここを逸脱しました」と報告する場合や，発注する側が発注時に「この部分はこういうふうに逸脱してもかまわない」と規定してくる場合があると思います．どのような形で逸脱理由を提出するかは，発注元のメーカの考えかたによるのではないでしょうか．

吉澤氏：「正しい逸脱手続きを踏む」というところはマネージメントの問題になります．逸脱手続きをどうするかをきちんと決めておかないと，（実際にコーディングを行う技術者が）苦労することになります．

舘氏：品質について突き詰めると，結局そのプロジェクト・マネージャが「ソフトウェアの品質」についてどう考えているかというところに行き着くと思います．そういった意味で，マネージャの方にはソフトウェア開発のことを少しでも知っておいていただきたいです^注4．

 注1；MISRA-C研究会は，MISRA-Cを実設計で使うための研究を行っている．同研究会の検討結果などをまとめたものが，解説書「組込み開発者におくるMISRA-C ― 組込みプログラミングの高信頼化ガイド」（日本規格協会刊）として発売されている．
 注2；MISRA-C：1998では127項目のルールが，MISRA-C：2004では141項目のルールが定められている．これらの日本語訳は自動車技術会からテクニカル・ペーパとして入手可能．購入方法などについては，同技術会のWeb サイト（http://www.jsae.or.jp/）を参照．
 注3；MISRA-Cでは逸脱する際に「各個人で決めない」，「逸脱理由を文書として残す」などとしているが，具体的な手順を決めているわけではない．
 注4；組込みソフトウェア管理者・技術者育成研究会（SESSAME）のWebサイト（http://www.sessame.jp/）にある「ハードウェア出身のマネージャに分かっておいてほしい７つのこと」を参照．

組込みソフトウェア管理者・技術者育成研究会(SESSAME)は，下記の日程で MISRA-SA（MISRA Safety Analysis）ガイドラインに関するセミナを開催する．

■欧州の企画・規制に対応した安全性解析プロセスを構築するには～
　実践ワークショップ(1日コース)
　6月27日(火)　東陽テクニカ　TIセンター(東京・日本橋)

■欧州から世界に広がる新たなデファクトスタンダードに乗り遅れるな～
　基礎セミナ(半日コース)
　6月28日(水)　日本青年館　中ホール(東京・千駄ヶ谷)
詳細は以下のURLを参照のこと．
http://www.sessame.jp/seminar/misra_sa/index.htm