組織構造を議論するなら今後は「Team Topology」をお供に

今年読んだ本は今年のうちにレビューしてしまおう、ということで第一弾「Team Topology」です。

Team Topology

Team Topologyはソフトウェア開発の規模をスケールさせるために様々なチーム編成と、チーム間のコミュニケーションについてベストプラクティスについて書かれています。 基本的な考え方として、チームの認知負荷(Recognitive load)を一定以下に抑えることと、システムアーキテクチャと組織アーキテクチャを一致させること(いわゆるコンウェイの法則)を重視しています。 その考え方に基いて、チームの型を4つ(Stream aligned team, Enabling team, Complicated-subsystem team, Platform team)、チーム間コミュニケーションのモードを3つ(Collaboration, X-as-a-Service, Facilitating)に分類しています。

チームの特性についての記述で興味深いところは、ダンバー数をベースとした適切な規模(5ー8名)と、コードのオーナーシップについてです。 昨今では、チームが開発から運用までオーナーシップを持つことが一般的となりつつあると思いますが、コードのオーナーシップは排他的なものではなく、他チームを排除するべきではない、とされています。オーナーシップは悪くするとセクショナリズムに陥りかねないので、この考え方を浸透させることは重要に思います。

またコミュニケーションについて、コストの高いコミュニケーション、つまりX-as-a-Service以外のモードでは、事前にコミュニケーションが必要とされる期間を決めておくところは慧眼だと思います。 個人的な経験としても、チーム同士のコミュニケーションが当初ほどは効果的ではなくなっても、なんとなく継続されていて、気付いた時にはあまり効果はなくコミュニケーションのオーバーヘッドだけが残っていた、ということがありました。あらかじめ期間を決めておくことは、効率的なコミュニケーションを維持する上では有効そうです。 また、逆に開発チームが本来は自分のチームでやるべきタスクをSREやPlatformチームに依存してしまい、その状況がずっと続いてしまう、ということもよくあります。これを避けるためにも決められた期限までにX-as-a-Serviceのコミュニケーションに移行する、と合意しておくことも大事でしょう。

その他の内容も面白いですが、チームとチーム間コミュニケーションの分類が、自分の経験としてもかなり的を射ているように思われ、今後、チーム構造やコミュニケーションパターンを議論する際の共通言語とできると良さそうです。

邦訳も最近でたので読み易くなってお勧めです。

"A Philosophy of Software Design"がお勧め

今年の7月に第二版が出た"A Philosophy of Software Design"を読んだ。

本書では、ソフトウェアシステムの複雑性を最小化するための設計について、モジュール/クラス設計、インターフェイス設計、レイヤー設計、エラーハンドリングから、コードの書き方まで様々な側面から具体なコード例をあげつつ解説している。

