デブサミ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年もよろしくお願い致します。

他社エンジニアの評価って気になりませんか? phpcon2018ブースでVOYAGE GROUP技術力評価制度を説明して反響が大きかったことベスト3

こんにちは!!

VOYAGE GROUP 新卒2年目エンジニア
しゅーぞー(@ShuzoN__)です.

2018/12/15(土)に開催されたPHPカンファレンス2018にスポンサーブーススタッフとして参加してきました.

f:id:namu_r21:20181225113705j:plain

今回は, phpcon2018ブースで新卒エンジニアがVOYAGE GROUP技術力評価制度を説明して反響が大きかったことベスト3 と題して, 他社のエンジニアから反響のあった弊社の評価制度についてクローズアップしていきたいと思います.

技術力評価制度を軸にしたVOYAGE GROUPブース

VOYAGE GROUPのスポンサーブースでは, 弊社の技術力評価制度である「技術力評価会」を軸として出展を行いました.

弊社エンジニアの本物の評価結果を展示し, 実際に来場者の方々に手にとって見ていただいていました.

f:id:namu_r21:20181225112631j:plain

みなさん他社エンジニアの評価は気になるそうで, 多くの方から評価制度や結果について聞いていただけました.

90分で自分の仕事を他のエンジニアにアピールする評価制度「技術力評価会」

みなさんの会社では, どのように技術力の評価を受けるでしょうか?

会場で聞いたところによると他社では以下のような制度であると聞きました.

  • そもそもエンジニアが評価に関与していない
  • 非エンジニアである上長が10分程度の面談で最終判断を下す
  • 数値的なKPIを設定し目標達成型で評価が行われる
    • 営業志向の会社はこの制度が多い印象
  • 割り込みや改善業務を考慮に入れていない締切達成駆動な評価制度
  • 技術力とは関係がない人柄ベースの評価の比重が大きい
  • 隣の人の評価結果や役職, グレードを知らない

営業や総合職の評価制度と同じ, もしくは引きづられた形の数値型評価制度が多く見受けられました. エンジニアの働き方に特化した評価制度はあまり耳にしませんでした.

f:id:namu_r21:20181225114259j:plain

ここで反響が大きかったことベスト3の発表です!

では, 早速 VOYAGE GROUPの評価制度「技術力評価会」で反響が大きかったことベスト3です.

  • 1位: プレゼン形式で1人あたり90分のプレゼンをエンジニア全員がやること
  • 2位: 評価や昇格結果が全社に公開されていること
  • 3位: 社外のエンジニアが招聘されエンジニアを評価すること

それぞれ細かく見ていきます.

1位: プレゼン形式で1人あたり90分のプレゼンをエンジニア全員がやること

f:id:namu_r21:20181225115304p:plain

弊社では, エンジニア1人1人に90分の時間を与えられ, 他事業部のエンジニア2名に半年間の仕事で最も良かったものをプレゼンテーションする機会を与えられます.

発表者の一方的なプレゼンではなく対話的に深掘りしていくため, 判断力や知識量, 説明力も問われます.

そこで, どこまでが本人の判断でどこからがチームの判断なのか洗い出されていきます.

やらなかったことや進め方まで細かく聞かれるため総合的な技術力を求められる制度になっています.

その90分間のプレゼン評価を元に, 評価者2名と事業部の技術責任者とCTOの意見を含めた評価結果レポートが決まります.

この評価結果レポートが事業責任者/本部長に渡り、給与やグレードに大きく影響を与えます。

ネタ選びやプレゼン, 対話を行うことで納得感が得やすい評価制度になっています.

実際の評価風景はこんな感じです. 写真はf-codeさんからお借りしています.

f:id:namu_r21:20181225114559j:plain

技術力評価会について詳細を知りたい方は以下の資料をご覧ください. 弊社CTOが7年かけて改良して来た評価制度について書いています.

speakerdeck.com

2位: 評価や昇格結果が全社に公開されていること

