[17日目] 自撮り棒はもう古い⁉これからは自撮りパラシュートだ

こんにちは。電気設計担当のスン&メカデザイン担当のINDです。
アドベントカレンダー17日目は、弊社で販売しているCDP-ESP8266ことESP-WROOM-02の使用例としてあるものを製作しましたので、紹介していきます。


さて突然ですが皆さん、自撮り棒にはそろそろ飽きてきた頃ではありませんか?

撮影者も一緒に写ることができるという非常に便利な自撮り棒ですが、アングルやポーズが固定されてしまうという弱点があります。
常に最先端を求める皆さんは、そろそろこのバストアップショットだらけな現状からの脱却を狙っているのではないでしょうか。
そんなあなたに向けて、今回はスマートなソリューションをご紹介いたします。
それがこちら、パラシュートカメラです。

IMG_0597__
パラシュートカメラとは、その名の通りパラシュートの付いたカメラです。

使い方は簡単。パラシュートカメラとスマートフォンをWi-Fiで接続。カメラを空高く投げ上げてから落ちてくる間に、後述するスマートフォンアプリを使ってリモートでシャッターを切ります。

パラシュートカメラによって、上空からのアングルで自撮りをすることが可能となるのです!
★IMG_2602

では、撮れた写真に行く前に、テックブログとしてまずはパラシュートカメラの作り方を解説していくことにしましょう。
まずはスンから電気設計について解説していきます。

パラシュートカメラ製作のために用意したもの

 

電気設計

接続図

paracam_ブレッドボード2
この接続図は見栄えが良かったのでFritzingというアプリで作ってみました。ライブラリの関係上、実物と見た目が少し違うものがありますが、どうか大目に見てください(笑)。

カメラモジュールはUART、microSDスロットはSPIでの通信なので、それぞれ対応したピンに接続します。
また、LiPoバッテリー電圧が3.7Vなのに対し、カメラモジュールは5V駆動ですのでDCDCコンバータのモジュールで昇圧します。ただ信号線(Tx,Rx)は3.3V入出力ということなので、CDP-ESP8266とそのまま接続できます。
LiPoバッテリーについては、容量が大きいとその分大きく重くなり、パラシュートの落下速度に影響してしまうため、今回は250mAh程度の小さいものを使用しました。

実際に配線するとこのようになります。
IMG_2598

ソースコード

まず開発環境ですが、今回はArduinoIDEを拡張して使いました。
拡張の手順はこちらを参考にしています。

それぞれのモジュールを動かすためのコードは、ネット上に公開してくれている方がいるのでそちら参考にさせていただきました。

また、カメラのシャッターボタンとしてはiOSCというiPhoneアプリを使用しました。
アプリ内に配置されたボタンを押すことで、ボタンに設定したデータをUDPパケットとして送信できます。そのデータをESP8266が受信すると、撮影の処理が走るという仕組みです。
IMG_2634
▲iOSCの操作画面
 

参考にしたサイト

完成したソースコードはこちらです。
https://github.com/MasatoOshikiri/Cerevo_techblog_Sun
 

メカ設計

筐体について

ここからはスンとコンビを組んでるINDが解説していきます。
スンとは一緒に仕事したことないけど仲良しです。

今回のメカデザインで気を使ったことは、以下の2つです。

  • 重心が下に来るようにすること
  • 落下時に回転しないようにすること

設計にあたり、まず重心が下に来るように部品を配置するために、各々の重さを測ります。
測ってみると重そうに思えたバッテリーが意外にも軽かったので、下図のような構成にしました。基板間は厚めの1mm両面テープで固定します。
microSDと電源スイッチのみ、筐体の外側から使用できるようにしておきます。
Print
落下時に回転しないようにするために十字のフィンの構造にしました。

普段、部品の配置の際はサプライヤーや電気設計エンジニアから部品の3Dデータをもらって設計を進めますが、今回はそのようなものはないというか時間がないので、ノギスで部品を計測しながら設計進めました。ですので攻めすぎない設計にしています。
モデリングはfusion360を使用しました。

レンダリングをするとこんな感じです。
Print
 

3Dプリンターで出力する

社内にある3Dプリンターを使用しました。
構造を簡易的に検討する際にはとても便利です。
Print

実際に撮ってみる

