本稿では、ファストドクターのモバイルアプリのリリースフローを整備した取り組みについてご紹介します。 モチベーション ファストドクターのモバイルアプリは、2022年夏にFlutterでのフルリプレースを実施し、それ以降は機能の開発が完了次第随時リリースをするという戦略を取っていました。 この戦略はシンプルであり、開発に関わっているステークホルダーが少ない状況下でうまく機能していました。しかし、組織の拡大に伴い以下のような問題が発生するようになりました。 複数機能の開発スケジュールの調整をしたり、バックエンドのリリース・QAとの整合性を取ったりという必要性が増し、調整コストが肥大化 リリースが不定期なため、いつPull Requestをマージすれば良いか分からずopenされたままのPull Requestが多数 この状況を改善するために、以下の要件を念頭に定期的なリリースとそれを支える仕組みを

こんにちは、メルペイでSREとして従事している @myoshida です。この記事は Merpay Tech Openness Month 2021 の8日目の記事です。 SREチームはお客さまへよりよいサービス利用体験を提供するため、日々様々な改善活動に取り組んでいます。その活動の一環としてPlaybookの概念を導入し、運用者の運用負担を減らす取り組みを始めました。今回はそのことについて説明してみたいと思います。 概要 メルペイではアプリケーションエンジニアとSREの双方がオンコール制度のもと運用に携わっています。 運用の悩みは様々ですが、そのうちの1つに手順書の取り扱いがあります。 どこに置くべきか、更新はされているのか、何を書けばいいのか、どの場面でどの手順書を利用すればよいのかというような悩みはどこの現場でも少なからず存在すると思います。 そこで、Playbookと呼ばれる体系的

タイミング 各フェーズで起点となるタイミングについて説明します。 プランニング確認 上の表の「プランニング」の週に行います。 リリースの3週間前にプランニング確認のミーティングを行います。開発の進捗や、一週間でQAが行える分量なのかなどを確認して、そのバージョンに含める機能を最終調整して確定します。そのタイミングまでは、PdMやエンジニアがNotionに機能を追記していきます。 QA準備 上の表の「開発」の週に行います。 リリースの2週間前にQA準備のミーティングを行い、そのバージョンのテストシナリオやQAリソースが足りているかどうかを確認します。休日などの都合に応じて工程調整を行ったりもします。 QA開始 上の表の「QA」の週です。 QA開始前までに全てのpull requestをマージしておく必要があります。このタイミングに間に合わなかった場合は次のバージョンに延期されます。 QA開始

こんにちは、スマートニュース株式会社の紀平です。 SmartNews のアプリ内では、最近 WebView を使った機能を多数公開しております。そのうちの一つにショッピングチャンネルという機能があるのですが、今日はそのショッピングチャンネルのタイムセール枠で以前発生した、謎のプチフリーズ問題の調査手法をご紹介します。 tl;dr 特定の Android 端末でプチフリーズが発生した 再描画領域を減らすことで現象は改善した Chrome の Tracing 機能を利用し、ブラウザのソースコードまで参照して、ついに根本原因まで突き止めた タイムセールで起こった問題 タイムセールは、SmartNews のショッピングチャンネル内において WebView で提供されている、期間限定のお得な商品をアグリゲーションした機能です。EC サイト各社のご協力の上にご提供しております。内部は HTML5 で開

One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of

Mobile Engineer の @chiiia12 です。今回は Android アプリのリリース作業の改善について紹介します。 Release Managerのしごと 私たち Android チームではアプリのリリース作業を担当するメンバーを Release Manager として当番制で回しています。 Release Manager がリリース時に行うタスクは以下です。 Release ブランチを作成する Version Name/Code を上げる 段階的公開の割合を設定する アプリの submit Tag を作成 Release ブランチから master ブランチへ merge back する CSチーム広報用の issue の作成 審査が通り次第 Play Console から公開する リリース作業の一部は既に自動化されていました。例えば Gradle Play Publi

2018年4月から務めた Quipper Limited の Vice President of Engineering を、2020年3月末日付で退任*1した。 なぜやめるのか 一言でいうと、 VPoE として担っていたミッションを完遂したため。 二年前に VPoE 就任を打診されたとき、自分が所属していた開発組織の課題は明白だった。人が辞める。定着しない。人が増えない（むしろ減る）ので現場の負荷が上がる。ムードも悪くなる。お世辞にもおすすめできる職場とはいえなかった。 そこで、「二年で開発組織を立て直す」をミッションに掲げ、上司と約束した。 結果、二年間でエンジニア組織は 25 名から 54 名へと倍増。かつ、ミスマッチを防ぐ採用方針を徹底したことで離職者を低く抑えることに成功。開発組織を安定化させた。 2017年3月 2018年3月 2019年3月 2020年3月 エンジニアの人数