他社の話を聞いていると, 隣の人の評価やグレードを知らない と仰っている方がいらっしゃいました.

弊社では, GitHub上に評価用リポジトリが用意され, 全エンジニアの評価結果が社内公開されています.

つまり, 隣で働いている人の評価を自由に読むことが可能です.

また, 半期に一度, 昇格者が発表されるため, 誰がどのグレードなのかみんな知っています.

VOYAGE GROUPに新卒で入社したため, 公表されているのは当たり前だと思っていました.

これに関しては僕自身も驚きましたし, 来場者の方も反応が良かったです.

当日のブースでは, ブーススタッフの本物の評価資料/結果を展示し, 手にとって見ていただきました.

外部に公開できる程度に透明性が高い評価制度と言えると思います.

ちなみに, 株式会社f-codeさんも評価会を見学しています. 見学レポートはこちら.

www.wantedly.com

3位: 社外のエンジニアが招聘されエンジニアを評価すること

来場者の方に聞いたところ, 同じ会社にいる人間が同じ会社にいる人間を評価する形式が多いように見受けられました.

弊社では, 社外からCTOクラスのエンジニアを社外評価者として招聘し, 弊社エンジニアを評価する制度があります. 毎回, 全体の1割ほどのエンジニアが社外評価者の評価を受けます.

社外からの評価を行うことについてCTOは以下のように考えています.

  • 人数が少ない技術領域では, 評価者/被評価者の組み合わせのパターンが少ない. 社外から識者を招聘することで, 新しい視点や気付きが得られる機会を増やしたい.
  • 技術力評価会を数年実施することでVOYAGE GROUPでの価値観がすり合ってきた. それ自体は良いことだが, タコツボ化していくリスクもある. 社外の目を入れることで, 自分たちでは気づけないバイアスを知りたい.

僕自身はこういう効果もあると考えています.

  • 世間の市場価値に見合った評価を受けられること
  • 外部の意見を取り入れることで社内では上がってこない案や思考を取り入れられる

最近では, オミカレCTO @soudai1025 さん, cookpad CTO @mirakui さん, はてな チーフエンジニア @songmu さんなど著名なエンジニアを招聘しています.

@songmu さんから弊社の評価制度についてコメントをいただいているので掲載します.

評価プロセスをオープンにして質を高めて行く取り組みの中で,それを社外にまでオープンにしたことは超絶ウルトラCです.社外評価者は劇薬的に強力であり,それを上場企業が適正に運用していることは恐るべきことです.私も社外評価者として関わらせてもらっていますが,その際,評価に関わる社内の情報をかなり見せてもらえます.それだけ社外の人を信用できるのは会社の制度としても凄いことで,毎回身の引き締まる思いで評価をさせていただいています.

当たり前だと思っていた弊社の評価制度はすごく珍しいものだった

ブーススタッフとして働いて見たところ, 「弊社の評価制度はめちゃくちゃ珍しいもの」であることに気づきました.

  • ここまで“評価“に時間と金をかけている会社は少ない
  • 「評価されづらい仕事を評価するための仕組み」のポイントは“時間をかけた対話“にあった
  • 隣の人の評価結果/グレードを見れるのは当たり前じゃない
  • そもそもエンジニアの評価をエンジニア以外の人が行なっている
  • 社外のエンジニアに評価してもらうことは、ほとんどの会社でやっていない

評価制度に対してここまで真摯にお金と時間をかけて行なっている会社は会場で聞いた限りはなさそうでした.

7年間の改良を経て, 市場価値にあった & 透明性のある評価が行われ, ただ評価をもらうだけではなく成長のアドバイスも添えてフィードバックが行われます.

被評価者だけでなく評価者も評価結果が社内に公開されるなど良い質問ができるかという部分で評価されています.

社内エンジニア全員の成長のために行われているという意図をはっきりと感じることができました.

