https://teamtopologies.com/ DevOps consultantとして技術と組織の両面からDevOpsの支援を行なってるMatthew SkeltonとManuel Paisによる本．Consultant本は大体中身が薄く感じることが多くなり手に取ることは少なくなってきたが，各所で見かけたり，2人によるDevOpsにおけるチームのあり方のパターンをまとめたWhat Team Structure is Right for DevOps to Flourish?が良かったので読んでみた． 本書はDevOpsの視点から高速なDeliveryを実現するためにどのようなチームや組織を作るべきかについてまとめている．個人ではなくチームをDeliveryの最も重要な単位と考え（Team first-thinking），チームが最大限にパフォーマンスを発揮するために，チームの人数

2019年のアウトプットとインプットを簡単に振り返っておく． Working 業務でのチームとしてのアウトプットはMercari Microservices Platformの進捗（2019年）にまとめた．前年に引き続きPlatformの開発と運用を続けている． 昨年はAPI gatewayの開発など自分で手を動かすことが多かったが，今年は自分が具体的なプロジェクトを持ち自ら手を動かすことは意識的に少なくし，Tech leadとしてチームのアウトプットをどのように最大化にするか?ということを常に考えていた．技術的な視点や意思決定も時間的に影響範囲的により広く見るように意識し始めた（インプットも組織やチームに関連するものが多くなった）．見えやすいアウトプットは少ないが，プロジェクトを進めつつ，これまで曖昧だったPlatformのMissionは何かを明確に定義し，チームが拡大しても皆が同じ方

この記事はコーヒー Advent Calendar 2015の17日目の記事です． コーヒーを淹れること，豆を買いに行くこと，コーヒー器具を集めること，コーヒー関連の本を読むことが好きだ．コーヒーは趣味といっても過言でなない．自宅で美味しいコーヒーを淹れるために今までいろいろ試行錯誤してきたが，最近ある程度固まってきたのでその環境についてまとめてみる． 過去 最初に自分とコーヒーとの馴れ初めをつらつらと． 親がコーヒー好きなので実家では当たり前のように毎日コーヒーが淹れられていた．そのため家で自分でコーヒーを淹れて飲むのは当たり前のものとして育った．実家ではドリップマシンが使われていた．特にこだわりはなく出されるものをそのまま飲んでいたと思う． 自分でコーヒーを淹れるようになったのは大学生で一人暮らしを始めてから．最初は実家にあった使われていないドリッパー（確かHARIO）と近所のスーパー

サンフランシスコでたくさんコーヒー飲んだ Google I/O 2015のためにサンフランシスコを訪れた．サンフランシスコといえば対岸のオークランドにサードウェーブの代表格となったBlue Bottle Coffeeの焙煎所があり，サードウェーブコーヒーの流れを受けた様々な有名ロースターが存在している．コーヒー狂としてはロースター巡りをせずにはいられず滞在中は時間があればロースターに行っていた．以下は行ったところまとめ． Four Barrel Coffee．Valencia St.にある．Drip Coffee（Pour-over）のために別途スタンドが準備されていて店員が豆の説明をしながら丁寧にドリップをしてくれる．COLOMBIAのla CABANA農場のものを飲んだがこれが圧倒的に美味かった（今回一番美味しかったと思う）．衝撃を受けた．ここは“Four Barrel, San Fr

Google I/O 2015のためにサンフランシスコを訪れたついでにDocker社に遊びに行った．Docker社はサンフランシスコのダウンタウンを南に下った475 Brannan St.にある（ちなみに275にはGitHub社がある）． 迎えてくれたのはNathan．Nathanとは昨年東京で開催されたCommunities meetup Chef, Docker, Openstack, Puppetで出会った．その後もtwitterで絡んでおり今回訪問させてもらうことになった． まず，近くにカフェ（Blue Bottleで焙煎された豆を使っていた）がありコーヒーを片手に近況などをゆっくり話した．NathanはDocker Machineをメインに担当していて，最近追加した機能や今後の予定などについて語ってくれた．今はv0.3.0に向けてRCを出して絶賛テスト中とのこと．Docker M

GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに

複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる