この記事は、Money Forward Fukuoka Advent Calendar 2024の12/18の投稿です。 12/17は hikari kobe さんで 異文化交流プログラム「TERAKOYA」に参加した感想でした。
はじめに
こんにちは、マネーフォワード クラウド経費（以下クラウド経費）でエンジニアをやっている、渡邊（わたしょー）です。
3歳の娘に日々遊んでもらいながら、子育ても奮闘中です。
私はマネーフォワードに参画して、Warriorグループ → Guardianグループでそれぞれ約1年勤務してきました。
本ブログでは、その2つのグループで経験したことを振り返ろうと思います。
WarriorグループとGuardianグループでやっていたこと
私は2023年3月にマネーフォワードに参画し、クラウド経費のWarriorグループに配属されました。
Warriorグループは主に新機能の追加開発を担当するチームで、私は明細カスタム項目の機能追加プロジェクトと、「明細カスタム項目」機能アップデートプロジェクトに取り組みました。
Warriorグループの中にもチームが存在しており、それぞれのチームごとにプロジェクトを担当しています。
それぞれのチームはプロジェクトの進行に責任を持っており、集中して開発に臨める環境となっております。
チームメンバー全員がプロフェッショナルであり、プロジェクトの成功に向けてプライドを持って日夜開発を行っています。
私はマネーフォワード参画前は違う業種にいたため、エンジニアのキャリアとしてはWarriorグループが初めてでした。
そのため、スピード感のある開発環境において、開発エンジニア1年生としてプロジェクトの進行を妨げないようについていくのに必死でした。
余談ですが、この時に尊敬するエンジニアの方に出会うことができ、勝手に心の中で師匠と呼んでいます。
そしてその約1年後、2024年2月にGuardianグループに異動しました。
Guardianグループではクラウド経費の運用・保守および改善を行っています。
運用・保守業務は一般的なものに近いですが、開発チームとビジネスサイドとの間に立ったコミュニケーションを重視しており、仕様調査や改善活動も行っています。
前期（2024年6月）より「攻めの運用」「守りの運用」といったGuardianグループ独自の概念を取り入れ、よりDevOpsを体現することを目指しています。
「攻めの運用」は、機能改善やパフォーマンス向上など、将来の問題を未然に防ぐためのタスクです。
「守りの運用」は、既知の不具合修正や障害対応など、既に発生している問題に対処するタスクです。
以下のブログにより詳細なことが記載されているので、興味ある方はこちらもご覧ください。
それぞれのチームのタスクの進め方について
Warriorグループ
Warriorグループはスクラム開発を採用し、2週間のスプリントで以下のイベントを行っています。
進捗はデイリースクラムで確認します。
- プロダクトバックログリファインメント
- プロダクトバックログの作成
- プランニングポーカー
- スプリントレトロスペクティブ
- スプリントレビュー
- スプリントプランニング
スクラムを通じてタスクをこなすことは新鮮で、多くの学びがありました。
プロジェクトに途中参加した新人エンジニアとして、難しいタスクは少なかったものの、周囲のサポートのおかげで日々のタスクをこなすことができました。
Guardianグループ
Guardianグループは日々、ビジネスサイドからくる問い合わせに対して技術的な調査・対応を行いつつユーザーの課題を解決していくことを主なタスクとしています。
問い合わせの範囲はサービス全般に渡るため、クラウド経費の機能や動作を広く理解することができました。
Warriorグループでは特定の機能に対して仕様理解を深めることはありましたが、Guardianグループではサービス全体の理解が求められるため、幅広い知識を身につけることができました。
また、ビジネスサイドとのコミュニケーションが多いため、日々の問い合わせのなかでサービスの改善点・要望をまとめ中小規模の機能追加や、開発生産性や業務効率を上げるような内部改善を行っています。
ライブラリの更新も担当し、サービスで使用されているライブラリの理解を深めています。
各グループを経験してみて
一つのサービスの異なる性質を持つグループに所属した私が、今までに経験したことをそれぞれのグループでどのように活かせるかを考えてみました。
GuardianグループからWarriorグループに活かせること
1つ目にタスクを小さく分割して進めることです。
サービスに変更（新機能の追加・既存機能の改修）が入った時に考慮漏れによって意図しない挙動や、インシデントが発生することもあります。
一度に大きい変更を加えてしまうと影響範囲が大きくなり、その影響範囲に比例してリカバリー作業のコストも大きくなっていきます。
Guardianグループはその影響範囲をいかに狭めるかを観点に入れ、変更を加えていくことが求められます。
小さく徐々に変更を加えることで、何かあった時の対応を最小限に留めるということをGuardianグループで学びました。
この考えをWarriorグループで取り入れるならタスクを小さく分割し、レビュワーの負担を小さくすることでタスクを完了させていきたいと考えています。
2つ目に、影響の範囲を考慮した機能を設計することです。
Guardianグループではサービスの機能全般を対象に問い合わせを受けるため、変更を加えようとしているコードがどこに影響を及ぼすのかがある程度予測できるようになりました。
この観点を活かして、特に影響範囲が大きそうな変更箇所についてはいつも以上に慎重にアプローチすることで、より安全に、かつ効率的に開発を進めることができると思います。
3つ目に、運用・保守を考慮した設計・実装を行うことです。
処理が失敗しないよう腐心することは大前提として、もし何らかの処理に失敗した時や障害が発生してしまった時のことを想定し、リカバリーが容易かつメンテナンス不要な仕組みを考慮して、設計に反映させることができると思います。
例えば、以下のような対策を実施できると思います。
- 例外処理の適切な実装: システムに予期しないエラーが発生した場合も動作を継続できるように、例外処理を適切に実装しユーザーへの影響を部分的に留め、システム全体が停止しないような実装を行いたいです。
- ログの出力: 障害発生時に該当箇所のログを出力する仕組み作りを行い、迅速に原因特定できるような仕組み作りを行いたいです。
- 自動リトライ機能: バッチジョブのような大量データ処理の際に、一時的なエラーで停止させず自動的なリトライを行う仕組みやもし適切に処理できなかった場合でも原因が特定できるようなログ出力の実装を行いたいです。
- 負荷を考慮した実装: システムへの負荷を考慮したアルゴリズムやキャッシュの利用を行い、より高いパフォーマンスを実現できるように実装したいです。
- 詳細なドキュメント化: システムの仕様や設計をドキュメント化し、誰でも問い合わせや不具合が発生した箇所に対応できるようにしたいです。
- データ不整合の解決策: データ不整合が発生したときに、ビジネスサイドで解決できる仕組み作りを行いたいです。例えば、データの修正ツールの提供や不整合箇所を確認できるようにすることで、ビジネスサイドで迅速に解決しユーザーのビジネス停止時間を短くすることができます。
WarriorグループからGuardianグループに活かせること
1つ目は、Warriorグループでプロジェクトに集中して取り組んだ経験から、その分野の仕様を深く理解できていることです。
この知識は、その分野での問い合わせに対するアドバンテージとなります。
すでに仕様を理解した状態から改修を始められるので、他のエンジニアに比べて変更にかかる時間が短くなると考えています。
2つ目は、Guardianグループでの「攻めの運用」にスクラムを取り入れたタスクの進め方を採用できる可能性です。
Guardianグループでは今後、攻めの運用という概念を用いてサービスの改善タスクを積極的に行っていく予定です。
しかし、現状では差し込みの問い合わせが入る都合上、Guardianグループではアジャイルな開発形式は取り入れられていません。
グループメンバーそれぞれが改善するべきタスクを見つけて日々の改善を行っていますが、グループメンバーの総意を元に戦略的なアプローチができているかというと、部分的に不足している点があると思っています。
その解決策として、改善タスクの管理とふりかえりにスクラム開発の手法を取り入れることで、社内顧客であるビジネスサイドに対して、より効果的な機能改善を提供できると考えています。
そして最終的なゴールとして、ビジネスサイド単体で解決できる領域を増やしてよりスピーディーにお客様の課題を解決できれば、結果的にサービスの質が向上していくと思います。
攻めの運用をもっと加速させていくためにも、スクラム開発を取り入れてもよいのではないかと考えています（もちろん差し込みを考慮したベロシティの算出など必要あると思いますが）。
今後Guardianグループでやっていきたいこと
今後、Guardianグループでは「攻めの運用」にさらに力を入れていきたいと考えています。
例えば、社内顧客としてのビジネスサイドの中で問題を解決できるような仕組みを開発する、問い合わせが起きにくい仕組み作りを進めるなどです。
また、運用上問題となるパフォーマンスの改善や障害発生時に素早く対応できるような仕組み作りなど、現在のクラウド経費がもっと前に進むために、多くのことに取り組めるフェーズです。
Guardianグループはサービスを見る範囲が広く、積極的に改善点を見つけリファクタリングしたり、リリース後に発覚する不具合を未然に防ぐ仕組みを作ったりすることができると考えています。
こうした「攻めの運用」という概念を取り入れ、よりDevOpsを体現するグループとして、私個人としても、もっと様々なことに取り組んでいきたいと思います！
マネーフォワード 福岡開発拠点では、エンジニアを募集しています！
Guardianグループでは運用・保守だけでなく開発にもコミットしています！
興味を持っていただけたらぜひ来ていただきたいです！
福岡開発拠点のサイトもあるのでぜひご覧ください！
明日12/19の記事は Shingo Kobayashi さんです！