僕自身も3回評価を受けましたが, 納得感を得やすく, 弱点を理解しやすい良い制度だと思います.

他社エンジニアの評価制度って気になりませんか?

ところで, 他社エンジニアの評価制度って気になりませんか?

2019/01/30(水) にVOYAGE GROUP本社で 弊社のエンジニアを皆さんの目の前で本当に評価する イベントを開催します. そして後日, Twitter上で評価結果を公開します.

きっと同じ会社でも他人が評価される様は見ることができないと思います.
弊社の仕事ぶりや評価制度について知るいい機会です.

お酒や食べ物もご用意いたしますので気軽に来てくださいね.

応募はこちらから可能です. 枠が少なくなって来ていますのでお早めに!

voyagegroup.connpass.com

PeXのRailsを2年ぶりに4.2から5.0にアップデートしました。キャッシュやセッションまわりでのエラーにご注意!

VOYAGE GROUPの駒崎です。PeXというポイント交換サービスの開発運用をやっています。

PeXは2016年3月にSymfonyからRuby on Railsにフルリニューアルを果たし、そこから2年ほどRailsのバージョンが4.2で止まっていました。 PeXというサービスを今後長く運用していくためにも、Railsに乗り続けるためにも、という考えで2018年7月頃に5.0へアップデートしました。(実は現時点ではRails5.2にアップデートされているのですが)

Railsのアップデートを行うまでの流れと、リリース後にキャッシュ、セッション周りでハマったことをここにまとめます。

Railsアップデートでやったこと

  • gemのバージョンを最新にする。
  • gemのバージョンを最新にアップデートし続ける仕組みを作る。
  • Railsのバージョンを4.2から5.0にする。

3行で言うとこの流れで進めました。 gemのバージョンを最新にし、アップデートし続ける仕組みを作るまでに2ヶ月くらい。Railsのバージョンを4.2から5.0にするのに1ヶ月程、かかりました。

Railsのバージョンアップを行うと依存しているgemのバージョンも上げることになるのですが、同時に行うと非常に大変なのでまずは周辺gemのアップデートを行いました。

次にRailsのバージョンアップ作業中および今後のバージョンアップを踏まえ、gemのバージョンを最新にし続けるような仕組みを導入しました。

最後にRailsのバージョンを上げました。これは Rails アップグレードガイド | Rails ガイド を見つつ進めました。多分普通にアップデートする分には問題ないはずなので、プロダクト固有のハマったところを紹介したいと思います。

規模感

参考に rake stats の結果です。テストが厚めに書かれています(素敵)。

+----------------------+--------+--------+---------+---------+-----+-------+
| Name                 |  Lines |    LOC | Classes | Methods | M/C | LOC/M |
+----------------------+--------+--------+---------+---------+-----+-------+
| Controllers          |  12864 |  10130 |     291 |    1307 |   4 |     5 |
| Helpers              |    278 |    222 |       0 |      49 |   0 |     2 |
| Jobs                 |    195 |    140 |       8 |      16 |   2 |     6 |
| Models               |  18907 |  10610 |     279 |     958 |   3 |     9 |
| Mailers              |    585 |    501 |      31 |      42 |   1 |     9 |
| Javascripts          |   3231 |   2628 |       0 |     404 |   0 |     4 |
| Libraries            |  40410 |  31991 |    1002 |    3728 |   3 |     6 |
| Tasks                |   1027 |    857 |       6 |      52 |   8 |    14 |
| Config specs         |     35 |     30 |       0 |       0 |   0 |     0 |
| Decorator specs      |   1323 |   1156 |       0 |       0 |   0 |     0 |
| Feature specs        |  35347 |  30387 |       3 |      33 |  11 |   918 |
| Helper specs         |     95 |     85 |       0 |       0 |   0 |     0 |
| Job specs            |    292 |    256 |       4 |       4 |   1 |    62 |
| Lib specs            |  39849 |  34079 |       6 |     153 |  25 |   220 |
| Mailer specs         |    112 |     94 |       0 |       0 |   0 |     0 |
| Model specs          |  30794 |  23455 |       0 |      18 |   0 |  1301 |
| Presenter specs      |    136 |    113 |       0 |       0 |   0 |     0 |
| Request specs        |   3521 |   3067 |       0 |       0 |   0 |     0 |
+----------------------+--------+--------+---------+---------+-----+-------+
| Total                | 189001 | 149801 |    1630 |    6764 |   4 |    20 |
+----------------------+--------+--------+---------+---------+-----+-------+
  Code LOC: 57079     Test LOC: 92722     Code to Test Ratio: 1:1.6

