開発スタイルの違うチームがコラボ。リクルートの新決済システムが作られるまで

松田大輝さん・小林啓人さんトップ画像

アジャイル・スクラム開発とウォーターフォール開発──開発手法を巡ってしばしば対立項に置かれるこの二つのスタイルは、考え方はもちろん、段取りやマネジメントの方法もまるで異なります。そんな全く異なるスタイルをとる二つのチームがコラボレーションし、開発プロジェクトを推進していくことは現実的に可能なのでしょうか？

そんなコラボレーションを、決済というミッションクリティカルな領域で実現し、新たなシステムのリリースにこぎ着けた実例がリクルートにはあります。

英語や英会話の学習を支援する『スタディサプリENGLISH（以下、スタサプENGLISH）』では、今や主流となりつつあるサブスクリプションモデルに決済システムが対応できていないという課題がありました。そこで、決済・金融関連のシステムを開発するチームと共同で、新たな決済システムの開発に取り組みました。

『スタサプENGLISH』のチームは、内製の開発組織によってプロジェクトをスピーディに回すアジャイル（スクラム）開発を採用しています。一方、決済システムの開発においては、スコープと要件をしっかりと定め、スケジュールに沿って開発を進めるウォーターフォール的なアプローチが主流です。

開発スタイルが大きく異なる二つのチームが、どのようにともにプロジェクトを推進し、リリースまでこぎつけたのでしょうか。『スタサプENGLISH』のチームを率いた松田大輝さんと、決済システムの開発チームとしてプロジェクトをリードした小林啓人さんにお話を聞きました。

※この記事は株式会社リクルートによるSponsoredContentです。

一度も交わったことのないチームがゼロイチで共同開発
開発スタイルの違いを乗り越えるためにやったこと
リスクの芽をこまめに摘む「チェックポイント」方式
「違和感」に目を背けずコミュニケーションをとる大切さ

一度も交わったことのないチームがゼロイチで共同開発

── お二人はそれぞれ今どんなお仕事をなさっているのですか？

松田大輝（まつだ・だいき）
株式会社リクルートプロダクト統括本部
プロダクト開発統括室プロダクトディベロップメント室
販促まなび領域プロダクトディベロップメントユニットまなび社会人・語学プロダクト開発部
EnglishテクニカルPMグループ

松田　『スタサプENGLISH』のチームで、内製の開発組織とビジネス側の橋渡し役となり、開発プロジェクト全体の取りまとめや調整業務を担っています。一般的に言うプロダクトマネージャー、テクニカルプロダクトマネージャーに近い仕事をしています。

小林啓人（こばやし・ひろと）
株式会社リクルートプロダクト統括本部
プロダクト開発統括室プロダクトディベロップメント室
SaaS領域プロダクトディベロップメントユニット SaaS領域開発ディレクション1部
SaaS領域開発ディレクション1グループ

小林　SaaS領域の開発ディレクションチームの開発統括として、リクルートの決済・金融系プロダクトの開発プロジェクトを主幹しています。

── 決済システムは可用性が大前提となる上に新規要望も多く、難しい分野ですよね。

小林　そうですね。クレジットカード決済ひとつとっても、イシュアー（カード発行会社）、アクワイアラー（加盟店管理会社）など数多くのステークホルダーが関わり、経由するシステムも複雑です。また、「ミッションクリティカル」という言葉にも象徴される通り、高い品質を求められる一方、ビジネスの観点からは機能のアップデートも頻繁に求められます。「いつ頃出せそうですか？」という会話はしょっちゅうです。

── 今回の新決済システム導入を巡っても、そんな会話が交わされたのではないかと推察していますが、そもそも『スタサプENGLISH』では、決済に関してどのような課題を抱えていたのですか？

松田　従来利用していたシステムでも、事業として実現したい課金形式は全て実現できている状況ではありました。ただ、サブスクリプションの決済モデルに特化したシステムではなかったため、事業側で決済システムの仕様を考慮しながら開発を進める必要があり、本来実施したい事業価値の向上に注力することができないという課題がありました。