上記、スン作の回路・ソースコードでなんとか動作したので、さっそくIND作筐体に組み込んで、青空の下、撮影を行ってみることにしました。


カメラを投げるのがすっかりプロ級になったIND氏。このパラシュートカメラが降りてきたタイミングでシャッターを切ります。

するとどうでしょう……

★PIC04
アホ面下げたおっさん2人の、上アングルからの写真を撮ることが出来ました。
気を付けなければならないのは、撮影時の風と光です。風が強く吹いているときに投げると簡単にパラシュートが飛ばされますし、影になっている場所や日暮れ時に撮影すると画像が暗くなりすぎてしまいますので気をつけましょう。
暗さについてはカメラの性能によるものでもあると思うので、もっと良いカメラを使用すればその点は解決できるかもしれませんので、カメラの選定時によく検討してください。

パラシュートカメラを使いこなすことができれば、あなたのSNSはさらに彩り豊かで充実したものとなり、沢山の「いいね」で満たされることになるでしょう……!
パラシュートカメラ、皆さんもいかがでしょうか?

以上、アドベントカレンダー17日目でした。

 

「祝」

撮影成功
★PIC00_1_2

[16日目] Cerevo製品ネタネイルコレクション2016

こんばんは。外に出るときもう一枚なかに着込もうかなと考え始めた広報のあくやんです。

わたしの妹がネイリストをしているということもあり、Cerevo入社前から変なおもしろいネイルをするのが好きです。
とはいえいわゆるネタネイルというのはまぁけっこうネタが尽きてしまいがちなのですが、いまのわたしはネタ切れということがありません。なぜならこんなにもネタ(製品)に囲まれているからです。やったね!

ということでただの自己満足はありますが、2016年どんなネイルをしてきたかを載せていきたいます。
 

CESネイル

1月は年明けそうそう、ラスベガスで開催されたCES 2016にCerevoは出展していました。
CES 2016では変形型ロボットプロジェクター「Tipron」、金属3DプリントパーツでできたIoT自転車「ORBITREC」が新製品として発表されました。なので、その2つの製品の一部もポイントにいただきつつ、CESカラーにしています。

akuyan _photoさん(@akuyan)が投稿した写真


 

DOMINATOR ネイル

2015年7月に発表したDOMINATORが2016年の春先に販売開始されました。
DOMINATORといえば、パラライザーからエリミネーターに変形するのはもちろんですがLEDをぜいたくに217個もつかっていることも特徴の1つ。なので、ネイルも光らせたいなとおもって蛍光塗料を調達してネイルのジェルとまぜてみました。夜ねるときに爪が光ってて1人で楽しんでました。

akuyan _photoさん(@akuyan)が投稿した写真


 

Listnr ネイル

周りの音をひろってサーバにアップし音を解析できるスマート・マイク「Listnr」ですが、実はCES 2016のときに製品版は初お披露目だったので、CESネイルにもポイントでこそっといれていました。見た目がまるっこくてかわいいのと発売を勝手に記念して改めてネイルに。
写真だとわかりづらいですが、白のフレンチの上にカラフルなチークネイルでListnrのLEDの雰囲気を出そうと試みました。

akuyan _photoさん(@akuyan)が投稿した写真


 

Cerevoネイル

6月1日に入社したので、6月にはいったのにあわせてCerevoネイルにしました。
それとあわせて3Dプリンタでネイルチップをつくったりできないかなぁと、遊んでいた写真と混ぜています。Cerevoに入るまで3D CADとか触ったことはなく、ずっとweb制作をしてきましたがCerevoの皆さんに色々教えてもらって少しさわれるソフトが増えました。

akuyan _photoさん(@akuyan)が投稿した写真


スノボの滑りを可視化するスマート・ビンディング「SNOW-1」、電動フル稼働「DOMINATOR」、IoT開発モジュール「BlueNinja」、Googleカレンダーと連携するスマート・アラーム「cloudiss」、サイクリング状況を共有できるスマート・サイクルデバイス「RIDE-1」のモチーフをちょこちょこいれています。どれがどれかわかったあなたはきっとCerevoマニアです。ありがとうございます。
 

MKZ4ネイル

ミニ四駆をスマートフォンで操作できるように改造するワークショップを2015年からはじめていましたが、とても好評いただいた結果、改造キット「MKZ4」として販売することになりました。もともとは社内のエンジニアさんが、Cerevoで売っているESP-8266を使って遊びで開発していたものだったのですが、まさかこんなに進化するとは。噂だとまだまだ進化中のようです。