gemのバージョンを最新にする

周辺gemをアップデートし、最後にRailsを4.2系の最新にするのがゴールです。 これまでgemアップデートはセキュリティFixのみ行ってきたので、2年以上前のバージョンで止まっているgemがたくさんあります。これを全て最新にしていきます。

bundle updateでRails以外の各gemを最新にする

不要なバージョン固定を外し、 bundle update でgemを最新化します。 細かく書くと長くなるので割愛しますが、 unicorn , sidekiq などサービスへの影響が大きそうなgemは個別にアップデートし、development, test groupのgemはまとめてアップデートしていきました。 また、gemの一部の機能しか使っていなかったり、バージョンアップで大きな変更が行われ追随していくのが辛そうなgemを精査して削除も行いました。例えば cells というgemは3系から4系で大きな変更が行われ、gemを使うと楽になるというよりgemを使うために頑張るみたいな本末転倒になりそうだったのでView専用のコンポーネントを自前で実装し、削除をしました。

gemのバージョンを最新にアップデートし続ける仕組みを作る

一度gemを最新化して終わりだと、次回以降のバージョンアップ作業がまた辛い作業になってしまい手付かずになってしまいます。 そこで、毎週bundle updateして Gemfile.lock を更新したPullRequestが作られるようにしました。 こんな感じでupdateされる各gemとchangesのリンクがついたPRを勝手に作るようになっています。

f:id:dkkoma:20181210180200p:plain

月曜にPullRequestを自動作成し、誰かがレビューして翌日くらいにはリリースをするようにしました。 最初は自分で何度かやってみてからフローをチームに共有し、あとはやりたい人がやる形で今は回っています。 毎週やれているとそこまでボリュームがないので、gemのCHANGELOGを眺められたり、こんなgemに依存してたんだって発見があるので良いです。

Rails4.2から5.0にアップデートしていた間も、gemの自動アップデートは別途やっていました。

Railsのバージョンを4.2から5.0にする

Rails自体のアップデートは Rails アップグレードガイド | Rails ガイド が充実していますし、Web上にも知見が転がっておりテストが書いてあれば不安は少ないです。何よりRails本体で大きな変更をするときは、DEPRECATION WARNINGを経て変更を行ってくれている点が多く、まずはアップデートしてからDEPRECATION WARNINGを消していくということがやりやすくなっています。

おおまかには以下の流れで進めました。

  • Rails5.0でいらなくなる大変お世話になったgemを削除 🙏
    • activerecord-mysql-awesome
    • quiet_assets
    • 等々
  • 雑に bundle update -> bin/rails app:update でテストを流し、落ちているテストを直していきます。
  • Rails アップグレードガイド | Rails ガイド を参考に進めましたが差分を小さくするため、いくつかはこのタイミングではやりませんでした。
    • ApplicationRecord の導入は後回しにしました。
    • ActiveSupport.halt_callback_chains_on_return_false = false をいれ、beforeコールバックの修正を避けました。
子PullRequestを作ってspec/以下のディレクトリ毎にPullRequestをわけた

まずはテストを直していくのですが量が多いので、 spec/model だけ通すなどいくつかにPullRequestをわけて進めました。 スコープが明確なのとFile changedが小さく抑えられると読みやすくなり、レビューアに優しいです。

