【連絡】Amazonから宛先不明で連絡が来ている方へ

先日の退職報告記事（下記）にてほしい物リストを晒していたのですが。。。ikeike443.hatenablog.com

じつはほしい物リストの登録住所が古かったようです。。

ほしい物リストから私宛にプレゼントを送ってくださった方のところへAmazonまたは配送業者から宛先不明の連絡が行っている可能性があります。。先ほど住所を更新しました。。。

このブログを読んでくださっている方の中で、万が一宛先不明の連絡を受け取っている方がいらっしゃったら、ご面倒ですが注文番号等を私宛にご連絡いただければ、こちらで連絡をとって受け取り致します。

ご連絡はTwitterのDMか、Facebook等でいただければ幸いです。

この度はご迷惑おかけして申し訳ありません。。

栗栖さん(id:chris4403)、ご連絡ありがとうございました！

『波よ聞いてくれ』おもしろい

会話劇、ラジオの話、面白くするの難易度高そうだけど、成功してる。
今すぐ買って読んだほうがいいよ。

波よ聞いてくれ(1) (アフタヌーンKC)

波よ聞いてくれ（１）

DeNAを退職しました

最近流行らない退職ブログですが、気にせず書きます。自分の記録の意味と、縁のあった方への連絡の意味もあるからです。

去る5月27日を最終出社日とし、2年お世話になった株式会社DeNAを退職することになりました。現在は有給消化中の身です。

DeNAでは下記のような仕事をさせていただきました。

Mobageオープンプラットフォームのテクニカルコンサルタント

Mobageにゲームを出してくださる会社様に技術サポート等をお届けするお仕事です。このサイトのメンテナンスもやっていました。いくつかサポートさせていただいたゲームの中から、一本大ヒットと呼んでいいゲームが出せたことが自分の中でも誇りとなっています。*1

DeNAライフサイエンスにてMYCODEのスクラムマスター的な仕事

Mobageのあとは新規事業室に異動して、遺伝子検査サービスMYCODEの立ち上げに関わらせていただきました。スクラムマスター的なお仕事プラス、CI, CD環境の構築担当みたいなかたちで仕事しました。mycode.jp

このプロジェクトはなかなかにエキサイティングで、いろいろ面白い話があるのですが、遺伝子情報というセンシティブな情報を扱うサービスのために外で発表することが出来ないのがもったいない感じです。このプロジェクトではDeNAライフサイエンスという子会社も新たに設立しましたので、新規事業室から出向するかたちを取りました。

DeSCヘルスケアにて開発部長

MYCODEローンチの後、住友商事さんとの合弁会社設立の話があり、このプロジェクトに開発部長というかたちで合流することになりました。ここでは部長として人材採用や予算作成、採用技術選定と（ちょっとだけ）プログラミングをやっていました。
健康保険組合向けのKenCoMというサービスです。kencom.jp

こちらもこれから採用健康保険組合が増えていくと、世の中になくてはならないサービスとなっていくと思います。

これら全て、DeNAのみなさん並びに協力会社様、お客様、ユーザー様のお力添えあってのことです。本当にありがとうございました。おせわになりました。

今後

このままDeNAのヘルスケア事業を盛り立てていくつもりもあったのですが、たまたま今回アメリカ資本の会社さんとご縁があり、自分の力を試してみようと思うに至りました。

どこ、というのはまだ明かせないのですが、いずれオープンにできると思います。

ひとまず来月渡米するので、いま必死で英会話をやっています。。。*2

来月渡米すると言っても、すぐに帰ってきます。仕事のベースは今後も日本なので、今後も飲みに誘ってください。勉強会やカンファレンスでの登壇依頼もお待ちしております。

というわけで今後ともよろしくお願いします。

ウィッシュリスト貼っておきます。www.amazon.co.jp

*1:もちろん、私はサポートをしただけで、素晴らしいのはゲームを作った当の会社様です

*2:そして絶望している

リモートワークで大きな仕事を成し遂げるには

ということが書かれた本を読みました。

なんだか最近、本をもらったとか読んだとかしか書いておらず、技術者のブログとは思えない感じがして鬱です。

