READYFORエンジニアリング2020年の振り返りと2021年の展望

f:id:itohiro73:20201224200104p:plain

こんにちは、READYFORでVP of Engineeringをしております、いとひろ（ itohiro73 ）です。

本記事はREADYFOR Advent Calendar 2020の24日目の記事となります。

2020年を振り返ってみると、READYFORのプロダクト開発チームにとって大きな飛躍の年となりました。大きく分けて プロダクト 、エンジニアリング 、組織の3つの領域で大幅な進化を遂げることができたと思います。

プロダクトの進化

クラウドファンディングとしてだけではなく、基金として想いの乗ったお金の流れを増やすプラットフォームへ進化
支援者さん向けUX改善施策
実行者さんの利用する管理画面のリニューアル・スマホ対応
想いの乗ったお金の流れを支える入出金業務プロセスのシステム化・自動化
コロナ禍の需要増で直面した処理限界への対応・改善

エンジニアリングの進化

技術的負債への対応の第一歩としてREADYFORが扱う複雑なドメインを境界づけられたコンテキストに沿って概念を分割
- READYFORにおける複雑なドメインとレガシーシステムとの戦い方
モノリシックなRailsアプリケーションを、フロントエンドとバックエンドが密結合な状態から、実行者管理画面・支援導線の機能を一部Next.js/Netlify/React/TypeScriptを用いたSSGとして分離し、疎結合化
サービスがスケールしていくためのコンテナ基盤としてECS化も同時進行
- GitHub Actions を利用しての ECSのBlue/Greenデプロイとトラフィック切り替え前テストを実践
e2e自動化のためにAutify導入。リリース前の動作検証コストを大幅削減
- Autify と Datadog BrowserTest を比べてみた

組織の進化

乳化（エンジニアリングが組織全体に溶け込んでいる状態）を大切にする価値観の全社的な共有
職能組織組織単位でのチームOKR設定から、ミッション単位で構成されたSquad体制でのSquad OKR設定へ移行
1年間でプロダクト開発チームの規模が倍増！
- 2020/1/1 時点: プロダクト開発メンバー14人（業務委託含む） => 2020/12/24 時点: プロダクト開発メンバー27人（業務委託含む）
- 2021年にはすでに計6人のPdM・エンジニア入社が確定 🎉

本記事では、これら3つの領域の進化の中でも、エンジニアリングの進化についていくつか深堀りしていきたいと思います。

技術的負債と向き合い、プロダクト開発にスピードをもたらす

今年2月のOOC（Object Oriented Conference）にて、技術的負債についてのお話をしました。

f:id:itohiro73:20201224154205p:plain

f:id:itohiro73:20201224154228p:plain

f:id:itohiro73:20201224154244p:plain

f:id:itohiro73:20201224154257p:plain

READYFORは9年半の長い歴史があるサービスであり、READYFORの先人たちが築き上げてきたレガシーシステムにリスペクトを持ちつつも、複雑なドメインを再設計し、更なる成長のためにリファクタリングをしていく必要があります。

READYFORは歴史的にモノリシックなRailsアプリケーションとして開発されてきたのですが、リファクタリングの第一歩としては、密結合になってしまっているフロントエンドとバックエンドの疎結合化が第一優先であると考えました。

疎結合化に取り組む前は、READYFORのフロントエンドは、React on Railsを用いてRails上にReactのViewコンポーネントが乗っかっているような構成でした。さらに一部の支援導線の機能においては画面の状態遷移にまつわるコードがバックエンド側に埋め込まれてしまっており、フロントエンドの改修をするにしても身動きが取りにくい状態となっていました。このままではプロダクトに価値をもたらすような仮説検証のような開発もバックエンド開発に大きな依存が生じてしまい、なかなか難しい状態です。

そんな中、実行者の管理画面のUXを改善するプロジェクトが立ち上がり、同時並行的にフロントエンドのSSG化（Next.js/Netlify/React/TypeScript）と、バックエンドRailsのAPI化を推し進めることができました。これにより、実行者プロダクトの領域ではフロントエンドとバックエンドが完全に疎結合化したモダンな構成の管理画面ができあがりました。

また、先ほど挙げた状態遷移がバックエンドコードに埋め込まれてしまっていた支援導線も、同様の構成で現在絶賛開発が進められています。

併せてバックエンド側の支援導線のAPIをコンテナ化してECSに載せることで、スケーラビリティ向上に向けての第一歩としても位置付けています。

f:id:itohiro73:20201224164138p:plain — フロントエンド・バックエンド疎結合化

リファクタリングのお供にAutifyのe2eテスト

上記のような技術的負債の返済・リファクタリングを安心安全に行っていくためには、改善前と改善後の動作検証でリグレッションがないことを確認することがとても大切です。そのためにも昨日のあふらっかさんのアドカレ記事にもあったAutifyでのe2eテストが非常に有用です。

4月頃から検証・導入を進め、今ではリリース前の動作確認としてAutifyのe2eのシナリオをまわすことで少ない工数で安心安全を担保することができるようになっています。

