Turtle日記 Annex

この書籍は読み物としてとても面白い。
『そうそう、こういう問題があるんだよ』『こうすればうまくいくんだよなー』『これをやれば改善できるかも』・・・本当に共感できる部分がたくさんあります。
また読んでいると稼働率に関する内容で「ザ・ベロシティ」で登場するようなシーンが出てきます。ソフトウェア開発でも製品製造でも同じなんだなーと実感します。

読み物として面白いのは共感できるから。では実践はというと・・・難しいところがあるんだろうなー。
確かにできるものもあると思います。でも、リーン開発（とかアジャイル開発とか）ってやろうとすると社内の抵抗に遭いませんか？今までのやり方だとほぼ間違いなく失敗する、だからこそ新しいやり方で進めなければならないのに、「今までのやり方は標準だから変えてはいけない」的な圧力・抵抗が出てくる。リーン開発（やアジャイル開発）はもうそれほど新しいものではありません。なのに新しいものとして取り組まなければならない・・・。だから「読み物」としては面白い、となってしまうのです。
実践しようとするならば、組織の抵抗を乗り越えるんだという強い意志が必要だと思います。


ただ、組織の抵抗を乗り越えるためのヒントが掲載されていたのでそれを紹介しておきましょう。
トヨタのかんばん方式を確立した大野耐一氏の言葉ということなので、その筋の方には説得力があると思います。
　「標準というものを最善だとおもったらもういかん。標準というのは、改善するためのひとつのベースであってね。」
　この言葉が強い味方になるはずです。

Cnet newsで「燃え尽き症候群に陥らせないために・・ITプロフェッショナルが避けるべき10の行動」というものが紹介されていました。

10の行動そのものは正しいと思うんですよねー。でも、そうさせている雰囲気が周囲にないでしょうか？
ということで今回はその10の行動に対して突っ込みをいれる形で「燃え尽き症候群に陥らせる10のわな」という形で紹介しちゃいます。

＃1 絶対にNOと言わない
　というより「NOと言わせない」雰囲気ない？本当にNOと言えます？？

#2 休暇を取らない
　あまり休暇を取ると査定に影響するんだよねえー。とれるものなら有給休暇消化したいのだけどね・・。

#3 昼食を抜く
　あまり昼食を抜くことはないとは思うけど・・・、13時に打ち合わせ設定されたら昼食取る暇なくなるんですけど・・。

#4 異常なほどの長時間残業を続ける
　長いデスマーチで自然とそうなっていく・・・。帰りたいのはやまやま・・・。好きでやっているわけではない。

#5 家族との時間をないがしろにする
　ないがしろにしたくないから結婚しなくなる？　『だって面倒じゃん、』って思考回路を組み込まれた気がする。

#6 健康に気を遣わない
　（ジャンクフード万歳！）　健康に気を遣うことができるなら燃え尽き症候群にはならない。

#7 趣味の時間を削る
　だってプログラミングが趣味なんだって・・・

#8 独力で行う
　他にやる人いますか？みんな手一杯でしょう？（お前以外手の空いているやついないんだ！！）

#9 周囲に過度の期待を抱かせる
　周囲（もといPM)が過度の期待を抱く・・・

#10 徹夜する
　「明日までに終わらせろ」「進捗が悪いぞ」と言って暗黙のプレッシャーをかけるというケースもあるけど、うるさい人がいないほうが仕事が進む・・・って考えてることもある（実際よく進む・・・）


あてはまる人、手を挙げて！！

ブログレポート 2011年12月分公開

2011年12月 48,474 アクセス
2011年11月 51,852 アクセス

まあ、こんなものですよ。。。

GARNET CROWのカップリング曲ベストセレクションの発売日が決定したようです。
発売は：2012年2月29日

GARNET CROWオフィシャルサイトの情報によると収録曲予定は以下のとおりです。
◎収録曲(予定)
【DISC-1】
　Gor For It
　Secret Path
　For South
　八月の夜
　Circle Days
　Float World
　His Voyage
　lose feeling
　短い夏
　Crier Girl& Crier Boy 〜ice cold sky〜
　Flower
　nonsense
　愛に似てる
　whiteout
　hi-speed スペシャル oneday
　夕立の庭

【DISC-2】

　in little time
　Love Lone Star
　Argentina
　Holy ground 〜just like a" dejavu "arr.〜
　夏の終わりの長い雨
　彼方まで光を
　廻り道
　夜深けの流星達
　blue bird
　Jewel Fish
　未完成な音色
　一番素敵だった日
　トランス・トラップ
　Nora
　live
　たとえば12月の夜に

