開発フェーズでの取り組み
新卒しかいないチームではコード品質に不安があったので、初期フェーズではシニアエンジニアにレビューしてもらいました。なぜそのクラス設計・実装にするのかについてはZoomで何度もミーティングを開き、言語化していきました。
言語化することで設計・実装方針のベクトルが同じ方向を向き、レビューにかかる工数を減らすことができたと思います。開発で最も苦労したのはEKSもAWSもあまり触ったことのないサービスチーム自身で行うインフラ環境構築でした。
今までインフラチームが担当していた領域を、サービスチームが学習して自分たちで構築、メンテナンスを可能にしなければ、マルチAWSアカウント/マルチテナントEKSのメリットを最大限に享受することができません。
インフラ領域の学習は、既に多くの手順書が作成されていたのでそれらも読みつつ、多くはインフラチームにZoomでサポートしてもらいながら進めました。大量のインプットが必要で大変な時期でしたが、そのおかげで現在はインフラーチームにほとんどエスカレーションすることなく、運用やAWSリソース追加、Kubernetesマニフェスト修正を行えるようになっています。
未経験だったインフラ環境構築は、サービス自体の開発よりも後のフェーズで着手し始めたのですが、開発の早い段階で本番/検証環境まで構築しておくほうがコスパが良いと今では考えています。
本番/検証環境を用意していれば、ビジネスサイドやQA、ユーザーに開発中の機能を実際に触ってもらえるため、フィードバックをもらいやすくなります。開発サイクルの早いタイミングでバグやUI修正に気づくことができれば、その分手戻りコストを抑えることができます。フィードバックサイクルを高速に回すためにも、最新の開発状況を簡単に確認できる状態を作っておくと良いです。
開発から運用までを通して感じたメリットとデメリット
組織の成長に合わせてスケールするインフラ構成やサービス構成は、マイクロサービス化をともない、逆コンウェイの法則により、チームの分割と権限移譲が進み、多くのポジションを生みます。ポジションは人を大きく成長させ、私自身もリーダーを経験することができ、視座が上がってマネジメントへの興味や組織に対する貢献意欲が向上しました。
また、影響範囲がマイクロサービスの中に限定されるので、社内で導入実績のなかったNginxの機能を採用できたほか、技術的なチャレンジも行いやすく、構成メンバーが新卒のみでも要素技術を学びながらサービスをリリースすることができ、成長環境としてマイクロサービスはとても良いと感じました。
対策や注意が必要だと感じたことも何点かあります。1点目は、どのような境界づけられたコンテキストでマイクロサービスに切り出すかの議論が重要だということです。マネーフォワードで扱うファイルは電帳法対応すべき請求書や領収書だけではありません。
CSVエクスポート/インポートで使うCSVファイルやバックアップ用ファイルなど電帳法と関係ないファイルも数多くあります。汎用的なファイルストレージにするか電帳法特化のストレージにするかで大きく設計思想が変わってきます。
クラウドBoxでは、電帳法対応ファイルを保存するというのは、それ単独で1つのマイクロサービスに切り出す意味があると判断して、電帳法特化ストレージとして開発を進めています。
2点目は、エンジニアの考え方をマイクロサービス思考へと変えていく必要があるということです。モノリシックなアプリケーションと違って、データの同期や特定のマイクロサービスが落ちた場合のサービスの可用性に関して新たな知見が求められます。また、監視やモニタリング体制は複数のサービスから情報を吸い上げて統合的に分析する必要があり、タグ付けのルールなど今まで以上に厳格に定めないと、適切にマイクロサービスの全体の状況をつかめません。マイクロサービスに関する知見を輪読会や勉強会を通して高めていく必要があります。
3点目はマイクロサービスチームを開発するスモールチームでは時間的かつ精神的に余裕がないと少数のパワープレーになったり、特定の技術領域ごとに担当が分かれてしまったりすることです。主要人物が体調不良や退職でチームから抜けてしまうと、一気にチームの体制が崩れてしまい、オンコール体制も含めたマイクロサービス全体の可用性や信頼性がとても低い状態になります。私のチームでは、モブプロや仕様整理会、レトロスペクティブなどで知見共有・技術力向上を目的とする時間を確保して属人性を減らす仕組みを導入しています。
最後に4点目は、策を講じないとスモールチームはコーディング力の成長が一定レベルで鈍化してしまうことです。コードレビューを通した成長はもちろんありますが、長期間同じメンバーかつ少人数でレビューしていると段々と指摘事項が減っていき、成長を感じられなくなります。新しい技術を学ぶこと自体も、全員が未経験だとどうしてもハードルが高くなりがちです。良くも悪くも情報やスキル共有がチーム内に閉じてしまうのです。
対策としては、チーム間留学などを通してスキルトランスファーを行うことが効果的だと考えており、実際に私たちも他チームへ留学してフロントエンド技術を学びました。ビジネス自体が成長すれば、マイクロサービスチームへ新しいメンバーが入り、アーキテクチャーを変更する必要が出てきて、自動的に新しいことを学ぶ環境になります。ビジネスの成長もまた成長環境には欠かせないポイントです。
最後に
スケーラブルな開発組織を目指す取り組みの一環で整えられたマルチAWSアカウント/マルチテナントEKS環境とアカウント基盤を用いて開発した「マネーフォワード クラウドBox」のプロジェクト発足から運用までを通して、現状のマネーフォワードの開発プロセスやその中で出てくる意思決定、課題について紹介しました。
マルチAWSアカウント/マルチテナントEKS環境とアカウント基盤のおかげで、マネーフォワードのサービス開発チームは、ミドルウェアや実行環境で利用する技術は何の縛りもなく適材適所での判断で選定できるようになりました。インフラのサポートチームやGo推進グループの誕生で今までRuby on Railsしか触ったことのない技術者でも新技術に挑戦できる環境が整いました。
スケーラブルな開発組織を目指すと結果的にスモールチーム・マイクロサービス構成になり、多くのリーダーポジションが生まれ、開発者が成長できる環境を作ることにもつながります。影響範囲がマイクロサービスに限定されることで、技術的にも挑戦しやすい環境となります。
一方で、マイクロサービス独特の考え方や注意点を学ぶ必要があります。スモールチームでインフラからフロントエンドまでメンテナンスする必要があるため、開発者一人ひとりがよりフルスタックに学習する必要も出てきて学習コストが高くなります。そしてスモールチームは良くも悪くも情報やスキル共有がチーム内に閉じてしまい、成長の鈍化につながります。ゆえに学習サポートやチームを超えた情報共有、継続的な成長へのコミットは意識的に行っています。
クラウドBoxプロジェクトのリーダーはプロジェクト初期メンバーでもある同期に任せ、現在私はアカウント基盤のプロジェクトリーダーを担当しています。アカウント基盤を作ってサービスを作った知見を生かし、より使いやすいアカウント基盤を作ること、そしてドキュメント整備、エラー検知モニタリング体制、開発スピードなどマネーフォワードを代表するマイクロサービス運営体制を作ることを次の目標にしています。
本連載がみなさんの組織で何かのお役に立てば幸いです。