ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと筆者が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 まえがき ある夜に同僚の@ujihisaと近場ないし遠方のEngineering ManagerやVPofEの皆さんと話す機会があり、その折にふと筆者がこぼしたのが 「開発などの日常の業務において自分がやっている以下の思考様式が大変便利なので、この考え方を最近入社したメンバーにもインス

こんにちは。SRE Team の @chaspy です。次の10月で Engineering Manager をつとめて1年になります。 本記事ではもしかするとメンバーからわかりづらい Engineering Manager のしごとについて、昨年10月からの約1年間を振り返りながら説明しようと思います。 ところで「エンジニアリングマネージャのしごと」もうすぐ発売ですね。筆者もとても楽しみにしています。検索のノイズになるのは本意ではないので記事のタイトルはカタカナではなく英語表記にしました。 www.oreilly.co.jp なお、リクルートでは人事制度上 "Engineering Manager" というロールはなく、GM (Group Manager) が正式なロールです。EM と GM は重複する部分、そうでない部分ありますが本記事では割愛します。 基本情報 会社組織編 SRE T

こんにちは。 SRE の @suzuki-shunsuke です。 Terraform の CI/CD を CircleCI から AWS CodeBuild に移行した話を紹介します。 背景 弊社では AWS のリソースを Terraform で管理しており、元々 CircleCI で CI/CD を実行していました。 リポジトリは monorepo になっており、様々なサービスのリソースが同じリポジトリで管理されています。 Terraform の State はサービス・環境ごとに分割されており、現在 70 個以上の State があります。 ちなみに Terraform の Workspace は使っておらず、 State ごとにディレクトリが分けられています。 State ごとに CircleCI の job を分けて terraform plan などを実行していました。 課題

Web Dev の @mtsmfm です。 ブログ再開 から2年半、年間40～50本程度のブログ記事がこの Product Team Blog からでています。 継続的な更新を重視し、これまで概ね週1本程度が公開されるようにしてきました。 ローテーションを組んでいるものと、個々人が高まったときにゲリラ的に執筆するものの2パターンあります。 このローテーションについて、ブログ番長という責任者を立てスケジュール管理などを行ってきました。そのタスクは概ねローテーションの管理と執筆依頼の 2 つです。とはいえ締め切りの催促は、手間としては大きくないもののお互いにストレスが溜まります。 これの自動化を試みて2ヶ月ほど経過し、少しづつ形が見えてきたので共有したいと思います。 ブログ番長 Bot の仕事 ブログ番長 Bot の業務は、以下の通りです。 次週の執筆者を決定して通知する (木曜朝10時) 執

こんにちは。 SRE の @suzuki-shunsuke です。 6000 行を超える巨大な .circleci/config.yml を分割してメンテナンス性を改善した話を紹介します。 背景 我々 SRE は日々 Developer Productivity の改善に取り組んでいます。 その取り組みの一環で Developer の方から直接フィードバックをもらう機会がありました。 その中で Monorepo の .circleci/config.yml が大きすぎて修正するのが大変という意見をもらいました。 弊社では様々なサービスを一つのリポジトリで管理する Monorepo というアーキテクチャを採用しており、 CircleCI で全てのサービスのテストやビルド・デプロイなどを行っています。 それ故に .circleci/config.yml は 6000 行を超えるものになっており

こんにちは。quipper.fm メインパーソナリティの @chaspy です。 今回、一緒に働く仲間をただひたすらに"褒める"社内企画をはじめてみました。好評により続いているので、その取り組みについて紹介します。 quipper.fm とは何か なぜはじめようと思ったのか 褒めることの重要性 1. "褒め"によるフィードバックが個人の振る舞いを強化する 2. "褒め"による振る舞いが言語化されることはそれ自体が貴重な学びの機会になる 褒める技術 褒められたひとからの言葉 おわりに quipper.fm とは何か 名前に深い意味はないんですが、ラジオっぽい"雰囲気"でゆるく聞いてもらえたら、という想いで .fm をつけています。実際は社内 Google Hangouts で行っているので、音声だけでなく映像も映ります。 この番組は隔週30分で行われています。各回に1名「褒められるひと」が選

こんにちは。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 に携わる方にとって学びに