Androidのアプリ実装面でのセキュリティだけを取り扱った日本語の本ってこれが最初じゃないかな。
とっても役立ちます。
AndroidはLinuxをベースにしているし、それなりにセキュリティの枠組みってできているよねーと安心していたら痛い目にあいます。アプリケーションで指定する・利用を宣言するセキュリティの組み合わせによっては脆弱性を生み出してしまう可能性もあります。自分自身はよくても自分自身が抜け道になってしまう可能性だってあるんです。結局Androidが標準で用意しているセキュリティの仕組みってやっぱり専用のものですから、皆さんまだまだ経験が不足していて、あれこれ漏れがありそうだなーと本書を読んでいて感じました。私自身も「え、これは・・・」と思うような点もありましたし。

特にIntentやコンテントプロバイダーによる外部との連携や、サービスなども十分気を付けないと「標準のままｍでは」とっても危険な状態になりえるってことが本書を読むとわかると思います。

今作っているアプリは・・・ある意味ぎりぎりセーフ（運よく回避できている）って感じだったなー。

本書こそ、Androidアプリ開発者必携です。（ステマじゃないですよ）

以前NLP（神経言語プログラミング）という言葉に引かれてある本を読みました。”プログラミング”というところがITに通じる響きがあったというのがその理由・・・。ただ、その時の書籍はちょっと難しい！？気がしました。また、対象が自分自身を変えるというメンタル強化とか、セラピー要素が強かった記憶があります。というわけでしばらくNLPという分野には興味を持てませんでした。

今回、偶然書店で「プロが教えるはじめてのNLP超入門」を見て"もう一度NLPって何なのか、これでわかるかな”と思って読んでみました。
そしたら、実はNLPはセラピーとか自身のメンタル強化だけではなく、普通の生活やビジネスのコミュニケーションにもとても役立つものだということがよく分かりました。メンタル面とかコミュニケーション分野のビジネス本と考えてもよい。「成功するビジネスコミュニケーション術」といっても間違いではない。そして本当に「超入門」、わかりやすいです。そして、”あ、これなら実践できるかも”と思える内容。とても印象的な一冊でした。

　多分読まれると『こんなこと実践しているよ』って内容もあると思いますが、そういった内容だからこそ実践できそうなものばかりとも言えるのです。それに全部を実践しているって人はおそらくほとんどいないでしょう？（全部実践しているならNLPを理解しているってことだし、そうした人は超入門はいらない・・・）

　どれだけ良いものかは、とりあえず自分自身の目で確認してください。図書館で借りてもよいと思います。
一度読んだら、『この内容はぜひ手元においておきたいものだ』と感じると思います。それだけいいものです。

ぜひぜひご一読を。

so-netが発表しているブログレポートの公開。
実際のユーザアクセスはもっと少ないんでしょうねー。

2011年11月 51,852 アクセス
2011年10月 60,070 アクセス

イノベーション・マーケティングというと何のことか最初はわかりませんでしたが、実際に読み始めると『イノベーション・プロセス』をどのようにマネジメントしていくかというものでした。
イノベーションというのは不確定要素が多いため、本書では6つの役割を中心としたロールベースマネジメントを提唱しています。その6つの役割とはA-Fと言われるもので
　A：アクティベータ　B：ブラウザ　C：クリエータ　D：デベロッパ　E：エグゼキュータ　F：ファシリテータ
です。それぞれの役割を持った人がその役割をまっとうすることで、イノベーション・プロセスを進めることができるという内容となっています。

本書の最初でも記述されていますが、本書はイノベーション・プロセスに関する教科書的な存在です。
ですから、組織内でイノベーションを推進するすべての人に本書を参考にしてもらいたい。

なお、イノベーションとは技術的なイノベーションだけではありません。組織のプロセスを変えるプロセスイノベーションなど、すべての変革がイノベーションであり、本書の対象となっています。
そのように考えると組織に属するほぼすべての人が本書の読者となるべきなのかもしれません。

今までのソーシャル関係の書籍の総まとめ・・・、そんな印象のある内容でした。
もちろん著者は「まとめる」つもりはなかったと思いますが、いくつか書籍を参照していますし、事例として掲載されているものも一度はどこかで聞いたことがあるものが多い（特に海外の事例は）。

グランズウェル ソーシャルテクノロジーによる企業戦略 (Harvard Business School Press)
やエンパワード ソーシャルメディアを最大活用する組織体制 (Harvard Business School Press)などが本書でも触れらている内容ですね。

