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

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

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

吉羽さんが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:過度な期待は禁物

『天才たちの日課』を読んだ

天才たちの日課 クリエイティブな人々の必ずしもクリエイティブでない日々

小説家や画家、作曲家などを中心としたいわゆるクリエイティブな仕事をしている人たちの日常をまとめた本。

村上春樹やスティーブン・キング、ゴッホやピカソ、ショパンなどの日常が出てくる。

人によって昼型や夜型に分かれていたりするが、大抵の人があるルーチンを持っていて、毎日それを守っているようだ。

毎日測ったように3ページずつ書く人もいれば（例として上がっているのはやはり小説家が多い）、日によってばらばらで、5時間座って一行も書けない日もあったらしい、なんて記述を見るとなんだかホッとする。

軽く読める本です。

進化はテクノロジーを望んでいる

年末年始に『テクニウム』という変わった本を読んだ。

テクニウム――テクノロジーはどこへ向かうのか?

この本はWIREDの創刊編集長であるK・ケリーが書いたもので、テクノロジーの進化を生命の進化の延長線上にあるものとして捉えた本。生命の進化に"なぞらえる"のではなく、進化の延長線上であるとしたところがかなりユニーク。

テクノロジーそれ自体に進化の指向性があり、テクノロジーは人間が生み出したものだけれど、既に人間の手から離れてテクノロジーそれ自体を進化させるべく進化を続けているというニュアンスのことを指摘している。

こういったテクノロジーの自律的な進化や、テクノロジーもつ進化の指向性、といったものをテクニウムと読んで、生命の進化の延長線上にあることを説明し、その本質を見きわめようというチャレンジをしている本。

かなり面白いが内容はだいぶぶっ飛んでいる。細かいところの議論が雑で根拠薄弱かなと思ったが、一つの思想として面白いかもしれない。

彼は生命の進化の過程で知性が生まれたのも偶然ではなく必然であるとしていて、しかもそれは人間に限るものでもないと指摘している。
カラス、イルカ、ヒト、カリスマ的な知能は鳥、海の哺乳類、霊長類で3度別々に進化したからだ。生命の六界では知能が何度も進化しており、あまりにも度々発生するので知性は必然なのだという主張。

その知性が発展して様々なテクノロジーを生み出すのだが、これも必然性が強いという主張をしており、例として様々な発明（電話や電球など）が同時多発的に別々の場所別々の人間によって生み出されていることや、吹き矢のように、遠く離れた別々の文化圏から全く独立して発明されている*1という事実を持って、テクノロジーの進化にも指向性と必然性があり、一つの方向に収束した形で進化を続けているとする。

生命の進化の果てに知性の誕生があり、知性がテクノロジーを生み出し、テクノロジーはそれ自体を進化させていく。

彼はこれらの主張を生命科学、考古学、文化人類学、情報科学、経済学といったあらゆる知識と事実を元に説明してみせる。

非常に興味深い。

だが一方でちょっとオカルトっぽいというか、ニューエイジっぽいなあと思ったら、作者のK・ケリーは元々「ホール・アース・カタログ」*2の編集者でもあったというバリバリのニューエイジの人だった。。

まあでも、とても面白い本なので、読めば何かの刺激を受けることうけあいです。

生命の進化の後ろには指向性があり、知性の誕生は必然で、同じ発現が何度も現れる、なんてまるで神学の本を読んでるみたいだ、って思ったりもした。

テクニウム――テクノロジーはどこへ向かうのか?

*1:吹き矢はアマゾンとボルネオにそれぞれ存在し、全く同じ形態をとっているが、文化的な交流は一切なかったという研究があるらしい

*2:ジョブズがはまっていたというニューエイジ雑誌

2014年まとめ

これを書いてる時点で今年もあと1時間半です。

本業では現場復帰しました

2013年にDeNAに入社して以来、他社で言うDeveloper Advocate的なことをしていたんですが、今年の4月に入ってその職を離れてWebサービスの現場に復帰しました。

スクラムマスター的な立ち位置で色々やらせていただきました。

書籍を出しました

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

2年ほどかかっていた書籍をついに出しました。

『チーム開発実践入門』という本を書きました - ikeike443のブログ

おかげさまで増刷しました！　ありがとうございます！

増刷しました 『チーム開発実践入門』 - ikeike443のブログ

『チーム開発実践入門』増刷しました！ 3刷です！ - ikeike443のブログ

電子書籍も出ました！

『チーム開発実践入門』も電子書籍になるよ - ikeike443のブログ

韓国語版も出ました！　ちなみに来年は中国語版が出る予定です。

投稿 by Web+db press.

良かったら下記にも投票してね！

「ITエンジニアに読んでほしい！技術書・ビジネス書 大賞（ITエンジニア本大賞）」 - ikeike443のブログ

レビューもしたよ

洋書だけどレビューにも関わりました。日本語書籍もレビューしてみたい。。。誰かオファーください。。

レビュアーとして関わった "Jenkins Continuous Integration Cookbook"が来年1月に出ます - ikeike443のブログ

登壇もしました

少しだけどお呼ばれしてお話させていただきました。呼んでくださった方々、本当にありがとうございます。今後もよろしくお願いします。

デブサミ

相澤さんにお声がけいただきました！ 初デブサミ！

デベロッパーサミット2014 OSSコミッタ大集合に登壇してきました - ikeike443のブログ
デブサミは前職でイベント管理の支援という形で関わっていたんですが、出る側になるとは思いませんでした。

DevLOVE

市谷さんにお声がけいただきました！

#DevLOVE でお話させて頂きました - ikeike443のブログ
上記についてはgihyo.jpにもレポートしていただきました。

池田尚史氏に聞くチーム開発の極意 ～「進め，現場のチーム開発 ～チーム開発実践入門」レポート：レポート｜gihyo.jp … 技術評論社
その時のスライドは下記です。

チーム開発をスムーズにするために何ができるか from Takafumi Ikeda

チーム開発をスムーズにするために何ができるか

DevLOVE関西

はてな本社に呼んでいただきました。初はてな！

#DevLOVE 関西でお話させていただきました - ikeike443のブログ
その時のスライドは下記です。

Dev love kansai from Takafumi Ikeda

Dev love kansai

来年に向けて

来年も何かしらアウトプットをしようと思っています。