PullRequestで変更点を解説する

バージョンアップ作業をやってる人にとっては小さいことを自分で積み重ねているので自明ですがメモしきれないことが多いしノッているのでそもそもメモったりしないし、 変更量が多くなって見る人には辛いのでレビュー前にPullRequest上で適宜コメントをいれていました。

PullRequestの概要に全体の内容をザクッと説明してリンク等もつけたり f:id:dkkoma:20181210181030p:plain

パッと見なんでこの変更入ったんだろう?って思われそうなとこにコメントいれたり f:id:dkkoma:20181210181216p:plain

その上でチーム全員にバージョンアップで変わる点を認識してもらえるように、全員にざっと目を通してもらったりもしました。

ハマったところ

キャッシュまわりでハマったのが印象的だったのですが、Web上で情報をあまり見かけなかったのでここに残しておきます。

キャッシュにActiveRecord_Relationがキャッシュされているとエラーになる

PeXでは redis-rails というgemを利用して、キャッシュストアにRedisを使っています。

検証環境にRailsアップデート後のアプリケーションをデプロイして確認したところ、

NoMethodError: undefined method `binds' for #<Array:0x00007f7de27c4ec8>

というエラーが起きてました。

該当のコードはcontrollerで Headline というmodelのスコープを利用してキャッシュに読み込む箇所でした。

      @headlines = Pex::Cache.fetch("headline", expires_in: 5.minutes) do
        Headline.limit(5).order("updated_at DESC")
      end

そもそもこれだと ActiveRecord_Relation がキャッシュされていて、キャッシュの恩恵がないのですがそれは置いておいて、 Rails4.2のコードでキャッシュされた ActiveRecord_Relation を5.0でロードするとどうなるかという話です。 Rails5.0から ActiveRecord_Relation の実装が変わっていて、 https://github.com/rails/rails/blob/v5.0.7/activerecord/lib/active_record/relation/query_methods.rb#L119where_clause にあたるものが、4.2時代は Array だったらしくそのキャッシュをロードすると Array として復元されます。 Array に対して bind というメソッドをcallしようとしますが、 Array#bind はないのでエラーになります。

対応としては ActiveRecord_Relation をキャッシュするのをやめ、viewでfragmentキャッシュするように修正した結果、Rails4.2でキャッシュを生成させてからRails5.0にアップデートしてキャッシュを読み込んでも動作するようになりました。

また、切り戻しによってRailsをバージョンダウンしたときにも同じ問題が起きそうなので確認してみます。 Rails5.0のアプリケーションで生成したキャッシュをRails4.2のアプリケーションで読み込むテストをしてみたところ、以下のように marshal_load メソッドでエラーが出ました。

TypeError: instance of ActiveRecord::LazyAttributeHash needs to have method `marshal_load'

今度は ActiveRecord_Relation ではなく ActiveRecord が依存したクラスのロードを行うところでエラーが起きているようです。 結局 ActiveRecord のオブジェクトをキャッシュに入れる限りは、切り戻しは出来ないということがわかりました。何かあった時に切り戻しが出来ないのは困ります。

そこで、以下のようにバージョンアップ後のキャッシュキーに rails5-0 というprefixをつけ、Railsバージョンを変えた時にキャッシュ全体が切り替わるようにしました。

- config.cache_store = :redis_store, ENV['CACHE_STORE']
+ config.cache_store = :redis_store, ENV['CACHE_STORE'] + '/rails5-0'

この方法を取るとリリース時にキャッシュが全て吹き飛ぶのと同じことになるので、アクセスが少なめの時間(PeXでは昼過ぎ頃)にリリースすることにしました。 キャッシュがなくてもサービスが落ちない程度に適切にインデックスは張ってあるため、この方法で問題なさそうだと判断しました。

sessionにActiveRecordのオブジェクトが入ってて、バージョンの前後でsessionのロードができなくなった