akuyan _photoさん(@akuyan)が投稿した写真


Cerevoにいなければミニ四駆をつくることはなかったかもしれません。
 

Hintネイル

9月にめでたくクラウドファンディングを達成した、Bluetooth搭載のラジオ「Hint」です。
ニッポン放送社、グッドスマイルカンパニー社と共同して現在ごりごり開発がすすんでいます。製品版でラジオをきいたり、ビーコン機能でURL取得できるようになるのが楽しみです。

akuyan _photoさん(@akuyan)が投稿した写真


 

こういうネタネイルしていると、どんな風にネイルのデザイン考えてるのか聞かれることがあります。
何も考えずに製品みながら「ここはこうしよう」と決めていく場合もありますが、きもちに余裕があるときはこんなかんじでかんたんにデザインをつくります。

nail

実は親指だけはずっと、Cerevoのロゴマークをモチーフにしたフレンチネイルを続けています。
これはわりと普通にみてもオサレ感高いのではないかなとおもって、社内で流行らせるためにUVプリンタでネイルシールでも作ろうかなと考えたりしています。

ネタネイルでもいいかんじに!が個人的なテーマなのでネタだと他の人からわかりづらいときもありますが、ネイルなんて100%自己満足なのでいいんです。キーボードを打つときに、改札にSuicaをかざすときに、ペットボトル持った瞬間にテンションが上がればそれで十分です。
次はどのネタにしようかな。

[15日目] 不具合を発見したときのテストレポートの心得

こんばんは。稲垣です。組み込みプログラム担当として、CEREVO CAM live!やLiveShellシリーズなどのライブ配信系製品をずっと作っています。

今回は製品やサービスを開発するなかで避けて通れないテストレポートとかバグトラッカーのチケットとかを書くときのテクニックを社内向けにまとめた内容をTechBlogに持ってきました。題して「テストレポートの心得」。前半がテクニック本体で、後半が今回ブログ向けに追加した効能とか背景の解説となっています。それではどうぞ。

テストレポートの心得

テストの結果、不具合を見つけたら再現方法を報告しましょう。 この心得を読めばきっと突っ込まれないレポートができるはず。

標題と概要の心得

まず、どんな不具合を起こすかを端的に書いて標題にします。

標題だけで書ききれない場合は概要を書きましょう。1つの手順で複数の不具合が起きる場合、箇条書きにしましょう。

どこが不具合なのかはっきりさせて書くためには、どのような挙動に直すべきかを考えて、対比させてみるとよいかも知れません。

再現方法の心得

次に再現方法を記録します。再現方法は、読んだ人が同じように操作して再現できるように記録しなければいけません。

いろいろな解釈ができる書き方は再現方法の書き方としてよくありません。同じことをするのに複数の方法が考えられる場合、どの方法をとったか明記しましょう。それはつまり、何をどのように操作したか、何をどんな方法で観察したのかを説明するということです。操作だけでなく観察の方法もしばしば複数あります。

再現方法は事実の記録として書くべきで、全て過去形で「何々した」という記述の羅列になるはずです。タイミングが重要である場合 (タイミングによって再現しなかったとか)、「すぐに何々した」とか「何分間待ってから何々した」などをきちんと記録しましょう。再現方法を書いたら、その方法で本当に再現するか試してみましょう (ただし正常な動作を続けられなくなるような重大な不具合は早めに報告した方がよいでしょう)。

何回実験して、何回不具合が再現したかを記録しましょう。1回試して1回再現したのと、10回試して10回再現したのとは違います。

よくない記録の例

「動かなかった」
「何々しなかった」

期待したとおりに動かなかったことは、不具合として報告されている時点で自明です。このような記述から読み取れるのは、あなたの願望と、それがそのとおりにならなかったということだけです。

実験の結果には「どうなったか」を記録するべきです。「どうならなかったか」は書かないとそのほかの事象とまぎらわしい場合だけ記録すれば十分です。たとえば天気の記録を付けるのに、「雨は降らなかった」とだけ記録することがあるでしょうか? 必ず「快晴」「曇り」「雪」などと実際の天気を記録するはずです。

考察の心得

