回路図中のコメントを考える

ソースコード重視のソフトウェアエンジニアが設計書の充実よりもソースコード中へのコメントに重きを置く傾向があるのと同じでハードウェアエンジニアも出来るだけ設計書は最小限にして回路図中へのコメントで対応しようとする傾向はおなじですね。

でもある程度の品質を確保するためにはやはり設計書レビューを行う為に設計書に明確に示した方が良い。

回路図中へDRCのルールを記述出来たりしますが回路図の可読性が悪くなるんですよね・・・


またある程度細かな雑規約群はソフトウェアのコーディング規約の様にプロジェクトで共通の規約集を纏めた方が良い。

例えば
パターン幅やクリアランス
VCCI配慮設計方針（クロックラインの引き回し規約、グランドベタ率、パスコン付け方）
CPUリセット中のIO処理（浮かせない、衝突させない）
コンデンサの対リップル設計
などなどその他多数


規約作った後はチェックリストまで作れたらかなり品質向上に繋がりそうです。
先は長そうです(^^;

電子回路図もリファクタリングで品質アップ

電子回路の品質向上のノウハウというのはなかなか公開されていないため、ソフトウェアの品質向上ノウハウをハードウェア開発にも適用できるのは無いかという発想で、いろいろ模索しています。

今回はソースコードのリファクタリングをハードウェアに適用できないか考えました。

ちなみにリファクタリングとはクチャクチャなソースコードを同じ動作で、より読みやすく（保守性向上）、より効率的に（CPUリソース、メモリ消費量）する作業で、一般的には一度完成（テスト通過後）した後に作業に入ります。もちろん再テストします。

またリファクタリングをしたあとは非常にソースコードの可読性が上がっているため見た目にも大変美しくなります。


電子回路図も同じではないかと思いました。
１、とりあえず全体を描く
２、全体が決まったところで改めて描き直す３、必要な時は部品ライブラリの作り直しもする

実際に本日、回路図のリファクタリングをしてみましたが、リファクタリング中に見つけた些細な凡ミスも修正することができました(^^;

回路図が美しくなることで可読性があがり、セルフチェックの質向上と回路図を改め見直すことで効率化や保守性向上も良くなるということに繋がります。
回路図を描く作業時間は多少増えますが、品質向上により全体の工期が縮まると同時に保守性向上により、その後の保守もしやすくなります。

締め切りに追われてるときはついつい動けば良い的な図面になりがちですが、品質に困っている場合は是非電子回路図のリファクタリングをお試しください。

二分化

人によってはできる人、できない人という言い方をする二分化。
できるできないが真義ではない。


当然なことナンだけど業務の効率化とかって大事なことなんですが、分かってるんだろうかって思う人います。
反論を出す人・・・勘弁して。

私の持論、
まず『やってみます！』、もしくは『頑張ってみます！』
その後、実際に頑張る
出来なかったときは詫びればよいだけ。


言っちゃいけないのは『それはちょっと・・・』、『それは無理です』
否定的な言葉は絶対にだめです。先ずは建設的に話を進めましょう！

最近の出来事でいうと在庫管理を効率化のためにバーコード化しようとか、会議の効率化のためにテーブルを立ち会議仕様にしようとか・・・なんで私以外の人から上がらないのかが疑問でならない。
少なくとも今のポジション（管理職）がなくともそのくらいのツッコミはしたし、そもそもそういったことを勉強していた。

今の社会は私的な時間が足りないかも(^^;