「日本人は人をほめない！！」と、日本人が（ほめないで）しかっている話

　Gooのトレンドブログランキングをみていたら。。

　Ｗｅｂ進化論の梅田氏の

直感を信じろ、自分を信じろ、好きを貫け、人を褒めろ、人の粗探ししてる暇があったら自分で何かやれ。
http://d.hatena.ne.jp/umedamochio/20070317/p1

というエントリが上位にきていた。。

うーんと、何が面白いんだろう。。

ふむふむ。

なるほどおお、みんなが面白いと思ったところがわかったぞお（＾＾）ｖ
（以下斜体は上記梅田氏のエントリより引用）


日本人は人を褒めない。昨日もLingrイベントで言ったけど、もっと褒めろよ。


って、みんなをしかっている（＝ほめてない）っていうところね！

もちろん、梅田氏は、論理的に考えると、ほめることができない。

なぜなら、梅田氏は、日本人である。
もし、「日本人は人を褒めない」のならば、梅田氏は、人をほめてはいけない。
なので、「もっとほめろ」としかるわけね。。。なるほどお。。。

---

って、そんな言葉遊びを書きたいわけじゃなく、
もちろん、「先ず隗より始めよ」みたいな、説教じみた話を書きたいわけでなく、

これをみて、昨日のワナゴナで、ドン小西が、若い人を珍しくほめていた！！

っていう話を思い出して、それが書きたかったんだけど。。

この話書くと長いんだけど、もうじき、安良城紅と辞書ネコのタンゴがやる、「新感覚・キーワードで英会話」が始まっちゃうんで、その話は、またこんど。

開発の初めから順番に書いていってみる その１１：立ち上げ（５）資源の配置。

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　今、プロジェクトの立ち上げから話を起こしているのですが、プロジェクト憲章、をつくって、スコープ定義をしてWBSを作りアクティビティ、つまりやることを挙げるところまできました。

　以前、順番を書いたところで言うと、「計画のコアプロセス」の（３）まできたので、今回は


（４）アクティビティ順序決定（タイム）
　　　「どのように」行うかについてきめたら、それらをやる順番を決める

（５－１）所要時間見積り
　　　「どのように」行うかが決まったら、それをやるには、どのくらい
　　　かかるかの所要時間をきめる（５－２資源計画とかかわる）

（５－２）資源計画
　　　「どのように」行うかが決まったら、それを、だれが、いつやるかを
　　　きめる。もちろん、人だけでなく、機材なんかも、いつ何を調達するか
　　　考える

について書きます。

---

■誰が、何を、いつ、どういう手順でやるかを決める

　以前までの段階で、やるべきこと＝アクティビティは挙がったので、それについて、

・「（４）アクティビティ順序決定」でどの順番にやるか決めて
・「（５－１）所要時間見積り」で、時間を見積もったら
・「（５－２）資源計画」でだれがやるか決める。。

てーんですけど、実際には、やる人がちがったら、かかる時間はじかうわけで、
で、かかる時間が違っても、終わりが伸ばせないとなれば、やる順番をいじらないといけないっていうことで、この３つは、相互に関係してしまいます。

つまり、アクティビティが決まったら、それを、誰が、いつ、どの順番でやるか考えるということです。

---

■考える順番

で、この順番は、

・まず、主要なコアとなるアクティビティを手順どおりに並べ、
・それをやる人（ふつうある程度できる人にコア部分をやらせると思うけど）をきめて、
・その人がやった場合の期間の見積もりをたてて

・残りのアクティビティ（作業）をテキトーに人を配置して、適切な順番で、あいている隙間に、順番が狂わないようにテキトーに入れる（適切とテキトーは使い分けてます。順番は適切に、正しくやる必要があります。それがあってれば、後はテキトーです）。

っていうふうに「決めるべきです」が・・・・

---

■でも、実際は営業の都合なのよね