上記の問題が解決し、ようやくリリースした後しばらく production.log を眺めていると、頻度は少ないのですが以下のようなエラーが起きていました。

ActionView::Template::Error (uninitialized constant ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter::Column)

backtraceがログに出ておらず再現条件がわからなかったのですが、前述のキャッシュでハマっていたことからキャッシュが怪しそうと見て redis monitor コマンドなどを使ってエラーが起きたタイミングのredisのクエリを調べていたところ、とあるアクションを行ったユーザのセッションに ActiveRecord のオブジェクトが格納されていて、セッションのロード時にエラーになっていることがわかりました。

このケースに該当する方はサービスが全く利用できなくなってしまっているため、切り戻しを行いRails4.2に戻しました。 が、今度はリリースから切り戻しまでの2時間ほどの間に、とあるアクション(先程と同じもの)を行ったユーザがRails5.0の ActiveRecord のオブジェクトがセッションに格納され、Rails4.2のコードではロードできなくなってしまっていました。 バージョンを進めても戻してもエラーが出るユーザがでてしまい、詰んでいます...。

悩んだ結果、ロードできない(壊れた)セッションは破棄して再ログインしてもらうしかないため、以下のようなコードを ApplicationController に定義して、セッション削除(強制ログアウト)&トップページへリダイレクトすることにしました。

  before_action :migrate_session

  def migrate_session
    session[:user_id]
  rescue StandardError => e
    # 壊れたsessionのloadが走るとエラーになるのでredisからセッションを消して強制的にログアウト状態にする
    sid = request.cookies[ENV['SESSION_KEY']]
    redis = Redis.new(url: ENV['SESSION_STORE'])
    redis.del "cache:#{sid}"
    redirect_to :root
  end

session.delete でなく redis.del にしている理由は、 session にアクセスするとセッションからのロードが走ってしまいエラーを避けられないためです。 その後、セッションに ActiveRecord を格納しないようにする根本対応は別途行いました。

まとめ

gemのバージョンアップを日頃からやっておく
  • フレームワークバージョンアップ時にまとめて頑張るのではなく、週次など日頃からgemのバージョンアップをしておく。
  • これをやっておけばRails本体のアップデートはそこまで大変ではない。(Rails3時代は結構大変だった記憶ですが楽になりましたね)
キャッシュに注意
  • ActiveRecord などライブラリのオブジェクトを突っ込んでいるとバージョンアップ後にエラーが起きることがある。
    • バージョンアップでキャッシュキーは変える。
    • キャッシュが全部吹き飛んでもサービス継続出来る程度にインデックスが適切に作成されていると安心、スロークエリがでていないか日頃から確認しておく。
  • セッションに ActiveRecord などライブラリのオブジェクトを突っ込んでいるとバージョンアップ後にエラーが起きる。強制ログアウトは最後の手段なのでセッションにはプリミティブなオブジェクトをいれるようにする。

PHPカンファレンス2018で技術力評価会を再演します!企業ブースでは評価資料の公開も!

こんにちは! Zucks アドネットワーク エンジニアのしゅーぞー(@ShuzoN__)です.

12/15(土)は何の日かご存知でしょうか?
そうです! PHPカンファレンス2018 ですね!

PHPカンファレンスは国内最大級のPHPイベントです.
PHPer であれば1度は行ってみたいイベントですよね.

VOYAGE GROUPは4年連続プラチナスポンサーとして協賛しています.

昨年はレガシーシステムからの移行がテーマ

昨年はブースにて実例や実コード, 実際に経験した話を交えた事例紹介を行いました.
多くの方にご覧いただき賑わいのある出展となりました.

techlog.voyagegroup.com techlog.voyagegroup.com

今年は「事業, 世代, 専門性, 会社を超えた成長のサイクル」がテーマ!

弊社の特徴的な評価制度「技術力評価会」を軸としたセッション発表, ブース展示を行います.

セッション発表

今年も, VOYAGE GROUPエンジニアが 1セッション登壇 いたします.

