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

2023-10-03
ビジネス x クラウド

安井 浩二 (弥生株式会社), 大塚 匠 (弥生株式会社),
牛尾 哲朗 (弥生株式会社), 小沢 好光 (弥生株式会社)
池田 飛鳥

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

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

  1. これからクラウドネイティブへの挑戦をしたい技術者
  2. アジャイル開発に挑戦したいプロジェクトマネジャー / スクラムマスター
  3. 開発生産性の課題に悩みを抱える事業責任者

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

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


はじめに

AWS 池田 飛鳥 (以下 AWS Aska)
「本日はよろしくお願いいたします ! まず自己紹介させてください。Customer Solutions Manager として、お客様のビジネスを成長させることがミッションです。金融業界にて新規事業の企画・推進、通信業界にてデータ事業のプラットフォーム開発からサービス推進を手掛けていました。サービス運用経験を活かして、今後弥生様のお力になれればと思っています。」

弥生株式会社の安井 浩二 (以下、安井氏) です。

前職はシステムインテグレーターとして、オンライン銀行向けシステムの開発に従事していました。2017 年に弥生に入社後、子会社のオンライン融資事業の立ち上げに参画。現在は次世代開発本部 SMART 分割のプロダクトオーナーを担当しています。

弥生株式会社の大塚 匠 (以下、大塚氏) です。

前職は PdM として、ロボット SIer 向け Saas サービスの開発に従事していました。2023 年 4 月に PjM として弥生に入社し、次世代開発本部で SMART 分割プロジェクトチームで、スクラムマスターとして、スクラム開発を牽引しています。

弥生株式会社の牛尾 哲朗 (以下、牛尾氏) です。

パッケージベンダーに入社し研究開発および製品開発業務を経験後、2016 年に弥生入社。YAYOI SMART CONNECT やスマート証憑管理の開発を経験し、AI/ML に関するシステム開発や研究開発も牽引しています。

弥生株式会社の小沢 好光 (以下、小沢氏) です。

コンタクトセンター向けCRMや医療情報を扱うシステムの開発を行ってきました。弥生には、2023 年 3 月にジョインし、次世代開発本部 SMART 分割チームに所属しています。機能開発はもちろんのこと、CI/CD、IaC などを推進しアジリティの高い開発体制の構築に貢献しています。

AWS Askaありがとうございました。では、早速お話を伺っていきたいと思います。」


開発生産性に対する課題

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

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

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

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

弥生様 当初のアーキテクチャ
(クリックすると拡大します)

AWS による変更後アーキテクチャ案の一例
(クリックすると拡大します)


密結合から脱却し、マイクロサービス化を実現

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

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

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

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

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

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

観点 実施前 実施後
User Interface SMART が持っていた 独自 UI は各製品が持つことになった
機能 会計に特化していた 製品特化した機能は各製品がもち、SMART はより抽象化させた
Database 複数製品間で共有 機能単位
ソースコードリポジトリー 製品単位 機能単位
アカウント 複数製品で 1 つ 製品単位
サービス間通信 1 つの製品がメンテナンス時に、他の製品にも影響を与えてしまっていた メッセージングを用いて、製品間の独立性を高めた

開発生産性の向上

小沢氏「今後様々なサービスに利用されることもあり、可用性やアジリティに対する要求が高まりました。可用性に関しては、例えば現行 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 スプリントでスコープを定義し、サービスとして成り立つものをリリースできる様になりました。プロダクトバックログを元に、優先順位を明確にすることで、チーム全体で設計、開発、レビューが誰でもできるチームにもなれたと思います。当初課題であった、リーダーがいないと開発が進まないことは無くなりましたね。」

1スプリントで実装したCSV取り込み機能

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

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

内容 実施前 実施後
デプロイ頻度 1 回 / Day 4 回 / Day
変更のリードタイム 4 時間 オンデマンド
変更障害率 ローカル環境で単体テストを実行し、本番環境への反映をしていたため、結合試験で手戻りする事象があった。 CI/CD を整え、一気通貫でテストできるようになったため、手戻りの回数が減った
サービス復興時間 - ローンチ後に期待 !
アジャイルによる役割の属人化排除 シニアメンバーと若手メンバーで明確に役割が別れており、体制の薄い役割がボトルネックになりがちだった。 チームとして開発ができるようになり、若手 / シニアのような役割の属人性が排除された。
モブプログラミングによるコミュニケーションの活性化 シニアメンバーと新規メンバーのドメイン知識の差埋まらず、業務範囲を広げられなかった。 新規メンバーがドメイン知識を自然と吸収し、チームに溶け込めるようになった。

今後の取り組みについて

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

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

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

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

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


まとめ

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

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


builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者プロフィール

池田 飛鳥
アマゾン ウェブ サービス ジャパン合同会社 カスタマーソリューションマネージャ

データの力で世界を変えることを目指して、データを用いた事業開発を強みにしています。お客様のビジネス課題を解決することを仕事にしています。
趣味は鮎の友釣りです。日本一の友釣り師になれるよう日々奮闘中。

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する