codedesign.jp

自社関連サービスで宣伝のようになりますが、DeNA Life Scienceの提供する遺伝子検査サービス「MYCODE」を注文してみました。

MYCODE | MYCODE（マイコード）

遺伝子検査という分野は実のところ研究自体は相当進んでいて、海外では手軽に試すことができます。国内ではジーンクエストさんが先行してサービスを提供し、他にも数社同様のサービスが開始された、という状況です。

在宅で、唾液サンプルを採取するだけで利用できる遺伝子検査ということで非常に手軽ですが、せっかくなので約280種類の検査項目が判るオールインワンを申し込みました。一日一項目をネタにすれば、営業日換算で1年以上はネタにできますね。

ちなみに、最初に開封するとスタッフからのメッセージが入っていました。これは購入された方ご自身で見て戴ければと思います。あと面白かったのは、唾液を出しやすくするようにということでレモンの写真のカードが入ってました。

結果がでましたら、またネタにさせていただきます。

随分前に読み終えていたのだが、良い本だった。

[amazonjs asin=”4873116309″ locale=”JP” title=”Team Geek ―Googleのギークたちはいかにしてチームを作るのか”]

いつもリーダーシップについて悩んでいるようであれば、是非読んだほうがいい。
技術が中心の会社で起きうるマネジメントの問題が網羅されている。

既に他の製造業と同じように、ソフトウェアの開発工程はより複雑になり、多くの人員を以って分担するようになった。
一方で、そのマネジメントは十分に成熟していない。本書はその道標になるだろう。

ただ、本書はソフトウェア開発のマネジメントを網羅的には書かれているが、体系的になっているわけではない。何度も読みなおして、自分の中で体系的に知識を身につける必要があるだろう。

正直この本は、帯のダニエル・ピンクのコメントで買った。

[amazonjs asin=”4873116198″ locale=”JP” title=”コネクト ―企業と顧客が相互接続された未来の働き方”]

非常によく書かれた本であることは間違いないのだが、正直ピンとはこなかった。かつて様々な本で書かれていた断片を集めて、丁寧に書かれている印象ではある。まだ私には早かったのかもしれない。読まれる方は、まず目次に目を通して戴けるとよいだろう。

ITシステムを構築する際にいつも問題となることの一つに「どの言語で作るか」があります。iOSはほぼObjective-Cでしか作れないので悩むことはありませんが、多くのシステムはその構築までにどのアーキテクチャを使い、どのフレームワークを使い、そしてどの言語を使うかとの問題がつきまといます。Perl, Ruby, PHP, そして最近はGoなど、どれも特徴があり、どれも万能ではありません。

[amazonjs asin=”477415654X” locale=”JP” title=”コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)”]

「コーディングを支える技術」はタイトルと通りのコーディングの本ではなく、どちらかというとコンピューター言語の本です。人が話す言葉が多くの過程を経て変わっていくように、コンピューター言語も様々な変遷を遂げており、それが何故そのように設計されたかを紐解いています。この本を読んだとき、ある人は設計書だと捉え、またある人は歴史書だとも捉えるでしょう。それ故、この本は技術本であることに違いは無いのですが、どのような人が読むべきかなかなか難しい。言語を習熟した人が過去を振り返り未来へと思いを馳せるためにあるような、そんな本でした。一つの言語を習得したと思ったら、読み返すと良いと思います。

技術書といえばO’REILLY、というのはエンジニアにとって定番中の定番。私も古くはPerlのラクダ本からお世話になってます。

O’REILLYはイベントにも良く出展していて都度立ち読みしていたのですが、つい先日のデベロッパーサミットでは「10%オフ」と「4000円以上でオリジナルTシャツ」に惹かれて3冊ほど買ってしまいました。まあ当日は近年稀に見る大雪で荷物が増えてしまったことを後悔したのですが、あとの祭りですね。

買う前に3冊はどれもサラッと内容を確認したのですが、最初に目に止まったのがこの本でした。
本全体の方向性としては「Geekが社内でキャリアを積むために理解しておくべきこと」という感じでしょうか。
内容はタイトルとはだいぶ異なり、GeekもしくはNerdが人間的な成長を迎えたときにどのようにあるべきかを書いたものです。元はブログの記事をまとめたもののようで内容は散漫としてるのですが、全般的にはソフトウェア企業・もしくはソフトウェア産業で働くエンジニアが生きていくための戦術がまとめられています。そんな感じなので、「どうやったら最良のコードが書けるか」「どうすれば一生プログラマーでいられるか」という視点では書かれてはいません。

[amazonjs asin=”4873114993″ locale=”JP” title=”Being Geek ―ギークであり続けるためのキャリア戦略”]

こういう本をエンジニアが読まなければならない、その理由だと私が考えているのは、常に環境は変化するということです。ソフトウェア産業は成熟していき、普通の産業になりつつあります。一方で、自分自身の記憶力は減退し、発想力は衰え、新しいタレントが台頭していく中で、会社のなかで以下に自分のポジションを確立していくか。小さい話ではあるんですが、30代くらいのエンジニアの、次の10年の生き方を客観視できる良書だと思います。

端的に面白かったのは下記の引用の部分でした。

　たとえば「このページにちょっとチェックボックスを追加してくれないかな」と頼むとき、頼んだ側の人間は、それが至極簡単なことだと思っている。「If/Thenとかで、条件分岐をさせればすぐにできるだろう」などと思う。
無邪気なものだが、エンジニアにとっては実に苛立たしいことである。
安易に頼まれたとおりにすれば、仕様が変わってしまう。しかも、ひどい仕様になってしまうことが多い。そして、何より困るのは、頼む側が、こちらの作業の具体的内容を良く分かっていると思い込んでいることだ。「この機能を追加するには、こういう作業をすればいいだろう」と想像し、その想像は正しいと信じているのだ。

いやあ、ほんと。分かっていらっしゃる。

ウォートン・スクール」と「ゲーミフィケーション」という2つの単語に飛びついてしまったが、良書であった。ウォートン・スクールといえば世界初の、そしてMBAランキングでも1位である最も高い評価を受けるビジネススクール。そして、ゲーミフィケーションとは、所謂新しい「ビジネス」の手法であり、ゲームデザインを人間の行動に応用させる手法である。ウォートン・スクールが新しいビジネスの手法をまとめた本、ということであれば読まない手はない。

[amazonjs asin=”4484131242″ locale=”JP” title=”ウォートン・スクール ゲーミフィケーション集中講義”]
本書はゲーミフィケーションの定義から始まるのだが、重要なのは訳者が指摘している

　日本の「ゲーム」と英語の「game」の意味が微妙に異なる

という点が前提、かつ重要となっている。日本人が思い描くゲームより、英語のgameはもっと広く、スポーツや金融・ビジネスでもgameという要素まで意味合いは広がっている。ゲーミフィケーションはゲームではなく、人がビジネスを楽しむ要素を研究して付加することだ。これは、ダニエル・ピンクが提唱する「モチベーション3.0」につながるものだと思う。

　すなわち、ゲーミフィケーションとは「ワクワクする動機付け」である。

どうやって「ワクワクする動機付けをさせるか」については本書はもしかしたら不十分かもしれないが、それでもゲーミフィケーションの概念を把握するには十分であろう。

そして、恐らく「ゲーミフィケーション」という呼び方は適当ではなく、今後言い換えられると予想している。そのうち新しい単語で、こういったマーケティング手法は説明されるのではないか。