技術的負債との戦い、マイクロサービスとアジャイル開発への挑戦

長年愛されているサービスは、機能の拡張に伴い技術的負債をどうしても抱えてしまいます。このような背景から開発生産性をどの様に高めるかに関心が集まっている時代です。クラウドをうまく用いることで、どの様に技術的負債を減らしながら高い開発効率を得られるのでしょうか ?

今回は、AWS の体験型ワークショップ [1] を通じて、まさにその変革に挑戦した弥生株式会社の皆様にお話をお伺いいたしました。マイクロサービスアーキテクチャへの分解をなぜ行ったのか ? なぜアジャイル開発に変更したのか ? お話を掘り下げて伺えればと思います。想定する読者は以下の方々です。

1. これからクラウドネイティブへの挑戦をしたい技術者

2. アジャイル開発に挑戦したいプロジェクトマネジャー / スクラムマスター

3. 開発生産性の課題に悩みを抱える事業責任者

[1] : 体験型ワークショップは、AWS が提供する Experience-Based Acceleration (EBA) のModernization party を指します。

* 実際の体験の様子は 弥生開発者ブログ をご覧ください。

X ポスト » | Facebook シェア » | はてブ »

AWS Aska「まず今回対象になった SMART (正式名称、YAYOI SMART CONNECT) プロジェクトの課題を教えてください。」

安井氏「SMART は 2014 年にサービスを開始し、たくさんのお客さまにご利用いただいています。2018 年に大規模なリファクタリングを行いましたが、度重なる機能追加によってシステムは肥大化していき、メンテナンス性が損なわれている課題がありました。また会社として変化の激しい会計市場に対して、柔軟な対応ができる体制にする必要性もありました。今回の取り組みでは、システムを構成する機能ごとの責務を整理しつつマイクロサービス化、デプロイの自動化、アジャイル開発への取り組みと、よくばりな挑戦することに決めました。」

AWS Aska「そこで今回体験型ワークショップを利用していただいたということですね。」

牛尾氏「はい。AWS さんにはまず現状のサービスを評価いただきました。これをもしマイクロサービスアーキテクチャに持っていくとしたらどのような形が理想的か ? 複数パターンで提示してくれたり、CI/CD やコンテナなどの分野ごとに詳細の説明があったりと、非常に具体的でした。良い意味で想定外でしたね。」

AWS Aska 「まず技術観点の挑戦から伺わせてください。今回こだわった点はどういったところでしょうか ?」

牛尾氏「2 点ありまして、一つ目はマイクロサービス化による SMART 解体、そしてもう一つはクラウドの良さを活かした開発生産性の向上です。」

AWS Aska「現行の SMART が抱えていた問題とはどういったところなのでしょうか ?」

牛尾氏「SMART の役割は、外部サービスなどから仕訳化するための取引情報を取込み、会計システムに受け渡すことです。会計システムは SaaS サービス (弥生会計オンライン) と Windows ネイティブアプリケーション (弥生会計) の 2 つのサービスが存在します。同じ会計のサービスですがデータ構造や仕様は異なるため、SMART がその差異を吸収する役割を持ち、非常に密結合になっている状況です。ですので SMART の未来を考える上で、この密結合から脱する必要がありました。」

AWS Aska「具体的にはどのようなことを行なったのですか ?」

牛尾氏「改めて SMART の責務の分解と、各サービスが持つべき責務の移管を行いました。新しい SMART に求められる機能は、会計サービスだけに限りません。よって既存の SMART が持っている機能の独立性を高めて、個別利用できるようにしておく必要が出てきました。我々はチーム名として『解体屋』という名前をつけ、最終的に SMART という製品を無くすためのマイクロサービス化を始めました。」

小沢氏「今後様々なサービスに利用されることもあり、可用性やアジリティに対する要求が高まりました。可用性に関しては、例えば現行 SMART にはマルチ AZ やオートスケールのような仕組みはありませんでした。なのでこのタイミングでゼロからクラウドネイティブなシステムを検討・構築しました。」

AWS Aska「ありがとうございます。スケーラブルな仕組みづくりを改めて実現されたんですね。アジリティに関する課題はどのようなことがあったのでしょうか ?」

小沢氏「アジリティに関しても 2 つの課題がありました。まずは CI に関してです。現行にも Jenkins を用いた CI の仕組みはありましたが、Jenkins サーバーを用いていたため、サーバー管理負荷や手作業が発生していました。例えば、複数ジョブを流したり、リソースを増やす際には、手作業で設定変更していました。また、バージョン管理は subversion を利用していたのですが、コミットをトリガーにビルドタスクを流すと複数人のコミットが重なった際 CI が渋滞してしまうため、4 時間ごとの定期実行としていました。その結果、問題点がリアルタイムにわからず非常に非効率でした。」

AWS Aska「どのように解決されたのでしょうか ?」

小沢氏「GitHub と AWS Fargate を組み合わせることで解決しました。Github Actions のイベントを使うことで、Pull Request をトリガーに更新しています。このイベントを元に AWS Fargate が連動する設定になっているため、環境の再構築やオートスケーリングを容易に実現できるようになりました。」

