皆さま、こんにちは！SHE採用チームの永田です！SHEには業務委託で採用人事として関わっております。

SHEは、2017年の創業以来「一人一人が自分にしかない価値を発揮し、熱狂して生きる世の中を作る」をビジョンに据え、既存の価値観に囚われず個々人の価値を発揮できる「自分らしい働き方」にフォーカスし、キャリアスクール事業「SHElikes」を展開しております。

今年は新規事業として、トータル美容スクール「SHEbeauty」と体系的なお金の知識を獲得できるマネースクール「SHEmoney」を新たにサービス提供開始し、キャリア領域だけではなく、美容・金融の領域においても、既存の価値観のアップデートに取り組んでいます。

この度「コミュニティテックをもっと身近に。」をコンセプトに「SHEテックノート」と題してSHEの開発チームの魅力をお届けてしていく取り組みをスタートしました。今回は記念すべき1回目となります！

「コンポーネントの共通化でSHEmoneyを爆速開発した話」と題して、
コンポーネントを共通化して、全サービス開発をしているSHEの開発の裏側について技術（前編） / チーム（後編）の2部構成で触れていきます。

今回は、コンポーネントを共通化したことで、先日リリースされたSHEmoneyの基本機能を1週間で作りあげたプロダクトチームに「技術」の観点から迫ります！

今回インタビューしたのは、未経験からSHEのエンジニアとなり入社3ヶ月でMVPを取るなど大活躍する 矢貝（おはる）です！
おはるの入社エントリやMVP受賞のnoteもぜひご覧ください👇

未来の受講生や自分たちのための「コンポーネント共通化」

ー改めてコンポーネント共通化の背景について教えてください！

前提として、SHEが提供しているコアな機能である、「コミュニティ・コンテンツ、コーチング」は全てのサービスで提供していきたいと思っています。

SHEが提供している3つのC

そのため、SHEbeautyでもSHEmoneyでも上記の機能を実装する必要がありましたし、今後出てくるサービスでも実装するだろうということが分かっていました。

また、スタートアップのようなスピードが求められる環境で、SHEbeautyもSHEmoneyもリリースまでのスケジュールは非常にタイトでした。

このような状況でどうやって実現していくか？ということを考え続けました。短期的には、共通化せずサービスごとに1から実装するのが早いと思っています。一方で、今後すべてのサービスに同じ機能を実装していくことを考えると、長期的には共通化したほうが圧倒的に早いと考えて、未来の受講生や自分たちのために「コンポーネント共通化」にこのタイミングで踏み切ろうという判断をしました。

ーコンポーネント共通化がされていなければ、どのような問題が起こっていたのでしょうか？

SHEmoneyのリリースに間に合っていなかったと思います。実は、今回の共通化によって基本機能の開発速度を7分の1ぐらいまで短縮できたんです。つまり、共通化を進めていなければ、7倍かかっていたことになり、リリース日に間に合っていなかっただろうと思っています。

リリースが間に合わないということは、サービスの提供を遅らせるか、スコープを削るかのどちらかを選択しなければいけなくなります。
リリース期日を遅らせてしまうことは、楽しみに待ってくださっている受講生を、モヤモヤさせてしまいます。だからといって、スコープを削るということは、不十分な機能で世に出すということになるため、使っても意味のない機能を出したとして受講生は本当に使ってくださるのか？という思いがありました。どちらもプロダクトチーム的には譲りたくなかったですし、どちらも達成したかったという気持ちで進めました！

エンジニア×デザイナーのスムーズな連携により、SHEmoneyの基本機能をわずか1週間でリリース

ー期日がタイトな中、どのように共通化を進められたのでしょうか？

共通化自体は、SHEbeautyやSHEmoneyのプロジェクトとはまた別でデザインシステム※1を作ろうというプロジェクトが走っていました。まずはインフラエンジニアの方が中心となって土台となるモジュールを作り、その後開発メンバーが引き継ぎました。そして、デザイナーからデザインが上がってきたタイミングで、SHEbeautyとSHEmoneyのデザインを比較しながら、どんなコンポーネントをどんな粒度で切り出すべきか？を決めて、チーム内で合意を取りました。

※1）デザインシステム
デザインの概念、原則などをまとめたドキュメント。それらを具体的なデザインに落とし込むためのスタイルガイド、UIコンポーネントライブラリなどの「仕組み」

そして、コンポーネントの切り出し方針をデザイナーとすり合わせ、問題がなければ実際にコンポーネントを切り出す作業へと移行していきます。次に、切り出したコンポーネントを使って機能を実装する段階に入ります。実装する過程で起こる問題はその都度解決してゴールを目指す。という流れで進めていました！

実際のコース画面やマイマネーノートの登録画面

ー共通化をチームで進める上で工夫した点や心掛けていた点はありますでしょうか？

デザイナーとエンジニアで大事にしたい軸が違うことをしっかりと理解することが大切だと考えていました。双方の最適解を見つけることを大切にして、進めていました。
例えば、デザイナー側は、px（ピクセル）単位でこだわりを持っていますが、エンジニア側はなるべく全体的に統一したほうが効率的でスピードも早くなる、という気持ちがあります。しかし、デザイナー側がどのように考えているか？という点も徹底して聞きながら、会話を重ねいい着地点を探すことを繰り返し行なっていました。

SHEのデザイナーの方は開発側の理解が非常に深いので、とてもスムーズに進みました！コミュニケーション量を増やせば増やすほど、開発の質を意識したデザインを提案してくれて、とても感謝しています。

ーどんなチーム体制で共通化を進められたのでしょうか？

