こんにちは、READYFORでVP of Engineeringをしているいとひろです。
先日2020年2月16日（日）に開催されたObjected-Oriented Conferenceにて、ランチスポンサーとして登壇してきました。
ランチセッションでは、「READYFORにおける複雑なドメインとレガシーシステムとの戦い方」 と題してお話ししました。
今回のブログでは、こちらの発表の要点をスライドに併せてお伝えできればと思います。
我々は、「誰もがやりたいことを実現できる世の中を作る」というビジョンのもと、「想いの乗ったお金の流れを増やす」というミッションを持ってサービス開発に挑んでいます。
READYFORは2011年に日本で初めてのクラウドファンディングサービスとして開始以来、約9年間サービス運営をしてきています。
そして、昨年のリブランディング/CIリニューアルを経て、クラウドファンディングの枠をこえた「想いをつなぐ金融機関へ」の変化を遂げようというチャレンジの真っ最中です。
では、本セッションの題名にあるREADYFORにおける「複雑なドメイン」とは一体なんなのでしょうか。
READYFORのクラウドファンディングサイトを覗いてみると、一見普通のWebサービスのように見えます。どこにドメインの複雑さが隠れているのでしょうか。
ここでは、トップページに複数回現れる「プロジェクト」という概念を起点に追ってみましょう。
READYFORのWebサイトを訪れるユーザーのペルソナとしては、大きく分けて「プロジェクト実行者」と「プロジェクト支援者」がいます。
実行者がプロジェクトを始めてから、支援者がプロジェクトを探して支援するまでの、「プロジェクト」のライフサイクルは、Webサイトの裏側に潜む「READYFORシステム」の中に存在しています。（正確にはプロジェクトを探して支援した後にもライフサイクルは続きますが、ここでは簡単のため省略しています）
「READYFORシステム」の中身はさまざまな条件に基づく状態遷移を持つワークフローが複雑に絡み合っており、BPMNと呼ばれるモデリング記法で可視化を試みてもなかなかすぐに理解するのは難しいものになっています。
「プロジェクト」という概念は、READYFORのシステム上でさまざまなコンテキストで扱われます。
READYFORはサービス開始以来約9年間運営し続けており、「プロジェクトという概念」がさまざまなコンテキストで少しずつ育った結果、
「プロジェクトという概念」は3700行に及ぶ、巨大なモデルとして成長しました。
こういった巨大モデルが育ってしまうケースはよく聞く話かなと思いますが、こちらのスライドに挙げているような問題点が挙げられます。
正しい責務分割をするための設計の前段階として、ドメイン駆動設計（DDD）でいうところの「境界づけられたコンテキスト」という概念があります。
READYFORは現在モノリシックなRuby on Railsのサービスとして実装されていますが、コード上には現れていない、本質的に存在しているであろう境界づけられたコンテキストを理解するために、大きく分けてSoE（System of Engagement）、SoC（System of Control）、SoR（System of Record）の3つの枠の中に当てはまるコンテキストに分けて整理していこうと考えています。
ここで少し横道にそれます。
SoEやSoRはアーキテクチャー設計をする上でよく知られている概念ですが、SoCは聞きなれないかと思います。実際Chatworkのかとじゅんさんからも以下ような疑問をいただき、Twitterのリプライで補足させていただいたのでご参照ください。
ありがたいつっこみです！当日は10分しかなかったので細かい話はできなかったのですが、System of Controlの出典はこちら↓で、READYFORではもう少し単純化した概念（BPMNで表現されるようなワークフローに相当するレイヤー）として使っています。https://t.co/ye0VwlrCD1
— いとひろ@READYFOR (@itohiro73) February 24, 2020
READYFORにおける業務ワークフローレイヤを表現するときにSoRって呼ぶのはちょっと違うなーと思ってたときに、リンク先のReference Architectureにあったここのレイヤーがちょうど良いモデルだったので拝借した次第です。 pic.twitter.com/Y0vnhG6qSg
— いとひろ@READYFOR (@itohiro73) February 24, 2020
さて、境界づけられたコンテキストを整理していくことで、プロジェクトモデルの責務分割を進めていくための前準備はできそうです。
しかしながら、スタートアップにつきものですが、開発リソースは限られています。われわれは「想いの乗ったお金の流れを増やす」ための新規開発をしていきたいわけなのですが、今このようなプロジェクトモデルの責務分割を進めるためのコストを支払う必要があるのでしょうか？
そこで、ビジネス観点としてのコストベネフィットを説明するために、「技術的負債」という概念の説明を試みます。
「技術的負債」の概念は、もともとウォード・カニンガムがリファクタリングの概念を上司に説明するために導入した概念です 。
この概念を拡張して、技術的負債をバランスシートで表現すると、「ソフトウェアの価値」として表層に現れるものと「技術的負債」というエンジニアにしか理解しがたい概念を説明するのに役立つと考えました。
上のバランスシートで「ソフトウェアとしての価値」の一部として組み込まれているように、「技術的負債」は必ずしも絶対悪ではないということは理解しておかなければいけません。
われわれが「技術的負債」と呼んでいるものも、READYFORの歴代エンジニアたちがその時々でベストを尽くした汗と涙の結晶なので、敬意と感謝の念を持って対処していきたいと思っています。
大事なのは「技術的負債」「技術的純資産」の特性を理解することです。
「技術的負債」に比べて「技術的純資産」が多い場合、最初に生み出すソフトウェアの価値は比較的小さくなりますが、時間軸に沿っての成長のスピードは大きくなります。
対して、「技術的純資産」に比べて「技術的負債」が多い場合には、初期に生み出す価値は大きくすることが可能ですが、時間軸に沿っての成長スピードは逓減していってしまいます。
では、技術的負債が貯まってしまった場合には一体どうすれば良いのでしょうか。
そこで、リファクタリングという概念が登場します。
リファクタリングは、「ソフトウェアの価値」を変化させることなく、「技術的負債」を返済して「技術的純資産」に変換することに例えることができます。これによって、その後の開発スピードに加速をつけることができます。
つまり、今後のスピーディーな成長を支えるためにも、リファクタリングは非常に重要な戦略の一つとなっていきます。
READYFORでは複雑なドメインを扱うため、ドメインエキスパートとの対話を大切にする ドメイン駆動設計 をリファクタリングの軸に添えたいと思っています。
さて、READYFORでは非エンジニアがBPMNのモデリングツールを駆使して業務ワークフローを可視化するなど、エンジニアとドメインエキスパートが対話できる土壌は育っています。
あとは、一緒に推し進めていく仲間が必要です。
このセッションでは、戦術的設計や実装など、詳細の話はしませんでした。
なぜなら、当日セッションを聴いている方に、そして今このブログを読んでいる あなた に事例をつくっていっていただきたいから。
ということで、READYFORでは複雑なドメインの再設計とリファクタリングを一緒に推し進めてくれる仲間を大々々募集しています。
という話をしてきました🤗
楽しんでいただけたら嬉しいです。
セッションでもお伝えしたように、READYFORでは各種ポジションで エンジニア大募集中 なので、興味を持った方はぜひご応募ください。
新しいお金の流れを作る、リードバックエンドエンジニア募集！ - READYFOR株式会社のWebエンジニアの求人 - Wantedly
新たな資金流通エコシステムの基盤をつくる、SoRエンジニア募集！ - READYFOR株式会社のWebエンジニアの求人 - Wantedly
資金調達の新たなスタンダード、READYFORフロントエンドエンジニア募集 - READYFOR株式会社のWebエンジニアの求人 - Wantedly
急成長中のベンチャーで品質管理をお任せする、一人目のQAエンジニア募集！ - READYFOR株式会社のWebエンジニアの求人 - Wantedly
スライドはこちら
当日のセッションの様子はこちらのTogetterにまとめられています。
Object-Oriented Conferenceは、最初から最後まで非常に興味深いセッションが目白押しで、非常に密度の濃いイベントでした。運営の皆さま、登壇者の皆さま、素敵な1日を本当にありがとうございました！
