はてなブックマーク

こんにちは。ソフトウェアエンジニアの @ttokutake です。 この記事では、スタディサプリ小中高プロダクト開発部の技術戦略グループの活動内容を紹介していこうと思います。 「いきなり何ですか？」と思った方がほとんどだと思われますので、まずは「技術戦略グループとは何なのか」から順を追ってご紹介させていただきます。 @chaspy さんが SRE NEXT 2022 ONLINE で発表している内容と被っている部分がありますが、ご容赦いただけたらと思います。 ちなみに自分は2021年10月〜2022年9月の期間で技術戦略グループの中の横断ワーキンググループをリードする役割を担当していました。 (横断ワーキンググループの説明はこのあとすぐ！) 技術戦略グループとは このグループの目的と目標は以下のようになっています。 目的 プロダクト開発組織とそのシステムをより変化に強くする 目標 技術的な

こんにちは。QA Engineerの@testtattoです。 今回はE2Eテストの自動化にあたって、どういった考えでツール選定を行ったのかを話したいと思います。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 E2Eテスト自動化によって課題を解決したいが、どういった技術があるのか分からなくて困っている人 E2Eテストの自動化は実現できているが、継続に課題を抱えている人 テスト自動化なら何でも興味がある人 まえがき 読んでもらう前にいくつかの前提を共有します。 リリースサイクルについて 当社のwebプラットフォームのリリースサイクルは一部のマイクロサービスを除いて基本的には週次です。 決まった曜日で各プロダクトのプルリクエストを取り込んで、リグレッションテストを実施し、リリースブロッカーがなければリリースしています。 流れとしてはこんな感じです。 月 火 水 木 金 特

（この記事は約5分で読めます） こんにちは、スタディサプリ TPM（Technical Product Manager）の@risa-hayashi です。 振り返りにGitHub Projects(beta)のInsightsという機能を利用してみたところ、振り返りが効果的にできるようになったのでその運用方法や効果を紹介したいと思います！ GitHub Projects(beta) Insightsとは？ とてもざっくり言うと、任意のGitHub Project(beta)に載せられたissueから、このようなチャートを作れる機能です。 しかもこのチャートの見た目（グラフの種類やX/Y軸の基準）は適宜カスタムすることができます。便利！ 私の所属しているスタディサプリ合格特訓コース、個別指導コースの開発チームでは、この機能を利用して数ヶ月前から振り返りの運用を行っています。 なぜInsig

こんにちは、ujihisa といいます。現在スタディサプリのProduct Platform の Software engineerとしての仕事を行っています。先月から社内留学で、開発支援チームからコーチングチームに一時的に移籍して、そちらの仕事をやっています。 Rubyのコードの書き方 まずは全体的なコーディングスタイルなどについて。 現在社内で統一的に使用しているコーディングスタイルの標準化などはとくに行われておりません。各チームごとに、それぞれのチームが開発運用している (= ownershipをもっている) コンポーネントそれぞれに対して個別のRuboCop設定などはあります。また、複数のチームの境界にある、歴史的な共有サービスに関しては (そう、まだあります、そしてこれは今後もかなり長いあいだ付き合っていくことになるでしょう) testdouble/standard というTes

こんにちは！iOSエンジニアの @chuymaster です。今回は私たちのチームが2月にリリースした「スタディサプリ 中学講座」のIn-App Purchase（IAP）の実装について書きたいと思います。SwiftUI x IAPの事例をお探しの方必見です！ 背景 「スタディサプリ 中学講座」では、ユーザーが月額料金を支払うことで、講座の動画を見る・演習をすることができます。iOSアプリでの決済手段として、In-App Purchase（IAP）機能を提供しています。 「スタディサプリ 中学講座」のApp内課金導線 既存アプリの実装が参考にできるとはいえ、IAPの仕様はかなり複雑で理解しにくい部分が多いです。また、UIKitで開発された既存アプリと違って、「スタディサプリ 中学講座」はフルSwiftUIで実装されたので、いかにSwiftUIらしく設計・実装できるかかなり悩みました。 この

こんにちは、iOSエンジニアの @elliekwon です。去年のiOSDC Japan 2021「スタディサプリ」がFull SwiftUIを選択した先に見えてきたものの発表で紹介させて頂いた通り、SwiftUIで開発してきた「スタディサプリ中学講座」ですが、SwiftUIでは対応しきれず、ごく一部UIKitを利用した機能も存在しています。この記事ではそれらのケースと対応策を紹介します。 事前知識 その前にSwiftUIからUIKitを使うため、先に知って貰えたいものがあります。 一つは UIViewRepresentable / UIViewControllerRepresentable と言うprotocolで、これらはSwiftUIでUIKitのUIView/UIViewControllerを使えるようにしてくれるwrapperです。 UIViewRepresentableに準拠し

