Treasure、10年間で変えたこと・変えなかったこと

こんにちは、CTOの @makoga です。

2019年5月にオフィスが移転します。新しいビルなので綺麗だし、社内バーAJITOもリニューアルするのでとても楽しみ。

でも、イベントなどの思い出が詰まった場所と離れるのは寂しいものです。

VOYAGE GROUPでは2006年から毎年夏にエンジニア向けインターン「Treasure」を開催しています。 オフィスが移転するということで過去の参加者たちと「さよならパンゲア・AJITO」というイベントを開催しました。

[f:id:voyagegroup_tech:20190425151343j:plain

このエントリはそこでLTした内容です。

10年間で変えたこと

VOYAGE GROUPで利用してる技術に合わせていった

10年前に用意したベースアプリケーションのプログラミング言語はPHPでした。モダンなフロントエンドのライブラリは使わず、シンプルなWebページを表示していました。

当時のサービスインフラはオンプレだったので、インターンではさくらのレンタルサーバを利用しました。

そこから、実際に利用している技術をインターンに取り入れていき、昨年はGo, React, AWSなどになりました。

1人では学びにくいことを講義に盛り込んでいった

学生が1人で学べることはこの10年でものすごく増えたと思います。チュートリアルは充実してるし、ビデオで学習できるし、データも提供されているし。

そこで、Treasureでは1人では学びにくいことを盛り込んでいきました。例えば、チーム開発の進め方、チームでのアイデアの練り方、などです。

講師をペアやチームにした

初期の頃は1人の講師が全テーマを担当していました。

その後、テーマごとに講師を割り当てました。プログラミング、Web API、データベース、セキュリティなど。

今は、テーマごとにメイン+サブだったり、チーム全体で1つのテーマを担当したりしています。

これにより、実践によるスキルトランスファーが行え、講師陣に厚みができたと思います。

10年間で変えなかったこと

講義+チーム開発

いきなりチーム組んで開発してもらってアウトプットだけを評価することもできます。

でも、それでは私たちが大事にしていることを伝えるのは難しいと思っています。

私たちは毎年新卒を採用しています。そこで培ったナレッジを活かして、インターンに参加した学生を圧倒的に成長させたいと考えています。

そのためには講義+チーム開発が必要と考え、この形式を続けています。

講師・サポーター陣がフルコミット

参加した学生より多くのクルーが関わっています。2018年は学生30人に対して44人が関わりました。

講義をする講師がいて、つまづいた人をフォローするTAがいる。チーム開発時には、チームごとにエンジニア2名+1が張り付き、議論が必要なのか、まずは手を動かしたほうがいいのか、最終日に間に合わせるための優先順はどう付ければいいのかをサポートします。

1人では学びにくいことを学べる環境にしています。

切磋琢磨できる雰囲気

チーム開発の最終日には成果発表があり、順位が付けられます。

単に勝ち負けを競ってもらいたいわけではありません。

このTreasureで出会った仲間と、この3週間はもちろんのこと、その後も切磋琢磨できる関係でいられるような雰囲気を目指しています。

まとめ

今回のイベントでは「Treasureが人生の転機になった」的なことを言ってくれた人が何人かいました。これからも学生の3週間という貴重な時間が、参加した人たちのTreasure(宝)になるよう全力でやっていきたいと思います。

おまけ

去年のTreasure様子はこちら → VOYAGE GROUPエンジニアインターンシップ Treasure2018 を開催しました #voyage_intern - VOYAGE GROUP techlog

春のエンジニア向けインターンシップ2019開催のお知らせ~第二弾~

こんにちは、VOYAGE GROUP人事の @saxsir です。
VOYAGE GROUPでは、21卒エンジニア学生向けに春のインターンシップを開催します!

3月にも開催していましたが、今回はその第二弾となる4,5月イベントのご案内です。※ベースは3月に開催したものと同内容になります


Goで学ぶWebアプリケーション開発とチーム開発

GoでWebアプリケーションを書いてみよう!
サーバサイドをメインにクライアントサイドとの連携、そしてチームでの開発についても学びます。

今回の内容は、VOYAGE GROUPで開催する夏のインターンシップ「Treasure」を少しだけ体感できるものとなっております。 (Treasureの詳しい内容については、過去のブログ にまとめています)

1dayインターンシップ当日は、サーバーサイドはGo, クライアントサイドはHTML, JavaScript(Vue.js)を利用し、クライアントサイドとサーバーサイドの連携、DBとの接続など、Webアプリケーションの開発に必要な技術を広く触ります。今自分が何を知っていてこれから何を学んでいけばいいのか?これからインターンシップを探していく上で参考になることをもって帰ってもらえれば嬉しいです!

当日はハンズオン形式で知識のインプット、個人でのアウトプットを通して学んでもらい、最後はチームで機能を実装してもらう予定です。

※ 当日のタイムスケジュール(予定)

11:00 開始
11:00~12:00 チュートリアル
12:00~13:00 ランチ
13:00~15:30 講義・実装
15:30~18:30 チーム開発
~ 21:00 懇親会

1日に詰め込んでいるので、とても消化しきれない量のインプットがあると思いますが、できるだけ多く経験、知識を持って帰ってもらえたら嬉しいです。

Treasureにおいて大切にしているチーム開発の楽しさを一足先に体感してみませんか?

f:id:saxsir256:20190313161750j:plain

こんな人にオススメ

  • プロのエンジニアがどのようにWebアプリを書いてるか学びたい!
  • チームで開発してみたい!
  • 同世代の中で自分のレベルを確かめたい!
  • 春からスタートダッシュしたい!!

前回参加者の声

Aさん

短時間ながらインプット、アウトプット共にとても密度の高い経験をすることができました。一人で黙々とやっていても得られないチーム開発の難しさや楽しさを学ぶいい機会になった

Iさん

1日であるため参加もしやすく,それでいて濃密な1dayインターンは他に類を見ないと思います.後輩や友人にもおすすめしたいので,今後もぜひ開催してください!

【2019/03/22 11:12追記】3月に参加してくれた学生さんがブログを書いてくれました!

medium.com

日程

  • 2019年4月13日(土) 11:00 - 21:00(18:30~は懇親会)@東京(VOYAGE GROUP渋谷本社)
    • 応募締切: 2019年4月8日(月) 9:30
  • 2019年5月6日(月・祝) 11:00 - 21:00(18:30~は懇親会)@京都(サポーターズ京都オフィス)
    • 応募締切: 2019年4月25日(木) 9:30

※どちらか片方の日程のみ参加可能です

場所

東京開催

VOYAGE GROUP本社(渋谷ファーストプレイス)8F セミナールーム https://voyagegroup.com/company/profile/#wrap_map

京都開催

サポーターズ京都オフィス セミナールーム
https://supporterz.jp/kyoto-rental/

持ち物

  • PC
    • 推奨: macOS 10.13 (High Sierra) 以降が動く Mac もしくは Ubuntu 18.04 LTS 以降が動く PC (仮想環境も可)
    • ※Windows環境は当日サポートしていませんので、VirtualBox等の仮想環境でLinuxが動く環境を用意しておいてください
  • 元気な身体とできるだけ吸収していくぞ!という気持ち

エントリー

下記フォームから登録してください!
エントリーフォーム

応募資格

  • 2021年4月以降に入社可能な方(文理不問)
  • プログラミングが好きな方!
  • (必須ではありませんが) サーバーサイドの開発経験があると良いです

その他

  • 交通費は自己負担となります
  • 懇親会では軽食と飲み物(アルコール・ソフトドリンク)がでます
  • 服装は自由ですが、できるだけ私服でお越しください!

※ 夏のインターン、Treasureの様子は下記ブログにまとまっています techlog.voyagegroup.com

お問い合わせ

  • 人事本部: インターンシップ担当
  • メールアドレス: new-recruit@voyagegroup.com

それでは、たくさんのご応募お待ちしております!

『VOYAGE GROUP エンジニアの公開ガチ評価会』を開催しました!評価資料・評価結果すべてお見せします!

こんにちは。

ポイントメディア事業本部エンジニアの、あっきー(@akkiihs)です。

2019/01/30(水)に開催した『VOYAGE GROUP エンジニアの公開ガチ評価会』の評価資料・評価結果を公開します!

(大変おまたせしました、、!)

voyagegroup.connpass.com

イベント経緯

その前に、イベントを開催するにあたった経緯など簡単に書いておきます。

もともと、このイベントを開催した経緯として、PHPカンファレンス2018がありました。

VOYAGE GROUPは、PHPカンファレンス2018のスポンサーであり、セッションやブースにてエンジニア評価制度である『技術力評価会』について話をしました。

ただ、話をしただけでは、概念としては伝えられても「実際のところ、どんな感じなの?」ってところが、まだ伝わりきりません。

そこで、実際の技術力評価会をイベント形式で見てもらおう!公開してしまおう!というのが『公開ガチ評価会』のイベントを実施するキッカケとなりました。

かなり思い切ったイベントだったのでは、、

イベント当日の様子

イベントの公開時から、思っていた以上に参加申し込みがあり定員が溢れ、当日は70名近くの方が参加くださいました!

当日は、Twitterハッシュタグ「#vg_tech_assessment」で、つぶやいてもらいました。

Togetterでまとめたので、ご覧ください。

togetter.com

イベントでは、最初にCTOである、小賀さん(@makoga)から、『5分でわかる技術力評価会』の話がありました。

『技術力評価会』を制度として導入した経緯や、評価会の内容、毎回改善が繰り返されていることなどが濃縮されてます!

speakerdeck.com

そして、実際の評価会へ。

今回は、以下の被評価者・評価者で、本来90分かけて実施するところを、60分に短縮し実施していただきました!

被評価者: やんうぇい さん(@yangwei21

評価者: すずけん さん(@suzu_v

   : ねこや さん(@nekoya

イベント後の懇親会では、評価制度についての交流もあり、

後日ブログで書いてくださる方もいて反響が大きかったんじゃないかなあと思います。

評価資料

当日、参加者にも公開していた評価資料です。

gist.github.com

評価結果

気になる評価結果はこちらです。

技術力評価会 評価結果

評価者 @suzuken

総評

管理画面のフロントエンドのツールやライブラリ類を入れ替えていくという話でした。うまくやっていたと思います。

このチームの話をきいて強みであると思ったのは、ほぼ毎日リリースされている画面でありかつほぼ全員で管理画面を触るということです。フロントエンド専任のメンバーが2,3人だけであれば話をして同意すればごっそりと既存スタックからの移し替えも含めて進めることができるでしょう。しかし今回はそうではなく、数年運用されてきていて多くの人が開発に関わっているフロントエンドの多様な実装を今あらためて置き換えていくという試みでした。結果として、段階的にかつ整備しやすい環境に向けての一歩が着実に踏めていると感じました。

次のあたりは安定した判断ができていると思った箇所です。

  • 無理にSPAにせず複数ページのアプリケーションに分けた
  • UI Frameworkを統一(ルールをシンプルに)
  • 静的な画面、簡単なフォームではひとまずさくっとSymfony Formを使う

ともすればフルリプレースですべてモダンな構成にと考えてしまいがちではありますが、現状のチームの知見や既存コードの運用を踏まえると、手堅く課題を解決できるプランとなっていました。

また評価会でも触れましたが、Reactをより全面に導入していくことにより、返って既存のスタックが複雑化してしまうのではないかという懸念もあります。これについては現在も既存画面を置き換えつつも、既存の技術スタックから移るメリットをチーム内のメンバーにも共有しペアプロなどを通じながら巻き込んで行けているのは良い進め方でした。

成長へのアドバイス

プロダクトを着実に前進させるための施策を適切なタイミングで実行できていたと思います。とはいえ決めてからが頑張りところです。がっつり改善していってください!

  

ねこやからやんうぇいへ

時間も短く多数のギャラリーのいる中、必然的にプロレスの様相を帯びる公開評価会ではありましたが、それも込みでいい会でした。

まず感心したのは、そうした場の作り方もひっくるめて、やんうぇいが「今日はこういう会にしよう」という線を言外に、極めて自然に引いてくれたことです。もしかしたらあまり自覚してないかもしれないけど。

そういう器用さも持ち合わせていることは不思議でもなんでもないけど、それをあの場でさりげなくやってのけたのは大人の立ち回りでかっこよかった。

具体的には

  • 時間とギャラリーの関係で見せるコードは限定的に
  • チームの誰それがみたいな個別の人の話はしない

あたりをメッセージとして受け取りました。

技術選定

そうするよねー、というセレクトで特に違和感ありません。1年前、2年前ならこのへん議論のしどころだったろうけど、今はそういう時勢じゃない。

TypeScriptの設定は自分ならもう少し堅くするし、実際にそうしている。既存のアーキテクチャからハードルを低くするという狙いも分かるけど、型に関する理解が薄いまま書いてしまう場面が出てこないかという懸念はあります。

投資判断

主眼に置いていると感じられたのは以下の2点です。

  • Developer experienceの向上
  • 既存アーキテクチャが抱えるセキュリティリスクの解消

いずれも理解はできるし、後者は具体的な事業リスクなので、そこを改善できるのは意義がありそうに思えます。

いろいろな要素がちょうどよく出揃ってきたタイミングで、シュッと新しいものを滑り込ませることが出来たんだろうなと見て取れました。

既存のものを置き換えるとしたら、もう少し材料を揃える必要があったかもしれないけど、新しいところに部分的に投入するなら「やっちゃいました」でいいのかな。そういう状況を作れていたならそれでよさそう。

チームへの普及、定着

最初の方に「チームの中で技術的な担当範囲での役割分担はしていない」という話があったけど、今回の取り組みの普及度合いはまだそこまででもなさそうに見えています。

書ける人を増やす取り組みを怠っているわけではなさそうなので、継続的に普及させていってください。

次の一手

既存のものを一気に置き換えないというのは現段階の選択としてありだけど、未来永劫それを併存させるのかは気になるところです。複数のアーキテクチャが混在していて、両方を理解していないと管理画面の開発ができないみたいになると効率が悪くなりそう。そこにどう立ち向かっていくのかが次の課題かと思います。

現段階ではそこはあまり意識していなそうに受け取れたし、まだその時期ではないかもしれないけれど、そこでどういう決断をするのかは気になります。

  

VOYAGE GROUPの、エンジニア評価制度である『技術力評価会』では、

準備、評価会そのもの、評価結果(フィードバック)、振り返りを時間をかけて取り組んでいます。

それだけ、評価する・評価されるに関係なく、エンジニアが納得感を得られるかが大切であり、

それによって組織全体としての育成・評価の共通基準が生まれやすくなるのかなと個人的に思います。

  

  

次回、同様なイベントを開催するかどうかは、、未定です!

  

  

最後に、VOYAGE GROUPではキャリア採用を募集しております(ちゃっかり宣伝)

voyagegroup.com

デブサミ2019講演「レガシーとのいい感じの付き合い方」の資料を公開します。

ポイントメディア事業本部の福田です。

Developers Summit 2019にて、「レガシーとのいい感じの付き合い方」と題して、ECナビの4年に渡る改善事例を発表しました。 講演資料を公開します。

セッション詳細

event.shoeisha.jp

公開資料

当日の反響(togetter)

togetter.com

発表を終えて

ネタが地味目なので、当日どれくらい来ていただけるのか少し不安でしたが、満員+立ち見の盛況でした。

当日ご参加いただいた方、ありがとうございました。

アイスブレイクとして、会場のみなさんには「何年もののレガシーシステムに取り組んでいるか?」について質問させていただいたところ、「10年以上」という方が半数超え(※壇上からの主観です)で、レガシーシステムの問題は顕在化していることを実感しました。

目立たずに水面下でじわじわと苦しめられてる問題だと思うので、私達のような”課題先進国”の事例が共有され、この問題を議論する機会が増えていくといいですね。

私達もまだまだ改善途上なので知見を深めていきたく、「レガシーシステムについて語り合いたい」という方がいれば、お声がけください。

あわせて読みたい

「老舗メディアが改善に取り組んでる話」 techlog.voyagegroup.com 2016年11月ごろの、PHPカンファレンスでの事例紹介。事始めが終わって、ECナビAWS移行を進めていた時期です。

「インフラチームと開発チームの垣根をなくすためにAWSのCI環境を構築した話」 techlog.voyagegroup.com 2017年2月ごろの記事。ECナビAWS移行を無事完了させた直後の話。CloudFormationとTravis CIあたりがくわしく説明されています。

最後に

ポイントメディア事業本部では、カイゼンを一緒に進めていくエンジニアを募集中です。

サービス開発エンジニア voyagegroup.com

システム基盤エンジニア voyagegroup.com

春のエンジニア向けインターンシップ2019開催のお知らせ

こんにちは、VOYAGE GROUP人事の @saxsir です。
VOYAGE GROUPでは、21卒エンジニア学生向けに春のインターンシップ(& 勉強会)を開催します!

まずはその第一弾となる、3月開催イベントの紹介です。

  1. Goライブコーディング(3h)
  2. 実践Webアプリケーション開発(1day)

の2コースを開催します。


1. Goライブコーディング

VOYAGE GROUPのエンジニアがペアプロでプログラムを組み上げていく様子をライブコーディングします!

使う言語はGo。プロのエンジニアがどう考えてコードを書いていくのか?どんなツールを使っているのか?当日はエンジニア2名によるペアプロスタイルで実装を進めていきます。

お酒もご用意しますので、最高のコードをつまみに、食べて、飲める、イベントとなっております。 お酒を飲みながら、プロの技術に酔いしれましょう。
(未成年の方、お酒が苦手な方向けにソフトドリンクも用意してあります)

ライブコーディング終了後はそのまま懇親会もあるので、直接VOYAGE GROUPのエンジニアに話を聞くこともできます!

※ ライブコーディングとはエンジニアが皆さんの目の前でコーディングを行うイベントです。 画面の分割や切り替えのテクニック、エディタの設定やプラグインなど、どんな環境でやっているのか トップエンジニアが扱うLinuxコマンドなどをライブで学ぶことができます!

f:id:saxsir256:20190208111306j:plain

こんな人にオススメ

  • プロの開発環境を見てみたい
  • Goでなにか書いたことがある/書いてみたい
  • 春、夏のインターンを探している

日程

2019年3月1日(金) 18:00 - 21:00

場所

VOYAGE GROUP本社(渋谷ファーストプレイス)8F セミナールーム https://voyagegroup.com/company/profile/#wrap_map

持ち物

  • 特になし

エントリー

下記フォームから登録してください!
エントリーフォーム

応募締め切り: 2019年2月26日(火) 23:59まで

応募資格

  • 2021年4月以降に入社可能な方(文理不問)

その他

  • 交通費は自己負担となります
  • 懇親会では軽食と飲み物(アルコール・ソフトドリンク)がでます
  • 服装は自由ですが、できるだけ私服でお越しください!

2. 実践Webアプリケーション開発コース

GoでWebアプリケーションを書いてみよう!
サーバサイドをメインにフロントエンドとの連携、そしてチームでの開発についても学びます。

今回の内容は、VOYAGE GROUPで開催する夏のインターンシップ「Treasure」を少しだけ体感できるものとなっております。

具体的にはフロントサイドはHTML, CSS, JavaScript, React, npm, webpack等々...サーバーサイドはGo, dep, MySQLに加えて、開発環境ではdocker等。

当日はGoでのアプリケーション開発がメインとなる予定ですが、Webアプリケーションを開発するために必要な知識が詰まったものになっているので、今自分が何を知っていてこれから何を学んでいけばいいのか?これからインターンシップを探していく上で参考になることをもって帰ってもらえれば嬉しいです!

当日はハンズオン形式で知識のインプット、個人でのアウトプットを通して学んでもらい、最後はチームで機能を実装してもらう予定です。

Treasureにおいて大切にしているチーム開発の楽しさを一足先に体感してみませんか?

f:id:saxsir256:20190208114339j:plain

こんな人にオススメ

  • GoでWebアプリケーションを書いてみたい
  • チームでの開発を体験してみたい
  • 夏のインターンを探している/Treasureでどんなことをやるのか気になる
  • 春からスタートダッシュしたい!

日程

  • 2019年3月10日(日) 10:00 - 18:00, 18:00 - 21:00(懇親会)
    • 応募締め切り: 2019年3月3日(日) 23:59まで
  • 2019年3月18日(月) 10:00 - 18:00, 18:00 - 21:00(懇親会)
    • 応募締め切り: 2019年3月11日(月・祝) 23:59まで

※どちらか片方の日程のみ参加可能です

場所

VOYAGE GROUP本社(渋谷ファーストプレイス)8F セミナールーム https://voyagegroup.com/company/profile/#wrap_map

持ち物

  • PC
    • 推奨: macOS 10.12 (Sierra) 以降が動く Mac もしくは Ubuntu 16.04 LTS 以降が動く PC (仮想環境も可)
    • ※Windows環境は当日サポートしていませんので、VirtualBox等の仮想環境でLinuxが動く環境を用意しておいてください

エントリー

下記フォームから登録してください!
エントリーフォーム

応募資格

  • 2021年4月以降に入社可能な方(文理不問)

参加者の声

"グループ開発ならではの面白さや難しさを知ることができた。 Goの自分の知るよりも大きなアプリケーションを触ることができて良い経験になった。"

"参加学生のレベルの高さを感じることができた"

"チーム開発経験に乏しかった為、チーム開発の時間があったのは良かった。 Githubを使った開発の流れを知ることができて、今後に活かせそうだと感じた。"

その他

  • 交通費は自己負担となります
  • 懇親会では軽食と飲み物(アルコール・ソフトドリンク)がでます
  • 服装は自由ですが、できるだけ私服でお越しください!

※ 夏のインターン、Treasureの様子は下記ブログにまとまっています techlog.voyagegroup.com

お問い合わせ

  • 人事本部: インターンシップ担当
  • メールアドレス: new-recruit@voyagegroup.com

春休み、なにか新しいことに挑戦してみませんか?
それでは、たくさんのご応募お待ちしております!

Netflixにおけるフルサイクル開発者―開発したものが運用する

こんにちは。fluctでiOS/Android向けSDKの開発をしているarimuraです。この記事ではPhilip Fisher-Ogden、Greg Burrell、Dianne MarshによるFull Cycle Developers at Netflix — Operate What You Buildを私が翻訳したものを著者の許可のもとに掲載しています。元の記事は弊社の技術力評価会のインプットの一つとして共有されており、そこで興味を持ったのが翻訳するきっかけとなりました。

以下、2018年5月時点における情報を記載したものであり Netflix TechBlog「Full Cycle Developers at Netflix」より引用したものである。

Netflixにおけるフルサイクル開発者―開発したものが運用する

2012年―Netflixでの重要なサービスの運用は骨の折れるものだった。デプロイは湿った砂の上を歩くように感じられた。カナリアリリースは機能ではなく忍耐力を検証するものとなっていた(「1週間何も壊れなかったからプッシュしよう!」)。問題の調査はチーム間でゴムボールを弾ませているようだし、原因の解明は難しく、次々と跳ね返ってくるボールを止めるのはさらに難しかった。これらの全ては変化が必要なサインだった。

そして2018年。Netflixは世界中の会員1億2500万人が1日に1億4000万以上の時間を楽しむまでのサービスに成長した。私たちはエンジニアリングチームの開発と運用の改善のために莫大な投資を行った。サービスの開発と運用を様々なアプローチで試した。その中からNetflixでよく使われているあるアプローチを、その良い点と悪い点を含め紹介したい。私たちの試みを共有することでそこから議論が発展し、何かを学んでもらえれば幸いだ。

1つのチームでの旅

エッジエンジニアリングのチームはNetflixのストリーミングを動かすためのAWSサービスの第一レイヤーを受け持っている。過去にはエッジエンジニアリングに運用専任のチームとデプロイ+運用+サポートを担当するSREが存在していた。新機能リリース時は開発チームと運用チームがメトリクス、アラート、キャパシティープランニング等についての調整を行い、その後デプロイと運用のため開発チームから運用チームにコードが手渡されていた。コードの運用とパートナーのサポートを効果的に行うために、運用チームは新機能やバグフィックスについての継続的なトレーニングが必要だった。開発チームとは分離した運用チームを持つことの主な利点は、物事が上手くいっているときは開発チームへの割り込みが少ないことだ。

しかし上手くいかなくなるとコストは積み上がっていく。開発チームと運用チーム間でのコミュニケーションや知識の移転はロスが多く、デバッグやパートナーからの質問に回答するためには余計な往復を必要とした。また、運用チームがデプロイされる変更点についての直接的な知識を持っていないため、デプロイ時の問題の検知と解決にはより多くの時間がかかった。コードの完成からデプロイまでの時間は今よりずっと長く、リリースは日ではなく週単位で行われた。アラート/監視の欠如や性能問題やレイテンシーの増加といった問題で実際に苦しむのは運用チームで、開発チームはそれを運用チームから間接的に伝えられるだけだった。

この状況を改善するため、エッジエンジニアリングでは開発チームも必要なときにコードをプッシュでき、業務時間外の本番環境での問題やサポートも行うというハイブリッドモデルが導入された。これにより開発者のフィードバックと学習のサイクルは改善された。しかし部分的に責任を負うだけでは、チーム間の溝は埋まらなかった。

例えば、開発チームがデプロイをしたりパイプラインの破損をデバッグできたとしても、多くの場合彼らはリリースの専門家である運用チームの指示に従うことが多かった。また運用チームにとっては、日々の仕事を行うモチベーションはあっても、他チームから自身への依存をなくすための自動化を優先させるのは難しかった。

より良い方法を探し求め、私たちは一歩戻って第一原則から考え直した。何を達成すべきで、なぜそれができてないのか?

ソフトウェアライフサイクル

ソフトウェアライフサイクルの目的はtime to valueの最適化、つまり効果的にアイディアを実際のプロダクトやサービスに変換することだ。ソフトウェアサービスを開発し運用することは一連の責任から構成される。


ソフトウェア開発ライフサイクルのコンポーネント

私たちはこれらの責任を分割していた。極端な例ではそれぞれの機能が全く別の個人/役割によって担当されていたのだ。


ソフトウェア開発ライフサイクルの専門家

これらの専門化された役割はそのセグメント内では効率的だが、ライフサイクル全体の非効率性を潜在的に作り出す。専門家は自分の分野での専門性の獲得や物事の最適化を行う。彼らは自分のパズルを解くことにより効果的になっていくのだ。しかしソフトウェアで顧客に価値を提供するためにはライフサイクル全体が必要となる。ライフサイクルの一断面のみを担当する専門家チームを持つとサイロ化が進み、最終的な顧客への価値提供を遅らせることになる。異なる分野の専門家を1つのチームにすることでサイロを減らすことができるかもしれない。しかし1つのチームで別々の専門家が自分の仕事を行うような状況では、コミュニケーションのオーバーヘッドの増加、ボトルネックの発生、フィードバックループの非効率性に繋がってしまう。

開発したものが運用する

devopsの原則は私たちのアプローチを考え直す際にインスピレーションを与えてくれた。サイロを解体しフルソフトウェアライフサイクルの共同所有を奨励することで、学習とフィードバックを最適化することができる。


devopsの原則を取り入れたソフトウェア開発ライフサイクル

"開発したものが運用する"というアプローチでは、システムを開発するチームが運用とサポートにも責任を持つことでdevopsの原則を実践する。責任を外部化するのではなく開発チームに与えることで、ダイレクトなフィードバックループと共通のインセンティブを持つことができるのだ。運用に苦痛を感じているチームにはシステムの設計やコードを変更することでそれを治癒する力が与えられる。彼らは開発と運用の両方に対して責任を持っている。各開発チームは開発上の課題、パフォーマンスのバグ、キャパシティープランニング、アラートの欠如、パートナーサポートといったものを受け持っているのだ。

開発者ツールによるスケール

一連の開発ライフサイクルに対するオーナーシップによりソフトウェア開発者に求められることは大幅に増えるが、開発上の共通する要求を単純化したり自動化するツールによって負荷を軽減できる。例えばソフトウェア開発者がサービスのロールバックの管理することになる場合、ロールバックができるだけでなく問題の検出やアラート通知ができる高機能なツールが必要になる。

Netflixでは、多くの開発チームが持つ共通の課題を解決するためのツーリングとインフラの開発をミッションとする複数の集中型チーム(e.g. クラウドプラットフォーム、パフォーマンス&リライアビリティエンジニアリング、エンジニアリングツール)が創設された。このチームは専門化された知識を再利用可能なビルディングブロックにすることにより他のチームの力を高める。


専門家が再利用可能なツールを作る

これらのツールを手中にして、開発チームはプロダクトのドメインの問題解決に集中することができる。新しいツールへの必要性が生じたとき、集中型チームは、複数の開発チーム間で共通のニーズがないか見極める。そして共通のニーズと認められたら、共同作業が進められる。開発チームからの要望が特殊すぎて共通の投資としては認められないこともあるだろう。その場合、開発チームはその課題が自分たちで解決するほど重要なものかを判断することになる。

類似した課題への対応を共通投資とするかしないかを判断することは、私たちのアプローチで最も困難なことの1つだ。私たちの経験では、複数のグループが最終的に1つになるような解決策を並行して作ってしまうリスクを冒してでも、開発者からの要望に対して新しい解決策を発見することは価値がある。コミュニケーションと目的の共有は成功への鍵だ。まずは要望を理解しそれが汎用的あるのか判断することで、Netflix全体の開発チームにとってより良い投資をすることができる。

フルサイクル開発者

これら全てのアイディアをまとめることで、私たちは1つのモデルに到達した。驚くべき開発ツールを持ち、設計、開発、テスト、デプロイ、運用、サポートといったフルソフトウェアライフサイクルへの責任を持つ開発チームだ。


エンパワーされたフルサイクル開発者

フルサイクル開発者はソフトウェアライフサイクルの全ての分野において知識があり効果的であることが期待される。多くのNetflixの新入社員は自分が経験の浅い分野にも挑戦することになる。そのため知識の習得やスキルアップのための開発ブートキャンプと継続的トレーニングが用意されている。しかし知識だけでは十分ではない。容易に扱うことができるデプロイパイプラインツール(e.g. Spinnaker)やモニタリングツール(e.g. Atlas)も効果的なフルサイクルオーナーシップには必須なのだ。

フルサイクル開発者はエンジニアリングの原則をライフサイクルのあらゆる分野に応用する。開発者の視点で問題を評価し、「このシステムを動かすために必要なものをどう自動化できるか?」「どのようなセルフサービスツールがあればパートナーが開発者の手を借りずに自分の疑問に答えることができるだろうか」と問う。人間中心よりもシステム中心に考え、手動で行われていたものを自動化することによって、チームはスケールする。

フルサイクル開発者モデルを取り入れるには考え方を変えることが求められる。ある開発者が活躍の場として主に設計と開発、そして時々はテスト、と考えたとしよう。この見方は運用を邪魔者とみなし、"本当の仕事"に早く戻るために運用やサポートの問題に対して短期的な視点での対応をすることに繋がる。しかし、フルサイクル開発者の"本当の仕事"はライフサイクル全てにわたる問題を解決することだ。フルサイクル開発者はSWE(Software Engineer)としてもSDET(Software Development Engineer in Test)としてもSREとしても振る舞うのだ。あるときはビジネスの課題を解決するソフトウェアを開発し、またあるときはテストケースを書き、そしてまたあるときはシステム運用の自動化を行う。

このモデルを成功させるためには、チームはそれが価値あるものになるよう真剣に取り組む必要があるし、コストについても意識的でなければならない。ビルドとデプロイを管理し、本番環境での問題に対応し、パートナーからの依頼に応えるために、チームは余裕を持って配置される必要がある。トレーニングするための時間やツールへの投資も必要だ。再利用可能なコンポーネントやソリューションを生み出すために集中型チームとのパートナーシップも構築されなければならない。計画と振り返りではライフサイクルの全ての分野について検討しなくてはならない。アラート対応の自動化やパートナー向けのセルフサービスツールの開発は、ビジネス上の要望と同じレベルで優先順位付けされる必要がある。十分な人員と優先順位付けとパートナーシップによって、チームは自分のビルドしたものを運用することができる。それなしにはチームは過度な負担や燃え尽きのリスクに晒されることになる。

Netflix以外でこのモデルを採用するには調整が必要だ。開発チームによくある課題は似通っている。例えば継続的デリバリーのためのパイプラインが必要だったり、モニタリングだったりするだろう。多くの企業ではNetflixのように集中型チームに対して人員を配置できないだろうし、Netflixの規模が必要とするような複雑性も不要だろう。Netflixの多くのツールはオープンソースだし、手始めに試してみるにはちょうどいいだろう。まずは潜在的な価値やコストの分析から始め、続いて考え方を変えてみよう。何が必要かを評価し、最小のコストでどう実現するかを考えよう。

トレードオフ

テック業界には開発と運用上の要求を解決するための多くの方法が存在する(devopsトポロジーを参照)。ここで記述したフルサイクルモデルはNetflixでは普通のものだが、マイナス面もある。あるモデルを選択する前にそのトレードオフを知ることは成功の確率をあげることになるだろう。

フルサイクルモデルにおいては、ツールによって拡大されたより広い分野でのオーナーシップや有効性に対して優先順位付けがなされる。仕事の幅広さは多様なテクノロジーへの興味や適性を求めることになる。あるエンジニアは狭い分野での世界的な専門家になることを好むし、そのような専門家が必要とされる分野もある。このような専門家にとっては、広い分野でそれなりのスキルを求められることは居心地の悪いことであるし、時には虚しいと感じるかもしれない。Netflixでも、幅のあるスキルではなく特定の分野での深い専門性を好む人々も存在するし、私たちもそのような働き方をサポートしている。そして別の人たちはより幅広い職務を楽しみながら働いている。

クラウドシステムの開発と運用を行う中で、私たちはフルサイクルであることを重視する開発者が如何に効果的に働くかを知った。しかし、その幅広さは開発者の認知的負荷を増大させるし、チームは1つの分野にフォーカスしてる場合より頻繁な優先順位付を行うことになる。これはデプロイ+運用+サポートを順番に担当するオンコールのローテイションを組むことで緩和することができた。上手くいっているときは集中してフロー状態で仕事をすることが可能になるし、上手くいかないときは割り込みだらけの環境でなり、それは結局燃え尽きにつながることになる。

ツールと自動化は専門知識をスケールすることができるが、開発者の生産性と運用についての全ての問題を解決するツールというのは存在しない。Netflixには集中型チームにより正式に管理された一連の"舗装された(paved road)"ツールとプラクティスがある。私たちはこれらの"舗装された"ツールを採用することを強制はしないが、これらのテクノロジーを使うことでずっと良い開発と運用を行えることを確認しているので採用を推奨している。しかし、私たちのアプローチのマイナス面として「最も重要な要求のための全ての機能を積んだ全てのツールを全てのチームが使ってる」という理想が殆どの実現不可能だということがある。私たちの集中型チームへの投資に対するリターンを実現するのには、努力と共通理解と継続的な適応が必要なのだ。

結論

2012年から今日までの道のりは実験と学習と適応の連続だった。エッジエンジニアリング——その早期の実験はより良いモデルの探求に繋がった——は今日のフルサイクル開発モデルに応用されている。デプロイは頻繁に繰り返されるルーティンになり、カナリアリリースは数日ではなく数時間で行われ、開発者はチーム間で責任を押し付け合うのではなく素早く問題の調査をして解決することができる。他の組織でも同様の恩恵が期待されるだろう。しかし、私たちは異なる場所から適用と学習によってここに到達したことを忘れてはならない。明日の要望がさらなる進化を導くだろう。

このモデルが実際に動いているところが見たい?未来に向けてこのアプローチがどう進化するかについての探求に参加したい?応募お待ちしています。

Philip Fisher-Ogden, Greg Burrell, and Dianne Marsh

arimura

この記事は社内のGitHubに共有された下書きに対して、有志のメンバーがフィードバックするという形で翻訳されました。 翻訳に協力してくれたアミン、海老原さん、小橋さん、 t-wadaさんに感謝!

#phpcon2018 でVOYAGE GROUPのエンジニア評価制度ってどんな感じなのか再演しました!(資料・動画あり)

目次


こんにちは!

ECナビエンジニアのゆきみねです。

12月15日に行われた PHPカンファレンス2018 で、VOYAGE GROUPのエンジニア評価制度「技術力評価会」ってどんな感じなのか再演しました。

発表資料・動画は公開してます

speakerdeck.com

VOYAGEのエンジニア評価制度ってどんな感じなのか25分で再演

動画はこちら

反響をまとめてみました

togetter.com

いただいた質問への回答

発表中にお知らせした通り、いただいた質問にお答えします。


【質問】
評価面談は発表30分+質疑応答60分とあったけど、
このMarkdown資料準備するのに時間どれくらいかかるんだろう

【回答】
せっかくなのでアンケートを取ってみたところ、
「評価会資料の作成にかけるのは2日未満」という人が8割でした。

初回は時間をかけた人も、何回かやっていくうちに
かける時間が短縮されているようです(僕もそうでした)。

評価会資料の作成にどのくらい時間をかけていますか?(素振り、素振り後の修正含む)

同アンケートの補足コメント

  • 題材による気がします!
  • 普段のissueを書くときから評価会を意識する. まとめを適度に挟むように書くことで資料を書く手間を減らすようになった.
  • 2回目以降でこれくらいです。だいたい1営強というところ。
  • 3回目あたりから資料作成は埋めるだけって感じ作業になってきてて、日頃の業務で意識してることと評価会資料との差異を減らしていく感じになってる
  • 規模が大きい + 相手にどれだけ事前に情報を提供すればいいか悩む + 本番で言葉が出てこないことが無いように資料作成に時間がかかってしまう
  • 初回は2日くらいかけたけど、少しずつ短くなっている。(仕事をしていく中で周りの人に説明するための資料をそのまま技術力評価会に使うなど、取り組み方がわかった)

【質問】
評価者による面談で評価を決めるとなると、評価者によってバラツキが出たりすると思うのだけど、
その辺の平準化とかどう解決してるのか気になる

【回答】
評価者のバラツキを少なくするためにやったこと / やってること は以下の通りです。

1. 最初の300回くらいはCTOが全てに同席し、CTOがフィードバックした
2. 評価者のペアを前回と同じにならないように組み合わせている
3. 評価結果レポートをCTO、上長、評価者ですり合わせしている

【質問】
発表で例示されていたアドバイス文は年1回もらうものとしては
ちょっと細かい粒度の内容だったけど、ただの例かな

【回答】
技術力評価会の実施頻度は半年に1度です。

発表で出したものはサンプルではなく評価者が実際に書いたものです。

できるだけ具体的に書こうと意識しているため細かい粒度に見えるかもしれません。

また、技術力評価会はあくまでも能力の部分だけで、
実績も含めてトータルのフィードバックは別途行われています。

【質問】
制度全体の話とかも気になる

【回答】
制度全体の話は是非以下の資料・記事をご覧ください。

2019年1月にまた実演します

2019年1月30日に技術力評価会の実演イベントを行います。

PHPカンファレンスでは 再演 でしたが、1月のイベントは、参加者の皆さんの前で、VOYAGE GROUP エンジニアを 本当に 評価します。

ありがたいことに、一般枠は埋まってしまいましたが、PHPカンファレンス2018に参加してくださった方用の枠に若干余裕があります。

他の人のエンジニア評価が気になるという方、是非遊びにきてください。

voyagegroup.connpass.com

ありがとうございました!

現地へ観に来てくださった皆さん、発表資料・動画を見てくださった皆さん、発表練習に協力してくださった皆さん、応援してくださった皆さん、ありがとうございました!

25分という発表時間で、どうすれば伝わるかと頭をひねった数ヶ月でしたが、無事評価会の雰囲気をお伝えできたようでよかったです。

2019年もよろしくお願い致します。