吉羽さんがTwitterで絶賛していたのをFacebookで見て面白そうだなーと思って買って読みました。

マイクロソフトを辞めて、オフィスのない会社で働いてみた

『マイクロソフトを辞めて、オフィスのない会社で働いてみた』です。原題はThe Year Without Pants*1です。

マイクロソフトであのインターネットエクスプローラーのプログラムマネージャーをやっていたスコット・バークンが、ワードプレスドットコムで著名なオートマチックにチームリーダーとして入社し、そこで見て聴いて感じた内容を本にまとめたものです。

オートマチックは最近増えてきているほぼ完全にリモートワークの会社*2で、著者が入社するまではチームというものもなく、チームリーダーというものもなかったとのこと。そこへ創業者*3のマット・マレンウェッグがスコットに声をかけ、半ば実験的にチーム制を導入し、リーダーをやらせてみたという話。

著者は『伽藍とバザール』*4を引き合いに出しながら、オートマチックのようなリモートベースでOSSのように開発するスタイルを「バザール」的とし、一方でマイクロソフトのように計画をもとに大きなものをつくり上げるスタイルを「伽藍」的とし、バザール的なスピード感と伽藍的な緻密さを融合しようと試みる。*5この試みが上手く行ったかどうかは、最後まで読み進めればわかる。彼のチームが成し遂げた成果はワードプレスを使っている人なら誰でも知っている「アレ」なので、おおっ、と思うでしょう。

この本は吉羽さんもブログで書いているように名言の宝庫。僕も読んでいて刺さったページを折りながら読んだんだけど、折り目だらけになってしまった。

その中からごく一部だけ引用しておきます。結構吉羽さんとかぶると思うけど。。

毎年、新しい仕事の方法が次々と流行するが、試してもほとんどの企業では上手く行かない。そういう方法はしばしば「革命」と称えられ、その時時の有名企業とひとくくりにされることが多い。カジュアルフライデーや、ブレインストーミング、リーン生産方式、シックスシグマ、アジャイル開発手法、マトリクス型組織、さらには20%ルールなど...

どれほど素晴らしいテクニックも、愚かな社員を賢くすることは出来ないし、疑心暗鬼の職場にどんな方法を導入しても、社員が同僚や上司を魔法のように信頼しだしたりはしないのだ。

テクニックが全て「論理」の産物であるのに対して、文化は「感情」に根ざしているからだ。文化をきちんと評価するスキルを持っている人はごく少数だ。それを「変える」スキルの持ち主となると、たとえやって見る勇気はあったとしても、さらに少ない。

実際にスコットはやってみせたんだなあ、というのが本を読むとわかる。

イノベーションについて語る会社の初歩的な間違いは、「実験」の基準を高く設定することだ。それではアイディアを試すことすら難しくなる。優れたアイディアを悪いアイディアから選り分けるのにどれほど多くの実験が必要なのかを理解していないからだ。