例えば、ユーザーごとの決済タイミングを『スタサプENGLISH』側で保持し「このユーザーの決済タイミングがここで発生するから決済処理をお願いします」と決済システム側にデータを連携する必要があったんです。

また、ユーザーの決済導線としては、『スタサプENGLISH』ではなく決済専用の画面に都度切り替えなけらばならず、ユーザー体験の改善や満足度の向上という面で改善の余地が大きいと感じていました。

── そうした課題があった上で、どのような検討をへてシステムをゼロイチで作るという決断に至ったのでしょうか？

松田　最初に考えたのは、従来のシステムを改善する方法でしたが、それは機能上難しかった。次に、世の中で標準的な決済システムをいくつかピックアップし、比較検討を進めたのですが、果たして僕らがやりたいことを全部できるのか若干の懸念がありました。

一方その頃、社内で「決済領域で新しいシステムを作ろうとしているよ」という話を耳にしたんです。これから作っていくならば自分たちのやりたいことも実現しやすく、何かしらの形で連携できないかと考えました。

小林　当時我々は、「決済流通額の最大化」という全社戦略に向け、どんな決済システムをどの順番で作っていくかを検討しているところでした。

そのつながりで、決済領域側でもサブスクリプションモデルに適した決済システムの構築の必要性が議論されていたので、『スタサプENGLISH』側と方向性が合致し、このプロジェクトが始まりました。それが2021年の春ごろですね。ちなみに、双方のチームはこれまで一度も交わったことがありませんでした。

松田大輝さん・小林啓人さんインタビューカット

── そもそもミッションクリティカルな決済システムを一から作ることに対して、不安はなかったのですか？

小林　もちろんありました。ただ、リクルートの中長期的な戦略と『スタサプENGLISH』が抱える課題をかけ合わせると、システムをゼロから作っていくことが最適解でした。それをやる前提で、「どうやっていくか」を考えることに集中しよう、というスタンスでしたね。むしろ、ユーザーと向き合う『スタサプENGLISH』チームのほうが、難しい決断だったのではないでしょうか？

松田　たしかに、決済というミスの許されない領域での挑戦でしたから、不安な面もありましたね。しかし『スタサプENGLISH』には、内製の開発組織があって柔軟に対応できる強みがありますから、不を解消するためにもゼロから作っていこう、とチーム内で話をしていました。

決済システムはユーザー体験に直結する領域だからこそ、その場しのぎで何とかするのではなく、ゼロベースで「あるべき姿」をしっかり描き、そこにどうたどり着くかを皆で考えながらやっていこうという思いでしたね。

開発スタイルの違いを乗り越えるためにやったこと

── 『スタサプENGLISH』のチームはアジャイル（スクラム）式、決済チームはウォータフォールに近いスタイルと、互いの開発手法も異なっていたと伺いました。そんななか、どのような体制でプロジェクトを進めていったのでしょうか？

小林　一週間程度で小規模にスプリントを回していくようなアジャイルの体制であれば、「いろいろ考える前にまずは作ってしまう」のが最適解です。しかし新しい決済システムをゼロイチで開発する、かつ関係するステークホルダーも非常に多いプロジェクトですから、やり方を変える必要があるなと。

僕は決済領域に携わる前、数百人月規模の大規模プロジェクトのマネジメントを経験してきました。その経験を通して、体制や会議体設計、コミュニケーションのとり方、マスタースケジュール、スコープがクリアになっていないと後で苦労することが分かっていたので、開発に着手する前にそういった部分に時間をかけて整理しました。

松田　当初は、マスタースケジュールの策定をはじめ、小林さんにプロジェクトをグイグイ引っ張ってもらいましたね。

異なる組織が一つのプロジェクトを推進する場合、「探り合い」になりがちです。今回、僕らの状況も理解した上で、小林さんが主導権を持って、いつまでに何をすべきかの旗振り役をしてくれたのでありがたかったです。

