こんにちは。Engineering Manager の @wozaki です。 2年前のプロジェクトで、プレモーテム(premortem)を実施した例をご紹介します。 プレモーテムとは、プロジェクト初期にチームで集まり「プロジェクトが失敗したとして、その失敗とは? 原因は? どう対策するか?」を話し合うワークショップです。*1 プレモーテム実施例 なお、本記事におけるリスクの定義はこちらです。 引用元 熊とワルツを - リスクを愉しむプロジェクト管理 将来起こりうる出来事で、望まない結果を生むもの 望まない結果そのもの 目次 概要 背景 なぜプレモーテムが打ち手だったのか プレモーテムの再設計 実施結果 参加者の所感 最終的にプロジェクトはどうなった? 終わりに 概要 プロジェクトは2つの特性があった 初めて協業するステークホルダーが多い 開発規模が大きい 特性に対する懸念の打ち手としてプ
はじめに こんにちは、Webエンジニアの濱田裕太 (@yuuta) です。 Quipperが開発・運用している スタディサプリ のプロダクトでは、バックエンドの一部をGoで実装しています。そのサムネイル画像作成で利用する画像処理ライブラリを imaging から bimg (libvips のGoバインディング) に変更したことで、高速化・省メモリ化を実現しました。本エントリでは、それによって得られた知見を共有します。 1. どのくらい高速化・省メモリ化したか 1-1. 検証コード 1-2. 処理時間 1-3. メモリ使用量 2. なぜ高速化・省メモリ化されるのか 2-1. libvipsの画像処理アーキテクチャ 2-2. SIMD対応 2-3. JPEGスケーリングデコード 3. 運用時の留意点 3-1. libvipsのパッケージサイズ 3-2. libvipsのオペレーションキャッシ
こんにちは。quipper.fm メインパーソナリティの @chaspy です。 今回、一緒に働く仲間をただひたすらに"褒める"社内企画をはじめてみました。好評により続いているので、その取り組みについて紹介します。 quipper.fm とは何か なぜはじめようと思ったのか 褒めることの重要性 1. "褒め"によるフィードバックが個人の振る舞いを強化する 2. "褒め"による振る舞いが言語化されることはそれ自体が貴重な学びの機会になる 褒める技術 褒められたひとからの言葉 おわりに quipper.fm とは何か 名前に深い意味はないんですが、ラジオっぽい"雰囲気"でゆるく聞いてもらえたら、という想いで .fm をつけています。実際は社内 Google Hangouts で行っているので、音声だけでなく映像も映ります。 この番組は隔週30分で行われています。各回に1名「褒められるひと」が選
自治体・学校へ『スタディサプリ』を無償提供 新型コロナウイルス感染症の影響による休校期間中の家庭学習支援、連絡手段として オンライン学習サービス『スタディサプリ』は、新型コロナウイルス感染症（COVID-19）の影響拡大を受けて、全国の小学校・中学校・高等学校に対しての支援を決定しましたことをご連絡します。 3月2日からの新型コロナウイルス感染症（COVID-19）拡大対策の小、中、高等学校の臨時休校を受け、『スタディサプリ』『スタディサプリfor TEACHERS』を自治体・学校に無償提供いたします。 学校および先生方は『スタディサプリfor TEACHERS』を通して、児童・生徒に『スタディサプリ』上の講義動画や確認テストなど家庭学習の範囲・単元の指示、実施状況の確認ができます。また、コミュニケーション機能での連絡・確認事項の一斉・個別での送受信など、休校中の連絡手段としても活用いただ
こんにちは、本記事では弊社のカジュアル面談についてライトに書いてみました。文字数は5800字程度ですので読了には5~10分ほどを要すると思われます。 対象読者 Quipperのカジュアル面談に来てみようと思っている方 他社のカジュアル面談がどのような感じか知りたい方 言うまでもないかもしれませんが弊社のやり方が唯一の正解ではありませんし、完成形でもありません。とはいえ現時点で獲得しえたカジュアル面談のノウハウを世に出すことで業界全体の採用活動のレベルの底上げに寄与していきたい気持ちがあります！ カジュアル【casual】［形動］格式ばらず、くつろいでいるさま。 カジュアル面談とは? 初めに言葉の定義を合わせていきます。 弊社 Quipper は面接・面談をより良いものにするために東京オフィス採用面接ガイドというものを公開しています。（同ガイドに関しての詳細はより良い面接を実現するために "
こんにちは。SRE の @chaspy です。 ユーザに価値が提供できなくなってしまうシステム障害は起きてほしくはありませんが、絶対に発生しないとは言い切れません。 そんなシステム障害は、そもそも発生頻度が不定、かつ多くないので、どのように対応すべきかを体系化することは（起きる事象が毎回異なることも相まって）難しいと思います。 本記事では、Quipper において、どのように障害対応を行うのか、また、障害発生時の考え方を紹介します。 障害はどのように対処されていくのか 障害発生フロー Quipper では 標準化された障害時連絡のフロー / 障害レベルがあります。 これによって、障害の内容、影響範囲によっては親会社のリクルートマーケティングパートナーズへのエスカレーションが必要であることと、その基準が言語化されました。また、エスカレーション時に送るメールのテンプレートも用意されており、「誰
挨拶 新規事業開発チームにてプロダクトマネージャーを担当している冨成です。 GitHubやSNSではtominaritとして活動しています。 2018年の6月1日に入社してから公式サイトのリニューアルプロジェクトを完了させて以来、新規事業開発チームのプロダクトマネージャーとして奮闘しています。 もし当時のプロジェクトに関するブログ記事にご興味がある方はこちらからどうぞ。 前提 今のプロダクトチームはWeb Engineer 7人、 Native Engineer(iOS) 2人、Product Designer 2人、 Product Manager 1人となります。今では12人と大きくなったチームですが、去年のこの時期(MVP検証時期)ではまだ3人だったため、ここ1年で爆発的に人数が増えました。 当時は人数も少なく意思決定が早かったのですが、人が増えるにつれて様々な意見が飛び交うようにな
こんにちは。SREの近藤（@chaspy）です。 2019年6月12日 ~ 14日、シンガポールで開催されたSRECon19 Asia/Pacific で登壇してきました。これは私にとってはじめての国際イベントでのプレゼンでした。 *1 *2 本記事では突然やってきたそんなチャンスをいかにして乗り切るかについてのたった1つのコツを紹介します。 tl;dr 本番前までに最低3回の発表練習の予定を設定し、あなたのチームメンバーを Invite してください。 発表練習をしよう 何も準備ができてない状態で構いません。発表が決まったあとまずやることは発表練習の予定を先に決めることです。人間は怠惰な生き物です。僕ももちろん例外ではありません。また、このような対外発表は重要ではありながら、普段の業務と並行して行うのは容易ではありません。(注釈：もちろん、Quipper では対外発表の準備あるいは参加を
こんにちは。SREの近藤（@chaspy）です。 新しいサービス、あるいは Microservices を 本番環境へリリースする際、私たちは何を注意すべきでしょうか。 今回は、Production Readiness CheckList と導入方法について説明します。 Production-Readiness Checklist とは Service を本番環境へリリースする前の、信頼性観点でのチェックリストです。このチェックリストを事前に行うことによって、本番での Service 運用開始後の問題をなるべく引き起こさないようにする、あるいは起きたときに最善な手が打てることが期待できます。 Production-Ready Microservices (日本語版：プロダクションレディマイクロサービス ――運用に強い本番対応システムの実装と標準化 を読まれたひとも多いと思います。本書の付録
こんにちは、Web Engineer の @wozaki です。 今回は、スキルマップを私が所属する開発チーム*1に導入した事例をご紹介します。 スキルマップとは、業務で必要なスキル(技術力、業務知識)と、チームメンバーのスキルレベルを一覧にした表です。 スキルマップの例 引用 スキルマップ作成のすすめ | Ryuzee.com 目次 概要 スキルマップ導入の背景 他社の事例とカスタマイズした点 スキルマップ詳細と運用方針 運用結果 まとめ 概要 チームで必要なスキル、メンバーのスキルレベル、志向性が不明だった 個人の志向性を表現できるようにカスタマイズしたスキルマップを導入した 結果 新メンバーにとって、スキル全体が明確になり、チームの役割の理解にも役立った スキル喪失リスクがあるものが明確になり、勉強会などスキル伝承のアクションにつながった 個人の志向性は、スキル伝承時の期待値調整にも
ujihisaです。先日2019年4月に日本の福岡で開催されたRubyKaigi 2019にて、ujihisaが "Play with local vars"というタイトルで発表してきました。この発表は、40分間英語でひたすらRubyのローカル変数についてだけ語るというものです。 発表スライドは公開済みで、こちらのgistですが、レンダリングにはshowtime.vimを要求しますし、実際にはデモがメインですので、RubyKaigi公式の動画を参照するのが便利です。 www.youtube.com 登壇に至るまで 一年前、RubyKaigi 2018に参加していろんなすばらしい発表を聞いているうちに、 「RubyKaigiでちゃんとした発表をしていないのは申し訳ない」という罪悪感というか強迫観念、 「Rubyを使う上でローカル変数と向き合うのは避けて通れないけど、これだけを取り扱った発表は
ゴリラ.vim#2のイベントスタッフを経験して こんにちは、Quipperのwebエンジニアを担当している @motorollerscalatron です。 恐れ多くも、webエンジニアとして何社かは経験させていただいてきた自分ですが、Quipperに在籍した半年の中でも今までなかったような体験を数多くしました。 今回は、その中でも、ひとつ、想像以上に面白かった、会社が場を提供する形での技術系のイベントの運営について、書かせて下さい。 ゴリラ.vimとは ゴリラ.vimは今年の2月から始まったゴリラさんのvimイベントです。 終了後、ゴリラさんにはちょっとだけご挨拶をさせていただいたのですが、お名前から想像していたよりお話のしやすい方で、意外だったと記憶しています。 私はこの前にも会社では、去年 meguro.rb #19 VimConf 2018 というイベントに参加していたのですが、年
はじめに みなさんこんにちは。データ分析グループでインターンをしています丹田 (@JinTanda)です。 今回、スタディサプリの合格特訓コースにおける、『コーチの声掛けと学習継続の関係性』を自然言語処理の観点から分析しましたので、ご紹介いたします。 概要 スタディサプリには『合格特訓コース』という、コーチが生徒の勉強計画やモチベーション向上、勉強に関わる種々の悩み事の解決をテキストチャットを通してサポートするプランがあります。 「コーチのどのような発言が生徒との良い関係性を築き、学習行動を促すことができるか」というのは生徒の継続的な学習を実現するために重要な分析軸です。 これまでのサービス運営の経験から、コーチのポジティブな発言が重要であるという仮説はあったものの確証は得られていませんでした。 そこで今回、コーチの発言からポジティブな単語を取り上げ生徒の学習継続率との関係性を分析したとこ
SRE チームの @yuya-takeyama です。 Quipper の SRE チームでは AWS や Kubernetes を用いたインフラの構築、CI/CD パイプラインの構築・改善等様々な Developer Experience の向上、社内のあらゆるサービスのマイクロサービス化のサポート、そしてそれに伴う複雑化にも耐え得るよう、サービスの安定稼働を支えるためのルール・ツール群を整備しています。 今日はその中でも、簡単かつより精緻に Logs-Based Monitoring が行えるよう、GCP の Stackdrider Logging に構造化ログを送る方法について紹介します。 構造化ログとは ここではとりあえず「Machine-Readable なログ」として定義します。通常のログはテキストベースの Human-Readable なもので、UNIX 哲学においては行指向
オンボーディングのはじめかた こんにちは。SREの近藤（@chaspy）です。 今回、SREチームではじめてオンボーディングプロセスを実施しました。本日はその内容について紹介します。 オンボーディングとは Onboardingとは、新しく入社した従業員が組織の中で効果的に成果を発揮するために、必要なナレッジ、スキル、行動を習得するメカニズムのことを言います。 これは単なる社内サービスへのアカウント登録作業ではありません。また、関連する技術的な研修を受けさせるだけでもなければ、OJTという名のもとに振ったタスクをやりながら覚えてもらうだけでも不足しているでしょう。なぜなら習得すべきことは技術的なスキルだけではないからです。確かに、実際の仕事を通じて学ぶことはできるはずですが、より短期間で、より効果的に必要なことを身に着けてもらうためには何らかの学習のための仕組み（Mechanism）が必要で
はじめに MAツールを導入前のメール配信方法と課題 まずスキーマ設計してから Marketo を導入 期中、やらないことを決める 目指せ、スマイルカーブ 昼会という名のデイリースクラム 他社事例の調査と運用の型化 スマイルカーブの行方 さいごに、スマイルカーブの向こうへ はじめに みなさんこんにちは、データエンジニアリングチームの戸井田( @toitech )です。 今回は、昨年の春からスタディサプリのユーザーへのメール配信で利用しているマーケティングオートメーションツール（以下 MAツール）「Marketo」の導入について書きたいと思います。 このプロジェクトで私は、スタディサプリのデータ分析基盤と Marketo のシステム連携を実装するエンジニアとしてアサインされました。 しかし、なぜか自分でも知らぬ間に役割がプロジェクトマネージャー的な立ち位置に変わっていきました。 そんな私が、ど
ぼくはオンライン教育サービスを展開するQuipperでSRE(Site Reliability Engineer)という仕事をしています。前職はレシピ動画サービス「クラシル」を運営するdelyで同じくSREをしていました。ほんとうは転職するときに英語で投稿したいなんて考えていましたが、バタバタして今になって日本語で書いています。 なぜQuipperに入社したのかこれはぼくが言い続けていることですが、自分にしかできない仕事をすることを目指しています。そうしないとぼくは自信を持って自己紹介できないんです。自分はこういう人間ですって胸を張って言うためには、アイデンティティを追求して自分にしかできないことをやろうって考えています。 ぼくは今から10年前に英語の勉強を始めました。 それまでは英語が苦手で中１の現在完了形あたりで挫折して止まっていたと言っても過言ではありません。30歳になったのをきっか
こんにちは、今年の 7 月に join した Web Developer の @yoshimaru46 です。 今回は、stateとpropsの違いがわからないくらいには React 初心者だった私が2ヶ月前に SPA のプロジェクトに join してキャッチアップする中で感じたことについてお話させて頂きます。 ちなみに言語歴はこんな感じです Java 2 年 Ruby, Rails 1.5 年 JavaScript 数ヶ月 先日の記事 で @ujihisa さんが「僕は Vim 暦 20 年くらいで、まだ初心者です。」と言っていたので、 まだまだ先は果てしないなぁと思います。 どんなプロジェクトだったか 参加したプロジェクトは既存のウェブサイトをフルリニューアルするプロジェクトでした。 規模が大きいうえにリニューアルで、相対的に新しい技術(The App Shell Model, The
Web Engineer の @kachick です。 今回はスタディサプリのクレジットカード決済を堅牢化するために行っている工夫の一部を抜粋して紹介したいと思います。 前提 本記事で紹介する内容は、過去に我々が提供していたサービス（以下、サービスAとします）において直面した決済バグから学び、スタディサプリに導入したものです。 決済バグとは 決済というものはその性質上、セキュリティに次いでバグへの高い温度感を求められがちです。 サービスプロバイダの目線からは決済のバグを2つに大別出来ます。 本来よりも多く請求しまい、ユーザーからの信頼を損ねる。 決済の金額を増やしてしまった。 決済の時期を早めてしまった。 決済は通ったがサービスを提供できていなかった。 本来よりも少なく請求してしまい、事業運営に支障を来す。 決済の金額を少なくしてしまった。 決済の時期を遅くしてしまった。 実際には決済が通
ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと筆者が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 まえがき ある夜に同僚の@ujihisaと近場ないし遠方のEngineering ManagerやVPofEの皆さんと話す機会があり、その折にふと筆者がこぼしたのが 「開発などの日常の業務において自分がやっている以下の思考様式が大変便利なので、この考え方を最近入社したメンバーにもインス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