こんにちは。iOS エンジニアの wadash です。先月2022年2月に無事リリースした「スタディサプリ 中学講座」のチームで開発に携わっています。 今回は iOS バージョンによる SwiftUI の挙動差異と制限のまとめをご紹介します。 SwiftUI の採用とサポートバージョンについて 「スタディサプリ 中学講座」では、SwiftUI を全面的に採用した開発を行っており、アプリのサポートバージョンを iOS 14 以上としています。 プロジェクト発足当初は iOS 13 以上をサポートバージョンにする方針で議論していましたが、プロジェクト期間途中の2020年9月にリリースされた iOS 14 にて、iOS 13 時点で一般に認識されていた SwiftUI の不安定な挙動がある程度改善されたことを確認したため、プロダクト自体の品質向上という目的と、ローンチのタイミングでユーザーがイン

つい先日リニューアルされた スタディサプリ 中学講座 の開発チームでインターン生をしている @YutaUra です。今回はインターンの中で New Relic と Prisma を連携させる業務に取り組んだのでそれに関してご紹介したいと思います！ スタディサプリ中学講座では、バックエンドの一部に TypeScript x GraphQL x Prisma を採用しており、パフォーマンスの計測などに New Relic を用いています。New Relic は Prisma を正式にサポートしていないため、導入するためには自分たちで実装する必要がありました。 そこで今回はライブラリを作成し、最終的に OSS（newrelic-node-prisma）として公開したので、それらについて実装と合わせて紹介します。 New Relic とは New Relic のトップページ Web サービスにおけ

こんにちは。 SRE の @suzuki-shunsuke です。 Terraform Modules を Monorepo で versioning して管理するようにした話を紹介します。 先日紹介したとおり、弊プロダクトではインフラを Terraform の Monorepo で管理しており、 CI は GitHub Actions + tfaction で実行しています。 blog.studysapuri.jp 弊プロダクトの Terraform Modules の管理手法は、この 2.5 年の間に 2 回ほど変化がありました。 Terraform Monorepo 内で管理し Local paths で Module を指定 Module を versioning するために Module ごとにリポジトリを作成し、 Terraform Monorepo とは別リポジトリで管理 M

こんにちは。SREの@kyontanです。スタディサプリのSREチームにジョインしてから初のブログ記事となります。 つい先日、スタディサプリ 中学講座が大幅リニューアルされました。*1 今回は、そのリリースを自信を持ってユーザーの皆様へお届けするために実施した、プレモーテムという取り組みについてご紹介したいと思います。 背景 今回のスタディサプリ 中学講座のリニューアルは、バックエンド、フロントエンド(Web/iOS/Android)の開発をフルスクラッチで行ったため、大規模なリリースとなりました。 すでにユーザーへ提供しているサービスを、段階的にリニューアルされたものへ切り替えていく複雑なリリースということもあり、リリースにあたっては予期しないトラブルが起きる可能性が推測できます。 通常、さまざまなトラブル(障害)が起きた際には、私たちはあらかじめ定めた障害対応フローに沿って対応を行い、

はじめに こんにちは、@shase です。 スタディサプリでは、データパイプラインのツールとして、従来 AWS Kinesis Stream や、Embulk や、AWS Lambda などがよく使われてきました。 ただ、現在開発中のプロジェクトでは、システム間の連携の為、Cloud Pub/Sub が多用されているということもあり、データパイプライン Cloud Pub/Subとの親和性が高いCloud Dataflowを一部取り入れています。 本記事では Cloud Dataflow 自体は詳述しませんが、簡単に説明させていただくと、Cloud Dataflowとは、GCP が提供するマネージドな Apache Beam の実行環境になります。 Cloud Dataflow のメリット Cloud Dataflow（Apache Beam）には、以下のようなメリットを感じています。 ス

こんにちは。SRE チームの@chaspy です。 本記事では私の所属する SRE チームにおける「ふりかえり」の文化を紹介します。 背景 最近のチームのふりかえり会 *1 で僕自身が以下のようなコメントを"Keep"として出しました。 これは、単にこのふりかえり会が継続している、という意味に留まりません。あらゆる物事に対してふりかえりが行われ、改善サイクルが高速に回っていると感じます。それはチームメンバー全員が以下の価値観で仕事を進められているからだと思います。 あらゆる問題、取り組み、事象について「それは本当に必要か？」「それはなぜやるのか？」といったことを問うことができる。いわゆるクリティカルシンキング。 あらゆる問題に対して、建設的・前向きに、他者や何かを否定することなく、より良い案を言葉にして提案できる。建設的思考。blameless。 やることにコストがかからず、やらない理由が

こんにちは。 SRE の @suzuki-shunsuke です。 Terraform Monorepo に対する Renovate の大量の Pull Request を処理するための技術について紹介します。 背景 過去ブログで何度か紹介しているように、弊プロダクトでは Terraform の Monorepo を管理しています。 先日、 CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました。 blog.studysapuri.jp working directory (state) の数は 400 近くあり、 working directory ごとに以下のような tool のバージョンを管理しています。 Terraform Terraform Provider tflint tflint plugin tfsec etc これ

