技術開発と製品開発とビジネス開発は全く別物だけど混同されていることが多いという話あらましお仕事で様々な立場の方とお話しする機会があるわけですが、以前からどの階層にいる人にも共通した「技術開発と製品開発とビジネス開発が同時に出来るのではないかという思い込み」を持っている方が非常に多い事に気付きました。おぼろげながら自分達で考えている製品像が浮かんだとしましょう。この製品像は、それこそ具体的になっているものではありませんが、必要な機能や性能やインターフェースが何となく整理できた状態になっていたとします。そこで必要になる機能を実現するための技術的な要素は、少し頑張れば実現できそうな事ばかりで、さっそく製品開発をスタートする事にしてしまいます。このシチュエーションで起きるのは以下です。製品の機能を仕様にまとめる仕様が好ましいものと判断され/判断し、計画をスタートさせる仕様を満たす機能を実現できるように設計を開始する設計が完了したので実装を始める(ハードウェア、ファームウェア、ソフトウェアは問わない)実装が完了したので製造する(ハードウェア、ファームウェア、ソフトウェアは問わない)製造が完了したので評価する(以降、付随したプロセスに続く・・・)何もマズい事が起きていないようにも見えます。実際に技術開発と製品開発とビジネス開発を混同している人達に起きる悲劇の一例を挙げます。出来ると思っていた技術的な要素に意外な課題があった技術的な要素に絡む問題のために実現すべき仕様の一部が実現出来なくなった仕様の一部が無くなったが、市場に出したい時期を明らかにしているので出す事にした実現できなかったのはエンジニアリング能力の低さだと誰もが落胆し真因にたどり着かない混同によって、どれもこれもが全て中途半端になってしまうのが最大の欠点です。ビジネス開発を混同してしまっている事にあります。当たり前の話ですが、製品を実現するために必要な技術要素について、事前に課題や実現性を吟味しておく必要があります。なければ製品の実現性すら不明のままで製品開発をスタートさせる事になってしまいます。このような組織にいたっては、製品開発を行う時点でビジネスまで混同して考えてしまっているので、全部が不透明感で一杯になる事になります。技術開発は、製品開発とは性格の異なるもので、将来何に役立つのかわからないが、魅力的な物事について事前に研究開発しておくものです。場合、これらは現場の技術者の個人的な興味に由来していたり、過去に失敗した製品の残骸からゾンビのように生き返って組織に残っているようなものだったりします。非常に重要な点ですが、これらは一般に組織的に必要性を認められることは少なく、たいていの場合アンダーグラウンドで活動する事すら認められないようなものだったりします。(そんな事をやっている暇があるのなら、別の事をやれというやつです。)もちろん、ニーズを的確に察知して必要になりそうな技術要素について研究開発する事も多いのですが、実際にそれらはビジネスへの発展を事前に考慮しているので、思わぬ発展に至るケースは少ないように思います。商品やサービスを実際に市場に出すために行う活動で、通常はビジネス開発との関係も持ちながら行われます。売れないものを作っても何もならないので、売れる前提でモノを作る事になります。実現性が非常に重要な点で、この時に初めて技術開発の成果物が価値を持ってきます。製品開発の段階では、明らかになった技術要素を用いる事ができるようになっていると失敗のリスクを低減できます。最近は様々な物事が安易に進む傾向があるようで、お金を積めば実現できると思っている方も多いのですが、実際に製品開発をするならば事前に積み重ねられた技術開発が伴っていなければなりません。なければ博打にもなりかねません。動くと思うけどどうかなー。ビジネス開発ビジネス開発では製品やサービスだけでなく、市場の動向や人々の趣味嗜好、その他さまざまな要素を踏まえて見えるものや見えないものまで作っていきます。重要な点ですが、技術開発はそれ自身が当初品質が低く、実現形態も最終品ではないので曖昧で、結果的にビジネス開発側では具体的な製品のイメージを持ちにくい性質のものです。ビジネス開発側に自分が位置している場合には、目の前で実現できているモノが、技術開発の成果物なのか、製品開発の成果物なのか、十分に理解した上でモノを見なければなりません。その点を見誤ると、将来の大事な要素を自ら見捨ててしまう結果になってしまいます。まとめじゃないまとめ沢山の失敗するプロジェクトと少しの成功するプロジェクトを眺めていると、ある一定の共通項が見えてきました。その結論の一つが上記の、技術開発と製品開発とビジネス開発を混同しない事。技術開発と製品開発を混同している組織は、製品開発で必ず失敗しています。その失敗の原因を現場の担当に押し付けてしまいます。実際に組織で起きているのは、単に十把一絡げに物事を混同してしまう思想の雑さ加減にあるのです。製品開発とビジネス開発も同様で、開発担当現場に一緒にビジネスまで開発させようとする組織すら存在しますが、エンジニアはスーパーマンではないので、小さなビジネスでまとめるなら別ですが、通常はうまくいかないでしょう。モノを作るのが大好きな日本人ですが、世界中で見ると創造性や生産性は高くないのが現状です。うまくいかなくても分析すらままなりません。結局は「社員の能力」などと言い放つ方すらいるのですが、それでは問題が解決しないようなぁと考える今日この頃なのです。(Atom)自己紹介shinta基板が大好きな組み込み系エンジニア。電気図面を描いてPCB上に美しく配線できた時に何とも言えない快感を覚える。ソフトウェアとドライバが一式になったパッケージをダウンロードします。インストール後に本体を接続してソフトウェアを起動すると以下のような画面が表示されます。勢いよく「改良しました!」と宣言したh8writeですが、やっぱり書き込みに失敗するという事がわかりました。そもそも真の原因を掴めないまま改良したと言っても、何を改良したのか意味がわかりません。自分でもそんな突っ込みを入れたくなるのですが、その日はグ...システムにおけるレイテンシーとスループットの話題レイテンシーとは、あるシステムに何らかの入力を与え、それに対応する何らかの出力が出てくるまでの時間(遅延量)を指します。ある処理の実行を指令してから実際の結果が得られるまでに250ミリ秒かかったとすると、それは250ミリ秒のレイテンシーを持つシステムという事になります。放置を防ぐアイデアの1つとして「具体的な目標に繋げる」というものを挙げました。アップデートしました。このアップデートにより、以下の動画で示すような長い曲でも難なく再生させる事ができるようになりました。mkIIは便利なのですがオンフィールドで書き換えるには不便ですし、ユーザに書き変えを頼むわけにもいきません。Atmelが公開しているアプリケーションノートAVR109に自己プログラミングがありましたので試してみました。LPC824を使ったサウンドモジュールMicroSoundModuleを開発していました。このサウンドモジュールは、コマンドを受け取って色々な再生を行うもので、当初はこのコマンド処理部分の実装にNT-Shellを用いる計画でした。BlackTankには有機EL液晶が搭載される予定です。接続部分はFPCになっていて、例によってFPC用コネクタなのですが、最初の実装は思いっきり失敗してしまいました。猫も杓子もIoTと皆さんが仰るので、その声が大きくなればなるほど自分は遠ざかる方向で生きていたのですが、そうすると完全に煙に巻かれたお爺さんのようになりまして、今は世の中が進んでおるんじゃのぉと言うだけの人です。moduleにブートローダを載せる(AVR109対応)随分前に対応しようと思い立っていたAVR109にようやく対応させた。以前やった時にうまく書けなかったのはボードのクロック精度が原因。ここ数日モニタを実装していて、思った以上にRC内蔵クロックの精度が悪いことが分かった。エコーバックのテストでやたらと文字が化ける。