グループ交流記憶？ そんなのカンボジア人はとっくにみんなやってますが何か

新しい事柄をチームで分担して記憶し、後でレビューすると、定着効率が高い……
記事の筆者はgroup transaction memoryと呼んでいます。

How We Store Memories in Other’s Brains!

元々は、老夫婦や恋人のいる老人は、記憶の分担と交流の効果により、恋人のいない独身老人よりも認知症になりにくいことを明らかにした論文です。

これってカンボジア人は昔からみんな実践してますよね。
目新しいことがあったらみんなでよって来て眺める。みんなで聞き入る。
やってみるときはみんなでよってたかって
「違うわよ！　こうだったじゃないの！　まったくもう(笑)」
とか助け合いながら実現する。

悪く言えば「二人で一人」ともいえるこのカンボジア人のソーシャルな学習特性を、私も会社でチーム制としてしくみ化したり、育成も複数人を一度に対象にして行うのが効果的という持論を実践したりして、大いに活用してきましたが、これからそのことについて人様に語るときには、この「グループ交流記憶」という学術っぽい用語で説明したいとおもいます。

ベトナム人とか中国人はよくも悪くも個人主義ですので、この方法はかなり使いづらいとおもいます。
このようにみんなで助け合いながら学び、みんなで助け合いながらミッションを遂行することが文化的DNAに刻み込まれていることは、はっきりと、カンボジア人の明るい将来をもたらす特長であるといえます。

顧客情報をまるで持たないことこそコアコンピテンスとなる時代が来た

ライス氏の天下りを受け入れたDropBoxをスノーデン氏が批判、これからはゼロナレッジだという記事。

http://pc.nikkeibp.co.jp/article/column/20140722/1137583/?ST=sp

そもそも中央サーバを持たないP2P技術を核としたBitTorrent Syncなどもこの流れをさらに推し進めたところに位置付けられますね。

先頃発生したベネッセの顧客情報大量流出と、それに対するネット上のセキュリティ技術者たちによる無力感あふれる記事の数々を見るにつけ、これからは顧客情報を保有すればするほど多大なリスクを負う時代、保有によるメリットよりもデメリットのほうが大きい時代だと感じられます。

クラウドの時代は徐々に終わりを告げ、P2P技術の上に新たなWebやネットサービスが築かれていく時代になってゆくのだと感じます。

教育その他さまざまなサービスを提供する企業も、顧客の住所氏名やIPアドレスを知るのではなく、P2Pチェーンで間接的につながる何かのよすがのみを持ち（いまでいえば.torrent）、それ以外は知ることを避けることにより、企業のセキュリティリスクを避けることができるようになることでしょう。

もちろんいますぐ転換は無理ですし、技術的に具体的にどうやるのよっ、マネタイズはどこでやるのよ、てのはありますが、中期的にはその方向へ世の中が進んでいくのは必然の要求とおもいますので、よくよく準備しておく者が勝つのではないかとおもいます。

世界最古のゼロが記されたクメール碑文を女学生が持ち去り、学者が返還訴え

インドより前にクメール人が7世紀に世界で初めて数字ゼロを記した碑文、クメールルージュにより失われていたのを学者が再発見、しかしイタリアの女学生が持ち去り、学者は返還訴え

http://www.phnompenhpost.com/post-weekend/did-ancient-cambodians-invent-zero

facebookからIFTTTでEVERNOTEにライフログ蓄積する際に改行を温存しようと画策するtest

fbやらtwやらBlogger・Pocket・NikeFuel・ToodledoからIFTTTでEVERNOTEへ転送してライフログ化を図っています。

が、改行が無視されます。

Blogger->IFTTT->EVERNOTEでは改行がちゃんと温存されています。

tw->IFTTT->EVERNOTEで改行無視されてもさほど困りませんが、fbは改行なくなっちゃうとダサいです。（ｘ＿ｘ；）

使ってるIFTTTレシピは、テケトーにツモった先人様制作の出来合いのものです。

そこで、
ifttt
の記事を参考に、IFTTTレシピにpreタグを入れてみました。

うまくいくか…？

しんがりを漢字で書くと…21世紀はカリスマのないリーダーの時代

リーダーとは神輿の上で踊る者でなく神輿を先頭で担ぐものであるみたいな絵がよくあるけど（ピラミッドの石運びでも同じ）、むしろしんがりで担いでるというのが個人的には実感であります。

この案件なんとか社員どうしで話し合って決めてみて、と私が言うのに対し社員がしびれをきらし「もう社長が決めてよ」と言ったときのみ初めて「そっすか？ じゃ…」という感じです。

それは社長が決めてねと社員が言ったんだから社長が決めてもう文句言いっこなしだよね。

しんがりは漢字で「殿」と書くのも故なきことではないとおもうんです。
前面で目立たせてもらってる派手なヤツではなく、実はいちばん後ろにいる地味男くん地味子さんが大ボスだったという。

ときたま最後尾で声を発してなにげに神輿の行方を頑固に支配しております。
最前列で踊りたいやつが、気持ちよーく踊れるように。

元早稲田大学ラグビー部監督の中竹竜二さんもまさにそういうことおっしゃってますね。