こんにちは。 SRE の @suzuki-shunsuke です。 Terraform の CI を AWS CodeBuild (以下 CodeBuild) から GitHub Actions + tfaction に移行した話を紹介します。 これまでの Terraform Workflow (CodeBuild) 弊プロダクトの Terraform の CI に関しては過去の記事でも何度か紹介していますが、 元々 CodeBuild 上で CI を実行していました。 かつては CircleCI 上で実行していましたが、 CodeBuild に移行しました。 blog.studysapuri.jp CodeBuild に移行した理由は大きく 2 つありました。 Security 永続的な Access Key を発行することなく AWS のリソースを管理できる GCP に関しても Wor

こんにちは。 SRE の @suzuki-shunsuke です。 AWS SSO を導入してセキュリティと利便性を改善した話を紹介します。 背景 これまで弊プロダクトチームでは各開発者に AWS IAM User を作成し、 IAM User の ID/Password で AWS にサインインし、 IAM User の Access Key を使って AWS CLI などを実行したりしていました。 しかし、この運用にはセキュリティと利便性の観点で以下のような課題がありました。 セキュリティ Access Key が流出するリスクがある 退職後も IAM User が残り続けてしまうリスクがある 利便性 入社時に IAM User を作成し、退職時に削除する必要がある AWS にサインインする際に AWS の MFA が地味に面倒 IAM User の ID, Password, MFA

こんにちは。SRE の @int128 です。 先日の「負荷試験、Gatling を使ってやってみた」で紹介したように、スタディサプリではユーザ体験の改善や本番障害の予防を目的に負荷試験を行っています。 本稿では、SRE と Product Team がどのようにして一緒に負荷試験に取り組んでいるか、考え方や仕組みを紹介します。 背景 SRE では新しいマイクロサービスの開発や機能追加の契機で Production Readiness Check を行っています。 具体的には、Product Team がテンプレートにしたがって Production Readiness Checklist を記入して、SRE と一緒にレビューを行っています。 その際に、トラフィックが多い、あるいは、レイテンシが厳しい、といったリスクがある場合に負荷試験を行うことにしています。 負荷試験は以下の流れで実施し

データエンジニアの@masaki925 です。 私が所属するデータ組織では、スタディサプリ本体に対して検索やレコメンドなどのデータプロダクトをマイクロサービスとして提供しており、その多くはPython がメイン言語です。 またデータ基盤としてBigQuery をはじめとしたGCP サービスを多く活用しています。 現在、私は2020年頃から新規プロジェクトに参画しており、そこでもPython とGCP をベースとした開発環境を構築しました。 私が開発環境に求めることは「TDD がしやすいこと」です。 これは平たく言うと、テストを書いて、実装して、CI/CD して、というサイクルを効率的に回すことです。当たり前のことを当たり前にやりたい、ただそれだけです。 今回、以下の環境でそれをやろうとしたらいくつか罠があったので記しておきます。 $ docker compose run poetry-do

スタディサプリのコミュニケーション開発チームの @chata です。開発実装を行った際に負荷試験をして実際のパフォーマンスがどの程度なのか計測したときの模様を共有いたします。 TL;DR 背景と結果 負荷試験をいざやってみると色々問題が見つかりました。パフォーマンスにおける課題だけではなくアーキテクチャの課題も把握できました。また弊チーム以外でも同じようにやってみたいという声があり活用してもらっています。 負荷試験に関するまなび 負荷試験は3種類のテストをそれぞれの目的で実施すると必要なリソース(CPUやMEM)や台数などの把握が事前にできます。またパフォーマンスの課題も見つけやすいです。 実行環境に関する Tips SREチームの多大なる支援を背景にPR環境で Report がDeployされる Loadtest Platform を活用することで試行錯誤のサイクルを速くまわすことができ

スタディサプリのコーチングサービス (合格特訓コース、個別指導コース) 開発チームで Engineering Manager をしている @pankona です。 最近弊チームで取り入れている Autify の良さについて紹介します。 TL;DR 弊チームでは最近 E2E テストとして Autify を便利に活用しています。 Autify の便利ポイントは以下。 E2E テスト構築が容易。非エンジニアでもある程度すぐに作れるようになる。細かいところは JavaScript や CSS セレクタを用いてエンジニアが補うこともできる。 多少 UI の見た目が変わってもテストが壊れにくい。UI の見た目が変わったことは検知することができ、問題ないと人間が判定することでテストが修復される。 チャットで質問を出すと結構すぐに返事がきて嬉しい。感謝。 Autify について Autify ランディング

不要な Swift コードを静的解析で安全かつ継続的に消していく こんにちは、iOS エンジニアの @manicmaniac です。 現在スタディサプリ iOS アプリ開発チームのエンジニアリングマネージャをしています。 スタディサプリ iOS アプリは開発開始から7年以上が経過した、そこそこ歴史のあるプロダクトとなっています。 そこそこ長い歴史の中では、「スタディサプリ」が React Native から卒業するまで、あるいは技術的負債への感謝と敬意 で触れたように大小さまざまの利用技術の変遷があり、開発者の入れ替えがあり、多数の新機能の追加や削除がありました。 したがって、コードベースには歴史の生き証人のような不要コードがポツポツと存在しています。 今回はこれらの不要コードを削除する活動を、ツールの助けを得て行った話をします。 不要コードとは さきほどから不要なコードと言っていますが、