こんにちは。SRE の @chaspy です。 Quipper では AWS 上で Kubernetes Cluster を運用してサービスを提供しています。 これまで kube-aws を用いて Kubernetes Cluster を Self Host してきましたが、このたび Managed Services である Amazon EKS に移行しました。（以下、 Amazon EKS を EKS と表記します） 本記事では、 Kubernetes Cluster の移行で遭遇した問題をどのように解決したかを説明します。また、数多くの Application が稼働している Platform を移行する際にどのような点を考慮するとよいのか、経験を通して学んだことを共有します。 EKS への移行を検討している方はもちろん、Platform Migration に携わる方にとって学びに

こんにちは、本記事では弊社のカジュアル面談についてライトに書いてみました。文字数は5800字程度ですので読了には5~10分ほどを要すると思われます。 対象読者 Quipperのカジュアル面談に来てみようと思っている方 他社のカジュアル面談がどのような感じか知りたい方 言うまでもないかもしれませんが弊社のやり方が唯一の正解ではありませんし、完成形でもありません。とはいえ現時点で獲得しえたカジュアル面談のノウハウを世に出すことで業界全体の採用活動のレベルの底上げに寄与していきたい気持ちがあります！ カジュアル【casual】［形動］格式ばらず、くつろいでいるさま。 カジュアル面談とは? 初めに言葉の定義を合わせていきます。 弊社 Quipper は面接・面談をより良いものにするために東京オフィス採用面接ガイドというものを公開しています。（同ガイドに関しての詳細はより良い面接を実現するために "

こんにちは、Web Engineer の @wozaki です。 今回は、スキルマップを私が所属する開発チーム*1に導入した事例をご紹介します。 スキルマップとは、業務で必要なスキル(技術力、業務知識)と、チームメンバーのスキルレベルを一覧にした表です。 スキルマップの例 引用 スキルマップ作成のすすめ | Ryuzee.com 目次 概要 スキルマップ導入の背景 他社の事例とカスタマイズした点 スキルマップ詳細と運用方針 運用結果 まとめ 概要 チームで必要なスキル、メンバーのスキルレベル、志向性が不明だった 個人の志向性を表現できるようにカスタマイズしたスキルマップを導入した 結果 新メンバーにとって、スキル全体が明確になり、チームの役割の理解にも役立った スキル喪失リスクがあるものが明確になり、勉強会などスキル伝承のアクションにつながった 個人の志向性は、スキル伝承時の期待値調整にも

Quipper Product Blog守り手の@chiiia12です。 ちょうど今日5/28でQuipper Product Blogを再開して1年が経ちました。この機会に再開してからの1年間を振り返り、ブログをどう運用してきたかについてご紹介したいと思います。 Quipper Product Blogの再開 Quipperではメンバーが書くブログ自体は以前から存在しましたが、更新が滞っておりほぼ運用されていない状態でした。長期的な採用ブランディングのためにも1年前の今日、Quipper Product Blogを再開することになりました。 quipper.hatenablog.com 再開してからは、週に1記事を目標に1年間走り続けて来ました。ブログの継続的な記事公開を促す役割である "守り手" もhotchemiさんから受け継ぎ、運用を続けています。 ブログでの継続的なアウトプットの

Rails Developers Meetup 2019 の自社スポンサーセッションはいっそ休憩室にすればいいのでは? と言い出した Web dev の @mtsmfm です。お弁当や神授業、そして Quipper からは 3 名が登壇しましたが、発表は楽しんでいただけましたでしょうか。 僕は自分の発表 を @jeremy さんが聞いてくださったり、キーノートでは Rails 6 で入ったパッチを紹介してもらったりして感無量です。 この場を借りて Rails DM の開催に尽力された @yhirano55 さん他みなさまには感謝を述べたいと思います。本当にありがとうございました。 今日は、Quipper における Git ブランチ と Kubernetes を組み合わせた、開発から本番デプロイまでの流れを紹介したいと思います。 流れ ざっくりとした概要としては Git flow をアレンジ