ソフトウェア開発において、システムをシンプルに保ち複雑性が上がることを避ける原則は、KISS (Keep it Simple, Stupid), DRY (Do not Repeat Yourself)YAGNI (You Ain't Gonna Need It)などが昔から言われている。これらのフレーズ自体はソフトウェアエンジニアが取るべき行動は示しているが、その理由は示していない*1。 本書では「ソフトウェアシステムの複雑性」が上がることの課題を「コードやシステムの理解が難しくなること」「コードの変更が難しくなること」の2点と定義しており、複雑性という抽象的な概念を言語化し、課題として認識しやすくしている。

昨今のソフトウェアシステムは、複数のソフトウェアエンジニアが入れかわりながら、長期間にわたって継続的に開発、運用されていくことが多く、いかに複雑性を上げずに機能を追加していくか、がシステムデザインの大きな課題となっている。 マイクロサービスもそのための方法論の一つで、一つのチームが担当する領域の境界を明確にすることで複雑性を下げることを狙った設計と言える(もちろん成功している例もあれば、失敗してかえって複雑性が増してしまっている例もある)。 いわゆる「技術的負債」も、コードの複雑性が上がり、コードの把握と修正が難しくなってしまっている状態と考えることができ、複雑性をいかに下げるべきか、という観点でリファクタリングなりを行うことができる。

本書で挙げられている具体的なポリシー、例えばコメントをどのようにどれぐらい書くべきか、例外をどのように扱うべきか、については、チームによって賛否が分かれるところもあるだろうけれども、ソフトウェアをデザインする際に複雑性を下げる(上げない)設計を良い設計ととらえる考え方は汎用性が高く、本書でカバーされていない領域(例えばマイクロサービスの設計)でも応用が効く原則だろう。

残念ながら翻訳はまだのようだけど、それほど分量も多くなく英文も平易なので、一読をお勧めしたい。

ちなみに初版と第二版の差分は、 * Chapter 21 Decide What Mattersの追加 * Chapter 6 General-Purpose Modules are Deeperの改訂 * Clean Codeと意見が分かれるところ(コメントに対する考え方)の追記 となっており、差分分のpdfが著者のサイトから確認できる。

*1:これらの原則に対して理由付けをしている文書は多数あるけれども

2016年振り返り ロンドン雑感

今年の振り返りを兼ねつつ、ロンドン雑感です。

f:id:stanaka:20161231213756j:plain

2016年の最大の変化はなんと言っても、はてなからメルカリに転職し、ロンドンに引っ越してきたことです。

ロンドンに引っ越したのは11月末なので約1ヶ月となります。Web系ではロンドンなどヨーロッパ方面に行く人は周りにもほとんどいないので、いろいろあることないこと吹き込まれましたが、滞在1ヶ月の所感を書いてみます。

  • 「冬はとにかく日が短かくて天気が悪い」説
    • 先週の冬至のロンドンは日の出が8:05、日の入りが15:51と、だいぶ日が短かくなっています。事前に思っていたよりは慣れるもので、朝の薄暗い雰囲気や夕方になるころにはもう暗いとかは、こんなものか、と思えばこんなものとして過ごせるものだな、と思います。
    • どんよりした天気が続くのは確かで、だいたい曇り空です。ただ雨が一日降ることはほとんどなく、曇りか小雨がほとんどで、たまに晴れるといったところです。日が短いのもあいまって、インドア生活が捗ります。
  • 「とにかく飯がまずい」説
    • これは相当にいろいろ言われたのですが、実際のところはそれほどまずいということはなく、美味しいものも多いです。とは言え、寿司・刺身などの和食についてはかなり高い金額を出さないと質の高いものを食べられないのはその通りだと思います。インドカレー・中華あたりはそれほど高くなく、かなりうまいものを食べられます。またスーパーでの食材はけっこう安く(20%の消費税(VAT)も非課税になる)、特にフルーツは安い(ブドウ1パックで2ポンド(=300円弱)など)ので、フルーツを食べる機会は増えました。

ロンドンの街としての重厚感はさすがで、歩いているだけでも歴史を感じます。個人的には累計10年過ごした京都に近いとも感じます。街並みの古さや、宗教施設(とうぜんこちらでは神社仏閣ではなく教会ですが)の多さ、アメリカ(東京)に対する距離感などなど。このあたりはまだ1ヶ月の所感なので徐々に変ってくるとは思いますが。 またヨーロッパの各国が近いというのはかなり良く、どこか一泊で合宿に行こうか、という時もフランスやスペインあたりが候補になります。LCCをうまく使えば2、3万円ぐらいで往復できたりするらしいので、東京から北海道・九州に行くぐらいの感覚です。会社の同僚でもちょっとした週末にイタリアに遊びに行ってきた、という話はよく出ます。

f:id:stanaka:20161231213754j:plain

f:id:stanaka:20161231213918j:plain

今年の主なアウトプットは、以下の3つぐらいですね。転職してからはあまりアウトプットできていないので、来年はもうちょっと発信できればと。

最後にメルカリではロンドンで働いてみたい人を募集しています。最近もエンジニアとして英語圏で働く是非の話で盛り上がっていましたが、ロンドンでもシリコンバレーとはまた違った英語圏での働き方ができるかと思います。海外に行くにあたってVISAの話は避けては通れないですが、メルカリではVISAサポートもちゃんとしています。興味ある方は是非ご連絡ください。学生の人向けにもなにかできないか検討中です。

ソフトウェアエンジニアとしてヨーロッパというのはあまりイメージが分かないかもしれないですが、以前軽く調べたところ*1GitHubのアクティブユーザー数ではイギリスは第2位で、人口比でいくとアメリカと同等のアクティブさです。技術カンファレンスも数多く開催されていますし、技術的刺激という意味ではそれほど遜色ないんじゃないかと思います。今年はいけなかったですが、来年はカンファレンスにもいくつか行ってみようと思っています。

gb.wantedly.com gb.wantedly.com

というわけで、ではまた2017年に!

Hello London, Hello Europe

はてなを退職してその後、しばらくロンドンに行ってました。(ちなみに、はてなとは引き続き技術顧問として関わりを持っています。)

morning in #london

Shinji Tanakaさん(@stanaka)が投稿した動画 -

なぜロンドン?という疑問に答えると、9/1よりメルカリのUK担当としてヨーロッパ方面のエンジニアリングの立ち上げに携わることになったためで、ロンドンの中心部にあるオフィスでしばらく働いてました。

入社翌週から先週まで1ヶ月ほどロンドンで立ち上げに向けていろいろ仕込みに行っていたのですが、ロンドンはアメリカのサンフランシスコやシリコンバレーあたりとはまた違う雰囲気でなかなか面白いです。実際にこれからのロンドンでの生活や仕事が楽しみになってきています。

今回の滞在で感じたロンドンの印象的なポイントはいくつかあるのですが、ざっとあげてみると次のあたりです。

  • とにかく街に歴史的な厚みがあり、建物も重厚で雰囲気がある。世界遺産がたくさんあったり、教会のような宗教的な施設がそこら中にあるのはある種、京都に近いものを感じる
  • イギリスに行くというと、まずご飯がマズいのでは、と言われるけど、普通に美味しいものもたくさんある。特にインドカレーは旨い店が多い。日本食の選択肢は少なくて高いのは仕方ないけど、一風堂はある
  • アメリカ(サンフランシスコ)に比べると治安が良い。夜中まで街は賑わっているし、危険な雰囲気はしない。イギリスの銃規制は日本並みに厳しいのもその一助になっていそう(もちろんロンドンでも治安が悪いところは場所によってあるとのことですが)
  • ロンドンでもヨーロッパ各所でもエンジニア系イベントはいろいろある*1ので、(英語さえなんとかできれば)インプットもアウトプットも楽しめそう

ロンドンには65,000人*2と思っていたより多くの日本人が住んでいますが、ウェブ系のエンジニアは数えるほどしかいないので、まだまだ開拓の余地があるんじゃないかと思います。(これは観測範囲の問題でいるところにはいるのかもしれませんが)

友人知人に今度は海外行こうと思っているんですよ、というと「サンフランシスコですか?」と聞かれることが多いのですが、今回は目の前にあったチャンスと一度はヨーロッパに住んでみたかったという想いから、「是非行きましょうロンドン」と決めました。

というわけで一昨日、無事にUKのVISAも発行されましたので、もうすぐロンドンに引越します。 11月下旬までは東京に居ますので、皆さんお相手をしてやってください。12月以降はロンドンに居ますので、ロンドンに在住の方、来訪される方は是非ご連絡ください。

また直前ですが金曜に海外で働きたいエンジニア向けのDrink Meetupがありますので、UK(もしくはUS)で働くことに興味があれば是非どうぞ。僕もUKの話をします。 (もう締切過ぎていますが、個別に連絡いただければ対応可能かもしれません)

mercari.connpass.com

Drink Meetupに来れないけど話を聞いてみたい人は個別に連絡してみていただければ、なにがしかお話できると思います。

最後にハリーポッターで有名になったオックスフォードにあるカレッジの食堂の写真を置いておきます。こういう重厚さはヨーロッパならではですね。

weekend short trip to #oxford. Christ church. ハリポタの食堂! #london #trip

Shinji Tanakaさん(@stanaka)が投稿した写真 -