ケータイが、なぜ、組み込みに分類されるか、わかるような気がする例

　組み込みなんかの調査をみると、ケータイがふくまれていることがあった気がします。
　今まで、「なんで、ケータイが組み込みなんだ？」と思ってたけど、こんなことがあって、たしかに、そんな気もした。。テストなんかは、組み込みっぽい感じになるのかも？

---

　ある会社のカメラは、非常に短時間に、カメラのインスタンスを生成、リリース、生成、リリースとくりかえすと、ちゃんとリリースしているのに、メモリフルのエラーになります。

　このとき、リリースしたあとで、タイマーをかけて、500ミリ秒とか、１秒とか待ってから生成すると、うまくいきます。

　つまり、カメラのコプロセッサと、本体のほうの、同期がとれてなくて、リリース命令をかけた時点では、完全にコプロセッサのほうが開放できていないから、そのあと、生成命令が来ると、メモリーフルになっちゃうんじゃないかなあ？？

---

　こんなのを見ると、組み込みのテストのときみたいな、タイミングの調整をするかんじのテストになりますよね。

　業務アプリなんかだと、境界値チェックということで、境界値ぴったりで、エラーになるかどうかってやるけど、組み込みのようなやつで、センサーと処理部分が分かれているとき、センサーに、境界値ぴったりの時間で、信号が入ってくると（タイマーで２０秒というとき２０秒ぴったしみたいな）センサーのほうでは感知するんだけど、アプリのほうでは、時間内に検知できなかったものとして、動作してしまうみたいな。

　そうなると、矛盾が起こらないように適当じゃない、適切に調整するけど、そんなかんじっす。
　ケータイのカメラの場合も（ただし、あるメーカーの場合。ほかのメーカーはＯＫ）

　うーん、そんなところが、ケータイも組み込みなのかな？

ＮＨＫが語学講座をネットラジオで放送すれば、ポッドキャスティング広まると思うが、問題は必要性

周りが使っているから…、7割以上が「理解していない IT 用語使う」
　という記事がありました（ここ）
　ここの中で、ポッドキャスティングがでてくるんですけど、私もいまひとつわからない。。。
　そもそも、ネットラジオで聞きたいものがない。
　だから、ポッドキャスティングをしない。
　なので、意味もわからない。。

そんなノリだとおもうんですよ。少なくともウィリアムのいたずらは、そうだ

---

　でも、ＮＨＫラジオの英会話入門・中級・上級などがネットラジオになって、ポットキャスティングできたら、話は別です。

　ラジオをＩＣレコーダーに入れるというものもあるんですが、ラジオって、建物の中によっては、よくはいんない。。。

　そこで、ＮＨＫが、ネットラジオに乗り出せば、べんりべんり！

　っていうことで、みんな利用すれば、意味がわからない人も減ると思うんだけどな。。。

　ただ、この場合、問題がある。

　もし、ホームページで、英会話入門・中級・上級などを、公開してしまったら、わざわざ、ネットラジオを聴く必要性がないじゃん。そっちのほうがいいじゃんっていうことになる。。。
　
　うーん。

社長さんと、従業員のビジネスモデルの考え方の違いと、ソフト開発上の対応について

　土曜日のビジネスモデル的なお話が、意外と見てる人多かったので、今日は、その前提となる、

　社長さんと、従業員のビジネスモデルの考え方の違いと、
　ソフト開発上の対応について

を書きたいと思います
（ただし、社長さん＝管理者、従業員＝作業・プログラムする人と読み替えると、この業界の常駐派遣（請負？）につながる話でもあります）。

---

まず、実は、（自分でも、最近、放送大学大学院の番組を聴いて、気づいたんだけど）ビジネスモデルには、３段階あります。

（１）事業計画書などに書くような、何を売って、お金をどうやって、いつもらうというモデル
　　　→モノ（サービス）とカネの流れ、
　　　　ホリエモンみたいな人や買収話で出てくるところ。

（２）その事業を実現するために、誰が、なにをやるかという、業務モデル
　　　→ここで、ヒトと情報が付け加わる。
　　　　システムの業務分析は、ここ

（３）さらに、そのヒトに、いくら払ってという待遇などのインセンティブを決め、組織を作る
　　　→これ自体はビジネスモデルではない。
　　　　ただ、この部分がないと、ビジネスモデルが完成しない。

　で、社長さんなんかが決めるのは、まず、（１）の事業計画です。

　で、このあと、（２）をきめないことが多いと思います（あんまり、偉いヒトは、作業員のことなぞ、決めないというか、考えないのだよ。。）

　そこで、社長さんなどは、（３）の人集めに走ってしまいます。

　一方、一般に従業員が考え、実行するビジネスモデルっていうのは、（２）のことです。
　でも、事業のはじめに、（２）について、組み立てていないので（実は、ヒトが決まっていないので、組み立てられないということもあるが）、本当に、事業内容が、業務に落とせるかどうか、落とせたとしても、その人でできるかどうかは、わからないという状況にあります。

　逆に、既存の組織などで、（２）がしっかりしていると、同じ業種では、似通っているところも多いため、事業計画が多少変わっても、悪くても、売れてしまう（問題なくできてしまう）というところがあります。

---

　ということで、ベンチャー企業などでは、（いや、ベンチャーでなくてもそうなんだけどね）上層部が（１）をきめてから（３）にいってしまい、そこで満足しているため、（２）の業務内容はぼろぼろというところもあります。そうすると、システム開発側で、（２）の通論的な知識をもっていないと、話がゆらゆらゆれて、仕様が固まらないということがあります。

　アジャイルを好む企業は、実はこれ！なんていうことがあります。

　事業内容を組み替えても、必ずしもシステムを組み替えないといけないわけではなく、また、事業の詳細なコンポーネントは、不変なことが多いわけです（じゃないと、商奉行とか、弥生販売とか、成立しなくなってしまう）。だけど、（２）の部分が決まってないと、ゆれます。そうすると、仕様変更が頻繁に起こってしまいます。よくいう、「うち独自のやりかた」というのはなんてことはない「うち独自のごまかしかた」というケース（ただし、ごまかすとはいわれず、臨機応変に処理するとか、柔軟に処理するといわれる）

　ちなみに、じゃあ、開発では、（１）については、出てくるのかというと、出てきます。
　その店の商品構成とか、販売方法（支払い方法）などがそれにあたります。
　ヒアリングの中心は、（２）を聞くことですから、（１）に関しては、ヒアリング前に資料をもらって、調べておく必要があります（商品カタログと、帳票から調べられる）。

　そして、この内容は、用語集に載ります。

　なんとなく、とりとめのないはなしになってしまいました（＞＿＜！）
　なんで、とりあえず、ここまで。