こんにちは、Progateで開発業務をしているkota_223と申します。
この記事はProgate AdventCalendar 2020 14日目の記事となります。
私はSoftwareEngineerチームに所属しておりバックエンドを書いたり週末にアメフトしたりする生活を送っていますが、
最近はとあるプロジェクトをリードしており、今回はそこから感じたProgateにおける仕事の進め方(2020年version)について書こうと思います。
技術的な記事が続いている中で箸休め的な記事ですが、エンジニアの方の面接などで質問いただくことも多いので、ご参考になれば幸いです。
プロジェクト
Progateでは定常業務と違い、数ヶ月かかるなどの大きいタスクがあるとプロジェクトとして固定メンバーでチームをつくり仕事をします。
プロジェクトとして動くときは、例えば以下のようなメンバー構成になります。
プロジェクトチーム
- プロジェクトリード
- エンジニア
- デザイナー
- コンテンツプランナー
プロジェクト外から協力するメンバー
- プロダクトオーナー、プロダクトマネージャー
- テックリード
- i18nチーム
- CSチーム、PR
- 海外マーケティング
プロジェクトの進め方と役割
プロジェクト内での役割分担はプロジェクトリードとその他メンバーとなっており、 プロジェクトに参加しているメンバーは基本プロジェクト優先で業務をし、 進捗報告MTGや振り返り会などもそのチーム単位で定期的に行います。
プロジェクトリードはレッスンの構成などを考えるコンテンツチームのメンバーだったり、 エンジニアだったりと特に決まってるわけではありません。
また社内には「はじめてのプロジェクトリードのためのガイドブック」というドキュメントが用意されており、 プロジェクトリードはそれを参考に進めていきます。
プロジェクト内の主な業務は
- デザイン
- コンテンツ製作、修正
- 開発
- 翻訳、ローカライズ
- CSチームと変更による対応協議
- リリース後のデータ分析
となっており、プロジェクトの進捗は毎週役員に、毎月全社に共有する形になっています。
2020年はインフラ刷新プロジェクトやJourneyプロジェクト、Node.jsのレッスンプロジェクト、英語翻訳の標準化プロジェクトなどがありました。
上記のような形で大きなタスクはプロジェクトとして動きますが、 細かいバグの修正やライブラリのアップデートなどはプロジェクト化せず定常業務として進めていきます。
Progateの開発で難しいところ
一般的なプロジェクトの進め方はPMBOK等で体系的に書いてあるのでここでは割愛しますが、 Progateならではの難しさ的なところをいくつか記載したいと思います。
グローバルなサービスであること
Progateは日本語、 英語、 インドネシア語でサービスを提供しており、インド、インドネシアにも法人があります。
社内にi18n(国際化)チームがあり、さらに日本以外にもメンバーがいるため、翻訳やローカライズを社内で行うことが多いです。
例えばプロジェクト管理的な観点で言うと、各国で同時にリリースする必要がある場合に適切なタイミングでグローバルチームに共有し協力してもらう必要があります。
早すぎると開発で手戻りが発生したときに、翻訳やローカライズも再度行う必要があり、 遅すぎるとそのときにリソースが足りずリリースがずれるなどの問題が発生してしまいます。
開発面でも翻訳するだけでなく
- 各国の法律、規約
- 各国固有の決済手段、通貨
- 日本語、英語、 インドネシア語のテキスト量
- タイムゾーン
- デバイス
- 国別の提供サービス
などの違いに気をつけなければならず、どうしても分岐が増えるため設計やテストコード等でうまくカバーしなければなりません。
言語や国ごとのReactComponetの出し分け方法や、データの持ち方は社内のdevelopment guideでルールが設定されており、 それに従って開発します。
また機能の追加や修正を行うとCSチームに変更の周知や、FAQの修正、想定されるお問い合わせの想定問答を作成したりしますが、 原則各国の現地メンバーがお問い合わせに対応することになっているので、うまくキャッチアップできるように密にコミュニケーションをとる必要があります。
サービスの歴史が長くなってきた
Progateに限らずですが、サービスを長期間運用していると開発当時と状況が変わっていることがよくあります。
Progateも6年以上サービスを作り込んでいるため1つの変更による影響範囲が大きかったり、 データの都合で変更が厳しいなど仕様決めや実装方法判断が難しい状況が発生します。
そこで社内では
- 方針レビュー
- 仕様レビュー
- 実装レビュー
などをテックリードやマネージャに相談するフローを設けて、 なるべく考慮漏れを減らしたり、適切な実装ができるようにカバーする体制をつくっています。
実装後のレビュー体制もapprove2つ(ジュニアレビュアーとシニアレビュアー)でmergeできるルールとなっています。
問題が起こった際はPostmortemを開き、根本問題の特定や対応の良し悪しなど共有することで社内で知見を蓄積するようにしています。
サービス内容がプログラミング教育であること
提供しているレッスンについての質問をいただいた際に、ユーザーの実行環境で起きている事象を正確に把握することが難しいということも挙げられます。
現在Rollbarでのエラー管理や、Redashでログやデータベースの分析を行って対応していますが、 ユーザーの入力にかなり自由度が高いことや、コードの実行環境を提供していることでエラーが起こった際に問題の特定が難しい場面があります。
ただ社内ではエンジニア以外にもSQLを叩けるメンバーも多いため、 ある程度調べてからエスカレーションされることも多く、エンジニアとしてはとてもいい環境だと思います。
「ユーザーがプログラミングに興味を持ち、できるようになっていくにはどうすればいいか」のような議論はコンテンツチーム以外のエンジニアもよくしており、まだまだやらないといけないことだらけであることを実感しています。
最後に
以上が2020年体制で行った開発の進め方やポイントとなります。
来年以降またメンバーや役割が増えて、どんどんアップデートしていく予定です。
Progateの開発の難しさで上記に書いた例は一部ですが、「こんなの全然難しくねぇよ!」とか「次のチャレンジはここだ!」と思われた方はぜひ 採用ページからご応募お待ちしております！
明日はSREチームの村山によるGitHubに関する記事です！お楽しみに！
