DSF2017「ハード屋＆ソフト屋ディスカッション」レポート
Design Solution Forum 2017 実行委員 守田 直也
ハードウェアとソフトウェアが密に連携して動作する製品開発では、ハード屋とソフト屋の間に深い谷があると、古くから言われている。ソフト屋はハード屋の常識がわからず、ハード屋はソフト屋ならこうあるのが当然と期待する動作に思いいたらず、開発の終盤になって問題が発覚した事案を、技術者なら苦い経験として持っているかもしれない。
一般論として、ハード屋とソフト屋の双方が少しずつ互いの領域を知っていることが良いと言われる。では何から始めればいいのか、何を知っているとよいのか、他人はどうしているのか？
「ハード屋＆ソフト屋ディスカッション」は、このようなテーマについて、さまざまな立ち位置の技術者が他の開発者の現状を知り、ざっくばらんにアイディアを出し合ったりできる場として企画された。前年のDSF2016では、パネルディスカッションの形式で催されたが、DSF2017ではさらに、参加者も話の輪に加わる形が採り入れられた。この日のプログラムは次のとおりである。
・ライトニングトーク
3人のエンジニアが、設計仕様書、開発現場の教育、不具合解析手順を題材に、事例を紹介。参加者がそれをもとに意見を出し合った。
・実機検証アイディアソン
用意された実機で発現している不具合を、参加者が3名ずつのチームに分かれて解析方法を検討。そのアイディアを出し合った。
この様子を紹介しよう。
■ライトニングトーク――あなたならこの問題をどうするか？
ライトニングトークは、3人のエンジニアがそれぞれ、設計仕様書、開発現場の教育、不具合解析のテーマで事例を紹介し、参加者が自分の考えや仕事で実践していることを出し合う形で進んだ。
設計仕様書編：ソフト屋が望むドキュメントとは？
事例1：ハードウェアのドキュメントに記載されていた制約条件が、ソフトウェア開発者にはうまく伝わらず、後工程で問題が浮上。
事例2：ハード屋は常識的と考えていた仕様だったが、ソフト屋にはその感覚がなく、不具合として報告された。
ドキュメントの重要性は誰もが認めるところだが、実際にはハードウェアを説明するドキュメントはハード屋の前提知識に基づくことも多く、ソフト屋が大量のドキュメントから開発に必要なことを拾いきれないことがある。
スピーカーと参加者の間で、いかにシンプルに書くか、わかりやすい統一フォーマットの採用、条件を整理するためにマトリックスやテスト仕様の活用、ソフト屋が掴みやすいシーケンス図の採用などが挙げられた。
また参加者のプロジェクトのなかには、ソフトウェア開発者側のリクエストをヒアリングしてドキュメントを用意しているケースもあった。リクエストは、何がわかっていないのかがわからなければできないことだ。ソフト屋とハード屋が互いの常識に歩み寄る、これまでの失敗経験の積み上げがあるなど、一歩進んだプロジェクトならではの形かもしれない。
開発現場の教育編：ハードウェア、苦手なままでいいですか？
事例：ソフトウェア開発者がハードウェア特性を考慮しないでアプリケーションを開発、実際に使用しだしてから問題が発覚した。
事例は、アプリを開発したソフト屋にハードウェア特性への理解が不足していたのが原因だ。ではソフト屋がハードの技術を知るにはどうしたらよいか？
参加者から、希望する人にはチャンスを与えよう、いやいやアプリ志向が高くて新人は興味がなさそうだ、クリエイティブなことをするならアプリのほうが面白いのではないか……と少々さみしい意見が出る。一方で、ハード屋とソフト屋さんがチームで仕事をするといいのでは？ そういえば最近身近にハード屋さんがいない、話す機会を増やそう、などの話もあった。
ソフト屋から自分で勉強してハード屋へ転向、最近またソフト屋へ回帰したという参加者からは、会社に何かしてもらおうとしてもダメ、ソフト屋がハードウェアの常識までの間を埋めるのは一足飛びには無理だから、まずRaspberry Piで何か作るところから始め、小規模なFPGAと連携して使う、のような段階を踏むとよいのではないか、という話も出た。
不具合解析編：不具合解析の困りごと
事例：同じハードウェア構成、同じファームウェアの製品構成で、特定の数台だけに問題が発生。再現性はあるものの、他の個体では現象が出ず、原因の究明は難航した。
この事例ではファームウェアを改造してログを取得することにより解決の糸口をつかんだ。だが、ログの取得がパフォーマンスに影響して不具合が再現しなくなる可能性もあり、いつでも有効な方法とはいえない。また、ハードウェアにあらかじめデバッグ機能を作り込んでおく方法も設計時の負担が大きい。では、他の開発者たちはどんなデバッグ戦略をとっているだろうか？
参加者からは、ICEやJTAGなどのデバッグ手段によらない方法として、ハードウェア設計時にデバッグ用のレジスタを用意しておき、ログを書き込んでおくというアイディアが紹介された。ただし、これは便利とばかりに他の開発者もいろいろなログを書き込むようになると、必要なデータを見つけられなくなってしまう。導入時にはログレベルの取り決めをしておくとよいとのことである。
■実機検証アイディアソン――チームA、B、Cに分かれて不具合解析
続く実機検証アイディアソンでは、参加者が3名ずつ3つのチームに分かれ、実機にあらかじめ作りこまれている不具合の解析方法を検討し、それを披露し合う形で進められた。
不具合1：N社が総力を挙げて開発した新製品「脳内イメージ表示システム」のQA試験にて、特定の画像で異常画像が発生するという報告が入った。
報告を受けたチームA、B、Cは、ただちに原因究明のための討議を開始した。
→ 報告が入った時点で、最初に何をするか？
→ そしてどのように解析を進めていくか？
提示された表示画面は、一見問題がないように見える（実はあとで画面上部に黒いスジが入っていることがわかった）。いったい何が問題なのか。各グループが一般論から問題の切り分け方法を検討した結果が、次のホワイトボードである。
まずは、何が異常なのか理解することが必要だ。最初に期待される画像の入手、不具合の再現性と再現手順を調査し、次に期待値の比較を行うこと。これはどのチームにも共通していた手順だ。しかし、そのアプローチは各チームで少しずつ異なった。最小限の手順を確認してソフトウェアとして動作が問題ないことを初めに確認する、画像出力側から順に入力側にさかのぼって不具合発生個所を特定する、過去の実績や経験から不具合のポイントを絞り込む、などの方法が挙げられた。
また各チームの検討の過程から、不具合の原因がよくわからない時点では、ソフトウェアのバージョンの違いやパラメータ設定を振るなど、あらゆる可能性が洗い出されていく様子が見えた。不具合解析は、原因がわかってしまえば大したことではないと思われがちだが、早急な対応が求められて大きなプレッシャーがかかる。担当者にとっては非常につらい作業だということを改めて感じた。
不具合2：無事にN社は不具合１を改修し、市場に製品を展開することができた。同社はさらに進んだ後継機種として、動画による「脳内イメージ表示システム」のプロトタイプを組み上げた。しかし、そのビデオ表示システムには不具合がある……。
チームA、B、Cは、次の2点に焦点を当てて討議した。
→ 何が不具合の原因となりそうか？（仮説を立てる）
→ 普段よく実施する解析手法と理想の解析手法は何か？
表示画面は、本来は緑色と思われる部分がピンクに見えるというように、色がきちんと再現できていないように見えた（実は、ビデオを最後まで見ると、ブロックノイズ様の映像の乱れが見える）。各グループが色の再現不良から問題の切り分け方法を検討した結果が、次のホワイトボードである。
不具合の原因としてどの参加チームも真っ先に挙げた仮説は、「色変換のプロセスが原因」で、見事に出題者の術中に嵌ってしまった。真相は、ハードウェアのFIFOのタイミング設定ミスによるもので、本来のタイミングで画像が出力されないことが原因となって表示画像が崩れていた（それはわからないぞ！）。
人はどうしても、目に見える現象を頼りに可能性の高い不具合を仮説として立てようとする。それが良い悪いということではない。設計過程の改善による工数削減が難しいのと同じように、不具合の解析もなかなか工数を短縮できない難しさを浮き彫りにした形になった。
動画ならではの理想の解析手法として、途中経過の画像と設定値のスナップショットを見たいポイントで自動的に取得しておく、レジスタ設定値の自動取得機能などのアイディアが挙げられた。また究極の対策として、上流工程での品質確保により、そもそもバグを埋め込まないようにする、という意見が述べられた。これについては、別の機会に議論したいテーマである。
◆
現象の特定に頭をかかえながらも、アイディアソンの室内は合宿のような雰囲気でどのチームも楽しそうだった。おそらくこの場に集まった参加者には、上位レイヤのアプリケーションを開発するソフト屋でも低レイヤ技術に理解があってほしいという意識があったと思う。ハード屋とソフト屋の谷を埋める黄金の解がすぐに見つかるわけではないが、ハード屋とソフト屋というテーマで異なる会社、異なる仕事の人から聞く話はおもしろく、何より楽しかった。この楽しいという気持ちが、ハード屋とソフト屋の谷に橋を架けてくれることを願う。