SHEmoneyの開発チーム体制としては、CTOの村下が全体管轄となり、PdMで1名、開発メンバー5名の体制でした。そのうち開発メンバー2名がSHEmoneyの基本機能の実装を担当し、1週間でリリースしました！！

実際のエンジニア×デザイナーとのやりとりをしていたNotionの一部

Storybookの導入で、開発中の作業を効率化。開発を進める上での難しさもやりがいに。

ーサービスごとにユーザーが期待する役割も違えば、実装に利用する言語や最適な手段も異なると思いますが、難しさはありましたか？

いい観点ですね（笑）おっしゃる通りです。利用する言語に関しては、バラバラにしてしまうととても大変なので、一つの言語に統一していこうと意思を持って進めていました。加えて、ユーザーが期待するものが違うというのもその通りです。SHEmoney独自の機能（SHElikes、SHEbeautyに存在しない機能）を実装する場合は、共通化せずにSHEmoney上に実装する、という判断をしていました。逆に、ジャーナリング※2機能のように、SHEbeautyとSHEmoneyの両方に存在する機能については共通化する判断をしました。機能としては一緒ですが、デザインやフォームとして送りたい内容も異なるため、どのように共通化していくかは工夫が必要で大変なポイントでした。それに加えて当初はデザインシステム上でUIの確認ができずUIを確認するためにはわざわざSHEbeautyやSHEmoneyを立ち上げ、そこでデザインシステムのコンポーネントを読み込む必要がありかなり非効率的でした。

これらの開発中の確認作業を効率化するために、デザインシステム側にStorybook※3という技術を導入していました。例えば、「ボタン」というStorybookのコンポーネントを作ると、Storybook上でそのボタンのデザインや色をサービスごと確認できるようになります。これを導入してからさらに開発スピードが速くなりました。

※2 ジャーナリング
データを定期的に記録する技術
システム障害などが生じた際に、ログに記録された内容を確認するだけでよいので、起動が速く、かつ、その情報を基にした復旧ができるようになる。

※3 Storybook
UIの一覧のようなものを作ることができるもの

ー最も難しかった部分 / 壁となった部分はどんなところですか？

コンポーネントを共通で使えるように、抽象化して切り出す作業はすごく難しかったです。基本機能に関しては、今SHElikesにあるものをコピーしてデザインシステム上に再実装する、という流れで進めて進めていました。

しかし、元のSHElikesのコードには、ビジネスロジックや色の情報がそのまま含まれてしまっているのでそのままでは共通化して使えません。どこを残して、どこは外側から受け取れるような形に変更して実装するのが良いか？ということを工夫しながら進めるのはすごく大変でした。
機能が増えて複雑になるほど難しくなっていくので、そこは大変ポイントであり、やりがいになったポイントでした！

自動でチェックテストが走る仕組みを導入し安心して開発ができる環境を作る

ー長期的な運用も大事になってくると思います。今後の運用ルールなどはあるのでしょうか？

運用の点で一番懸念しているのは、共通化していることでSHEbeautyだけ変えたい！と思って修正した時に、意図せず他のサービスに影響が出ていないか？という点です。
今は、Storybookで目視で確認する方法しかないのですが、ここを全部自動でUIと機能レベルでテストしてくれる仕組みを導入していようとしています。導入方針もすでに決まっていて、「このような技術で自動化を進めよう！」と会話しており、すでに実装に着手している状況です。

ー他のサービスに影響が出ていないかを検知するには、具体的にどのような方法があるのでしょうか？

テストを書いて、テストが検知する仕組みを作ることですね。意図しない変更を人力で感知することは難しいため、Github上にプルリクエストを作成したタイミングで自動でチェックテストが走り、意図しない変更を検知したらアラートを出して教えてくれる仕組みを導入しようとしています。この仕組みがあることで、安心して開発ができるようになります。テストを書くことは品質保証の観点でも非常に重要なので、小さい単位でも毎回テストを書いていきたいと思います！

SHEmoneyの爆速リリースを支えた3つの技術方針。

ー最後に今回のコンポーネントにおける技術方針を是非教えてください！

技術方針としては、以下の3つがありました。

①言語の統一
②ビジネスロジックを持たせない
③テーマカラーの概念の導入

1つ目が「言語の統一」です。全部の言語をバラバラにすると負担が大きいので、TypeScript/React を使って実装するという方針を決めていました。

2つ目は「ビジネスロジックを持たせないこと」です。ビジネスロジックを持たせてしまうと汎用性がなくなり、他のサービスで使いづらくなってしまいます。必要な画面だけを切り出して、ビジネスロジックは各サービス側（例：SHEbeauty、SHEmoney側）で設定するというような形で実装しましょうという方針を決めていましたね。

3つ目は、「テーマカラーの概念の導入」です。今後サービスが増える中で、一つ前提として理解しておくことがあります。それは、「SHEが提供しているサービスごとにメインカラーが異なる」ということです。

SHElikes＝ピンク
SHEbeauty＝ネイビー
SHEmoney＝オレンジ

そのため、同じコンポーネントでも色だけはそのサービスのメインカラーで表示したい、という場面がよくあります。そのような時にサービスごとに色の切り替えを行えたり、新しいサービスが増えた時に簡単に色を追加できるように、テーマカラーという概念を導入しています。

ー様々な角度から裏側について教えていただき、ありがとうございました！！コンポーネントを共通化して、全サービス開発しているSHEのこれからが楽しみです！

ー最後に

最後まで読んでいただき、ありがとうございました！今回は開発の裏側を「技術」の観点から深堀ってみました。次回は、「チーム」の観点からお届けしていきますので、楽しみにしていてくださいね！