小林　相手の状況や立場を理解した上で、こちらでどんどん組み立ててぶつけ、もし違うところがあればチューニングしていく進め方がいいだろうと。もちろんお作法の押し付けには絶対ならないようにしつつも、ベースは作る、というバランス感覚を重視していました。

松田　常日頃から「何かあったら変えるから、遠慮なく言ってね」という空気感を出してもらっていましたね。

先ほど開発スタイルの違いについての話も出ましたが、『スタサプENGLISH』はto Cのサービスということもあり、こちら側のスケジュールではなくその時々のユーザーニーズを重視して常に最速でやれることをやろう、というスタイルです。一方で決済は、いつまでに何を出すかをかっちり決めていくスタイルで、そこは考え方が全然違いますよね。その違いを踏まえ、どう我々のやり方をアジャストしていくかを、チーム内でも考えていました。

松田大輝さんインタビューカット

小林　決済システムは数多くの関係会社・連携システムやクライアントと接点のあるプロダクトなので、「いつこの機能をリリースします」と一度アナウンスすると、基本的に変更がききません。だから「誰が、何を、いつまでに」といった段取りを綿密に固める文化が特に根強いんです。世間一般的には「ウォーターフォール」と呼ばれるものですね。一方『スタサプENGLISH』は先ほども申し上げた通り、最速で開発して、問題が起きたら直前でもスケジュールをずらしていく、という開発スタイルです。

どちらも、プロダクト特性を踏まえると最善の開発スタイルですが、方向性は真逆と言えるほど違います。なので、僕らから「ゴールから逆算して、この時期までにこれができますか？」と尋ねても、「分かりません。できるかもしれないし、できないかもしれません」となるわけです。

リスクの芽をこまめに摘む「チェックポイント」方式

── そんな難しさが付きまとうなか、具体的に、どのような方法でプロジェクトを前進させていったのでしょうか？

松田　先ほどもお伝えした通り、決済システムを新規に作り上げる、というプロジェクトの特性上、開発に着手する前に仕様やプロセス、スケジュールを固めておく必要がありました。

加えて、僕たちのチームは他のプロジェクトとの兼ね合いで、開発エンジニアがアサインできる時期が少し先になりそうといった事情がありました。また、開発規模も双方の間に大きな差がありましたね。

小林　つまり、開発に着手するタイミングや開発に必要な期間が両チームで異なっているわけですね。

松田　そうですね。なので、双方がスムーズに開発を進められるよう、小林さん主導で開発プロセスを調整していきました。

小林　要件定義の工程を二分割することにしたんです。具体的には、我々主導で先行して検討するフェーズと、後から合流する『スタサプENGLISH』チーム側の要件定義結果との整合性をとるフェーズに分け、後者にコードを書きながら仕様も変更していく調整期間を設けました。ウォーターフォールのスタイルに、ちょっと崩しを入れるようなイメージです。

── 開発しながら仕様も検討するというアジャイル（スクラム）的な側面もありつつ、要件定義やスケジュールを事前に固めておくウォーターフォールの側面もある。アジャイルとウォーターフォールのハイブリッドスタイルですね。

小林　そのように捉えることも可能ですね。ただ、大規模プロジェクトは開発物の仕様や開発プロセス、スケジュールが可変的だと暗礁に乗り上げる可能性も高まるので、ここはウォーターフォールならではの段取り力が問われるところです。

そこで、マスタースケジュールを眺めながらどこでどんなリスクが顕在化しそうかを見立てた上で、リスクが顕在化しそうなタイミングにチェックポイントを入れていきました。

松田　小林さんのチームには、通常のプロジェクトよりも細かく、複数のチェックポイントを設けてもらいました。同時に僕らも、内製開発ならではの柔軟性を活かしてスコープを調整したり、設計と開発を並行して進めたりと、あの手この手でスケジュールを守る努力をしました。

── 開発スタイルにアレンジを加えることで、開発はスムーズに進められる一方、チーム内外のコミュニケーションは煩雑になりそうです。関係者間で認識のズレを減らしていくために、何かしらの工夫はあったのでしょうか？