ECナビエンジニア 林が 技術力評価会を25分で再演 いたします.

企業ブース

技術力評価会で用いられた実際の評価資料や結果レポートの公開を行います.

また, ajitofmの収録風景動画や弊社エンジニアが寄稿したWEB+DB PRESSの展示などもございます.

セッション発表では, 技術力評価会を再演します

セッション発表では, VOYAGE GROUPのエンジニア3名が登壇し, 技術力評価会を25分で再演します!

実際に評価会で用いられた題材を元に, ステージ上で評価会を行います!

題材は「14年続くポイントサイト"ECナビ"のポイント失効自動化について」です.

  • 発表者: 林 志嶺(@yuk1mine) ECナビ エンジニア
  • 評価者: 小賀 昌法 (@makoga) VOYAGE GROUP CTO
  • 評価者: 前田 雅央 (@brtriver) Zucks アドネットワーク リードエンジニア

技術力評価会は, 半年間で行った自分の仕事のうち最も技術的に推せる物を発表し, 他事業部のエンジニアに評価してもらう制度です.

改善業務のような「大事だけど評価されにくそうな仕事」に対しては評価が難しくなると思います.

そのような仕事に対して, VOYAGE GROUPはどのような評価を行うのか, 評価の仕組みを持っているのかを見ていただけます.

当日資料をちょっとだけチラ見せします!

f:id:namu_r21:20181212133909p:plain:w300 f:id:namu_r21:20181213121653p:plain:w300 f:id:namu_r21:20181212170656p:plain:w300 f:id:namu_r21:20181212170806p:plain:w300 f:id:namu_r21:20181212133339p:plain:w300

技術力評価会に関しては, 他社からも仕組みを知りたいという要望の声が多くなっています.
前回評価会はf-codeさんが見学に来てくれました.

www.wantedly.com

企業ブースでは実際の評価会発表資料や結果レポート, ajitofmの収録風景を公開!

以下のテーマを予定しています.

  1. 技術力評価会で用いられる評価軸, 実際の発表資料や結果レポートの公開
  2. 弊社エンジニアが寄稿したWEB+DB PRESSの展示
  3. ajitofm収録風景の動画公開
  4. VOYAGE GROUPの特色でもある事業ポートフォリオ紹介

企業ブースでは技術力評価会で用いられた資料や実際の評価結果を手にとって見ていただくことができます.

セッション発表後は, 登壇者もブースにて待機しております.

発表に関する質問, 相談の場としてもご利用ください.

またWEB+DB PRESSの展示やajitofmの収録風景を見ていただくことができます.

興味がある方はぜひいらしてくださいね.

今回は初のノベルティも登場

今回はVOYAGE GROUPノベルティを作成しました.

会場に来ていただければ手に入ります! コースターはブースにて配布, ホールドリングは懇親会の景品として出品いたします.

f:id:namu_r21:20181212142409p:plain:w300 f:id:namu_r21:20181212142447p:plain:w300

2019/1/30(水)にみなさんの前で公開ガチ評価会を行います

参加者の皆さんの前で, VOYAGE GROUP エンジニアを本当にその場で評価します.

本来, 技術力評価会は90分時間をかけて実施されますが, 本イベントでは, 短縮してお送りいたします.

後日, VOYAGE GROUPのTwitterアカウント(@tech_voyage)にて, 実際の評価結果を公表します.

評価制度に興味がある方は是非ご参加ください. 参加はconnpassから申し込み可能です.

f:id:namu_r21:20181212140326p:plain

voyagegroup.connpass.com

当日会場でお会いしましょう!

VOYAGE GROUPからは CTO 小賀, 登壇者 林, 前田, 若手3名(僕を含む)の計6名で参加します.

当日はVOYAGE GROUP企業ブースにてお待ちしております!

PHPカンファレンスへの参加はまだ間に合います! connpassから応募してください!

phpcon.connpass.com