QAエンジニアとモバイルアプリチームのバックエンドエンジニアというトリッキーな二足のわらじを履いた半年間の思い出
皆様、こんにちは！
佐久間まゆちゃん兼北条加蓮ちゃんのプロデューサーのhiroki_tanakaです。
この記事はnote株式会社 Advent Calendar 2022の22日目の記事です。
(ふと気づいたのですが、私事ですが今年入籍し結婚記念日が2022年2月22日なので、2という数字に縁がある一年ですね！)
昨日はnote社のエジソンこといえもんさんの『IoT鐘』という記事でしたね
昨日無事上場することができたnote社にピッタリな記事でしたね。何より鐘を自作できるいえもんさん、凄すぎです…！
さて本題に入ろうと思います。
はじめに
私はこれまで得意な言語はJavaとRuby・SQLでnoteではRuby on Railsを中心としてサーバサイドエンジニアとして生きてきました。(得意と言っても技術力は中の下程度です。)そのため、入社以来1年近くチームの一メンバとして新機能の開発や既存機能の改修を行う生活していました。
ところが、2022年5月からひょんなことから私は社内で新設されるQAチームのQAエンジニアになると同時にモバイルアプリチームの1人目のバックエンドエンジニアにジョブチェンジしました。
そんな中々ない2チームの兼務をしながら、行ってきたことと感じたことを振り返ります。
QAチーム編
そもそもなぜQAチームが生まれたのか
noteはこれまで専任のQAエンジニアがいなかったため、様々な品質課題が発生し、オーナー不在で蓄積されていました。
単体テストを始め各フェーズのテストに取り決めがなく、機能の品質担保が実装者に依存してしまい、品質の属人化が進んでいた。
本番環境で発生した不具合の知見の蓄積・活用が行われておらず、個人や各チーム依存になっていた。
全社的な不具合報告口がなく、何らかのSlack chで報告があった場合でも流れてしまうことや宙に浮いてしまうことが多かった。
これらの問題は組織・システム共に拡大するにつれて顕在化していきました。
そんな状況の中でQAチームは『noteに品質文化を定着させ、note全体の品質が向上し、クリエイタが安心して利用できるようになること』を目的に生まれたチームです。メンバはEMを兼務している烈さんと私と同じく未経験からQAエンジニアになったくぼぴーさんの3人でした。(チーム内にこれまでQAエンジニア経験がある人はいませんでした。)
私はその中で多忙な烈さんに代わっての代理リーダでありながら、実際に手を動かすQAエンジニアでもありました。
QAチームでの活動
これまで自分やチームメンバが経験してきた品質向上につながると思われる施策・勉強会や書籍で学んだ施策の内、出来そうな施策から順番に片っ端からやっていきました。
この時考えていたことはあまり質を考えずに、本当に「何でもできることはやってみよう！」の精神でまず実施してみて、結果効果がなかった施策や工数が多大に掛かる施策は止めていこうというものでした。
QA未経験しかいないチームだからそこ、量の精神で色々試してみて、上手くいくこと・行かないことを身体で覚えていこうと考えていました。
最初は上手く行かないことばかりという前提でとにかく、失敗を恐れないことを一番大事にしていました。
その結果、下記にあるような半年間とは思えないほど様々な施策を実行する事ができました。ただ、どの施策も簡単なものはなく、私一人の力では到底出来なかったことばかりでしたが、1つ1つの大きな施策に対してチーム一丸となって取り組んできた結果が繋がったのだと思います。
障害対応フローの確立
定期リリースフローの確立
複雑な機能をリリース前に検証するQA会の実施
全社的な不具合報告口の設置
テストカバレッジの向上
E2Eテストの整理・高速化・コストカット
新入社員とQAチームの2on1実施
本番で発生した障害を振り返るポストモーテム会の実施
複数人でランダムに機能を打鍵し不具合を発見するBug Bash祭の実施
いつでもQAチームと気軽に会話できるQA TeaTimeの開催
各施策の中身に関してはアドベントカレンダー6日目に同じQAチームのくぼぴーさんが丁寧に記事を書いてくださいました。
とても良くまとまっているのでくぼぴーさんに大変感謝です。
※各取り組みの詳細まで知りたい方は是非、『noteエンジニアのQA/テスト マガジン』を見て頂き、フォローして頂けると嬉しいです🙏
また、施策を行って終わりにせず、積極的に社内外への発信も行いました。結果、半年間で以下のようにたった3人のチームとは思えない程の量を発信してきました。
毎週欠かさずQAチームが行った内容をまとめたQA週報の共有。
QA関連書籍の社内輪読会を実施し、3冊読破。
社内向けのLTを9回・社外向けのLTやパネルディスカッションを2回と社内外合わせて計11回登壇。
noteにQA関連記事を19本投稿。
社外発表資料の内1つがこちらです。
発信を重視してきた理由としてはQAチームは社内で出来たばかりのチームなので、他チームから「あのチーム、何しているかよくわからない……」となるのを防ぎたかったためです。特にシステムの品質に無関係な方はエンジニア・非エンジニア問わず誰もおらず、全員野球で取り組んでいきたいと考えていたためです。
そのため、常にQAチームの取り組みは(時には悩みも)オープンにすることや周りから質問・相談しやすい環境作りは心掛けていました。
モバイルアプリチーム編
そもそもなぜモバイルアプリチームにJoinしたのか
これまでnoteのモバイルアプリチームにバックエンドエンジニアはおらず、モバイルアプリ起因でバックエンドのAPIを修正する場合は他チームに依頼している状態でした。しかし、他チームはメインのチーム目的に紐づくタスクがあるため、どうしても優先度の兼ね合いなどでモバイルアプリ向けのバックエンドの改修はスピード感が出ませんでした。
そのため、モバイルアプリ向けの施策の開発速度向上及びモバイルアプリとWebの架け橋になることを目的として、専属の1人目バックエンドエンジニアとして私がJoinすることになりました。
モバイルアプリチームでの活動
1人目ではあるもののこれまでモバイルアプリチーム内でやりたかったけど、できていなかったバックエンド課題をまず整理・棚卸し~タスク管理を確立することから始めました。
その上で優先度付けし、優先度の高いものから1つ1つ着実にこなしていきました。
一例を挙げると以下のような施策の対応を行いました。
モバイルアプリでの記事複製機能対応
新ホームタイムラインのモバイルアプリ対応
AndroidのPush通知処理をGCMからFCMに移行対応
様々なモバイルアプリのPush通知追加対応
レガシーなAPIのリニューアル対応
この中でも特にAndroidのPush通知処理はこれまでずっとレガシーで既に使用が非推奨になっているGCMを使っており、通知に関する施策の大きなボトルネックになっていました。モバイルアプリチームとしても移行したかったけれども、バックエンドのリソースがなくて出来ず…な状態が続いていました。
しかし、私が加わったことでAndroidの通知処理を一から見直し、調査・実装をAndroidエンジニアと協同で進めることで、無事FCM移行することができ、これまでのAndroidのPush通知では出来なかったことが色々出来るようになり、今後の施策の幅が広がるとてもインパクトがある対応でした。
※FCM移行の実装詳細に関しては下記を参照ください🙏
また、QAチーム同様にこちらでも学びを発信し、社内LT1回と外部記事2本を発表しました。
以下は社内発表資料の一部抜粋です。
やはり、こちらも1人目のエンジニアということで、他チームからモバイルアプリのバックエンドの相談事はhiroki_tanakaに言えば良いんだというように広く認知して貰いたかったためです。
感想とおわりに
正直に言うとQAチームとモバイルアプリチームの二足のわらじはやっぱり、かなり大変でした。マネジメントやチーム間調整といったタスクに疲れてくると、ある程度答えの見えている実装タスクばかりやりたい…という気持ちに囚われそうになったことは数え切れません。
(未だに頭のスイッチコストに慣れません笑)
ただそれでも、モバイルアプリチーム・QAチーム共にやって良かったとは胸を張って言うことができます。本当に周りの人に助けて頂き続けた半年間でした。
これまで個人の実装力で何とかすることが多かったのですが、この半年間は自分の力だけでは到底出来なかったことを人を巻き込んでチームとしてゴールまで持っていくということが多く、マネジメント・調整力や説明力・決断力といったこれまで余り使ってこなかった部分が非常に身についたと思います。
気づけば、誰かにメンションする際の「送って大丈夫かな…？」という抵抗感は全くなくなっていて、社内のnoteの各ドメインの詳しい人に詳しい人になっていました。(これも色々な人を巻き込みながら進めていった結果ですね笑)
そして何より、自分のこれからのキャリアとして技術力に尖っていくのではなく、エンジニア・非エンジニア問わず人と向き合い・人を巻き込みながら物事を進めていくようなキャリアを歩みたいと思うようになりました。
(1年半前にnoteに入社した時は技術力に尖っていくキャリアにしたいと何となく思っていたので、これはとても大きな変化でした。)
そのため、来年は自分自身で手を動かす機会を徐々に減らしていく代わりに、タスクマネジメントや個人間/チーム間調整・意思決定といった周りの人が働きやすい環境作りに尽力していきたいと思っています。
まとめると、これからは「人を巻き込む」から「巻き込んだ上で自分が責任を取る」に昇華させていきたいです。
なので、来年は以下の言葉を胸に邁進しようと思います。
プロフェッショナルなプログラマの最大の特徴は「自分が責任を取る」という態度、責任感です。
責任の取れないような見積りやスケジューリングは決してせず、作る製品の質にも責任を持ちます。ミスがあれば、必ず自ら対応します。他人に責任を押しつけるようなことは一切しない、それがプロです。
P.S.
明日23日は我らがエンジニアリングマネージャーのunnoさんの記事です！
どんな記事が公開されるのか、今からとっても楽しみです！！(*´∀`*)ﾜｸﾜｸ
そして、noteに少しでも興味を持っていただいた方がいれば、ぜひ遊びに来てくださいヾ(o･ω･)ノ
noteでは新しい仲間を積極募集しています！
この記事が気に入ったらサポートをしてみませんか？