READYFORは「誰もがやりたいことを実現できる世の中をつくる」をビジョンに掲げ、国内初のクラウドファンディングサービスとして、既存の金融サービス・資本主義ではお金が流れにくい分野、主にNPOや医療機関、研究分野、地域活性化などに資金調達の手段を展開。約2万件のプロジェクトに対して約200億円のお金を流している。
また、昨年は（公財）東京コミュニティー財団と共に「新型コロナウイルス感染症：拡大防止活動基金」を設立・運営し、国内クラウドファンディング史上最高額となる約8.7億円もの支援を集め、社会的な活動に助成分配を実施。クラウドファンディングの枠を超え、「想いの乗ったお金の流れを増やす」企業として、変化を遂げようとしている。
開発者たちは、この壮大なミッションを実現すべく日々どんな課題と向き合い、新たな価値を生み出す努力をしているのだろう。READYFOR株式会社で開発とQAを担当する、伊藤博志さん、石井麗子さんのお二人に話を聞いた。
― お二人はどのような業務を担当されていますか？
伊藤さん: 僕はREADYFORでVP of Engineering（Vice President of Engineering）をしています。2019年10月に入社した時点では、エンジニアが僕を入れて10人の小規模な組織でしたが、ここ2年弱ぐらいで25人にまで拡大してきました。その中で、QAも大事なミッションのひとつとして取り組んできました。
石井さん: エンジニアとして副業という形でジョインしました。事業をスケールアップさせていくためには、品質を落とさず、でも守りに縛られず攻めていけるような体制を作りたいということで、QAにも力を入れています。
— Autify導入前はどのような課題がありましたか？
伊藤さん: READYFORは2011年からスタートしたサービスで、僕が入ったタイミングは8年目でした。いわゆるスタートアップとして、少人数で技術的負債を少しずつ積み上げながら価値をあげる努力を続けて走ってきた――という8年間。
そして、クラウドファンディングだけでなくプロダクトの価値をアドオンして非線形の成長を目指すフェーズに入っていく中で、積み上げてきた技術的負債ときちんと向き合わなければならない問題意識がありました。
エンジニアが10人しかいない中で、足元を固めつつも新たな価値を生み出していくことと、技術的負債を返却すること、その両方を並行してやっていかなければならない。 技術的負債を返済するためには、なるべくデグレードが起こらない形でスムーズに開発をするのが大事だと思いました。
それまで、Railsのバージョンアップや、大掛かりなリファクタリングなどを行った際、エンジニアやプロダクトマネージャーが、膨大なシナリオをポチポチと確認して「これで大丈夫ですかね？」と不安がりながら工数を掛けてテストしていた日々でした。
このような状況では、人の工数がかかるばかりで、プロダクトの価値を見出すこともなかなかできなくなってしまう。この意味で、E2Eテストの導入が必要だという問題意識が背景にありました。
— 全社で品質やコストへの意識が高かったのは、お金を扱っているサービスであることが理由でしょうか？
伊藤さん: それもありますが、すでに積み上がっていた負債が、見えない形で全体を圧迫している状況にあったことが大きいです。
その技術的負債については、エンジニアリングサイドから全社に「今こういう状態です」とコミュニケーションしていたので、全体的にも意識は高まったように思います。
— 「技術的負債の課題」を経営陣に伝えるのは難しそうなイメージがあります。どのように工夫したのでしょう？
伊藤さん: これは経営陣のみならず全社的にですが、技術的負債の概念を、いわゆるバランスシートと対比して説明してみました。バランスシートならみんな分かる言語だし、技術的負債というワード自体もまさに「debt」に相当するものなので。同様の内容をObject-Oriented Conferenceでも発表しました。
ソフトウェアという全体の資産があった中で、一定割合の技術的負債というのが存在します。それ以外のところは「技術的純資産」と呼んで説明しました。 技術的純資産が多い状態であれば、時間軸で見ると、価値を高めるスピードが上がっていく。要は、ソフトウェアの全体の資産が増えていく傾きが大きくなるのが、この純資産の多い場合。
逆に技術的負債が多いと、スピードが遅くなります。負債自体は作るのがラクなので、最初に資産を上げることができます。その後、技術的純資産が多い割合に変えるとスピードが上がっていく、という説明をしました。
– 純資産を増やす活動も当然必要ですが、変えなくても負債の割合を減らせば純資産の割合が増えるので、開発スピードが向上していく。 とても分かりやすいです。技術負債を返却するためには、リグレッションテストのカバレッジや効率化も重要ですか？
伊藤さん: そうです。不安なままリリースして問題を起こしたくないので。
– 自動化するにあたって「まずはSeleniumでやってみよう」と考えましたか？
伊藤さん: もちろんその選択も頭の中にはありました。でもそもそもエンジニアの数が少ない中で、Seleniumを使ってゴリゴリ開発をするのは、逆にコストが掛かってしまうと考えました。Autifyは「こんなにいいものがある！」と渡りに船で見つけました。
エンジニア歴が長く、テストも自分でやってきた経験から言えることですが、E2Eテストはかなり壊れやすい性質を持っています。壊れやすいものにとって大事なのは、メンテナンスがいかに簡単であるかです。
壊れやすくメンテナンスも大変なら、そもそも使わないほうがいい。下手したら手作業でも頑張るほうがいい、くらいの考えでした。その点、Autifyは初めから「簡単に直せる」ことにフォーカスして作られていたので当然「それは使うでしょ」と。
– 導入までのプロセスを教えてください。
伊藤さん: もともと問題意識として、READYFORのQAを強化しなければという意識があって、石井さんに相談に乗ってもらっている中で、Autifyの話が出ました。
「Autifyを導入したい」と思いながら開発を進めていましたがエンジニアもプロダクトマネージャーも少ない中で、Autifyを導入するにも初段のコストはどうしても掛かってしまいます。いきなり始めるのは結構ハードルがありました。
しばらくチャンスをうかがっている中で、石井さんの“本業のほう”で本格的にAutifyを導入しているという話を聞いて「石井さん、ウチ手伝ってよ」と（笑）。なので「石井さんに入っていただく」＋「Autifyを導入する」はセットで進めました。
石井さん: そんなに責任重大だとは思ってなかった（笑）。
先ほどメンテナンスコストの話が出てきましたが、自動化にあたってはそこを一番重視しています。確かに導入自体は、誰にでも何とかできると思います。問題は「導入後の運用は誰がどうやるの？」というところ。仕様変更が入れば、画面の見た目も変わってくるので、そのテストを楽にする。
将来的には、「〇〇エンジニア」と付いている人たちだけじゃなくて、ビジネスサイドや、そのときに“たまたま手の空いている人”など、社内の誰もが「ここちょっと壊れてるから直しとくね」と軽いノリでメンテできる運用になったらいいなと思います。
– 石井さんは副業でジョインされて、具体的にはどう参画したんですか？
石井さん: QA専任者がいないので「QA担当で参画してほしい」という話をいただいて、まずはテストにフォーカスさせてもらいました。というのも、Autifyがあれば少ない時間しかない副業でも、バリューを出せると思ったのが正直なところです。
運用できる自動テストを相談する中でAutifyを使うことに。それからAutifyで、どんなテストを回したいのか、シナリオについてプロダクトマネージャーとも話して、まず最小構成からスタートしました。
一度テスト環境を触らせていただき、動きを確認してその中でどこを見ていきたいかをヒアリングしていきました。どんなルートでどう動作するのかを箇条書きにして、画面的には何をチェックしたいのか、どういうルートで遷移させたいのかを書き出しました。
選択肢が変わると入力内容も変わる場合があるので、「別のルートに行かせたいか／このルートでそのまま最後まで行くか」などの細かい話もしました。
– 次のステップとして、自動化できることを整えたんでしょうか？
石井さん: 全部洗い出してから自動化できることをピックアップしていくのは、そこそこ大変です。なので「Autifyを使ってできること」に絞ったうえでヒヤリングしていきました。
手動のほうが早いテストと、機械に任せられるテストに分けられるので「繰り返しできるループってどこだろう？」というのを洗い出してからピンポイントに絞るという進めかたをしました。
– Autifyを経験していた石井さんだからこそ、その知見があったんですね。
石井さん: 確かに実際に使っていなかったら「これはできる／これはできない」を、そんなに感覚的にジャッジできないかもしれませんね。
– ちなみに「ノーコードでエンジニアじゃなくても使える」という点ですが、「ノーコードでもQAの知識がない人だと無理」という考えに対してはどう思われますか？
石井さん: 複雑なシナリオを新規で作る場合、「QAの知識や経験がないと」というのは、確かにその通りだと思います。ただベースとなるシナリオがある状態なら、少し考えれば正解までたどり着けると思うんですね。
一人で考えるんじゃなくて、ミーティングや朝会の時に相談したり、周りを巻き込んでいけば「こうじゃない？」とアドバイスしてもらえると思います。そんなに身構える必要もないし、新規で作るなんてことは1回しかなくて、既存のものをメンテナンス／修正していく、または組み替えて使っていくケースが多いと思います。それをパズルのように解いていけば、誰にでもできるんじゃないかなと、私は思います。
– 最初に道を作るところはQA経験者がやって、その後、誰でもできるように委譲していくのが成功パターンでしょうか。
石井さん: そうなんじゃないかなと今は思います。もっと頭いい人なら「全然違うもっといいやり方あるよ」と言ってくれるかもしれないですけど（笑）。
– 導入で苦労した点はどんなところですか？
石井さん: シナリオ作りそのものより、READYFORの状態遷移の部分が絡んでうまく再現性が保てないことは、どうしてもつまづいてしまうポイントでした。シナリオを作って自分でも動かしつつ、解決できる問題もありましたが、社内のエンジニアにアドバイスをいただいて直したところもありました。
– E2Eテストの冪等性の担保も苦労されたんでしょうか。
石井さん: そうですね。「1回目と2回目、実は状態が変わっていた」とかだと、コケちゃいますので（笑）。
– この点、伊藤さんはエンジニアリング側としてどのように対応したんですか？
伊藤さん: ここは未だにチャレンジングな部分で。本当にケースバイケースで直していきました。一番大きな壁のひとつに、クラウドファンディング特有の「時間」の概念があります。
クラウドファンディングは、募集期間が決まっていて、時間が経つと募集が終了します。そこで「成立した」か「不成立だった」かが分かる。E2E環境だと、その環境の中でプロジェクトを公開してから募集期間が終わってしまうものもあります。そうすると、自然と状態が変わってしまうんです。
今どうしているかというと、期間が過ぎると石井さんがプロジェクトをまた作るという、非常に悲しいメンテナンスコストを払っています（注: 記事公開時点ではテスト対象のプロジェクト募集期間延長をバッチ処理で自動化済み）。テストにおいて時間の概念は、かなりハードです。
– Autifyの運用で、何か工夫していることはありますか？
石井さん: データテスト機能を活用して効率化しています。シナリオをテンプレート化して、ユーザー情報やクラウドファンディングのURL、プロジェクト名を変えるだけで、シナリオ自体に手を入れなくてもいいので便利です。データテスト機能は導入時から活用する前提で考えていました。
伊藤さん: 石井さんがやってくれたので活用できていますが、普通だったらここまで当たり前にできていないかもしれませんね（笑）。
石井さん: 今あるAutifyの機能は割とそのまま使っています。ステップグループも、シナリオの冒頭は、ログイン・ステップグループを作って、それを全部に適用させているので便利です。
– 定期実行やCI連携も使っていますか？
石井さん: 定期実行は回しています。テストプランによって、週1回か週2回で頻度を変えています。そこまで優先度の高くないものは週1で。頻度の高いものは、週2回「月・木」や「火・金」という感じで、トータルで10～15本くらいは回しています。
定期実行しつつ、リリース直前のリグレッションテストで、開発エンジニアも回すので、回数はもう少し上がっているかもしれないです。
CIは走らせたいテストの中身が変わった時に、構成をハードコードし直す必要があるため、今のところまだ連携できていません。
– 10～15本がアクティブに回っているのはすごいです。テストプランはどういう観点で切り出されているんですか？
石井さん: クラウドファンディングの場合、支援を「する人」と「される人」でユーザーの動線が分かれます。支援する人のシナリオを回すことがひとつ。それから支援される側、クラウドファンディングのプロジェクトオーナー側の動線確認用のシナリオをそれぞれ回しています。さらに、時間軸と曜日で分けて実行しています。
– 最初にお聞きした、技術負債が膨らみテストに時間が掛かっていて、開発速度が速まらないという課題感について。Autify導入によって、どのように変化したか聞かせてください。
伊藤さん: なくなったコストがどれくらいあったか、起こり得たリスクなどが定量的に測れなくて難しいところではあります。ですがリリースがある時にAutifyを流せば「ここは安心だね」とパッと出せるようになりました。以前ポチポチ確認していた時間が大幅に減っていると感じます。
– 時間にして、どのくらい減りましたか？
伊藤さん: Autifyが開発ライフサイクルに当たり前のように組み込まれている今、Autifyがない場合の時間を出すのは難しいです…。もしAutifyがなかったら「今どうなっていたかな」と想像がつきません。かなり良いバリューを出せていると思っています。
– 技術的負債と純資産のバランスは、どんな変化がありますか？
伊藤さん: 技術的負債をドラスティックに返却していると感じます。僕が入った時点だと、技術負債と純資産のバランスが「8：2」くらいの割合でしたが、今は半々くらいにまで改善されてきたと思います。
例えば、2年前まで弊社のサービスは完全に大きなRailsのモノリシックのアプリケーションでした。ですが、すでにフロントエンドとバックエンドは分離され、Next.js／React／TypeScriptのフロントエンドと、RailsのAPIを、API通信で行う構成に大部分が変わってきました。
それによって、フロントエンドが機動的に開発できる形に変わった。こういう大きめなリファクタリングを進める上でも、Autifyで確認をしながら「既存の動き、壊れていないよね」と確認できてきているがゆえに、進められていると思います。
– Autifyで自動テストできる状態で、裏側をどんどん変えていく。
伊藤さん: そうです。それがまさに、大きな目的のひとつでした。Autifyがなかったら、ここまでやるぞ！とはならなかった。めちゃめちゃありがたいです。
– リリースサイクルは速くなっていますか？
伊藤さん: もともとデプロイ頻度は高いんです。今は、デプロイできているものの質が相当上がっていて、価値の高いものを頻度高く出せるようになってきました。感覚的には5倍くらい価値が上がっているように感じます。
なおかつ、1回に出すものを大胆に出せる。だから頻度はあまり変わらないけど、1回の内容が増えている感じもありますね。
– 今後の展望をお聞かせください。
石井さん: 守れている部分の品質は地固めしたまま、Autifyで担保できるカバー範囲を増やしていきたいです。
QAはどうしても守りがメインになってしまうのですが、新たに追加する機能や画面についても自動でどう回していくのかについて、ベストな回答を見出すことができたらいいなと思っています。
伊藤さん: ようやく技術的負債の返却も落ち着いてきて、ここからはプロダクトの価値を高めていくことや、新たな価値の創出に取り組みたいと思っています。どのドメインで、アーキテクチャはどうなっていて、素早く価値を生み出せるかどうか。エンジニア組織全体として取り組む体制をつくっているところです。
ドメイン駆動設計も学びながら取り入れています。ここでもっとも肝心なのは、コアドメインがどこなのかをしっかりと蒸留し、そこにどんなモデルが存在しているのかを言語化して、それをきちんとアーキテクチャに落とし込んでいくこと。
そして生み出す価値の品質をきちんと上げていくこと。ですが、QAの体制づくりにはまだ至っていないんです。我々のドメインに必要な品質が何なのかをまずは言語化して、それを選択と集中によって高めていきたいと思いっています。
– これからテスト自動化に取り組む方たちにメッセージをお願いします。
伊藤さん: テスト自動化は、本当に奥が深い領域だなと感じます。Autifyはそこに新しい風を吹き込んでくれました。
「テストファースト」ならぬ「Autifyファースト」のようにAutifyを入れる前提で、開発を始めることもアリだと思うし、新しいものがどんどん生まれそうな予感がします。QAコミュニティの皆さんと一緒に、テスト自動化を推進していけたらいいなと思っています。
石井さん: 手動のものを自動に持っていこうとすると、ツールを新たに使う・使いこなすハードルもありますし、社内でコスト面の交渉も必要です。でも、頑張って人の手でやるというのは、その人が潰れてしまう可能性もあります。
「機械に任せられるところは任せよう」と割り切ってみると視野がグッと広がり、見据える未来や、自分が実現したいことが見えてくるんじゃないかなと思います。
– 最後に、お知らせがあればどうぞ。
伊藤さん: QAの体制づくりがまだ道半ばだとお伝えしましたが、READYFORはQAマネージャーを大・大・大募集しています。READYFORの品質文化について考え、組織内に浸透させてくれるようなQAマネージャーを募集しています。
先日公開した記事や今回のインタビューを読んで、ご興味を持っていただいた方はぜひご応募ください。お待ちしています。
（聞き手: オーティファイ株式会社、CEO & Co-Founder 近澤 良）
.jpg)
.jpg)
