大規模サービスだからこその
贅沢な問いに向き合い、
主体的な意思決定を通じて、
ユーザーに価値を届け続ける

僕は『ホットペッパービューティー』のiOSエンジニアとして、「日本中の街にBeauty Smileを」というビジョンのもと、 iOSアプリを開発しています。
アプリ開発は学生時代から行っており、iOSエンジニアとしてリクルートのインターンシップにも参加しました。そこで現在と同じビューティー領域のアプリチームで実働し、チーム構成や文化に惹かれ、リクルートに入社しました（入社理由の詳細はこちら）。配属後は『COIN+』導入の案件や動画機能追加の大型案件に参加し、入社2年目の下期からは案件リーダーとして約1年間、ヘアカタログを探しやすくする機能追加の大型プロジェクトを推進しました。現在はマルチモジュール化とSwiftUI移行のふたつの案件を並行して、主担当として実施しています。
これまで行ってきた案件は、2種類に大別できます。ひとつ目は「プロダクト自体の改善」で、ユーザーがより自分に合ったサロンを見つけられるよう、プロダクトを磨き込んでいくものです。動画機能の案件やヘアカタログの案件はこちらに該当します。
ふたつ目は「技術的な改善」で、開発生産性が高まるよう、より良い技術を導入していくというものです。直接的に恩恵を受けるのは開発チームですが、開発スピードが上がれば、実施できる「プロダクト自体の改善」の量も増えるため、結果的により多くの価値をより速くユーザーに届けられるようになります。いま担当中のマルチモジュール化やSwiftUI移行の案件はこちらに当てはまります。
僕の所属するアプリ開発チームは、ひとつでも多くの「プロダクト自体の改善」を実施したいわけです。なぜなら『ホットペッパービューティー』の予約数の半分以上をモバイルアプリが占めるため、改善のインパクトが非常に大きいからです。
しかし、むやみに人手を増やすとコミュニケーションコストが増加し、リードタイム短縮には繋がりにくいため、人海戦術を取っても結局リリースできる量には限界があります。そこで、ひとり当たりのスループットを上げて案件量を増やす、つまり開発生産性を上げることの優先度が高まってきます。「技術的な改善」の出番ですね。

こうした背景から、SwiftUIへの移行が起案されました。開発生産性を高めるために、複雑なコードを書く手間やコードの認知負荷といった、プロダクトの変更にかかる労力を減らしたい。そのために、現在の「UIKitによるUI開発」から「SwiftUIによるUI開発」に移行しよう、ということですね。
実際の開発フェーズでは、はじめにチームで議論しながら、SwiftUI全体のアーキテクチャを設計しました。今はその設計に基づいて、UIコンポーネントという、画面を組み立てるときに使い回すパーツを実装しているところです。これを2ヶ月ほどかけて体系的に実装してから、各画面の実装に入ります。主要導線というユーザーが最もよく使う一連の画面、なかでも特に検索や予約といった今後たくさん変更されることになるだろう画面にフォーカスして、ひとつずつ順番にSwiftUIに置き換えていきます。半年ほどかけて順次リリースしていく予定です。既存の画面をいかに品質を落とさないように置き換えていくかが、わりあい難しいポイントになりそうです。
また、アーキテクチャ設計の一環として、デザインガイドラインの見直しも行っています。UIコンポーネントを再定義している今は、それにもってこいのタイミングだからです。デザイナーの意図が実装に反映されていなかった部分を拾い上げ整理しつつ、コンポーネントの命名規則の統一、他コンポーネントとの一貫性の担保、不足するパターンの追加などを、SwiftUIとの整合性を保ちながら進めています。
同様に、コーディング規約がやや古くなっており、それが作られた当時とはメンバーも入れ替わっているので、「どんなコードを良しとするのか」「チームとして何を大事にするのか」についても改めて見直しています。

今回の案件では、「えっ、これ決めていいんですか？最高！」と心のなかで叫ぶことが何度もありました。前述のSwfitUI全体のアーキテクチャやUIコンポーネントの設計にとどまらず、VRT（Visual Regression Testing）の方針を議論するなど、チームで大きな意思決定をする機会が次々にやってきて。これらのような論点を「いかに素早く開発して価値を届け続けるか？」という根本の問いから切り出し、自分たちで決めていくというのは、リクルートで求められる動きかただと思います。
この会社には、自主性を尊び、裁量を重んじる文化があります。「自分はこう考えますが、どうですか？」とスタンスを取り、周りも納得する説明ができると、その人の意志を周囲もサポートしてくれます。
このようなボトムアップの文化は、個人にだけでなく、チームに対しても当てはまります。「システムはこう作るべきだ」「アーキテクチャはこうあるべきだ」「テストはこの戦略でいく」といった、リクルートという会社横断での決まりごとは存在しません。それぞれの領域、それぞれのチームが自分たちで最善を模索し、自分たちにとっての正解を定義していくんです。この結果、意思決定をする機会が豊富にあり、またそのときの裁量も自然と大きくなるというわけです。