小林　関係者には、あらかじめ「こういう構造なので、ここでコストが膨らんだり、スケジュールが変わったりするリスクがあります。だから、チェックポイントを設けておいて、ダメな場合にはこういう手を打ちます」と説明し、各チェックポイントでチェックする観点と「OK or NG」の判断基準、NGだった場合の対策オプションまで事前に目線合わせをしました。

松田　「ここでこの組織にあらかじめ共有しておくと、お互いスムーズに進行できるんだな」と、僕自身とてもいい勉強になりました。現在、チーム内の他プロジェクトでも、チェックポイントを設けて、どこで何をやっておくかを把握する方法を取り入れています。

── なるほど。そうした工夫を取り入れた結果として、スケジュール通りに開発は進んだのでしょうか？

松田　いえ、『スタサプENGLISH』側で要件定義を進めた結果、工数が膨らみ、チーム内の開発体制を考えると二ヶ月くらいスケジュールがずれてしまう可能性が出てきました。もちろん、バッファを取った上での話ではありますが、その確からしさも含め、「どうですか」と聞かれても、「いや、まだ分からないです」としか言えないのが正直なところでした。

小林　ここが一番大変だったところでしたよね。僕と松田さんの間では温度感が共有できていても、決済チームのプロジェクト関係者はスケジュール変更に敏感なので、「まだ分からないです」とだけ言うわけにもいかず、普段あまりない状況なだけに適切なニュアンスで状況を伝えることがなかなか難しかったです。それに、こちら側はすでに25人ほどのエンジニアのチームを組んでいたので、スケジュールが二ヶ月遅れたら彼らの工数をどうするのか、という事情もあり、結構ハラハラしました。

松田　そうですね。いつもであればスケジュールを変更するところですが、決済チーム側のそうした事情も当然分かっていたので、できる限りスケジュールの見通しを立て、それを丁寧に伝えるよう心がけました。

その上で、スコープを絞ってスケジュールを優先するものとリソースを割いてでも優先して開発する機能をピックアップし、各機能に優先順位をつけることで関係者間の共通認識が持てるよう意識しましたね。

── 少し話が変わりますが、今触れていただいた仕様検討時のエピソードに関連して、今回開発した新しい決済システムは『スタサプENGLISH』だけでなく他サービスへの適用も想定されたものだと伺いました。汎用性と個別性をどのようにすり合わせていったのでしょうか？

松田　「こういう機能を作りたい」という要望はいったん全て提案しました。基本的には歩み寄ってもらえますが、中には、汎用性を持たせる上でどうしても作れないものもあるため、そこは合わせようとコミュニケーションをとっていました。

小林　毎回、個別に判断を下していくわけにもいきませんから、プロジェクトを始めるときに、「将来を見据えて汎用的な機能検討を行う」「他のサービスにも展開する展望があるので、基本、個別要件に対応しない」という基本方針を決め、関係者に共有したんです。この骨格があるかないかでかなり違うと思います。それでも、お互いに譲れない部分はありますから、そこは丁寧にすり合わせました。

松田　「小林さんのチームにとっては『個別要件』だけど、僕らとしては汎用的な機能だと考えます」と議論したこともありましたね。ただ、単に「できない」というだけでなく、「こんな形ならできるかもしれない」と代替案を示してくれるので、気持ちよく議論できました。

「違和感」に目を背けずコミュニケーションをとる大切さ

── そうした過程をへてようやくシステムリリースに至るわけですが、肝心のリリース時に大きなトラブルは起こらなかったのでしょうか？

小林　多少のトラブルは覚悟して当日に臨んだのですが、スムーズにリリースできました。

新たなシステムにおいて、我々はAPIだけ提供するので、画面は自由に作ってください、という方式に変わりました。なので、決済導線のUI/UXは『スタサプENGLISH』側でどんどん改善できる状態になっています。

