こんにちは、サーバーサイドエンジニアのいわむ(@k_iwamu)です。
社内のエンジニアが発端となり、Fammポイントサービスの負債解消合宿を行いました。
普段の業務も多くある中、どのような流れで負債解消合宿を行えたのか、また合宿という形で開催することで何が得られたのかを紹介します。
目次
Fammポイントサービスとは
我々が運営するサービスFammがあるのですが、その中に「Fammポイント」と呼ばれる、Fammの商品購入時に貯まり、商品注文時に利用できるポイントがあります。
ちなみに、最近ではFamm関連サービスを利用することでもFammポイントが貯められるようになりました 🎉 詳細はこちら。
Fammアプリや素敵なサービスのご利用もお待ちしています！
そして記事中の「Fammポイントサービス」とは、Fammポイントのデータを管理し、付与や失効操作を行うマイクロサービスのことを指しています。
合宿をやることになった経緯
私が所属している、FammアプリやFamm出張撮影、Famm年賀状など、既存サービスの保守運用を行うスクラムチームがあります。
先日Fammポイントサービスのテスト周りを整備したことがきっかけで、チームの振り返りで以下のようなことをつぶやきました。
もともとスモールスタートで始まったFammポイントサービスでしたが、マイクロサービスとして色々なドメインから利用されるようになってきましたし、Famm関連事業との重要なハブとしての存在にもなってきました。
よってシステム側も技術的負債の解消を含めたメンテナンスを定期的に行うことで、長期的に開発スピードを落とさず、運用コストをあげず、アプリの成長に追従できるようにしたいと考える方が多かったです。
また、「タスクデー」という約2週間に1度の頻度で各自で技術研究をしたりリファクタリングを行う日があるのですが、 チーム発足時に、個人ではなくまとまって作業に取り組む日を作っても良さそうという話もありました。
そういった話が重なり、スクラムチームのエンジニア3人でFammポイントサービス負債解消合宿を行うようになりました。
前日までの準備
合宿を行う理由や当日のスケジュールを考えまとめておく
1日xエンジニア人数分の工数をとるので、合宿の理由やることをPOと合意を取ったほうが良いですし、内容も詰めておかないとせっかくの機会や工数を無駄にしてしまいます。
ドキュメントを書き、チームやPOに共有やスケジュールの相談を行いました。
サーバーエンジニア全体で課題を洗い出すMTGを開催
サーバーエンジニアは各スクラムチームで活動しており、Fammポイントサービスを改修したり利用するマイクロサービスも作っています。そういった経験から思い当たる課題はないか、大きなことから些細なことまで洗い出す会を開きました。
MTGでは課題を口頭で軽く説明や質疑応答することで共有し、最後は優先度高く取り組みたいものを投票することで優先度を決めました。思っていた以上にたくさんの課題があがりましたし、エンジニア目線ではなく会計面でも課題を感じている方もおり、新しい発見が多かったです。
当日解決を目指す課題決め
課題を洗い出すMTGを経て、合宿で解決を目指すものを決めました。
結論、エラー設計とエラーハンドリングの課題を解決することにしましたが、以下のようなプロセスがありました。
取り組む課題を決める上で考慮することを決める
まずエンジニアの方々につけていただいた投票を参考にしつつ他に2点を考慮して課題を決めました。
- 単なる作業ではなく共同で取り組めるものか
- 単なる作業であれば合宿としてみんなを集める必要がないため
- 1日である程度区切りをつけられるものか
- 1日である程度区切りをつけられないとそのまま放置になってしまったり、背景などを思い出すのに時間がかかってしまうため
投票の結果から精査する
投票の結果、1番優先度が高いものはエラー設計とエラーハンドリングであり、次が会計監査周りの機能改修でした。
会計周りの機能改修も事情を聞くとすぐに解決したい問題だったのですが、1日単位で収まるものではなかったですし、有識者とさらに要件を詰める必要があったので、今回の合宿では行いませんでした。
その代わりPOを通じてPBLに乗せるようにしています。課題を発見できただけでもよかったです。
一方エラー設計では、エンジニアが集まって議論をしながら設計を考えることができますし、エラーハンドリングの実装を行うことでシステム側の知識が少ない方でも全体像を知ることができます。
エラー設計やエラーハンドリングの具体的な課題を深ぼる
エラー設計やエラーハンドリングの具体的な課題は以下の2点でした。
- 解決する必要のないエラー(e.g. APIクライアント起因のエラー)もslackに通知され、その度エラー原因を調査している。
- 適切なエラーメッセージが返されていない箇所がある(e.g. リクエストパラメータ不足なのにInternalServerErrorを返している)。
Fammポイントサービスはお金に関わるサービスなので、本当に修正が必要なエラーが埋もれてしまうと致命的ですし、 APIを利用するマイクロサービスも今後増えていく予想がされる一方で、適切なレスポンスが返されないと開発しにくくなってしまいます。
なので今回その課題を解決することにしました。また工数を考えて目標は以下の2つに絞って作業を行いました。
- エラー設計を行うこと
- 実際に課題のあるAPIを1つ修正することで、模範となるコードを残しておくこと
当日のスケジュール
当日は以下のスケジュールで行いました。
- 0.5h: アーキテクチャなどのレクチャー
- 2.0h: エラー設計の議論
- 4h: モブコーディング
- 0.5h: 振り返り
エラー設計の議論では、我々の他のサービスで行われているエラー設計を参考にしつつ、本当に必要なのかどうか深く考えて議論を進めていきました。
モブコーディングでは、3人が必ず1回はコーディングする側に立つことと、前のコーダーの改修と似たような実装はせずに新しい箇所をコーディングしていくことを意識して行いました。
また基本的に共同作業で疲労も溜まりやすいため、休憩もこまめに取っています。
当日の成果
目標にしていた、エラー設計とAPIの修正を両方行うことができました 🎉
直接的な成果であるエラー設計のドキュメントやAPIの修正は内部事情のためお見せすることができませんが、成果以外にも学びや収穫が多くありました。(詳細は下部の「振り返り」にて)
振り返り
最後に、発案から合宿当日までの振り返りを行いました。
いくつかピックアップします。
Good
課題をみんなが知ることができた
合宿前日に行ったFammポイントサービスの課題洗い出しMTGのおかげで、重要なサービスの課題をサーバーエンジニア全体が知ることができました。 今後エンジニアの誰かがFammポイントの課題を解決しうる技術を発見したり、他のサービスの実装時に同じような課題を踏まないような意識ができると思います。
チーム発端でイベントを開催する一例を作れた
普段我々が行う合宿は、全社で行う合宿や、CTOが発端となった開発合宿が多いのですが、 チーム発端でイベントを開催する一例を作れたことで、様々なチームがさらに自発的に動くようなきっかけになれたと思います。
みんなでまとまってモブコーディングや設計会ができたことで知見の共有ができた
合宿を行ったメンバーでも、Fammポイントサービスに対する知識や経験値もバラバラでしたが、モブコーディングを行うことで知見の共有や、Fammポイントサービスの全体感を理解することに繋がりました。 属人化を減らせたので、今後はみんなでお問い合わせの対応や、Fammポイントサービスの改修に素早く取り掛かりやすくなりました。 また、エラーに対する様々な角度からの視点を知ることができ、1エンジニア個人としてもよい経験になりました。
Issue
進め方や、やることの検討を深く考えておくべきかもしれない
前日までにアジェンダや解決する課題を決めておいても、1日の長丁場となると所々どうやって進めていくか曖昧になり、その場で進め方を議論することも度々ありました。合宿をより濃い内容で進めていくためにも、少し過剰なくらい詰めるところは詰めておいてもよかったかもしれません。
たたき台があったほうがいいかもしれない
エラー設計の議論ではスコープが大きくなったり、空中戦になってしまうことも度々ありました。
以前もサーバーエンジニアで他のサービスの設計を考える機会があったのですが、その時は参考資料をもとにして話を円滑に進められたので、今回もたたき台となる案があってよかったかもしれません。
今後
普段の業務でもやることはたくさんありますし、振り返りで話し合ったことは意識しつつも実行に移せないままで終わってしまうこともあると思います。 1日x人数分の工数を使うイベントを実行まで移すのは少し気持ちがいりましたが、チームの方々やPOが相談に乗ってくれることで内容も濃い合宿を行うことができました。
今回の合宿に限らず、サービスが良くなるであろう試みは自発的かつ定期的に行っていきたいですね。
PR
子育て家族アプリFammを運営するTimers inc.では現在エンジニアを積極採用中！ オンラインでの面談やカジュアルランチなどもやってますので是非お気軽にご連絡ください！