この案件における数々の意思決定機会のなかでも、アーキテクチャに向き合う機会があるというのは、とりわけ嬉しいことでした。すなわち、「システムのライフタイム全体で、変更にかかる労力をいかに低く保つか」「それを実現する優れた設計になっているか」について、考える機会があるということが。
ソフトウェアというものは成長し大きくなるにつれ、コード1行あたりの変更コストが高まり、開発スピード、ひいては開発生産性が下がっていく傾向にあります。一方で事業として成長し続け、ユーザーに価値を届け続けるためには、たえず競合プロダクトよりも素早く開発していなければなりません。プロダクトが成長すると開発スピードは落ちるが、プロダクトの成長のためには開発スピードを保たねばならない、というジレンマをソフトウェア開発は常に抱えています。
このジレンマは、プロダクトの規模が小さいうちはさほど問題にはなりません。しかし、サービスが大規模になると、変更コストが膨れ上がり、開発スピードが無視できないほど落ちてくるのです。
リクルートのプロダクトもコードベースが大きいため、このジレンマに直面しています。そのうえユーザー数に比例して社会的インパクトも大きいため、プロダクトの変更には素早さだけでなく、安全性や安定性も求められます。さらにサービスの歴史も長いため、ここに歴史的な経緯による制約も乗っかってきます。エンジニアとしてはチャレンジングな環境だと言えるでしょう。
「歴史的な経緯による制約のなかで、いかに最善の意思決定をして、安全かつ素早くプロダクトを改善するのか？」という問いは、学生さんの目には渋く映るかもしれません。「何の制約もないまっさらな状態から、最新のモダンな技術で開発したい！」という気持ちがあるかもしれません。 しかし、10年以上もサービスが成長し続け、ソフトウェアとしてアップデートし続けなくてはならない、しかも変更の速度を落とさずに、というのは大変に贅沢な問いだと僕は考えています。そういうことができる場というのは限られています。
僕は学生のころから7年近く個人開発をしてきて、社会人になってからも20個以上のアプリをリリースしています。おおかたのサービスは鳴かず飛ばずに終わり、リリース後に伸びたアプリでもまだひとりで開発できる規模です。なので、そういう問いに向き合って、手も動かしてみてという機会はなかなかありません。でもそれが、このリクルートって会社だとできる。贅沢じゃないですか？
どんなサービスだって、うまく軌道に乗って成長し続ければ、いつかは歴史の長いサービスになります。そのことを見据えると、現時点でこのような「大規模サービスだからこその贅沢な問い」に向き合うチャンスがあるというのは、とても恵まれたことだと僕は思っています。

こうした問いに対するアーキテクチャの意思決定が、正しかったのか間違っていたのか、それは実装したその瞬間には分かりません。リリースした直後にも分かりません。そのアーキテクチャのおかげで「変更しやすいかどうか」を判断するのは未来の人で、何年もの時間をかけて答えが見えてくるものです。しかし、もしその間にサービスが打ち切りになってしまったら、答え合わせのチャンスはありません。
この点において、僕の担当するプロダクトは成長し続けているため、アーキテクチャの意思決定についてフィードバックを得る機会があります。それはアーキテクチャにとどまらず、今回の案件で行った他のさまざまな意思決定についても同様です。
こうして振り返ることで、意思決定の精度を高めていけるのも、事業成長を続けているリクルートならではの魅力ですよね。自分の意思決定の是非を、プロダクトの成長とともに見守り続けるのを、これから楽しみにしているところです。

リクルートのサービスは成長を続けていますが、成熟しきって理想的な状態になっているかと言われたら、決してそんなことはありません。まだまだ改善できる余地がたくさん残っています。ということは、意思決定の機会にもまだまだたくさん出会えるはずです。なので、その場その場で「面白いな」と感じることを見つけて、その時々の「これやりたいな」という気持ちを大切にしつつ、目の前の選択に全力で向き合っていきたいですね。
最近は事業ドメインの知識が増えたうえ、技術力も上がり、引き出しも増えたので、やりたいことが自分のなかからいっそう湧き出るようになりました。以前よりも自分なりの理想をよりクリアに描けたり、それと現状とのギャップを埋めるためのアプローチを思いついたりするので、「あれもやりたい」「これもやりたい」と良い意味で欲が出るんです。だから、貪欲にこれからも意思決定の機会を掴まえつつ、前向きに、大胆に、伸び伸びと挑戦して、贅沢な問いを楽しみながら、プロダクトを改善し続けていきたいです。

MY FAVORITE

スマホスタンド

開発中のアプリをiPhoneで動作確認するために、スマホスタンドを使っています。なくしたと思ってAmazonで新たに購入すると、しばらくして姿を消したスタンドが見つかることが頻発し、今や5台も手元にあります。何台もあるほうがテンションが上がるので、良しとしています。