VP of Design をしております @daitorii です。本記事は2019年9月14日に開催された UX MILK Fest 2019 の登壇内容を噛み砕いたセルフ解説ブログとなります（話が長くなりそうなので、グローバルの話は割愛させていただきました）。 はじめに 勉強は面倒くさいものです。私はそう思います。興味のある領域において、知らないことを知る/知識をつけること自体は大好きなんですが、勉強と聞くと途端に面倒くさい。その過程が面倒に感じてしまう。 大切なのは、学習サービスが「面倒なこと」をやり続けてもらわなければいけないものと認識すること、だと私は思います。勉強自体がやりたいことではなくそれは手段であり、ユーザーが欲しいものを手に入れるための過程なのです。 人間は「現在」を過大評価する 「今すぐもらえる10万円」と「1年後にもらえる11万円」どちらを選びますか？ 目の前に10

こんにちは、今年の4月から Quipper の iOS エンジニアになった @manicmaniac です。 ちょっと話題としてはニッチかもしれないのですが、今日は Apollo iOS client を利用したアプリで GraphQL のデバッグに苦労し、そしてコードを書いてそれを克服した話をします。 そもそも GraphQL とか Apollo ってなに？ GraphQL とは Web API のクエリ言語であり、またそのランタイム自体を指す言葉です1。 対して、Apollo は GraphQL のサーバー・クライアント用のライブラリで、Meteor の開発元でもある Meteor Development Group 社が開発しています。 Apollo の iOS 向けクライアントである Apollo iOS は単なる API クライアントを超えて、以下のような機能を備えています。 G

こんにちは、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さんから受け継ぎ、運用を続けています。 ブログでの継続的なアウトプットの

はじめまして、Quipper 東京オフィスでデザイナーをしております @daitorii です。 幼い頃は公園でよく落とし穴を掘っては友達が落ちて行く様を笑い転げて見ていました。なんでこんなのに引っかかるんだよ、俺は絶対に引っかからねえ。とは思っていたものの、もちろん自分も落とし穴にハマり（しかも結構壮大だったし若干トラウマ）、子供ながらになんとなく感じた古い記憶があります。 「自分が当たり前だと思っている前提や認識は、誰かにとっての当たり前ではない」 という事です。 今日はリアルな落とし穴の話ではなくデータの分析やデザイン思考の落とし穴の話。 ですが、実は根本的な問題は同じような気もしています。 デザイン思考と科学的方法 最近よく「デザイン思考」という言葉を耳にする方も多いと思いますが、結局のところそれは何だということで Wikipedia 先生に聞いてみました。 デザイン思考（でざいん

エンジニアリングマネージャの@rivayamaです。 2018年5月に第一子が誕生してから約2ヶ月間の育児休業を取得したので、その話をしたいと思います。 育児休業を取るまで 一定の基準を満たした労働者には育児休業法により育児休業を取得する権利があります。もちろんQuipperにも育児休業の制度があり、2017年以降に子供が生まれた男性エンジニアの100％が取得しています（予定含む）。このような状況から私も妻の妊娠がわかった際には「育休を取得しよう」と自然に考えることができました。 エンジニアリングマネージャになりたてだったこともあり育休について伝えることには若干の不安がありましたが、みんなが快く了承してくれたのでとても安心しました。チーム全員が不在時の体制作りや引き継ぎなどに協力してくれて、改めてQuipperという組織の健全さを感じました。 チームメンバーがプレゼントしてくれた riva

@kyanny です。先日 Vice President of Engineering になりまして、スタディサプリを開発する Quipper 日本オフィスのプロダクト開発部門の責任者をやっております。 僕はかれこれ 15 年くらいブログを書いています。ウェブエンジニアはみんな自宅サーバーに blosxom や Movable Type をインストールしてブログを公開したり、はてなダイアリーが流行ってたり、 WordPress が出てきたとき「再構築しなくていいからすごく速い！」とみんな驚いたり、そんな頃からブログを書いています。 それほど長いあいだ続けていられるのは、ひとえにブログが僕にとてもよく合っているからです。自分の思考を整理したり、思いのたけをぶちまけたりしながら、人生を綴り人生を切り拓く手段としてブログよりよいものを僕は知りません。フィードを購読するかわりに Twitter で

この記事は React Native Advent Calendar 2017 6 日目の記事です。5 日目は Quipper 同僚の @hotchemi によるQuipperにおけるReact Native活用事例でした。 こんにちは、Quipper で Software Engineer をやっている @yuya-takeyama です。 入社以来ほとんど Web のサーバサイド・クライアントサイドをやってきましたが、最近は React Native アプリのプロジェクトで TypeScript を書いています。 昨日の記事でも軽く触れてますが、Quipper で最近運用が始まった OTA (Over The Air) によるアプリ配信の運用とその自動化について詳しく紹介します。 なお、実際に動くコード例として以下のリポジトリを用意しました。 quipper/ReactNativeCo

