『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