• カリスマになろうとして「倍返し」を食らいました
• ｢日本一オーラがない監督｣が成功したワケ
• 中竹竜二さんの、黙ってオレについてきてはいけない！──『選択の時』第4回
• 中竹竜二氏（前編）～組織を劇的に変える「フォロワーシップ」とは？～

これからの組織は変化の早い世の中に即応できるよう現場の個々人の知恵とリーダーシップを引き出した者勝ちであり、そのためにはメンバーのリーダーシップを引き出すフォローに回ることこそ、21世紀のリーダーのコンピテンシであるみたいなことをよく言われますね。

言い換えれば、21世紀はカリスマのないリーダーの時代であるともいえます。

しかし…じつは20世紀の偉大な経営者の多くも、「僕はカリスマがなかった」とおっしゃっています。いやいやあるでしょ、という感じですが、そうした方々がそのような自覚のもとにどのようなリーダーシップを発揮されたか、という思想と手法は、21世紀になっても、いやむしろこうした21世紀だからこそなおさら、充分学ぶべきものがあると考えています。

http://ehonkasan.exblog.jp/10670594

Redmineのカスタムフィールドからリンクを張れる機能も今じゃ普通に標準装備な件

「Redmineでこんなことができない、とネットで言われてることのかなり多くが、じつは今ではすでに標準機能でできるようになっていた」の顕著な一例を…。

2.5.0 adds a "Link" custom field format but also adds the ability for other custom field formats to render values as a http link to a configurable URL with the following substitution available:

• %value% => the custom field value
• %id% => id of the customized object
• %project_id% => id of the project of the customized object if defined
• %project_identifier% => identifier of the project of the customized object if defined
• %m1%, %m2%... => capture groups matches of the custom field regexp if defined

カスタムフィールドのURL欄に文字列やこれらの要素を記述することにより、そのフィールド自身の内容やプロジェクトID・プロジェクト識別子などから組み立てた任意のURLへのリンクを張らせることが可能です。

惜しむらくは、他のフィールドの内容を参照できればもっと良いのに！ という点です。
人間の欲には限りがありませんね。

具体的には、たとえば「FTPサーバアドレス」というプロジェクトカスタムフィールドを作ったとして、その定義において、「値に設定するリンクURL」欄に

と指定しておくと、たとえば

• 「FTPサーバアドレス」フィールドの内容が「ftp.oreore.oredayo.tokyo」、
• プロジェクト識別子が「test」

であれば、 「FTPサーバアドレス」フィールドから「ftp://ftp.oreore.oredayo.tokyo/test/」へのリンクが張られます。
しかし実際には、下図でいえば、「FTPログインID」フィールドや「ルートパス」フィールドの内容を合成することができれば、より実用的でしょう。

まあ、この例にかぎっていえば、「FTP URL」というフィールドを作れよ、といわれればそれまでなんですが。

このほかに、カスタムフィールドのデータ型として「リンク」も新設されております。
URLそのものがフィールド内容となる場合にはこちらがお手軽です

IT技術者の生き残る道はIT業者でなくユーザー事業部内にしかない

IT部門が没落すればIT業界の大概の問題は片付く
という記事を読みました。

1. 事業部門がバリバリITを活用して新事業展開や業績浮揚を図るようになるだろう。
2. それについていけない頭の堅いIT部門は没落し、結果として、IT部門を頂点とするIT業界ピラミッド構造は崩壊するだろう。
3. そのピラミッド構造に伴っていたIT業界の諸問題も解決するだろう。

という三段論法なのですが、1と2は同意です。
すでにそのような動きを、一般の報道に現れるさまざまなニュースでも、ひしひしと見て取ることができます。

しかしこの木村氏も強く警鐘を鳴らしているように、実は2から3へはオートマティックな帰結ではない。
IT部門から仕事が出なくなったからといって、当然、事業部門が自動的に既存IT業者へ仕事を出してくれるようになるわけではないのだ。

それどころか、木村氏が前提にしているのとは異なり、私は、事業部門はそもそもIT業界へ仕事を外注しないケースが増えていくのではないかとみている。
理由は、木村氏の文章でも指摘されているように、事業部門が進めるIT案件は本質的にアジャイル性・小規模性を有するからである。

事業部門のITプロジェクトの試行錯誤とは、事業の試行錯誤そのものである。
なぜなら事業部門のITとは事業そのものだからだ。
アジャイルなやりとりを外部と行うほど効率の悪いことはないだろう。
外部業者が提案できる程度のイノベーションなら、そのユーザー企業のどこのライバル企業も当然に取り入れていくと思われ、新たなコアコンピタンスになどとてもなりえないのではないかとおもわれる。（そもそもそれで満足してたら事業部門の存在意義がない。）

よって問題は、IT業者はいかにこの先生き残るか？
ではない。
IT業者は現在のような形では生き残れないこと前提で、IT技術者がいかに生き残るか？
が、いま現在IT技術者として生計を立てているひとにとっての重大なテーマだろうとおもう。

これからITやプログラミングを学ぶひとについては、IT技術者などにならず、プログラミングを専業で行うなどという酔狂な道へ進まず、事業側へ入り込み、あるいは事業を立ち上げ、みずからプログラミングを行うのがもっともストレートフォワードな道であることは、火を見るより明らかな論理的帰結であることはいうまでもない。