人は一対一で話しかけた時には別人になる。これがわかれば人生における成功の秘訣をひとつ手に入れたようなものだ。（中略）会議で全てが決定されると考えるのは愚か者だけだ。(中略）大勢の同僚が集まった会議室で演説をして、全員を説得できる人などまずいない。

あらゆる測定は誘惑を生む。（中略）データが物事を決めてくれるわけではない。データを注意深くとらえれば物事がはっきり見えるようになるが、それは決定ではない。（中略）社内の文化があまりにデータ信奉に傾くと、すぐれた直感を持つ社員は去っていく。（中略）すばらしいものを作るには直感と論理の両方が必要であり、どちらかが突出するのは良くない。

デザインをスッキリさせるためには、大局的な思考が必要であり、ひとつひとつのアイディアが優れているかどうかより、全体としてのサービスがユーザーにどう適合するかを考えなければならない。ワードプレスのバザール型の文化には様々な強みがあるが、ユーザー体験には使いやすさと明確さが欠けていた。それは本来、伽藍型の建築家が得意とするところなのだ。

仕事に関する最も危険な思い込みは、深刻で無意味なものでなければならないというものだ。それ自体無価値でつらいものだからこそ報酬を支払われる、と私達は信じている。（中略）金は地位を与えてくれるが、地位が意味を与えてくれるとは限らない。

データ主導の思考は危ない（中略）「富」は一般的に蓄えた金の量で測ることができるが、「意味」に似たような計測方法はない。意味は個人によって違う。人生に唯一無二の意味はなく、人によってさまざまに異なる意味があるだけだ。意味、情熱、魂といった感情的な言葉は、人生はすべて純粋理性的なことだけで決まると考える人に恐怖をもたらす。（中略）
仕事に意味があり、労働者が仕事自体に大きな自由と誇りを感じるというのは、新しい考えでも過激な考えでもない。むしろこういう考えは仕事の起源に根ざしている。私達は単に道に迷っただけなのだ。

著者のスコット・バークンって聞いたことある名前だなあと思ったら、『アート・オブ・プロジェクトマネジメント』の人だった。この人といい、ジョエル・スポルスキーといい、マイクロソフトのプログラムマネージャー出身の人の書く本は面白い。NTのカトラーについて書かれた『闘うプログラマー』も熱い本だったし、マイクロソフトはすごかったんだなあと思いますね。

そして、オライリーさんはなぜこの本を訳さなかったのかな。。今までのスコットの本はオライリーさんから出てたのにね。

マイクロソフトを辞めて、オフィスのない会社で働いてみた

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

イノベーションの神話

パブリックスピーカーの告白 ―効果的な講演、プレゼンテーション、講義への心構えと話し方

伽藍とバザール

闘うプログラマー[新装版]

Joel on Software

More Joel on Software

ソフトウェア開発者採用ガイド

*1:意味は本文を読めばわかります

*2:GitHubなんかもそうですよね

*3:つまりワードプレスの生みの親

*4:このタイトル、すっかり定着しちゃったけど、伽藍って変だよな。cathedralなんだから大聖堂って訳したほうが結局意図がわかりやすかったんじゃないかと未だに思う。。

*5:逆の言い方をすると、バザール的に仕事をするとどうしても解きやすい問題や自分にとって面白い問題ばかりを解決してしまい、難しく面倒な問題は後回しにされがちな点がある点を指摘している

レビュアーとして関わった『Jenkins Continuous Integration Cookbook Second Edtion』が届きました

昨年、上記のようにお伝えした本がようやく手許に届きました。

レビュアーとして参加した本が届きました！ pic.twitter.com/PY0zQq3GGy

— Takafumi Ikeda (@ikeike443) 2015, 3月 13

クレジットもされてるようです。

クレジット確認 pic.twitter.com/zJaeMoT8Pb

— Takafumi Ikeda (@ikeike443) 2015, 3月 13

英語が苦にならない人はJenkinsのレシピ集として一冊持っておいてもいいのではないでしょうか。

Jenkins Continuous Integration Cookbook - Second Edition

Kindle版もあります。

Jenkins Continuous Integration Cookbook - Second Edition

書籍のレビューって、基本無償労働です。クレジットしてもらえるくらいが報酬といえば報酬です。

不憫に思った方のために、ウィッシュリストも貼っておきます。
www.amazon.co.jp

懲りずにまたもう一冊の洋書のレビューやってんだけどね。。。

『スクラム実践入門』をいただきました

投稿に失敗してたっぽいからもう一回。著者の貝瀬さんよりスクラム実践入門いただきましたー。 pic.twitter.com/rivQbkfIk6

— Takafumi Ikeda (@ikeike443) 2015, 3月 13

著者の貝瀬さんとはよく一緒に仕事しています。その関係で発売前の本をいただくことが出来ました。
ありがとうございます。

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

発売は3月18日です。

目次としては下記のようになっています。

第1章 ソフトウェア開発の困難にスクラムで立ち向かう
第2章 スクラムチーム
第3章 スクラムイベント
第4章 スクラムの作成物
第5章 スクラムを支えるプラクティス
第6章 GMOペパボの事例 ── どのように導入したか
第7章 mixiの事例 ── 導入失敗からの立てなおし
第8章 DeNAの事例 ── 大規模開発、業務委託への適用
第9章 スクラム導入時によくある問題と解決策
第10章 スクラムチームでよくある問題と解決策
第11章 スクラムイベントでよくある問題と解決策
第12章 スクラムの作成物によくある問題と解決策

第1章から第5章まではスクラムとはどういうものなのかについて、トップダウンアプローチで説明しています。
スクラムについてほとんど知識がない人は、第2章から第5章を読むと具体的な用語や回し方がわかるようになっています。
第1章はかなり抽象的なアプローチからスクラムについて語っている章で、完全な初心者は面食らう可能性があるので、先に2章以降を読んだほうがいいかもしれません。

ある程度スクラムを行った経験があってから第1章を読むと、色々得られることがあるかもしれません。

スクラムの経験がある人にとって気になるのは第6章以降で、具体的な事例や、具体的な問題と解決策が述べられていて、とても参考になります。

スクラムオブスクラム（複数のスクラムを回す大規模なスクラム）について言及があるのも書籍では珍しいと思います。プロジェクトによっては、解くべき問題がどうしても大きいために、やむをえず大規模なチームを組まざるを得ないことが往々にしてあります。そういうプロジェクトにとって示唆に富む内容を含んでいるのもポイントが高いです。

「はじめに」にもありますが、スクラムは「軽量で理解が容易だが習得は困難」なフレームワークです。Webに書いてある情報や、人から聴いた内容をそのままプロジェクトに当てはめると、上手く行かないことが多いです。

それはなぜかというと、「はじめに」の貝瀬さんの言葉を借りるとスクラムは「問題をあぶり出すフレームワークではあるが、発見した問題に対して具体的な解決策を提示していないため」だと思います。これは至言です。

具体的な解決策はスクラムを実施している当事者その人が都度自分で考えてひねり出すしかないのです。

本書は、そんなふうにしてひねり出した事例の数々を読むことができる一冊となっています。ぜひご一読を。

著者のみなさん、出版おめでとうございます！

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

スクラム実践入門に関連して一緒に読むといい本を列挙しておきますね。
僕の本があるような気がするのは気のせいです！

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

Jenkins実践入門　?ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)

