小中新規開発グループ (a.k.a. tara チーム) の qsona です。 tara チームでは、スタディサプリ中学講座というプロダクトを開発しており、約1年前 (2022-02) に本リリースして以来、継続してプロダクト開発を続けています。 tara チームのプロダクト開発は、基本的にスクラムの手法にのっとる形で行っています。ビジネス的な境界により分けられた3つのスクラムチームが存在します。 スクラムの運用については、それぞれの現場において悩みごとが起きがちだと思いますが、tara チームでもご多分に漏れず、うまくいっていること・いっていないことが存在します。今回は、その3つのうちの1つのチームである「学習コアチーム」において存在した、Sprint Planning に関する (あるいはそこから掘り出された) 課題と、それに対してどう対処したかについて書きたいと思います。 なお、本

挨拶 新規事業開発チームにてプロダクトマネージャーを担当している冨成です。 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）です。 先日、より高い信頼性でサービスを提供するために、スタディサプリ小中高大のサービスの最後の砦であるデータベース、MongoDB のインスタンスクラスのスケールアップを行いました。また、スケールアップをするにあたり、負荷試験を行いました。 本記事では、データベースインスタンスのスケールアップの際に行なった負荷試験に対する考え方と、得た学びを紹介します。 なぜスケールアップするのか サービスの急成長に伴い、アクセス数もデータ量も増加しています。数年前に「しばらくは大丈夫」と判断できるインスタンスクラスにスケールアップをしたデータベースも、高負荷時には性能が劣化してしまう問題に遭遇しました。 私たちの MongoDB は AWS 上に EC2 インスタンスとしてセルフホストしており、MongoDB Cloud Manager を使って運用の一部を

こんにちは。SREの近藤（@chaspy）です。 新しいサービス、あるいは Microservices を 本番環境へリリースする際、私たちは何を注意すべきでしょうか。 今回は、Production Readiness CheckList と導入方法について説明します。 Production-Readiness Checklist とは Service を本番環境へリリースする前の、信頼性観点でのチェックリストです。このチェックリストを事前に行うことによって、本番での Service 運用開始後の問題をなるべく引き起こさないようにする、あるいは起きたときに最善な手が打てることが期待できます。 Production-Ready Microservices (日本語版：プロダクションレディマイクロサービス ――運用に強い本番対応システムの実装と標準化 を読まれたひとも多いと思います。本書の付録

こんにちは。@ohbaryeです。 『Quipper Alumni Network(卒業生ネットワーク)』の記事にて宣言した通り、去る2018年12月20日に卒業生と在職者の交流会を開催しました。 どんな会だったか 交流会には6名のQuipper卒業生と7名の現職者が参加しました。私の興味本位で参加者の在職期間を表現した図が以下です。 在職期間が全く重なっていない参加者が多いためどんな"化学反応"が起きるか一向に想像が付かなかったのですが、開口一番に弾んだのは以下のような会話でした。 「あっこの人 git blame したときに出てきたアイコンの人だ」 「古いドキュメントやissueでよく見る人だ」 「はてなブックマークのコメントを付けてくれた人だ」 同じ会社・プロダクトに携わったメンバーとして、また、インターネットと共に在る者として、親近感を得るのはそう難いことではない、のかもしれません

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

こんにちは、Web エンジニアの @kechol です。 Quipper では現在、ブログを再開したり StudySapuri Meetup（Product 回、Data 回）を開催したりと、採用活動に力を入れています。今日はそんな採用活動について、僕も関わっている Web エンジニアの採用プロセスの裏側を少しご紹介したいと思います。 TL;DR Quipper における Web エンジニア採用プロセスにおいては、コードテストを実施しており、そのプロセスは非常に重要なものだと考えている これまでアプリケーションを書いてもらうようなテストを実施していたが、候補者・採用メンバー双方の負担が大きく、改善の余地があった それを受けて、より小さく、実務に近いコードでテストできるようにコードテストを改善した Quipper における Web エンジニアの採用プロセス Quipper における Web

はじめに CTO兼SREエンジニアリングマネージャーの中野です。ここしばらくの間、CTO/SREエンジニアリングマネージャーとして注力しているKubernetes導入について紹介したいと思います。 今回は、Kubernetes自体がどういうものなのかということより、それをツールとしてどう使い、それでどういう世界を実現したいのかみたいなところを中心に紹介できたらと思います。 まず現在の状況ですが、Quipperでは、大きく分けてスタディサプリの小中高校生向けと日本以外向けの2つのサービスを展開しています。サービスとしての構成はほぼ同じですが、基盤としては別々のAWSアカウントで運営されています。このうち日本国外向け環境では、Kubernetes化がほぼ完了というステータスになっています。目下、スタディサプリも移行中です。 Kubernetes化以前は、Deis(Herokuクローン的なもの)

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