ジョブ理論とDSair

ネットで、ニュースを見ていると「ジョブ理論」という言葉が目に付きました。

自分の主観で要約すると、顧客が何故商品を買うのか、本質を探る理論、というところです。例題のミルクシェイクの話がアメリカらしくて、面白かったですが、確かにマーケティング手法としては面白いな、と思いました。

DSairを皆さんが”雇う”理由を考えると、以下のことがあるのかなと思いました（他にあればご指摘ください）

■動き回り系
・あちこちに動き回って鉄道模型を走らせたい
・自分のジオラマをいろいろな視点で見ながら走らせて楽しみたい

■みんなで遊びたい系
・みんなでワイワイと同じ線路で複数車両を走らせたい（MECYさんがまさにそうです）
・子供と一緒に車両を走らせたい（何台もスロットル持ってない）

■自慢したい系
・カッコイイiPhone / iPad / スマホでドヤりたい（スタバのMacbookみたいな）

■窮屈系
・コマンドステーションを置く場所がそもそも無い
・固定の場所でコマンドステーションで動かすスペースが無い（部屋狭すぎ）

■広すぎ系
・ジオラマが広すぎて、コマンドステーションのそばにいるのがイヤだ

-------------------------

KATOのスマートコントローラが出来ないで、DSairができることは、２番目の「みんなでワイワイ」でしょう。レンタルレイアウト屋さんで、ケチっぽいですが１つの路線だけ借りて、みんなで複数車両で動き回って遊ぼうと思ったら、DSairしか選択肢がありません。

人柱という表現について

DSairのキット頒布で、アーリーアダプター(早期購入層)の方々を人柱呼ばわりするのは何事か、とご指摘を受けました。

人身御供で命を捧げるようなことを、ユーザーに求めているという誤解を与える表現も含まれているのは、ご指摘の通りですので、申し訳ありません。

念のため、解説させていただきますと、ネットで「人柱」という言葉は、特にデジタルグッズ、ガジェット系では頻繁に使用します。

キーワードノート: 人柱とは？
https://kw-note.com/internet-slang/hitobashira/

DSairの初回キットは、価格を大幅に引き下げる代わりに、失敗して使えなくなってもいい(お金が無駄になってもいい)という、かなりの犠牲を要求しているので、このように表現とさせていただきました。

今後は、気をつけて命名させていただきます。

FlashAirのOEMカスタマイズサービス

FlashAirのOEMカスタマイズサービスが始まっているようです。模型用途では使うつもりは無いですが（ソフトハウスに頼めるようなお金は稼げてない。）

一応、電機屋を長くやってる人間から言わせてもらうと、この情報量では、初期段階の検討ができない。FlashAirの内部にはマイコン、ROM、RAMが入っていて、さらに無線の処理部もあって、かなり複雑です。

今は、コストと性能のバランスを徹底的に追求することを求められます。なので、FlashAirでどれくらいの機能を実現できるか、詳細に検討して実現性を確認してから、見積もりなどを行っていきます。

また、基本的には、FlashAirの内部のソフト開発ツール類は公開してもらわないといけないです。ここにしか頼めませんよ、では話が通りません。ぶっちゃけ、技術力のある懇意の外注ソフトハウスは電機メーカーも抱え込んでいるので、そこに依頼したいというのが心情です。

FlashAirを使って、とりあえず欲しいのはDBサーバーです。簡易的な機能で良いので、データを保存できるようにして欲しい。しかも同時アクセスを加味したものです。共有メモリも癖があって、保存してもいったん空読みしないとうまく反映されなかったりするので、ちょっと使いにくい。マイコンと受け渡すには良いんですが、接続したスマホ同士でデータを共有するにはやっぱりDBの方が使い勝手が良い。

あと、産業用イーサ(EtherCAT、Profinet、CC-Link)は今後、TSNベースに移行するので、ここを抑えておくのも重要です。

と言うことで、FlashAirは、カメラ向けのSDカードから、もっと進化できるポテンシャルはあるので、IoTを軸に進化していけば良いと思います。Luaも悪くないけど、やはりスピードが求められる部分はたくさんあるので、内部のマイコンで作り込んでおきたいです。

・・・模型用については、W-04でひとまず問題ないと思います。模型側がまだついてこれてないですし。

デジタルとアナログ

Taka@さんが、重連時の進行方向を物理的に逆にするアクロバティックな操作を、エラーや不具合というように指摘するのは何でだろう？と、不思議に思っていたのですが、よく考えると、アナログ鉄道模型をベースに解釈していたからだと気づきました。

※Taka@さんの指摘は、エラーでは無いですが、重連機能として不足しているのは間違いの無い指摘です。コミュニケーションがちょっと足りなかった（もっと髪を伸ばすべきだった）ということです。

アナログとデジタルって、実際には何が違うのか、ちょっとおさらいしましょう。
以下の図は、アナログとデジタルを説明する際に、電気工学の大学１年生で習う教科書に出てくるものです。



アナログは、線が連続的に続いています。この線を切って細かく見ても、線はずっと繋がっています。
一方でデジタルは、線を切る間隔というのが決まっています。これを不連続と言います。難しい言葉で言うと、離散、とも言います。

デジタルにすると、アナログの情報量が減りますが、人間が必要なアナログの情報量というのは、ケースバイケースで、そんなに細かい情報は要らないことも多いです。またデジタル化すると、コピーや改変、保存が非常に簡単になります。現代のデジタル社会は、まさにこの部分をおいしく頂いていると言うことが言えます。

-------------------------------------

で、そのデジタル化して、情報を保存する部分で、今回の誤解が生じているのです。

従来のアナログパワーパックや、アナログ車両（ただのモーター）では、車両の状態というものを保持していません。線路の電圧の極性と、機関車が一致しているかしてないかは、人間が配線し、人間が機関車を置いて判断します。

一方で、デジタルのコマンドステーション側は、デコーダが厳密に進行方向の基準というものを保持しています。どっちが正方向、どっちが逆方向か、デコーダを車両に入れると必ず決まってしまうのはご存じと思います。コマンドステーション側もそのデコーダの設定されている進行方向を基準にして制御を行います。

今回のトラブルのように、進行方向を物理的に逆にしたとき、人間の頭の中では逆にしたつもりになっていますが、コマンドステーションやデコーダにセットされている進行方向は、そのまんま逆にはなりません。

よって、きちんと、機関車を逆にした場合には、物理的に逆にしたことをコマンドステーション側（進行方向の逆設定機能）か、デコーダ側（CVで設定）かに明示して教えてあげる必要があるわけです。

人間はアナログなので、全て繋がっているように見えますが、デジタル機械は、設定されたものが全て基準なので、その基準を逆にすると、人間の意図したものと、機械の意図されたものがちぐはぐになってしまいます。今回のトラブルの原因というか、誤解はそこにあります。

ということで、何が言いたいかというと、次のFlashAirアプリで、コマンドステーション側に進行方向の逆設定機能を追加します、ということでした。

新年度

昼間の会社で、社内の辞令がたくさん出されてました。

先月末で定年や退社された方も大勢居ますし、一方で、一緒に仕事をしたことのある身近な先輩方が、課長になったり部長になったり、続々と出世してました。確かに、ちゃんと仕事が出来て、部下へのコミュニケーションもしてくれる人達なので、上がるのは当然だなとは思いました。