『間違いだらけのソフトウェア・アーキテクチャ』を読んだ

間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価 (Software Design plus)

技評さんの本なのですが、装丁がオライリーっぽい気がする。。

大企業相手にJavaEEのアーキテクトをやっているらしい人の書いた本。

アーキテクトである主人公（著者）が自著のセミナーを開いてアーキテクトの仕事について講演するという構成になっている。

セミナーに来ているお客さんが、プログラミングのわかっていないマネージャーや、調整ばかりしているSE、アジャイル教の教祖（ｗ）、現場をしらないIT雑誌記者、といった戯画化された面々なのがだいぶ挑発的で面白い。

だって、本編始まって3ページ目くらいがこんなんだからね。

USの人の書いた本なのに、日本のドSIの現場でよく見る光景が広がっていて笑える。

内容的にはさすがに5年前の本なので古めです。

ウォーターフォールってのは間違っていて、フィードバックループを早く回さないとダメなんだよ、って言っているのに具体的なCIのプラクティスについては触れていなかったりします。アーキテクチャのROIを測るのに静的解析手法を用いる方法を紹介しているけど手動を前提にしてたり*1、若干の古さは感じざるを得ません。

ただ、品質特性シナリオを使ってアーキテクチャの設計のところは役に立つし、アーキテクチャの分析や評価に使える様々なメトリクスについての紹介は役に立つと思います。特に出来上がってしまったものを評価しないといけない時には。

派生開発*2についても触れていますが、Webサービスの開発だとこういうの当たり前だしなと思ったりもしました。

なんだけど、全体的に皮肉がきいていて、この業界が長いおじさんには面白く読める読み物になっていると思います。ページ数も170ページ程度と短いです。

息抜きにどうぞ。オチにはアット驚く*3人物が出てきます。

間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価 (Software Design plus)

*1:これもCIの中でやればいいのに。。と思った

*2:新規開発ではなく、サービスイン後の運用の中での改善や新機能追加のことかな

*3:過度な期待は禁物