(Jo^▽^)ﾉぁぃ♪

「エンジニアの心がけ」

私は企業の開発センターへ週1回程度の頻度で「技術顧問」として活動しています。

ところが、開発チームの上長から「若手向けに勉強会をしてもらえないか？」と打診されました。
私はエンジニアであって、講師なんてやったことはありません。

200人ほどいる開発センターの20代の若手30人ほどを中心に、1時間ほどの技術講演会を行いたいとのこと。
ただ、開発センターなので参加者のジャンルが広い。
メカ・強電・電子回路・ソフト・製造など、専門分野は多岐にわたります。
さて、何を話そうか……。
　
　
そこで、専門分野に関係なく、私が普段から若手に伝えている考え方をまとめて話すことにしました。
題して、「エンジニアの心がけ」です。

「1．今どこにいるのか。」

道に迷ったとき、現在地が分からなければ道案内はできない。
問題解決も同じ。「何が正常で、どこから異常なのか」をまず確認する。
人に教える場合も、相手がどこまで理解しているかを知ることから始める。
まず「今どこにいるのか」を把握する。

「2．電子回路とプログラムは、思うようには動かない。作ったように動くだけ。」

「こうなるはず」という思い込みを捨てる。
実際の回路、配線、電圧、電流、波形、プログラムを見る。
デバッグとは、「自分の思い込み」と「実際」の違いを探す作業。
シミュレーションも有効な道具だが、シミュレーションと実測が違うなら、モデル、部品、測定条件、実装、環境のどこかに、その差を生む要因があります。

「3．良い設計とは何か」

必要最低限の部品で、要求スペックを十分に満たす。
ただし、単に部品を減らせば良いわけではない。
・性能
・安全性
・信頼性
・マージン
・コスト
・製造性
・保守性
これらを満たした上で、必要なものは残し、不要なものを削る。これが「最適化」。

「4．ブラックボックスを作らない」

可能な限り、すべてを設計者の管理下に置く。
IC、モジュール、OS、AI――ブラックボックスを使うこと自体が悪いわけではない。
ただし、「何をしているか分からないものを、分からないまま使わない。」
トラブルが起きたとき、自分で原因を追える設計にする。

「5．失敗を恐れない」

新しいことをすれば、失敗することもある。
大切なのは、失敗しないことではない。
失敗 → 記録 → 原因究明 → 理解 → 次の設計へ反映
記録されなかった失敗は、再発したときに「初めての問題」になってしまいます。
失敗を経験で終わらせず、「技術」にする。

「6．初心者であることと、調べないことは違う」

誰でも最初は初心者。
分からないことは恥ではない。
しかし、何も調べずに答えだけを求めてはいけない。
マニュアル、データシート、回路図、測定結果をまず確認する。

質問するときは、
・何をしたか
・何を期待したか
・実際にどうなったか
を整理する。
修行怠るべからず。エンジニアは一生勉強です。

「7．人ではなく、仕組みを見る」

問題が起きたとき、「誰が悪い？」だけでは解決しない。
回路の部品に怒っても、回路は直らない。
「なぜ、その問題が起きる仕組みになっていたのか？」を見る。
人のミスも含めて、問題が起きにくい仕組みを作る。

「8．AIについて」

AIは非常に便利な道具だが、間違えることもある。
したがって、AIの回答をそのまま正解として使うのではなく、設計の検討、壁打ち、見落としの確認、レビュー支援などに活用する。
AIを使うときも、設計と同じ。
まず対象を機能ごとのブロックに分け、
・何を実現したいのか（意図）
・どのような条件で成立するのか（前提）
・どのように動くと考えているのか（仮説）
を明確にしてからAIに伝える。
「最初に、こちらから条件を正しく伝えること」が重要。

条件が不足していれば、AIは不足した部分を推測して回答する。
その推測が間違っていれば、もっともらしい答えでも間違っていることがある。
AIは「魔法の道具」ではない。
最終的に判断し、確認し、責任を持つのはエンジニア。

AIは、使い方を利用者が決めることで、初めて本来の力を発揮する道具である。
「AIに考えてもらうのではなく、AIと一緒に考える。」

「9．最後に」

問題にぶつかったら、まず「今どこにいるのか？」を確認する。
現在地が分かれば、目的地までの本来の道筋に戻れるし、新たな道が見つかるかも。
カーナビもGPSが無ければ、ただの地図。

「電子回路とプログラムは、思うようには動かない。作ったように動くだけ。」

良いエンジニアとは、知識をたくさん持っているだけではなく、「なぜ？」を考え、自分で確認し、問題を解決できるエンジニア。

そして、ときどき自分自身に問いかける。

「今、自分はどこにいるのか？」