組込みプログラマがはまる要因

 ちょっと前にhttp://blog.livedoor.jp/lalha/archives/50261226.htmlというエントリを見つけたのだけれど、非常に腑に落ちる内容で、勉強になった。
 そこで今回は特に組込みプログラマがはまる要因というのを考えてみた。以下に列挙してみる。

必要な情報を可視化していない

 例えば、マイコンを使った開発で、その内部の状態を把握する手段を用意せず、ブラックボックスとしてひたすらイメージファイルの焼きこみ→実機で動作確認、のサイクルで作業を進めている状態がこれに該当する。また例えば通信モジュールの開発で、入力と出力のコードをいじくるだけで、実際に配線上にどのような波形が流れているか確認していない状態もこれに該当する。

 こういった状態では、問題が発生しても原因を絞り込む手段が限られているため、ただひたすら勘や力技に頼ることが多くなる。また問題を運よく解消したように見えても問題が完全に解消しているか確認するのが困難な上、可視化されない問題を後工程に素通りさせてしまうリスクも持っている。非常に信用できない状態だけど、組み込み開発はソフトウェアの挙動が見えにくいので、何もしなければ自ずとこのような状態に陥りやすい。

 そのため、組み込みのような情報が乏しい開発では、情報の明示化を特に重視する必要がある。例えばマイコンやDSPを使った開発なら、ホストPCとの文字列の通信機能や、ボタンやLEDといったUI制御機能を優先して追加する必要がある。可能ならJTAGなどを導入して積極的にデバッグ環境の整備を進めた方がいい。またI/Oといった周辺部の情報も、オシロスコープロジックアナライザ、テスタなどを導入して、どんどん可視化していくべきだと感じる。

ドキュメントをきちんと読んでいない

 例えば、何かのICを使う際に、ドキュメントをよく読まず、「I2C通信で制御可能」「○○とコンパチ」といったキーワードだけ拾い読みして、開発を進める状態がこれに該当する。

 組み込みでは、例えば指定型の変数でアクセスしないと正しい値を返さないレジスタ領域や、一定時間ウェイトを置かないと連続使用できないAPI等々、常識や共通概念から離れた特殊な仕様や特性が珍しくない。ドキュメントをよく読まないと、そうした特殊な取り決めで頻繁に捕まることになるだろうし、時には部品や装置を壊してしまう場合も多いにあり得る。

 そのため、何か新しいものを使う際は、ドキュメントを読んで必要な情報をあらかじめ置いた方が安全だといえる。また使用例やチュートリアル資料としてソースコードが添付されている場合は、是非目を通しておいた方がいい。そういったものには、必要なおまじないのコードや、注意点をまとめたコメントが書かれていることが多く、前述のリスク回避の一助になる。

ソフトウェアしか分からない

 文字通りソフトウェアしか分からず、アナログ回路やHDLといった関連する分野を理解できない状態を指す。

 このような状態では、問題が発生してもソフトウェアの領域でしか検証が進められない。そのため問題が発生すると「ソフトウェアの問題を突き止める」か「ソフトウェアに問題がないことを証明する」の2択の対策を取るしかなくなるが、得てして後者は無駄が多くとても非効率な対策になる。特に開発対象が複雑になってくると、原因がコードでないのに、コードを延々と調べて時間を無駄にするなんて事態も常態化してくる。
 また厄介なことにこの分野では、ソフトウェアとソフトウェアでないものが複合してバグを形成していることが多い。例えばI/O部のクロックのデューティなどは、ソフトの遅延とロジック回路の遅延が協調して調整している場合が多い。そういった状況下では、コードの問題を直したと思ったら意味不明の問題が新たに発生した、という状態に陥るリスクがかなりある。

 そのため組込みエンジニアである以上は、直接関連する他分野は積極的に学んだ方が良いといえる。一般常識レベルでも、回路ならマイコンやプロセッサのドライバ回路を組む程度の知識や、最低限のノイズフィルタリング回路やロジック回路を使いこなせる程度の知識は修めておいた方がいい。また製品にFPGAを使っているのならI/Oやロジック処理を組める程度のHDLの知識も習得しておいた方が無難だと感じる。(そもそもソフトしか分からないというのは、組み込みエンジニアとしてのスキルが偏屈な状態であり、あまり好ましい状態ではないと思う)

ハードウェアをテストしていない

 例えば、妥当性評価や受け入れ検査を行わずに、内外から提供されたハードウェアを開発物に組み込んでしまうような状態を指す。

 こうした状態では、ソフトウェア外のバグをすり抜けさせたまま開発を進めてしまうため、バグが発生しても原因の特定が大掛りになりやすい。開発対象が複雑化してくると、ハードウェア起因のバグと知らずに、延々とソフトウェアをいじくりながらデバッグデバッグ中に誤って新たなバグを混入させる、なんて展開も普通に出てくる。またハードウェアに外注や組立プロセスといったものが絡んでくると、ハードウェアのバグ発見の遅れが致命的な手戻り・時間の浪費に十分なってくる。

 そのため、開発前にハードウェアやその他ソフトウェア実行環境をテストする工程を、プロセスとして用意しておいた方がいい。また外注を行うなら再利用可能なように受け入れテストを設計すべきだし、内製するハードウェアでもチームのためにテストベンチや評価手順書を設計して提供した方がよりリスクを抑えられると感じる。

関連要素の担当者とうまく情報共有できていない

 例えば

  • ハードウェアのサプライヤの担当者と納期を確認していない
  • プロジェクトリーダーとスケジュールを共有していない
  • 他分野メンバ(回路担当等)と仕様やスケジュールを共有していない

のような状態を指す。

 ソフトウェア開発というのは、複数の工程、複数のサプライヤーや外部リソース、複数の構成要素(メカ、回路、ロジック、画像設計等)と深く関わりあっていることが多い。特に組込み開発に関しては、何をするにしろ時間が必要なハードウェアが関わってくる点で、それらの持つリスクがさらに増大しており、それぞれのインテグレーション地点や同意形成地点がはまる要因になりえる。
 例えば外注の納期を見誤ると、ハードウェア・開発環境が不十分な状態で、非効率な形のまま開発を進めてしまう状態に陥りやすい。またハードウェアの開発状況をよく把握しておかないと、細かな仕様変更が発生しやすくなる点で、作業の手戻りを繰り返し発生させるリスクを高めてしまう。

 そのため、自分の業務に直接影響を与える要素に関しては、その担当者からよく情報を把握しておく必要がある。またこちらの都合や要求も、聞き入れさせるかどうかは別にしても、その担当者に明示しておいた方が何かと無難だと感じる。



 以上まとめると

  1. 自分が依存しているものはきちんと検証しておかなければならない
  2. 自分が必要な情報はあらかじめ明示化しておかなければならない

といったところになると思う。
 もちろんこういうものは一朝一夕でできるようなものではないので、慣習的に環境づくりや改善活動を継続させていく必要があると感じる。