最後に、なにか考察を書きたければ書いてもかまいません。最後に書くのは、事実の記録である再現方法とあなたの推測を区別するためです。事実と想像を混同してはいけません。

不具合の原因についてなにか推測したのなら、それを検証するための実験を考えた方がよいでしょう。

FAQ

これは本当に問題なのか? と思ったら

「俺がルールだ」と思っていただければ結構です。これっておかしいんじゃないの? と思う部分はきっと他のユーザもそう思うでしょう。そういうところには直すかマニュアルやFAQでフォローするかの対策をすることになります。

再現条件をどこまで絞り込んでチケットにするか

必要十分条件を最初から見つける必要はありません。再現方法には事実だけ記せばよいのですから、十分条件が分かっていればよいのです。たとえば10分しか待つ必要がないことが後から明らかになるとしても、30分待って再現したのならまずはそう書けばよいのです。

解説

心得編はいかがでしたか。基本的には大学なんかで実験レポートを書くときに教えられることだったんじゃないかと思いますが……。ここからは背景の事情とかの解説編です。

複数の方法

LiveShellみたいな製品を作っていると、たとえばある設定を変える操作がDashboardからでもできるし、本体のキーを押してもできるということがあります。そして片方でしか問題が起きないことがあったりします (大抵両方で起きます)。本体のUIも頑張って作ってますから使ってください。

観察の方法が複数あるというのも同じ事情です。たとえばビットレートの表示はDashboardにもあるし本体にもあります。これがDashboardの表示だけおかしいとなると、web側の問題である可能性が高いので組み込み担当はホッとします。どこが問題か分からない書き方をされると余計なところにまで無用な不安が拡がります。

過去形で

過去形で書くのは科学的に大変重要なことです。現在形で書くとどうなるか。「フリーズする」。今まさに目の前でフリーズするってときだけは適切な言葉です。しかし何もないのにフリーズするフリーズすると言うと、それは公理や定理の書き方です。つまりそれが真実であると主張していることになります。「お前のプログラムはフリーズする……それが永遠の真実、世界の理 (コトワリ)、変えられない運命なのだ」。呪いですね。プログラマに恨みでもあるんでしょうか。

これが過去形で書いてあると、途端に過去の一個の事象に格下げとなります。あのときはフリーズした。でも将来は分からない。他の人が操作したら違う結果になるかも知れない (ヒューマンエラーだ!)。一挙に謙虚になりました。美徳ですね。

「『フリーズした』なら使ってもいい!」

何回実験したか記録する

サンプリングというのは回数を増やすほど信頼性が高くなります。1回試して1回起きただけだと、追試してみたら本当に1回しか再現しないこともありますし、忙しいときはそんな再現するのかしないのか分からない事象にはなかなか手が出せません。全部の個体で起きるとも限りませんしね。これが10回試して10回再現したとか百発百中とかになると、自分の個体でも出荷した個体でもそこでもここでも再現する可能性が高まってきます。ヤバい。

よくない記録

「動きません」。ありがちです。エラーメッセージくらいは報告してほしいものです。エラーメッセージの目的の半分は報告してもらうことにあります。ちなみに残りの半分は「やさしさ」です。解決の糸口になりそうなことも書いておきました。できれば自力でなんとか。

「フリーズした」。「画面が動かなくなった」と同義です。「○○しなかった」の報告は情報量が少なくてツッコミ返す必要があるから手間なんですよね……本当に何をしても動かなかったの? 何をしたのか列挙してみて? なんだACアダプタの抜き差しを試してないじゃあないか。ホラ、インジケータが変わった。フリーズはしてないでしょ。使いものにならないことには変わりありません。でもネチっこく絡まれます。

最後に

「過去形で書け」とか大学で実験レポートを書くときに必ず指導されることで、リアルに「あっこれゼミでやったやつだ!」と思える内容だったかも知れません。社会人の方々には昔を懐かしみつつ、一つでも「あれはそういうことだったのか」と納得していただけたら幸いです。まだ学生の皆さんはしっかり勉強して、勉強したことが役立つ仕事ができるように頑張ってください。この心得があなたの心に残って、素敵なレポートライフの一助となることを願っています。

Happy Hacking!

[14日目] 海外へのフライトでスーツケーツがなくなったときの対応あれこれ

