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

01/02/03 という日付を見たときに、どう読み取りますか? 著者 ujihisa はこれを素直に 2003年1月2日と読み取りますが、人によっては 2001 年 2 月 3 日 2003 年 2 月 1 日 平成元年 2 月 3 日 令和元年 2 月 3 日 などと読み取ることもあるでしょう。日本では年/月/日が普及していますが、英語などから順序を無視した機械的な翻訳の日付でまれによくある「1月2日 2003年」みたいな表記を見すぎてしまった人は月/日/年みたいに読んでしまうかもしれません。 ところで私はカナダに住んでいるのですが、カナダという国はこのようにスラッシュ区切りの日付を以下の 3 パターンのいずれかで読みとります。 月/日/年 年/月/日 日/月/年 https://commons.wikimedia.org/wiki/File:Date_format_by_country

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

はじめまして。 データーリサーチエンジニアの @bwtakacy です。 私は、データ分析やAI技術を活用して学習をサポートする仕組みや機能の研究開発を行うチームに所属しています。 今回は、研究開発の取り組みの一つをご紹介したいと思います。 英単語学習に新しい「目線」を 早速ですが、以下の二つの画像を見てください。 英単語の意味を答える問題をPC上で解いてもらった時の目線の動きをヒートマップと経路として表示したものです。 一つは、あまり目移りせずに正解を選んだパターン。 もう一つは色々迷ったパターンです。 どうでしょうか。自分の感覚と照らし合わせてみて当たっていますでしょうか。 あくまで象徴的な例ですので、個人によったり、体調によったり、と毎回このようなはっきりとした違いが出るとは限りません。ですが、大まかな傾向として、目線の動きを見ることで「どれくらい解答に迷ったか」を推定することができ

はじめに MAツールを導入前のメール配信方法と課題 まずスキーマ設計してから Marketo を導入 期中、やらないことを決める 目指せ、スマイルカーブ 昼会という名のデイリースクラム 他社事例の調査と運用の型化 スマイルカーブの行方 さいごに、スマイルカーブの向こうへ はじめに みなさんこんにちは、データエンジニアリングチームの戸井田( @toitech )です。 今回は、昨年の春からスタディサプリのユーザーへのメール配信で利用しているマーケティングオートメーションツール（以下 MAツール）「Marketo」の導入について書きたいと思います。 このプロジェクトで私は、スタディサプリのデータ分析基盤と Marketo のシステム連携を実装するエンジニアとしてアサインされました。 しかし、なぜか自分でも知らぬ間に役割がプロジェクトマネージャー的な立ち位置に変わっていきました。 そんな私が、ど

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

QuipperデザイナーのMatsumotoです。 今回はQuipperのデザイナーが、普段どんなチーム構成で働きどんなワークフローで動いているのか、簡単に紹介していきます。 また、様々な職能を持つメンバーが集うチームで求められるデザイナーの役割、日々の気づき、今後の抱負など軽くまとめてみました。 デザイナーの「何かの気づき」になれば嬉しいし、エンジニアやPMの方が、デザイナーと一緒に「デザインについて考える」きっかけとなれば幸いです。 はじめに 事業会社で働く面白さ どんなチームで働いている？ プロダクト単位のチーム チーム内訳 職業単位のデザインチーム プロダクト単位のチームによるワークフロー 良い点 改善したい点 UI/UXはデザイナーだけで作るもの？ どんなフィードバックがいいの？ 終わりに はじめに 前提として自分の経歴を簡単に書いておきます。 2017年11月にQuipperに

デザイナーの@riku-kunishiです。 今年に入って、AirbnbがLottieを公開したり、InVision Studioのバージョン1.0が公開されたりと「動き」までデザインすることが当たり前になりつつあります。特に私が携わっているプロダクトのターゲットは学生なので、なるべく操作に対して自然な反応をしてあげるようなプロダクトを作りたいと思っています。 ただし、動きを含む要素をNative Appに実装する場合、CodePenのような便利なものもなく、エンジニア / デザイナー間のコミュニケーションの難易度高いなと思っていたりします。私が携わっているプロダクトでは実現に必要な情報等をまとめる方法を考えたり、フローとして整理できないかと検討しているので、今回はその取り組みの経過を記載します。 マイクロインタラクションとは 「マイクロインタラクション ――UI/UXデザインの神が宿る細

つい先日, 2018-11-24 (土) に開催された VimConf 2018にて、弊Quipper社の ujihisa さんが登壇しVimの技術発表を行いました。本記事ではその発表の解説と、その裏話をめいっぱい記します。 発表タイトルは "Modes" という一単語のみで、公式サイトに載っているtalk abstractによると以下のようなものです。 Abstract Discover what is happening internally when you switch modes, such as insert mode, normal mode, and operator-pending mode. This talk first revisits how modes are when you use Vim, then I'll let you dive into the V

モバイルエンジニアの@hotchemiです。 今回は少し前にReact Nativeアプリの開発中にメモリリークを調査、解決した体験が学びが多かったので調査の顛末を共有できればと思います。 概要 今回問題となったのは、上記の課題・宿題を管理する画面の開発でした。 QA中に発覚した問題としては、「アプリを操作していると特定の端末(主にiPhone5)でアプリが落ちたり、その他の端末でも次第に筐体が熱くなる事がある」というもので、表示するデータはそれなりにあるものの画像や動画を表示する画面ではないのでさすがにおかしいだろうという事と、プロセス起動から時間が経つに従い事象が発生・深刻化していくという特性を考慮しメモリのリークが発生しているという仮説を元に調査を開始しました。 モニタリング 「推測するな、計測せよ」の格言通り、まずはメモリの使用量を計測する所から始めてみます。 Native Rea

Web Engineer の @kachick です。 今回はスタディサプリのクレジットカード決済を堅牢化するために行っている工夫の一部を抜粋して紹介したいと思います。 前提 本記事で紹介する内容は、過去に我々が提供していたサービス（以下、サービスAとします）において直面した決済バグから学び、スタディサプリに導入したものです。 決済バグとは 決済というものはその性質上、セキュリティに次いでバグへの高い温度感を求められがちです。 サービスプロバイダの目線からは決済のバグを2つに大別出来ます。 本来よりも多く請求しまい、ユーザーからの信頼を損ねる。 決済の金額を増やしてしまった。 決済の時期を早めてしまった。 決済は通ったがサービスを提供できていなかった。 本来よりも少なく請求してしまい、事業運営に支障を来す。 決済の金額を少なくしてしまった。 決済の時期を遅くしてしまった。 実際には決済が通

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