ハートランド・データは、2024年4月17日（水）～19日（金）に開催された Qiitaカンファレンス2024 にて、スポンサーセッション「組込みのバグ修正を支える解析技術 ～15年間の解析ツール開発で遭遇したヤバい事態Top3～」を提供させていただきました。
本ページでは、セッションのサマリーをお届けします！
組込みソフトの不具合解析を強力に支援する動的解析ツールですが、うちの製品はご好評いただいているお陰で15年ものロングラン開発になっています。そんな長い開発史、二度と遭遇したくない事態もいくつかありました。 「機能安全対応でちょっとやらかしかけちゃった」とか。 「やっぱりアジャイルだけじゃどうしてもうまくいかなくて詰みかけた」とか。 今回は、エンジニアの皆様が同じ轍を踏まないよう、スポンサーなのにセールス要素はほとんど置き去りで、そんな「ヤバかったこと」Top3についてお話しさせていただきます。
大手LSIテストシステム・計測器メーカーやソフトウェアハウスで解析系アプリを作ってきた歴戦のSE。初代の動的解析ツール「DT10」をつくった人。開発の全工程とISO 26262ツール認証のための開発プロセス構築と運用を担当した。いまはソフトウェア開発全般をマネージメント中。お酒好き。娘さんに各地の銘酒を教えていたら若くして娘さんの舌が肥えまくってしまった。
はじめに
なぜ、15年もひとつのツールの開発を続けているのか
1990年代、弊社社長の落合がDVD機器の開発をやっていた際に、かなり大量の不具合に悩まされる事態が発生した。
当時はJTAGでのデバッグが主流だったが、2回のブレークでできるソフトの挙動は限定的であり、バックトレースも容易ではない。
「このままではメカ機構制御を伴う開発では問題解決に多大なコストがかかってしまう。動作ログを取りためて、いつでもバックトレースできるようなツールが欲しい」という思いから開発スタートを決意。以来、組込み開発者のテストを助けるために様々なアップデートが続いている。
15年も開発がつづいている動的テストツールってなに？
動的テストツールDT+は、動的解析（print文デバッグのハイエンド版をイメージすると理解しやすい）を行うテストツール。まず、動作を解析したいソースコードの関数In/Out部分や条件分岐箇所に経路情報をログ出力する処理を埋め込み、いつも使っているコンパイラでファームウェア形式に。これを実機やシミュレーター上で実際にRunさせることで、実動作としてのソフトウェア実行経路を記録。この経路情報を解析し統計処理することで、関数遷移や処理時間に要した時間、変数の遷移をグラフ形式でわかりやすく確認することができる。また、取りためたデータから疑似的にバックトレースをすることも可能。
複雑な不具合解析に困り果てたら
プログラムのトレース情報と時間情報を合わせてログ収集。
実行経路・変数値・実行時間・波形・通信・映像など、
様々なデータを組み合わせて解析ができるから複雑な不具合でも解決がはやい。
動的テストツール
ヤバい事態その①
開発初期における技術的負債の蓄積
最初のDTシリーズを作製するために集められた人数は3名ほど。プロジェクトスタートから半年後にある展示会でのお披露目を目指してver1.0を急ピッチで作り上げていった。
以降、半年ごとに開催されていた組み込み開発業界の展示会での大きめな追加機能の発表を目指して、昼夜問わずの急ピッチで仕様決定→設計→実装→デバッグを詰め込んでいた。
当然、一人あたりの作業量が膨大なものになってしまい、定時まで実装したらそこから2～3時間のレビューを行い翌日修正、なんてことも。そんな開発を行っているうちにどんどん技術的な負債が蓄積し、ある日解決できない問題が発生する、という事態に･･･。
開発プロセスの導入で解消傾向
技術的負債の蓄積を防ぐためには、開発リソースの数％を書いたコードの見直しや修正に充てつつ機能実装を進める「防衛的プログラミング」を実施するのがセオリーだが、それすら許容できないほどの省リソースによる開発は、いつか大きな破綻を招く。
作業に対する適切な工数見積もりをしっかり確保することも重要。当時、日本の自動車業界で始まった「ソフトウェア開発プロセス」の導入に着眼したことで、工数見積もり精度が向上し、負債の蓄積リスクを最小に抑えるようなリソースの確保と安定した開発ができるようになった。
ヤバい事態その②
実装した機能がお蔵入り
過去、「なにか目新しい機能を」という経営視点からの要望で、小難しい仕様の機能を実装することになったが、開発期間も、リソースも小さいものしか確保できなかった。仕様を周囲にレビューする時間が取れず、苦肉の策として単独で実装してから周囲にお披露目する事態になってしまった。
その機能が、あまりにニッチなニーズを攻めた機能だったため、評価担当やセールス担当も仕様の把握に苦戦。お客様にもうまく説明できず、目玉機能のひとつという位置づけだったにもかかわらず、最終的にお蔵入りしてしまう事態に。
プロトタイピングのやり方
新しい機能を実装する際は、「なるべく多くの人にレビューしてフィードバックをもらう」というのが重要であり、そのためには機能の動作仕様を新しい機能を実装する際は、「なるべく多くの人にレビューしてフィードバックをもらう」というのが重要であり、そのためには機能の動作仕様をより具体的な形で示せることがポイントになる。
ここでは「プロトタイピングをどのように進めるのか、ということが大切である。例えば、要求仕様から簡単な動きを作ってしまって「こういうイメージですか？」と聞けるところまで作ってしまうのか、それとも手書きの落書きレベルのUIデザインを行ってレビューをし、制限事項や未確定の仕様を洗い出してからプロトタイピングを行うべきなのか、など。
ヤバい事態その③
自社開発への開発プロセスの適用具合
DT+シリーズのISO 26262対応の経験から得た開発プロセスの知見を活かすべく、認証が必要ない自社製品の開発にも認証ツール開発と同じレベルの開発プロセス管理を当てはめようとした。
「要求仕様はこう書くのだ」「要求定義はこうやるのだ」「変更はこう管理するのだ」といった箇所をガチガチの開発プロセスにして運用した結果、コード1行変更するのにも規定文書の変更作業などの付随作業が大量発生。コード実装工数が大きく膨らむほか、コードのリファクタリング作業自体を自発的に困難にしてしまうような状況になってしまった。
開発プロセスの本質的なトコロとは
認証系の開発プロセスをベースに考える場合、「なぜそのプロセスがその手順を求めているのか」というところを考えて見極めるということがポイントになってくる。「認証のプロセスでやっていたから」ということを理由に、すべての製品にガチガチに適用してしまうと、上手く回らないパターンが出てくる。
例えば、「どこまでプロセスに沿った記録を残してトレーサビリティを確保しておくべきなのか」など。やらなくちゃならないところと、効率を優先してよいところを見極められるようになると、現実的な開発プロセスになってくる。
いますぐ聞けるオンデマンドセミナー！
大好評「設計をはじめる前に知っておいてほしい」シリーズ
さいごに
使ってくれている人がいる限り「道具」を作り続ける
いまさらという感じではあるが、今後もしっかりとお客様の方を見て作っていきたい。
目立つ機能の実装は、見栄えが良いし宣伝もしやすく、そちらに流れそうになるのも分かるが、それよりも本当にお客様にとって使いやすくなるような地味な改善を優先して、「お客さんがすぐ取り出してすぐ使える」ような、道具のようなツールとして作っていきたい。
ゼロからほぼスクラッチで作り上げたツールであり、わが子のような愛着がある。そんなツールをお客様が使って、役に立ったと言ってくれている。そんなお客様の声がある限り、道具として開発を続けていきたい。いつかサポートが終わったあとも、それでも使ってくれるお客様がいるなら、サポートするつもりです。
お知らせ
ハートランド・データのWEBページでは、ソフトウェア開発の役に立つ、濃いめのコンテンツをお届けしています。
テストや不具合解析でお悩みの方向けのWEBページ
「どうするテストとバグ修正」では、
フローチャート形式で開発者の知りたい情報をご提供しています。
Zoomを利用した「WEBセミナー」では、
ソフトウェア開発上の様々な課題を掘り下げる無料のセミナーをお送りしています。人気セミナーは今すぐ見れるオンデマンドとしても配信中。
組込み機器開発の情報収集をされている方は、ぜひ一度ご覧ください。
お問い合わせ
ハートランド・データ(株)
セールス&マーケティングユニット
TEL： 0284-22-8791(代表) (平日 9:00～17:30)
お問い合わせ
製品に関するお問い合わせは、下記のEメール・お電話・FAXで承ります。
どうぞお気軽にお問い合わせください。
お問い合わせ フォーム
0284-22-8791 （平日 9:00~17:30）
0284-22-8792 （平日 9:00~17:30）