Blogは書いたことがないのでとても緊張しています、海外営業の三寺(みてら)です。
今年は4月から色々な国に出向きました。1年を振り返ると欧米をはじめとした色々な国へ行き、なかでも初めてアジア圏で仕事ができたのはとても良い経験になりました。

20161206_002803981_iOS

さて、普段涼しい顔をして海外出張に行っているのですが、実のところトラブルも多くあります。
今回は、パスポートや財布をなくす次ぐらいに面倒くさい「預けたスーツケースが紛失した時」について、発生した際の対処方法とダメージを最小に抑えるコツについて書こうと思います。

スーツケースがなくなったらどうするか

スーツケースを紛失する一番よくあるパターンは乗り継ぎ時、次の飛行機に載らなかったというものです。
機内手荷物だけで済むフライトもあるかと思いますが、メーカーにいるとサンプルや製品を持って行ったりする事が多くそんなに身軽に行ける出張はほぼ0に等しいです。大体、乗り継ぎ時間が1時間未満の場合紛失する可能性が飛躍的に高まります。
また空港のシステムエラーで乗継空港の登録自体が間違っている場合もあります。これは防ぎたくても防げない一番最悪パターンです。
これを未然に察知するには荷物の預け入れ時、チケットカウンターで預け荷物と引き換えにもらったレシートをその場でチェックすることです。ただこれは空港のIATAコードを知らないと判別がつきません。IATAコードとは、成田であればNRT、羽田であればHNDといったアルファベット3桁で表す空港識別コードです。もらったレシートに記載されたコードが自分の乗り継ぐ空港と違うコードだった時があり、もらった際に気づくことができず紛失してしまいました。

さて本題はここからです。スーツケースをなくしたときにどのように対処すればいいでしょうか。
1回の出張で2.5回もスーツケースをなくされた事がある私の経験談から、申請の流れをお話しさせてください。

20161204_073300802_iOS

どこで紛失を申請するか

どの空港でも同じですが、パスポートコントロールを過ぎた手荷物受取所(Baggage Claim)のどこかにそういった荷物のトラブルを相談できるカウンターあります。使った航空会社によって申請カウンターが異なりますので、自分がどの航空会社を使ったのかは良く覚えておきましょう。深夜になるとカウンターに人が少なくなるので下手をすると数時間待ちになります。
ええ、深夜で数時間待ちです……。

大体の場合、航空会社が契約している紛失(Lost & Found)を専門に扱っている業者とのやり取りになります。

申請方法

カウンターにいくと書類を渡されるので、個人情報と便名を一通り申請書に書いて署名をします。そしてスーツケースの判別に関わる、色、形、ブランド、大きさなどの質問のやりとりがあります。スーツケースの形はコードになっているようで、それが書類に記載されます。2輪のキャリーケース、4輪、箱型など様々な識別コードがあり、これは世界共通なのだそうです。

申請後について

質問が完了して手続きが終わると問合せ番号と窓口の連絡先をもらうことができます(一部もらえない会社もあります)。
連絡先をもらったら、ほぼ数時間ごとに業者へメールをして状況を聞きながら、自分の滞在先に送って貰う様に手配しないといけません。これが海外出張だと拠点が目まぐるしく変わるのでなかなか難しくなります。
某国では結局滞在先には届けられる時間がなかったので、次の日の帰国便に載せて貰う様な手配になった事もありました。

毎日結構な数紛失はあるようです。そのうち、完全に見つからないパターンも我々が思っているよりも多いという話をちょうど先日なくされたタイミングで成田空港の職員の方に聞きました。

ダメージを最小限に抑えるには

スーツケースには必ず判別出来る様なタグを付ける

名前が書いてあるタグは非常に重要です。ユニークであったりするとすぐにわかるので良いです。また行く前に写真を撮っていると良いかもしれません。

重たくても重要なモノはスーツケースには入れない

よくパソコンやカタログを入れてしまったりするのですが、商談するのに必要なものはなるべく手荷物で持って行くのをオススメします。なくしても最悪なんとかなる、という状態にしておくとよいでしょう。

機内手荷物に食料と歯ブラシ

私は軽くて腹にたまる煎餅を食料として出張中は常備しています。私的には味も濃い「技のこだ割り 醤油せん」が気に入っています。
フライト後にスーツケースの紛失申請と続くと、相当疲れているはずです。なくしたものがいつ出てくるかわからないので気が休まらず本当に食べ物は重要です。食べた後は歯ブラシです。ただ歯磨き粉は手荷物検査でいちいち出さないといけないので個々の判断で。

