Staff EngineerとSenior Engineerの違いを知る「Staff Engineer」

今年読んだ本は今年のうちにレビューしてしまおう、の第二弾「Staff Engineer」です。

Staff Engineer

すこし前にTwitter界隈でIndividual Contributor(以下、IC)の話が話題になってましたが、そのICとしてのキャリアの先にある、日本ではあまり馴染みのないStaff Engineerについての本です。ちなみに本の内容は全て https://staffeng.com/ でも読むことができますので、紙が不要な人はこちらからどうぞ。

Staff Engineerは、会社ごとに、またおそらく部署ごとでも様々なバラエティのある役割の定義があり、この本は著者での経験に基づく記述と、各社のいろいろなStaff Engineerの人たちからのインタビューから構成されています。 著者の経験によると、Staff Engineerの典型例として、一つ、もしくは複数のチームをリードするTech Lead, 特定領域のアーキテクチャに責任を持つArchitect, 複雑で難易度の高い問題解決を担うSolver, シニアリーダー(経営層)のビジョンを実現するためのRight Handの4つが紹介されています(Staff archetypes)。その他、Staff Engineerとしてどのように活躍するか、Staff Engineerになるためにはどうすればよいか、Staff Engineerになるために転職する方法などについて記述されています。

個人的にもっとも興味深かったところはSenior EngineerとStaff Engineerの違いです。

多くの会社では、"Career level"という概念があります。これは、多くの人が到達する上限で、ほとんどの会社ではStaff engineerの下に位置するSenior Engineerとされています。つまり、Staff engineerになることは平均的なことではない、とされています(Getting the title where you are)。具体的には、Senior Engineerに期待されていたこと、例えば、コードを書くなどは、Staff Engineerには付属的なタスクとなります(What do Staff engineers actually do?)。 このあたりの話は、ICの役割をあくまでも手を動かすこと、と捉えていると期待値のギャップに繋がっていきそうです。

実際にCircle CIのCompetency Matricを見てみるとStaff Engineerの"Delivery / Self-organization / Reliability, delivery accountability"の項目では

Ensures expectations with their team and external stakeholders are clarified between all parties involved.

というような外部ステークホルダーの期待値の明確化が含まれています。このシート全体を"stakeholder"を検索すると、15箇所中13箇所がStaff Engineer以上に含まれており、チーム外とのコミュニケーションや期待値マネジメントが各所に入ってきています。

ここ最近では徐々にICのままでもキャリアを進められるように環境が整備されてきていると思いますが、その際にはStaff Engineerに求められる役割はなにか、という理解が世の中的にも浸透していくと、エンジニアとしても経営としても見通しが立てやすくなるんじゃないかと思います。

組織構造を議論するなら今後は「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"を読んだ。

A Philosophy of Software Design, 2nd Edition (English Edition)

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

ソフトウェア開発において、システムをシンプルに保ち複雑性が上がることを避ける原則は、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年振り返り ロンドン雑感

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

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

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

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

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

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

• Goのcontributorに名前を載せることができた
• WEB+DB PRESS Vol.95に「機械学習×サーバ管理」という寄稿をした
• dots conference spring 2016で「10年間戦えるWebサービスのスケールアウト/アップ」という話をして「僕たちは「新しい技術」で生き残る テクノロジーで未来のビジネスをつくる戦略会議」に採録された。

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

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

gb.wantedly.com gb.wantedly.com

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

*1:http://nlpx.net/archives/172