近況報告です。4年7ヶ月勤続したQuipperを"退職"ります。 退職エントリですか？ これは退職報告ではありますが、一般的に期待されるような"退職エントリ"ではない気がしています。もう少しちゃんとしたやつは後ほど書くつもりです。 誰 @ohbarye です。"広島の粗大ごみ"と呼ばれることもあります。 在職中はRuby on Railsによるサーバサイド、React, TypeScriptによるフロントエンドを中心に学習サービスの開発をやってきました。長らくBtoC領域に携わっており、登録導線や決済システムやカスタマーサポート周りの開発・運用経験が長いです。また、必要に応じてスクラムマスターのような動きもした時もありました。 ここ2年半ほどは上記のような動きをしつつ、Engineering Managerとして組織設計・採用プロセス整備・評価制度策定・表出した組織課題への対応・会社主催の

あまり声を大にして言っていなかったが、Engineering Managerになってからのほうが学習意欲が増して技術力が伸びたのではないかという自負がある— ohbarye (@ohbarye) 2019年3月26日 もう半年以上前だが、このツイートにそこそこFavが付いたのでもう少し丁寧に考えや経験を補足しようと思った。 僕が観測する界隈ではエンジニアがマネジャーになることに対するネガティブな印象として「コードを書けなくなる」「技術力が落ちる」といった意見を聞くことが多いので、いち反例として個人的な経験を挙げてみる。*1 どういうことか 僕がエンジニアリングマネジャーになったのは2017年で、今から約2年前。*2 過去に記事で書いたようにその頃は 「日常の業務を漫然と続けるだけで成長するフェーズは終わった」という焦燥感があった一方、目線の上げ方・課題の見つけ方・実行するための冴えたやり方

charity.wtf charity wtf's about technology, databases, startups, engineering management, and whiskey. Lately I’ve been doing some career counseling for people off Twitter (long story). The central drama for many people goes something like this: “I’m a senior engineer, but I’m thinking about being a manager. I really like engineering, but I feel like I’m just solving the same problems over and over

モバイルエンジニアの@chiiia12です。 先日@m-sugawaraからReact Native開発全般についての記事が公開されましたが、今回はAndroid対応にフォーカスして紹介します。 QuipperではReact Nativeで書かれた業務用アプリがあり、iOSでのみ提供していました。対象ユーザーは内部のスタッフに限られていたため、会社から配布している業務用iOS端末のみで正しく動作すれば十分だったためです。しかし私用端末でも使える方が業務上効率が良いこと・業務用の端末を用意するコストの観点から、会社からの端末配布をやめ、iOS/Android両プラットフォームでアプリを提供し私用端末で利用してもらうことになりました。 今回は私達のチームが遭遇したReact NativeアプリでのAndroid対応をサプライズ度(★★★)と一緒に紹介します。React Nativeのマルチプラ

@mntshさんをゲストに迎えてFeature Flagについて話しました。 podcast feedを購読するか、DLしてお楽しみ下さい。 Show Notes:Feature Toggles (aka Feature Flags)巨大なアプリ開発を支えるフラグ管理術 / Flag-based feature management - Speaker DeckDroidKaigi 2019 - 巨大なアプリの開発を支えるフラグ管理術 / munetoshi [JA] - YouTubeIntroduction to GitLab Flow | GitLabTrunk Based DevelopmentContact:@dexfmpodcast@hotchemi@mntsh

ぼくはオンライン教育サービスを展開するQuipperでSRE(Site Reliability Engineer)という仕事をしています。前職はレシピ動画サービス「クラシル」を運営するdelyで同じくSREをしていました。ほんとうは転職するときに英語で投稿したいなんて考えていましたが、バタバタして今になって日本語で書いています。 なぜQuipperに入社したのかこれはぼくが言い続けていることですが、自分にしかできない仕事をすることを目指しています。そうしないとぼくは自信を持って自己紹介できないんです。自分はこういう人間ですって胸を張って言うためには、アイデンティティを追求して自分にしかできないことをやろうって考えています。 ぼくは今から10年前に英語の勉強を始めました。 それまでは英語が苦手で中１の現在完了形あたりで挫折して止まっていたと言っても過言ではありません。30歳になったのをきっか