最後に

さて、Cerevoではこういったトラブルも含めてそれを楽しみながら一緒に働ける仲間を募集しています。私は海外営業ですが今募集しているエンジニアの世界も予期せぬトラブルが起こります。
その中で落ち着いて臨機応変に出来るようになる対応力を磨くのも楽しいかもですよ。

[13日目] Cerevo的 トップエンジニアになる方法

アルバイトの中島駿太朗です。主にメカ設計をやっています。
静岡の大学で機械工学を3年間学んだあとに休学してCerevoで修業中です。

 

今回は9月7日にNHK総合のクローズアップ現代+で放送された「逆転ホームランなるか?日本の”新・ものづくり”革命」の中でトップエンジニアとして紹介されたCerevoのエンジニア陣について書きます。

日々Cerevoのエンジニアと接していると「あなた、そんなことまでできるの!?」と驚くことや、「ちょろっと遊びで作った〜」という物が「スゴッ!!」と感じることが多くあります。ただそれは私がエンジニアとして未熟者だからなのかCerevoだからなのかはCerevo以外のエンジニアさんと仕事をしたことがほとんどないのでわかりません……

とにかく、まだまだエンジニアとして未熟な私としては、Cerevoに在籍するようなスキルフルなエンジニアはどうやって出来上がってるのかな?、というのは気になるところです。というわけで今回Cerevoエンジニアのみなさんに以下のようなことを聞いてみました。

  1. 現在使用する知識・スキルを獲得した場所は?(計100の比率で)
    1. 大学など学校
    2. 大学院
    3. 前職(Cerevo以外)
    4. Cerevo
    5. その他(趣味・独学など)
  2. オススメの知識・スキル獲得法
  3. 専門分野でオススメのWebサイトや本(コンテンツ)
  4. その他(自由)

現役エンジニアの感じていることを聞くことが出来たと思うので、エンジニアを目指す人・別ジャンルにスキルの幅を広げようとしている人の参考になれば幸いです。

1. スキル獲得した場所

現在Cerevoで使用する知識・スキルをどこで身につけたか、についてです。

このエントリではCerevo内で大まかに分かれている以下の担当ごとに話を進めていきます。

  • デザメカ(デザインとメカ設計をする人達)
  • アプリ(Webサービスやスマートフォンアプリ、サーバ、データべースを扱う人達)
  • 組込みソフト(製品に搭載するソフトウェアを開発する人達)
  • 電気(回路設計、基板設計、部品選定をする人達)

※上記、大学院の項目をAの「学校」に含めて書かせて頂きます。

まずエンジニア全体の結果です。

Q_All

回答数24

全体で見るとこんなに綺麗に4分割になるとは……驚きでしたw

続いて上記4つの担当を順番に見ていきます。

Q_design_mecha

回答数7

Q_application

回答数8

Q_embedded_software

回答数5

Q_electric

回答数4

各担当に分けてみると、それぞれ特徴があるようです。

※回答人数が限られる事、外れ値など統計上の処理を行っていない事から、正確な傾向が表れているとは言えないかと思います。あくまでCerevoに在籍するエンジニアについて得られた結果である事を理解した上でご参考ください。
一人一人の比率を詳細に知りたい方はこちら→アンケート結果

デザメカ担当の自分としてはデザメカの人達の前職(Cerevo以外)の比率が大きいのは「やっぱりか」という印象です。というのは実際にCAD上で製品設計をした時は完璧なつもりでも、出来上がってきた試作品がダメダメという失敗を私自身が現在進行中でやってしまっているからです……その失敗から自分の設計の見落としポイントを学ぶことが多いので、そのサイクルの経験が多いほどCAD上での設計の見落としポイントが減っていくのだろうなぁ、と思います。ただその失敗をするとお金と時間が吹っ飛ぶので、なかなか個人や学校でその経験を数多く積むのが難しいのかなという印象です。

上の結果から考えてみると、各分野どこで専門知識・スキルを学ぶのが良いのか、ヒントになるかもしれません。

技術の変化が速い分野は最近(つまり前職やCerevo)に得られたスキルであったり、作る上で必要となるものが比較的安価に手に入って趣味になるスキルであったり、といったような様々な要素で考えられると思います。