この記事はReact Native Advent Calendar 2017の5日目の記事です。 こんにちは。モバイルエンジニアの@hotchemiです。 今回はQuipperにおけるReact Native活用事例に関して紹介したいと思います。 目次 導入の背景/効能 開発におけるメリット/デメリット リリースサイクル 技術スタック おわりに 導入の背景/効能 Quipperが開発しているスタディサプリでは合格特訓プランという現役大学生コーチによる学習伴走サービスを提供しており、コーチとユーザーのコミュニケーションをより円滑にする為にメッセージ機能をベースとした業務補助iOSアプリの開発を実施する事になりました。 最初のバージョンこそSwiftで開発を進めていたものの以下の組織的・技術的な課題に直面した為、React Nativeを用いた開発に方針転換し現在では運用が軌道に乗っています。

自己紹介とインドネシア進捗 こんにちは、Quipper創業メンバーで、現在Quipper Indonesiaのカントリーマネージャーをやっている本間拓也です。簡単に、（プロダクトブログですので）インドネシア展開の現状についてプロダクトチームとの関わりも含めて、ご紹介させていただければと思います。 Quipperはもともとイギリスで創業された会社なのですが、2014年からアジア展開をしてきました。そのあたりの温度感に関しては以前Wantedlyブログなどに書いたので、ご参照ください。 ・「ユーザーと共創する」 ・「異文化の組織を成長させるために大事にしている３つのこと」 ・「新興国で急成長する「Quipper」の躍進」 フィリピン、インドネシア、ベトナム、タイ、メキシコ、といった国々でQuipperを展開していますが、その中でも2016年はインドネシアで大きく組織を拡大しました。40人程度の

こんにちは、デザインチームの宇賀神です。 Quipperに入社して３年半、QuipperSchoolの立ち上げからスタディサプリのリリースまで、慎ましく従事してきました。ロンドンオフィス所属のため、普段はリモートにて各国のデザイナーや開発チームとやりとりしています。 このたびWantedlyにてモバイルUIデザイナーの募集をはじめましたので(２０１６年１２月時点)、「採用目的」と宣言されていますこちらのブログにて、より詳しく弊社のデザインチーム（特にモバイルUIデザイナー）の環境についてざっくりと紹介したいと思います。 チームの今 Quipperのデザインチームには世界６カ国に９人が在籍しており、大きくプロダクトチームとグラフィックチームに分かれています。プロダクトチームは主にアプリケーションのUI/UXデザイン、グラフィックチームは各国のマーケティングマテリアルの作成が主な担当業務です。

前回の記事に引き続き、Web developer の大庭 (@ohbarye) です。 先日『グローバルサービスでのタイムゾーンとの向き合い方』にてタイムゾーンにまつわる諸問題や解決策を1つの記事にまとめました。 しかし同記事はテクニック集としての側面が多く、Quipper の開発者として実際にどのような問題に直面するのかいまいち伝わりづらかったかもしれません。 そこで今回は Quipper の機能に関連するタイムゾーンを考慮した設計と実装の一部をケーススタディ編と題し、改めてご紹介します。前回の記事と一部重複する内容はありますが具体例を交えた復習として参考になれば幸いです。 目次 1 宿題管理機能 モデルイメージ 設計に関する問いかけ 解答・解説 2 TODO 管理機能 画面仕様 信頼すべきタイムゾーン 3 キャンペーン機能 画面仕様 タイムゾーンをユーザーに入力してもらう リテラシーへ

Web developer の大庭 (@ohbarye) です。 今回はタイムゾーンにまつわるお話をしたいと思います。 タイムゾーンは私が Quipper に入社したばかりの頃に最も頭を悩ませたことの一つです。入社以前にはタイムゾーンを跨ぐようなグローバルなアプリケーションの開発を全くしてこなかったので、まさにゼロから学び、考え、そしてハマりました。今でも気を抜くとハマりそうです。 入社からおよそ1年。この間に得た経験と知識を活かし、タイムゾーンと向き合うテクニックをまとめてみたいと思います。 目次 はじめに 前提 - Quipper のご紹介 難しさ 現在時刻を扱う問題 言語、フレームワークの実装 認知の問題 タイムゾーンを考慮した設計の問題 解法 基本的な考え方 デフォルトタイムゾーンを設定する PostgreSQL Rails タイムゾーンを意識した設計 タイムゾーンを意識したプログ