Embeddedの行く末

いつも通り、業務で商品のシステムをデザインして、マイコンにソフトウェアを組む必要が出てきて、内部ではリソース不足なので外に出すと言う作業。その合間、合間に前回のRFP, 要求定義の失敗を少しでも減らそうと今日また本を読んだけれど、こういう事を考えてるといつも腑に落ちない。なんだかなー。。って感じになります。
今日読んだ本のRFPのプロジェクトのターゲットはいわゆる情報システムで、データの入力／管理／参照、またクラウド化などなどサーバー上で動作するプログラムが成果物となるものなどが多いのかな？ 私のいる世界はEmbeddedなので、プログラムの対象はマイコン。だからそういう観点では違うので違和感を感じている。。のかと思っていたけど、そうじゃなかった。

私が外注に出すことになるのは、技術的にシステムが組めないワケではなくで、人手が足りないか、外に出した方が責任リスクも分散できるし。。といった理由の方が大きいのではないかと思う。身内でハード構成を考えるのでついでにソフトの構成も考えてしまいます。なので、本当は自分たちでソフトを組みたかったりするんだけど、ソフトのみ外注に出したりします。全部が全部、できないから。

外に出すときはもちろん目的を満たそうと要求を出します。
ベンダーからは機能実装の可否と設計書、スケジュールなんかが返ってくることになると思います:

• 要求の整理
• 機能の調査
• 設計
• 製造
• テスト

製造、腑に落ちない原因はこれなんじゃないか？と思い始めました。実際に設計通りにコーディングをすることを「製造」行程と呼びます。あたかも工場であるかのよう。。
たぶん、ここです。「これ、本当の工場で使われている様なロボット、まだソフト業界には登場してないの？」この疑問。

ちょっとした治具を作るときにマイコンなんかを使いますよね？で、「前にも同じようなの作ったな〜」と言いながら作り上げますよね？ここって絶対自動化できるはずです、将来。決まり切ったルーティーンを繰り返す行程は工場では人がやるべきでないですよね、機械の方が寝ずに働けますし、ミスもなく正確で進捗予測が立てやすいですから。

ソフトの世界の製造ロボットを作るの、Embeddedの世界だと意外にいけるんではないか？と思います。
最近のマイコンのコアはARMが主流ですし、似たような機能をつけたのがゴロゴロあります。実現したいUse caseは結構似てて、ハードの構成なんてほとんど定食状態だと思います。NFCはおとす？加速度入れとく？とかそんな程度な気がします。実際は機能部品として付けるペリフェラル部分はベンダーがARM用の制御ドライバなんかを提供しているところがほとんどでしょうから、このあたりもモジュールとして扱えてるはず。。。

今でこそ、人向けに要求を定義して、文書でやりとりしますけど、本当はユースケースと要求をある言語で記述したら、コンパイルされて必要なハードシステム構成が出力され、そのハードのシステムに対応したバイナリが出てくると最高ですよね。
たぶんもう誰か動いているんでしょうけど、ARMとWi-Fiを使ったシステムとかそんなどのデバイスにも共通しそうなフィールドから出てこないですかねー、こんなコンパイラ。
アンドロイドとiPhoneのアプリなんか、これで出来るべきですよね。UIのデザインと仕様が全て、みたいな。

もちろん、ほぼフルスクラッチで書いている組み込み機器も多いのでしょうし、コンパイラなんぞに任せたらハードの制御が出来んわ、と言う現実もあるんでしょうけど。
それでも「よく使われる人気の組み合わせ」なんかはあるだろうから、そこのペリフェラル間の制御などはみんなで作れば質も上がりそうですし。。。

そうなると今後、益々アイディアと全体のバランスが重要になってきますね。

そんなことを読みながら考えてました↓

図解入門 よくわかる最新RFPと提案書の基本と作成法―失敗しない情報システムの構築 (How‐nual Visual Guide Book)

佐川博樹

秀和システム

発売日：2011-06

ブクログでレビューを見る»

全体的にうまくまとまっていました。

RFPをどうして書くのか？
どうして意思の疎通に問題がでるのか？
どうしたら失敗を防げるのか？
などなど、著者が言いたいことは全体を通して筋が通っていて、最後までスッと読めました。