またCerevoに入ってから今までとは違う分野も担当するようになったということが多くあるようなので、それも比率に大きな影響があるんじゃないかと思います。例えばデザメカで、デザインだけを担当していた人がCerevoに入ってからメカ設計もやるようになった、とかその逆とか、よくあるようです。

2. 知識・スキル獲得法

続いて、オススメの知識・スキル獲得法を聞きました。ここでは今現在Cerevoで使用する知識やスキルを身につける上で効率が良かった方法や、今でも仕事中に分からないことがあった時にどうするか、を聞きました。

 

まず担当分野に関係なく支持が多いのが次の2つです。

・自分で手を動かしてやってみる(作ってみる、使ってみる)

・ググる

何はともあれ自分で手を動かして作ってみる(使ってみる)。わからないことがあれば、とりあえずググる。以上に尽きるようです。

 

自分で手を動かして作ってみる(使ってみる)というのは、本や雑誌、Webサイトなどの資料を読むだけにとどめないという意味です。

例えば、作ろうと思っているものに似た製品を分解して色々な視点から観察し、仕組みや設計意図を考えてみる。プログラミングをするような分野ではサンプルを写経するところから始める。なるべくそこから発展させてサンプルにないオリジナルのものを小規模でもいいので作ってみる。という意見がありました。

 

その他の回答を以下にまとめておきます。

  • 知っている人に聞く(答えを得る最短ルートですが、聞くのは失敗してから、という意見も…)
  • いろんなジャンルの人と突っ込んだ話をする。ベテランの話はオモロイ。
  • 自分で試した時、そのブログを書く。(後々、過去の自分に助けられる)
  • 社外の勉強会に参加する。発表する。(その道のトップレベルの人に教えてもらえる)
  • 学校の勉強をちゃんと学ぶ。
  • 関連する本を読む(基礎固めとして読む。)(本はわからなくなったら素直にあきらめて3か月くらいしたらまた読む)

3. オススメのコンテンツ

次に専門分野で参考になったとか良質だと思うWebサイトや本を紹介して頂きました。

ここでもGoogleを推して下さったエンジニアが何人もいたので、Googleでの検索能力を上げるのは必須スキルなのかもしれません。

その他、以下のようなものが回答として上がりました。

4. その他

最後に、何か伝えたいことがあれば……ということで自由に答えて頂きました。
担当分野に関連がありそうなものは回答者の担当を記載しています。

「遊び・趣味はプラモとかラジコン、ゲームすらも意外と仕事にフィードバックできる。面白いと思ったことが一番身になります。」

「引き出しは増やしておくほうがいい。後で役に立つかどうかはそのときにはわからない。」

「気になったもの(ガジェット、スマホ、アプリ、電子工作キット、PCなど)は理由を付けて買って散財しておくと、いつか役に立つかもしれない。」

「とにかく手を動かして相場感とネタを身につけておくと、いつか役に立つ。」

「やりたいこと実現するためには、目の前のことを積み重ねて落とし所を見つけること。」

「自分の触った事のないジャンルは結構アイデアの宝庫。」

「電気・メカ・ソフトを自分でやることでエンジニアとしての視野が広がる。」

「なるべく曖昧なワードでググるといい。」

「エンジニアは特に開発を進める上で先の日程が読みにくい(だいたい遅れる)・成果が数値化しにくい。 だからこそ自分のモチベーション(軸)が何かを早く見つけて伸ばすことが大事だと思います。」

「自分が苦手そうな人にあえて話をしにいって人見知りしないようにする。(プロマネ兼任)」

「技術の変遷が速いので臨機応変な適応力が必要。深くマスターするよりいろんなものを即自分の道具として使いこなせるような訓練をしたほうがいい。 ただ、Linuxやネットワークプロトコルなどの知識はずっと役に立つ。(アプリ担当)」

「何より先に熱設計をやるべき。(電気担当)」

「深圳を上手く使え。 ドル円105円くらいになれ。」

「向上心のないものは馬鹿だ。」

「運動、瞑想、睡眠、野菜350g。」

「追い詰められると大体、なんでもできる。」

「楽しく学べ。」

 

以上、Cerevoに在籍するエンジニアが仕事に使う知識・スキルを獲得する方法について、まとめてみました。
エンジニアを目指す同志の皆さん、とりあえず自分の手を動かすところから始めていきましょう!