Embeddedの行く末
いつも通り、業務で商品のシステムをデザインして、マイコンにソフトウェアを組む必要が出てきて、内部ではリソース不足なので外に出すと言う作業。その合間、合間に前回のRFP, 要求定義の失敗を少しでも減らそうと今日また本を読んだけれど、こういう事を考えてるといつも腑に落ちない。なんだかなー。。って感じになります。 今日読んだ本のRFPのプロジェクトのターゲットはいわゆる情報システムで、データの入力/管理/参照、またクラウド化などなどサーバー上で動作するプログラムが成果物となるものなどが多いのかな? 私のいる世界はEmbeddedなので、プログラムの対象はマイコン。だからそういう観点では違うので違和感を感じている。。のかと思っていたけど、そうじゃなかった。 私が外注に出すことになるのは、技術的にシステムが組めないワケではなくで、人手が足りないか、外に出した方が責任リスクも分散できるし。。といった理由の方が大きいのではないかと思う。身内でハード構成を考えるのでついでにソフトの構成も考えてしまいます。なので、本当は自分たちでソフトを組みたかったりするんだけど、ソフトのみ外注に出したりします。全部が全部、できないから。 外に出すときはもちろん目的を満たそうと要求を出します。 ベンダーからは機能実装の可否と設計書、スケジュールなんかが返ってくることになると思います: 要求の整理 機能の調査 設計 製造 テスト 製造、腑に落ちない原因はこれなんじゃないか?と思い始めました。実際に設計通りにコーディングをすることを「製造」行程と呼びます。あたかも工場であるかのよう。。 たぶん、ここです。「これ、本当の工場で使われている様なロボット、まだソフト業界には登場してないの?」この疑問。 ちょっとした治具を作るときにマイコンなんかを使いますよね?で、「前にも同じようなの作ったな〜」と言いながら作り上げますよね?ここって絶対自動化できるはずです、将来。決まり切ったルーティーンを繰り返す行程は工場では人がやるべきでないですよね、機械の方が寝ずに働けますし、ミスもなく正確で進捗予測が立てやすいですから。 ソフトの世界の製造ロボットを作るの、Embeddedの世界だと意外にいけるんではないか?と思います。 最近のマイコンのコアはARMが主流ですし、似たような機...