オンボーディングのはじめかた こんにちは。SREの近藤（@chaspy）です。 今回、SREチームではじめてオンボーディングプロセスを実施しました。本日はその内容について紹介します。 オンボーディングとは Onboardingとは、新しく入社した従業員が組織の中で効果的に成果を発揮するために、必要なナレッジ、スキル、行動を習得するメカニズムのことを言います。 これは単なる社内サービスへのアカウント登録作業ではありません。また、関連する技術的な研修を受けさせるだけでもなければ、OJTという名のもとに振ったタスクをやりながら覚えてもらうだけでも不足しているでしょう。なぜなら習得すべきことは技術的なスキルだけではないからです。確かに、実際の仕事を通じて学ぶことはできるはずですが、より短期間で、より効果的に必要なことを身に着けてもらうためには何らかの学習のための仕組み（Mechanism）が必要で

モバイルエンジニアの@chiiia12です。 私がQuipperのモバイルチームにjoinした際に驚いたことの一つが、自動化スクリプト/便利ツール等が多く使われていることでした。 今回はモバイルチームで最近導入されたものをいくつか紹介したいと思います。 DeployGateのビルドバージョン通知 私達のチームではDeployGateを使ってQAチームやデザインチームに開発中のアプリを配布しています。 QAテスト期間中は、不具合を改修した後に改修が含まれたバージョンのアプリをQAチームに確認をお願いしています。その際にDeployGateのバージョンを伝えてテストをしてもらっていますが、開発者にとってはDeployGateのビルドバージョンを確認するのはひと手間かかる作業になっていました。 これをissueがリンクされたpull requestのマージをトリガーに、どのDeployGateの

こんにちは、Web エンジニアの @kechol です。 今回は スタディサプリの学校向けサービス を開発しているプロダクトチーム（社内通称: スクールチーム）で、千葉県の金谷にて１泊２日の合宿をしてきたレポートをお伝えしたいと思います。 合宿の目的 今回の合宿は、PM・Web エンジニア・デザイナーが参加しており、お互いのことをもっと理解することで、今後のチームの生産性を高めたいという思いがありました。実際に合宿のコンテンツを考えるにあたっては、以下のように目的を言語化しました。 チームとしての相互理解を通して 1. 成果の質を高めるためのアクションを決める 2. プロダクトの品質向上にチーム全体で取り組む 合宿の最初に改めて目的を説明する Product Owner こうした目的を達成するために、今回の合宿では、１日目に PM とエンジニアのペアプログラミング、２日目にはこの一年間の振

こんにちは、データグループのマネージャーをやっています beniyama と申します。 先の記事『プロダクトの「負債」を「機能」と呼び直す 〜A/Bテストを用いた"価値"の定量化〜』でも触れられていますが、データグループではデータ分析基盤の構築（参考資料）からデータ分析、あるいは学習データを活用した研究開発までスタディサプリのデータに関わることほとんど全てを担当しています。 プロダクトや事業 KPI の社内向けモニタリング環境の構築・整備も行なっているのですが、今回、既存の環境を刷新して Looker というまだ日本ではほとんど無名？のツールを導入することにしましたのでその経緯をお話ししつつ、今後国内でもユーザーが増えていくといいなという願いを込めて１エンジニアとして興奮したポイントを書き連ねていこうと思います。 最初の１年間は DOMO を導入して運用 スタディサプリではもともと各種 K

Quipper で Web Engineer 兼 Engineering Manager を務める @ohbarye です。スタディサプリの開発、その中でも特に合格特訓コースや決済周りの機能開発・保守が主な業務です。 弊社が開発するプロダクト「スタディサプリ」ではA/Bテストを用いたプロダクトの改善を行っています。Quipper の行動指針の一つに "Fact based" という言葉が含まれており、憶測や独断ではなく計測されたデータや事実に基づいて意思決定することが強く推奨されているためです。 このたびスタディサプリにおいて負債と考えられていた機能を「消してよいかどうか」、A/Bテストを通して判断しました。その際に用いた手法や結果、そこから見えたこと、考えたことをご紹介します。 プロダクトの負債とは プロダクトチームにとって負債と考えられていたのは「キャリア決済」という決済手段でした。そ