装置制御ソフトウェア開発に関するいくつかのアドバイス

装置制御ソフトウェア開発は、一般のソフトウェア開発とは環境が異なります。量産装置の上で動くコードならではの制約と、一度のミスがもたらす損失を踏まえて、繰り返し参照する価値のある実践的ガイドラインをまとめました。

装置制御コーディングのアドバイス

装置制御 SW 開発は特有の環境があるため、以下の点で一般のソフト開発と異なります。

• デバッガを最少化 — 装置の稼働中はデバッガを当てづらい。ログを積極的に活用し、ソースコードを素早く読み解く力を養いましょう。
• 構造設計 — まずは全体像を見て、コードを書く段で初めて細部に集中。
• 顧客要望の分析 — 表面的な要望そのものではなく、根本原因を探ることに時間を使いましょう。
• 共通条件の抽出 — 複数の条件を含みつつ核を貫けるシンプルな共通条件を見つけましょう。分岐が減ります。
• 修正の副作用 — 一つの修正が 10 個の問題を生むことがあります。チェックボックスのオプション 1 つで、テストケースとバグは 2 倍になります。
• コード分岐コスト — 同じ装置を 2 つのコードベースで分岐管理すると、業務量は 1.5 倍、保守コストとバグは 2 倍になります。
• 新規ドライバの検証 — 新しいドライバは 1 台で十分検証してから量産装置へ展開。
• 配布チェックリスト — 実行ファイルだけ配布せず、バージョンアップで追加されたファイルを必ず確認。
• ログ戦略 — 重要な条件・シーケンス・データは必ずログに残す。例外パスでは特に必須。意味を失ったログは整理。
• UX の基本 — 結局のところ、ユーザーへの配慮が最も大事です。

条件文の書き方

条件文は読んだ通りに意味が頭に入る順番で並べましょう。

• いちばん大きい大前提を先頭に置く。
• 同じレベルなら、true になりにくい条件から書く(短絡評価でコスト削減 + 早期失敗)。
• 全体否定 !(...) は使わない。読み手が頭の中で反転させる手間が増えます。

// GOOD
if (A == false && B == false && C == false) { ... }
 
// BAD
if (!(A || B || C)) { ... }

比較式では変数を左、定数を右に書きましょう(自然な読み順と一致)。

// GOOD
if (A > 2) { ... }
 
// BAD
if (2 < A) { ... }

ポインタを返す関数の設計

ポインタを返す関数で NULL を返すと、呼び出し側が null チェックを忘れるリスクが残ります。多くの場合、結末は装置停止です。

• 意味のある Dummy データのポインタを返してプログラムを止めない。
• ただし、その場合も必ずログを残すこと。fallback がどこで発生したか後追いできるように。

UI / UX

• XEdit 等の入力コントロール追加時は、適切なデフォルト値を設定しましょう。空欄だとユーザーが毎回入力する羽目になります。
• 保存せず画面を抜けるときは、データを元の状態に戻すこと。「保存しない」 の挙動は一貫している必要があります。

管理と最適化

• 顧客の要望を簡単に呑むほど、それが当たり前の基準になります。
• 重複コードは見つけ次第、関数化。先延ばしにすると 2 つのコードが分岐します。
• Include Path は全体オプションではなくプロジェクト個別に設定。環境依存を減らせます。
• プロジェクト中盤を過ぎたら、出口戦略(引き継ぎ・ドキュメント・ログ整備) を意識しましょう。

ログと検索性

ログメッセージで関数名を書くときは、() を付けない — 検索性が下がります。

// GOOD
LOG_PRINTF("", "DoFunc 実行");
 
// BAD
LOG_PRINTF("", "DoFunc() 実行");

互換性とシナリオ

• 機能追加時には、既存データとの互換性と量産装置への適用可能性をまず検討しましょう。データ移行コストは想像以上。
• シーケンスの問題は、明確なタイミングとシナリオで再現できるまで追究をやめないこと。「ときどき発生」 で済ませると量産後に高くつきます。

開発ツールと言語

強力で便利な開発ツール・言語を使いましょう。

• 汎用: Visual Studio(C++、C#)
• 制御特化: BeckHoff TwinCAT、CodeSys
• ICT 自社の統合制御 IDE: QMachineStudio — シーケンス・GUI・ランタイムデバッグを一つの IDE で。

良いツールと強い言語は、開発効率に大きく効きます。慣れたツールがあっても、定期的に環境を見直すと長期的に得です。