このような、技術的負債の返済・リファクタリングをスピーディーに攻めていくための守りのエンジニアリング施策も足元固めとして進めていくことができました。

f:id:itohiro73:20201224200505p:plain

ちょうどAutify CEOの近澤さんも昨日の記事に反応してくださっており、新しく提供される機能を通じてAutifyをAPI経由でCIに組み込んだりと、より開発サイクルに自然に組み込まれた形で活用していけるのではないかとワクワクしております。

おおお！ありがとうございます！API、webhookもありますよ！https://t.co/FxhRW8XyBN
— Ryo Chikazawa | Autify CEO (@chikathreesix) December 24, 2020

ありがとうございます！
> テストプランの直列・並列実行を設定
これは実装の予定があります。
> それを外部から叩け
上記ができれば、test plan idを指定してPOSTしてもらえればOKです。
> その進行状況も取得できる
これは現在のGET /results/idで出来ます！
— Ryo Chikazawa | Autify CEO (@chikathreesix) December 24, 2020

もしかしたら、直列並列の設定ができれば解決します？？
— Ryo Chikazawa | Autify CEO (@chikathreesix) December 24, 2020

ありがとうございます！解決するように思います。あとそれらが同時実行されないような制御と実行結果の取得・通知ができるととても嬉しいです！
— Kuman (@KUMAN_R) December 24, 2020

READYFORでの境界づけられたコンテキストの整理とコアドメインの抽出

さて、フロントエンドとバックエンドが少しずつ疎結合化されていく中、この先どのように技術的負債を返却して開発生産性を上げていけば良いでしょうか。

ここの整理・理解のためにも、READYFORのプロダクト全体の概念を、境界づけられたコンテキストごとに分け、それぞれのコンテキストでコアとなるドメインを抽出しました。

f:id:itohiro73:20201224021908p:plain — READYFORの境界づけられたコンテキスト

それぞれのコンテキストでは必要とされる技術特性も、意識するべきドメインモデルも変わってくるため、それぞれのコンテキストにおいてより詳細なドメインの理解と設計・開発を推し進めていく必要があります。

SoE（System of Engagement）とよばれる、ユーザーが直接触る領域では、フロントエンドとバックエンドの疎結合化が如実に効いていきます。フロントエンド側で独立して素早い仮説検証を回しやすくなっていくので、今後はグロース・新規開発ともに開発生産性が高い状態でプロダクトの価値を届けていくフェーズに移行していくことができるのではないかと考えています。

f:id:itohiro73:20201224022012p:plain — SoE（System of Engagement）

READYFORでSoC（System of Control）と呼んでいる、業務ワークフローや審査のワークフローを司るアプリケーションの領域では、より複雑な状態遷移や条件分岐が存在しています。この領域は、実は現時点では技術的負債の返却にはまだ手付かずなのですが、ここはSoEとも非常に密に関連している領域でもあるため、より深いドメインモデルの蒸留を行っていく必要があります。こちらはエンジニア採用が進み組織が一気に拡大している中で、DDDのような設計・ドメインモデリング領域に強いメンバーも少しずつ参画が決まり始めており、2021年に力強く推し進めていけるのではないかという機運が少しずつ出てきております。

f:id:itohiro73:20201224022114p:plain — SoC（System of Control）

さらに、READYFORのお金の流れの根幹を担う、SoR（System of Record）という大切な領域があります。この領域での入出金にまつわる業務は、経理チームが管理画面やスプレッドシート等さまざまな情報を元にマニュアルワークをこなしてきた歴史的経緯もありました。しかし、今後の事業拡大期においては、堅牢さと柔軟さの両方を持ちあわせてスケーラビリティをしっかり担保していく必要があります。このSoRを担うシステムは、想いの乗ったお金の流れを増やすための心臓部であるため、 READYFOR HEART と名付け、2020年はこの領域のシステム化・自動化の開発を一気に推し進め始めてきました。こちらのREADYFOR HEARTもコンテナ化・ECSの初期事例として運用していく想定で開発を進めています。

f:id:itohiro73:20201224022147p:plain — SoR（System of Record）

最後に「データ分析基盤」と呼ばれるSoI（System of Insight）ですが、こちらは事業運営に大切な動体視力を与える根幹を担う仕組みになります。READYFORでは乳化の一環としても、現場の様々なメンバーがRedashによるデータや可視化情報をもとにさまざまな意思決定を行っています。プロダクト開発においてもデータ分析を活用してデータドリブンな意思決定を今以上に推し進めていきたいと考えています。現時点ではまだデータドリブン思考が開発組織全体に浸透している状態とまでは言えないため、ここは2021年の取り組み課題として伸ばしていきたい領域でもあります。

f:id:itohiro73:20201224022226p:plain — SoI（System of Insight）

これらそれぞれの境界づけられたコンテキストにおいて、解決し始めている課題、まだまだ取り組めていない課題、それぞれ存在しています。2020年を通して、それぞれの領域での技術的負債の解消やドメインの整理が大幅に進んだことにより、READYFORビジネスの価値向上につながる課題解決に向かっていくための土台はつくられたと言って良いかなと考えています。