　そーやってまじめに決めると、開発から見ると妥当な時間なんだけど、営業から見るとありえない時間らしく、結局営業に押し切られ、ありえない時間になるので、劇的な(自動変換とか）手法のギャンブルに出る。。ってことになることも多数だったりするわけです。

---

　ま、それはさておき、こんなかんじで、何を、いつ誰がやるか決まったら、それを、スケジュールと開発コストという形に纏め上げていきます。

　これは、次のお話の作業になるので、今回はここまでです。

ニンテンドーDSで動かすロボット

やっぱ、でてきましたね。
ここの記事
DSでロボットを動かす
http://www.gizmodo.jp/2007/03/ds_2.html
によると(以下斜体は上記サイトより引用）

「RoboDS」。オープンなプラットフォーム採用のロボ君です。

ロボット専用キットとコネクタ、あとはDSに繋いでプログラミングできるカートが付いていて、全部取り寄せると99ドル＋45ドル + 送料（海外は一律5ドル）かかります。

セットアップしてプログラムしたら、DSのWi-Fi接続経由でこの車輪のついたロボットが動かせる、という趣向ですね


だそうです。やっぱり、でてきましたか、ニンテンドーDSを使って動かすロボット。。

といっても、「ロボットお　（＾＾；）」という外観ですが。。
日本のメーカーが作るとなったら、もっとちゃんとしたのを作るんだろうな。

あ、ちなみに、これ、販売は日本じゃないです。

ここ
RoboDS
http://www.natrium42.com/shop/robods.php

法人もau、それも東芝端末に流れる可能性

　前に BREWフレームワークを開発」－東芝ソリューションっていう話を書いたけど、これによって起こる波及効果については書いてなかったので、今日はそれについて。。。

　そのまえに、そのフレームワークって言うのは、この記事です。
東芝ソリューション、携帯アプリ開発でBREWフレームワークを開発
http://japan.cnet.com/news/ent/story/0,2000056022,20345211,00.htm

---

　で、やはり、大きな効果は、これによって、Docomoからauへ顧客が流れるという構図が、個人だけでなく、法人にも起こり得る（それも濃厚に。。）ということだと思います。

　Docomoでも、auでも、ケータイを使ったアプリケーションを考えた場合、サーバー側でCGI等で行うのであれば、さほどの差はないです・・けど、たとえば、商品名などを表示したい場合、そのたびにパケットを飛ばしていたのでは、入力するたびに待ち時間が発生してしまう（＾＾；）。

　ということで、端末側に商品マスタや顧客マスタをもち、それを定期的に更新をかけたいわけなのですが、そのような商品マスタ、顧客マスタを持つ領域が。。。

Docomoのiアプリの場合、スクラッチパッドにもつことになるのですが、
　これは、DoJa-5.xでも、Jarファイルとあわせて、１メガ（１０２４K)しか、もてない。
（iアプリコンテンツの概要にある「iアプリコンテンツ開発ガイド for DoJa-5.x　詳細編」(PDF)の４８ページ下の表参照）
これでは、商品マスタなどを持つのは難しいっす。

---

一方BREWでは、もっと大きなファイルを持つことも可能っていうか、SDカードにアクセスできるわけなので、カードに入れちゃってもよいわけなのだが
・アクセス方法が、知られていない
・それ以外でいろんな制約がある
・そもそも、BREWで承認してもらってとか、アプリ作るのがたいへん（＞＿＜！）

っていう問題があった。

　逆に言えば、BREWにおいて、アプリが簡単に開発できるフレームワークが、開発者に分かる形で提示され、それで商人が取りやすくなれば、いっきにBREWアプリに流れ、法人市場の勝敗は決する。。って言ったら大げさだけど、そのぐらいの機能差はあった。

---

　しかし、なぜかいままで、KDDIは、このBREWでの法人向け開発のためのフレームワークをだしてこなかったというか、そこまでの情報開示も企画を出さない限りしてこなかった（でも、企画を出したくても、その時点では情報開示されてないので、企画の立てようがなく、立てられなかった（＞＿＜！）

　ところが、ここで、そのようなフレームワークを東芝が出して、特に（まだ見てないのでどれくらいのフレームワークかわかんないけど）これに沿って設計すれば、KDDIの承認もとおるし、業務アプリ作ってた人でも開発可能というレベルにまでなっているのであれば、一挙にそれを利用してケータイを利用した業務アプリ開発が現実的になるわけで、このインパクトはでかい。。。

---

　だけじゃない。

　実は、「東芝」というところに、めちゃくちゃ意義がある。

　BREW端末は、実は、東芝が先行して新機能端末を出すことが多い。

　BREW端末の命名は
　W－Win端末を意味する（CDMA-ONEはA)
　数字２桁－上１桁がメジャー番号：これが違うと機能が大きく違う
　　　　　－下１桁が、メジャー番号内で、その会社の何番目の端末
　英字２ないし１文字－企業名　T：東芝　SA：三洋　CA：カシオ　H：日立など

　というようになっていて、今W4●XX系が多く出ている。次はW51になるが。。。

　ね、W51とくれば、今W51Tでしょ（＾＾）

　このように、メジャー（上１桁）が変わるとき、東芝が結構早く出す。

　メジャーが変わると、開発できるものが大きく変わる（容量が変わったりするので）んだけど、今までだと、変わったすぐの端末だと。。うごくの？っていうのがあったけど、今度、フレームワークができるのであれば、「東芝のフレームワークを使えば、東芝端末は動くだろう」とみんな思うので、先端機能を使いたい人は、このフレームワークをつかってしまう。。

　とすると、今度は、「東芝のフレームワークつかっちゃったから、また、東芝端末にしようか」ということで、また、Tの端末を使い出す。。。

　ってことで、フレームワークがあるおかげで、ずーっとTの端末を使い続けることになる。。

　つまり、これって、T以外のSAとか、とくにSOにとってはピンチだと思う。
　ソニエリって、デザインはいいんだけど、すぐに出てこないのよねー
　また、デザインもあんまりこりすぎると、法人にはねえ（＾＾；）

---

　ってことで、これ、Docomo陣営にとっては、すんげー不利な話だと思う。

　まあ、au陣営は、たしかに東芝有利だけど、そんなの、他の会社でもフレームワーク出せばいいし、そのうちフレームワークが乱立したら、KDDIが統一フレームワークを出さなきゃいけなくなるだろうし（そのとき、すでにフレームワークを作った東芝は有利だ。自社のフレームワークを提供し、自社に都合のいいように話を持っていける）。

　っていうことで、今後の法人端末需要に、大きく影響する話なのかもしれない。
　このはなし。