一方で、サブスクリプションモデルならではの決済タイミングの制御といったビジネスロジックは、全部こちら側で持つようにしているので、その辺を気にせず開発できるようになっていたらうれしいなと思っています。

松田　リリースしてから半年ほどたちましたが、決済まわりの大きなトラブルは起きていません。決済まわりの開発を気にしなくていい世界ができて、今後さらに効果を実感できると思っています。

── プロジェクトをうまく進められた要因は何だと分析していますか？

松田　「違和感」に目を背けず、腹を割ってコミュニケーションをとったことが一番大きいと考えています。ちょっとでも「おかしいんじゃないか」と感じたり、受け入れ難いなと思ったことについてお互いしっかり言える関係性を、現場のメンバーと各組織のリーダーの間でも、また組織間でも構築できていましたね。

小林　そうですね。互いのギャップに目を背けず、「こういうギャップがあるよね」ということを言語化し、「だから、こんなリスクが発生して、こういう打ち手を打っておく必要があるよね」と丁寧に議論できていました。コンフリクトを前提にしてチェックポイントを設置したり、要件定義を二段階にしたり、判断や会議設計をどうするかも検討しておいたので、トラブルが起こっても破綻せずに済んだと思っています。

── チーム内でコミュニケーションをとるときに意識していたことがあれば教えてください。

松田　各部署が最高のパフォーマンスを出せるよう、各所に対する情報の出し分けは意識をしていました。例えば、スケジュールに関する議論をエンジニアにそのまま伝えてしまうと、不必要に焦らせてしまう可能性もあります。安心して仕事を進めてもらいたいからこそ、伝える時期や伝え方にこだわるようにしていました。

小林　相手に納得感を持って、気持ちよく動いてもらえるような伝え方を意識していました。

例えば、『スタサプENGLISH』の皆さんにスケジュールの線を示すときは、「ここはこういう事情で譲れませんが、こっちはアジャストできますから、難しかったら言ってくださいね」と、相手が代替案やスケジュールの調整をできるような背景情報や検討材料とセットで伝えるようにしていました。

── 杓子定規に伝えると、なかなかうまくいきませんよね。

小林　互いの関係がギスギスするときって、だいたいそうしたボタンのかけ違いから始まりますよね。「こちらの要望を理解せず、ダメしか言ってこない」とストレスを感じるだけならまだしも、「相談してもどうせ無理と言われるんだろうな」と思われると、情報すら出てこなくなってしまいます。

でも例えば、現場から「無理です」と報告が上がってきても、障壁をきちんと深掘りしていくと「この前提をちょっと変えればできるよね」というパターンもあり、両者にとっていい感じの解決策を編み出せたりします。

小林啓人さんインタビューカット

── 相互理解や綿密なコミュニケーションが大事というのはどこでも言われることですが、どう実践すればいいのでしょうか？

小林　両方のプロダクトや事業が成長し、成功していくことや、カスタマーやクライアントに価値を提供し続けることが大目的です。そこを目指せば自然と、互いの事情を理解した上で最適解を出すためのコミュニケーションになっていくと思います。

ここまでずっと、チーム間の文化が違うと話してきましたが、リクルートの従業員に共通する文化として、事業やプロダクトに主語を置いて、目的ドリブンで考える点があると思います。こういう根本的な考え方が共通しているから、開発スタイルが違っても前向きに議論できるのかなと。

── プロジェクトを通して学んだこと、気づいたことはありますか？

松田　やり方っていろいろあるんだな、ということでしょうか。今回のサービスも、各フェーズで試行錯誤し、やり方をその都度変えながらゴールにたどり着きました。一つのやり方を極めるのもアリですが、いろいろなやり方を取り入れながら何とかしていくのもアリなんだな、というのが気づきであり、楽しかった部分です。

小林　実は、こんなに分かりやすく開発スタイルの違うチーム同士で、コンフリクトを体感しながら開発をしたのは初めてだったんです。二律背反にならずに両立させる引き出しを方法論として編み出せたことが学びです。

松田大輝さん・小林啓人さん談笑カット