COOの原崎です。
高専卒にしてはレア？かもしれませんが、マーケティングを学び、社会で実践してきたことがありましたので売り物に加えて、売り方と売り先について考えています。
とはいえ、「ものづくり大好き！」ですので、ハードウェアの開発も担当しています。
ソフトオンリーの開発は作る実感が抱けず、どうも苦手です。実際にものが動いているときの感動が欲しいのです。
高専で水中ロボットの研究に没頭し、卒業後は大学でマーケティングを学んでいました。
大学卒業後は就職し、IoTのサービス企画をやっていました。2018年の6月ごろから改めてハードウェアの開発を再開して一から学び直す覚悟で１年間試行錯誤しながら２つほどプロダクト開発に取り組んでいますが、その中で私が感じた難点についてまとめます。
ちなみにこの一年で取り組んだことは下記です。
- Arduino IDEかmbed IDEで開発できるマイコンを使ったプロトタイプの作成
- 植物とコミュニケーションできるIoTデバイス
- ポータブルSOSデバイス
- 基板CADを使った基板設計（基本的にはSoC使っているので、部品点数はせいぜい数十です。）
- コストと入手性を考慮した実装部品の選定
- 設計した試作基板の発注と表面実装部品の実装
- 量産化のための業者とのやりとり
卵から孵ったばかりのひよこみたいな取り組みですが、苦労した点を少しでもシェアしてハードウェアに取り組む若い人にとって励みになれば幸いです。
1年間開発してみて苦労した点
（所感ですので、いい解決方法あればぜひ教えて欲しいです。。。。切実）
1. エラー発生時の情報収集
2. そもそも使いたい部品名がわからない
3. やることが多い上に時間がかかる
4. まとまった場所や専用の道具が必要
5. たまに怪我する
この記事では「１.エラー発生時の情報収集」について書いてみます。
エラー発生時の情報収集
ソフトウェアに比べると、ハードウェアで障害が発生するととにかく時間が掛かります。
ハードの問題解決は過去の経験がものを言います。その問題を解決した経験がある人はすぐに解決できるような問題でも初心者にはなかなか打開策が見えてきません。
例えばブレッドボードや基板上で実装していると、必ずうまくいかないことが多数発生します。プログラムであれば、PC上でエラー個所はここじゃないかな？と親切に教えてくれますが、ハードだと、エラー個所を明示してくれないんですね。
シンプルなケースですが、例をあげると、
断線してたりだとか、素子が仕様書通りに機能しないものだったりとか、電池の残量が不足して動かなかったりだとか、マイコンのライブラリにそもそもバグがあるとか・・・です。
テスター片手に可能性がある問題を問題個所を特定してみることから始まります。ようやくこの辺が問題個所っぽいなと特定できて、具体的にググる時になんと調べていいかわからないことも多々あります。つまりエラー名そのものが不明、もしくは定義されたエラーネームがそもそもないというケースです。
そんな時にどうするか？
私の場合、下記の順番に検討を進めます。
・考えられる限りのエラー名をググる
・利用しているマイコンの開発者フォーラムに同じ問題に出くわした人がいないか覗きに行く
・考えられる限りのエラー名をググる
・マイコン内に書き込まれているプログラムのライブラリや素子のデータシートを読む
・考えられる限りのエラー名をググる
基本的には他力本願です。きっと全く同じ問題に出くわしている人が世の中にはいるということを信じて、ググります。
その過程で、「考えられる限りのエラー名」の語彙を少しずつ増やしていきます。
すると、少しずつ、ググりレベルが上がっていきます。普段目にしたり耳にしない言葉が徐々に蓄積されていき、ググれる範囲が広がっていきます。すると、関連しそうな記事が徐々にヒットし始めます。
こうなればシメたものです。関連ワードの組み合わせを変えながら何度かググると必ず「これだ！」という記事に出会うことができます。
最初からエラー解決のための適切なページを探し出せるほどシンプルなエラーメッセージは定義されていません。
問題箇所で起こっていることを冷静かつ順を追ってつぶさに検討して、該当ページもしくはそのヒントが記載するページにたどり着く「語彙を絞り出せるかどうか」がエラー解決の近道だと考えております。
ソフトウェアオンリーの開発はほとんど行ったことがないのでなんとも言えませんが、
ハードウェアの開発ではエラー解決に王道なんてものはないのではないかなと考えています。
雑多な内容になってしまいましたが、ハードウェア初めて間もない人にとっての気づきにつながればと思います。
苦労した点の2,3,4,5についてはまた別記事で体験談を綴っていけたらと思います。