AWS Aska「大変よくわかりました。牛尾さん、小沢さん、貴重なお話しありがとうございました。」

大塚氏「私からはウォーターフォールからアジャイル開発に移行している話をしたいと思います。今まではウォーターフォール開発に近いプロセスで開発をしていました。特に課題に感じていたのはリリースにかかる時間が長いことです。上流工程はリーダー、実装をメンバーで進めていましたので、リーダーがいないと開発が止まってしまう課題が頻発していました。そこでアジャイル開発を導入し、各々が意思決定できる仕組みに変革しました。」

AWS Aska「アジャイル開発をやってみる前はどうでしたか ?」

大塚氏「不安だらけでしたね。まず実際にアジャイル開発を経験したメンバーはおらず、今までの開発プロセスからどう移行すればいいか、イメージが湧きませんでした。加えてリリース計画や開発対象も決まっていない状態だったので、全員何をすれば良いかわからず、全く手が動いていない状態でした。私自身もスクラムマスターとしての経験が乏しく、不安に拍車がかかりました。」

AWS Aska「どのようなところに不安がありましたか ?」

大塚氏「1 週間スプリントで実施したため、最初はスコープ、タスクを細かくする感覚に慣れませんでした。プランニングでの見積もりは、そもそも相対見積をする意味は何なのかなど、色々なことをメンバーと議論しておりました。またどうしても今までの開発プロセスが抜けず、要件定義、設計に時間をかけてしまい、そもそもスプリントが始まらない、などの失敗を経験しました。」

AWS Aska「それをどのように解決したのでしょう ?」

大塚氏「スプリントごとにレトロスペクティブ (振返り) をすることで改善しました。今までは開発中の改善ができなかったり、そもそも課題だったことを忘れてしまっていたので、そのスプリントをすぐ振返り、改善することは非常に学びが多かったです。レトロスペクティブを通じてチームが常に変化していく感覚を得られました。AWS の方にも改善のサポートに入ってもらいながら、少しずつレトロスペクティブの質も上げていけたと思います。

AWS Aska「改善へ向けた振り返りを繰り返すことで振り返りそのものの質も向上したんですね。」

大塚氏「他にも大きな挑戦をしました。一度設計開発からローンチまでのスプリントを作って、短期開発に挑戦しました。とても小さいスコープでしたが、実際に実装を進めていく中で、設計が足りない部分がわかったり、実装知識が足りず進められないなどがあり、うまく回りませんでした。この失敗経験がまさに大きな学びでした。最終的には効率的にスプリントを回すことができ、楽しんで開発をできたと思います。1 スプリントでスコープを定義し、サービスとして成り立つものをリリースできる様になりました。プロダクトバックログを元に、優先順位を明確にすることで、チーム全体で設計、開発、レビューが誰でもできるチームにもなれたと思います。当初課題であった、リーダーがいないと開発が進まないことは無くなりましたね。」

AWS Aska「ありがとうございます。今回の取り組みを通じて得られた成果があれば伺えますか ?」

安井氏「今回の体験型ワークショップを通じて、以下のような結果を出すことができました。技術的な課題に対しても For Keys をベースに数値的な改善が見られています。また、組織的な課題に対しても定性的な効果が見えてきたのかなと思います。」

AWS Aska「ありがとうございます。技術面、組織面それぞれでの改善を実現されてきたことがよくわかりました。今後の予定をお伺いできますでしょうか。」

小沢氏「現在、開発チームでは、AWS CDK を利用した IaC の整備も実施しています。IaC を CI/CD に組み込むなど生産性を上げる仕組みを積極的に採用し、変更を前提としたスピード感のある開発を推進していきたいと思います。」

牛尾氏「今回、チームとして大きな成功体験を得ることが出来ました。ただ良くも悪くも非日常的な体験であったため、今後もチームの文化として根付くよう継続と改善を繰り返していきたいと思います。」

大塚氏「今回はスクラム開発をどのように実施するかを学ぶことができ、良い点、難しい点を知ることができました。今後はよりチームに合ったやり方を考えながら、より効率的に、サービス開発、リリース、改善ができるようなチームになっていければと思っています。」

安井氏「まずは 2023 年秋に社内向けに機能を絞ってリリースします。その後も次々に機能をリリースしていく予定です。運用フェーズに入った後は、お客さまからのフィードバックや、FourKeys などの指標を取り込みながら、さらにアジリティの高い開発を目指します。」

弥生様は ”あなたの事業コンシェルジュ” として、会計という枠組みを超えた挑戦を始めた歴史の長い会社です。このような会社が既存の組織文化から変革することは非常に大きな挑戦です。しかし、弥生様はこの歴史の重みを乗り越え、クラウドネイティブな組織へと生まれ変わりました。

クラウドネイティブな組織に挑戦されている皆様、ぜひ AWS へとお声がけください。技術課題のみならず、組織課題の解決もお手伝いさせていただきます。