ただ、そうした書籍と決定的に違うのは、日本の事例が掲載されていること。例えば、有名なソフトバンク孫社長の「やりましょう」からはじまったソフトバンクグループのtwitter（やそれを含めたソーシャルメディア）の活用や「加ト吉」の事例など。twitterを少し前からご利用の方はご存じのものがその内幕もふくめて紹介されています。
日本もソーシャルシフトができてきているんだ、アメリカばかりに先行されているわけではないんだ、と感じさせてくれます。そして3.11の震災の際のソーシャルメディアでのさまざまな動き、この動きが日本のソーシャルシフトを決定づけたのかもしれないというくらいに、広範囲に活用された事例ではなかったかと思います。

いくつも「ソーシャル・・・」と名のつく書籍はありますが、今までの動きを総ざらいするならば海外・日本の事例双方をフォローできる本書が一番の近道ではないかと思います。

2011年12月20日にdocomoのspモードで、「メールアドレスの置き換え」という障害が発生しました。
本当の原因等はメディアにお任せいたします。
（例えばITProなどはいかがでしょうか）

どうやら原因は、ドコモのセンター側でIPアドレスとメールアドレスを紐付していたが、センター側が高負荷状態となり紐付に不整合が発生してしまった・・ということ。

ということで、「なんでIPアドレスを紐付たのだろう？？」と勝手に考えてみるのが本稿の趣旨。

まずはじめに携帯のメールと通常のSMTP（POP/IMAP）メールとの違いを把握してみたい。
通常のメール（POP/IMAP）はメールの着信確認を、クライアントサイドから行う。1分とか極端に短い確認間隔を設定しない限り、送信後ほぼリアルタイムに着信することはない。
それに対して携帯のメールは、センター側から携帯端末にメールをプッシュすることで（通信可能状態にあれば）ほぼリアルタイムに着信する（と聞いたことがある）。このリアルタイム性がうけたのか携帯のメールってほぼチャットのように利用されていることがありますよね。

さて、ここでどうやって携帯端末にプッシュするか、その仕組みを考えてみたい。仮定として、利用するネットワークは純粋なIPネットワークであること。
センターからプッシュするためには送信したいメールアドレスのIPアドレスを知らなければならない。端末側からのメール着信確認のアクションがない以上、何らかのかたちで端末側のIPアドレスを把握しておく必要がある。
ここでおそらくspモードではメール－＞IPアドレスに変換するダイナミックDNSのような仕組みを作り上げたんでしょう。端末側のIPアドレスが変更された場合は自動的に変換テーブルを更新しちゃんと同期がとれていれば問題はないはずだと。

IPアドレスではなく、端末固有のIDで管理すればよかったのではないか、と私もはじめは考えたのですが２つの理由からそれはできないと考えられたものと思います。

1. 携帯時代の「かんたんログイン」で端末固有のIDを利用していたが、この方式はセキュリティ上問題があるとされ、その利用をためらった。端末固有IDが偽装されたら・・という思いもあったかも。
2. こちらのほうが仕組み上問題なのだが、端末固有IDをつかっても送信先を特定できない。メールアドレス->端末固有ID→IPアドレスの変換の仕組みが結局必要。

こうして今までのspモードの仕組みができあがったと・・・。

では、どうすれば今回のような問題は起きなかったのかを考えてみると・・・、意外と解決策は難しい？
なんらかの形でメールアドレス->IPアドレス変換は必要になるのはほぼ間違いない（はず）。
とはいえIPアドレスとメールアドレス変換テーブルが完全に同期する保証はないことが今回証明されている。
・・・端末ID-IPアドレスの組み合わせもセンター側で管理し、メールをプッシュする際に端末IDを送信し端末側で受信する際端末IDが異なっていたらrejectする、という案もあるかもしれない。これで99%は問題がなくなるはず。（センター側の同期は相当のことがない限り、破たんしないようなので）けれど、今回のような問題が発生することを想定し、かつ受信側でcrackされてどんな端末IDでも受け入れられる仕組みを作られたら、と思うと100%完全ではない。

　おそらく回答に近いものはAndroidのC2DMのような仕組みなんだろうな。ただ、ユーザGoogle Acountの認証Tokenのようなものがないので、そこに何か代替手段を考えないといけないのかもしれない・・・。

　今回の事故を教訓に、何か問題があっても最悪の事態にならないフェールセーフな設計を心掛けなければいけないな・・と実感しております。（それにしてももし本当にspモードを設計していたら、自分はどんな解決をしただろうか・・）


　--
　当然のことながら、ここで仮定している仕組みはspモードの本当の仕組みではありません（と思いたい・・・）。事故原因報道および私自身の想像でつくりあげた架空のものです。