こんちはめろたん(YOUTRUST / Twitter)です。
最近、住んでる地域の近くに温泉(尾張温泉っていうところ)があることを知って、楽しくなって行ってきた結果、帰り道が土砂降りでもうなにもかも終わりになってました。
はい。
そんななかYOUTRUSTはWebのPC版だけですが、とある画面が8月にリニューアルされました！！
🎉WebPC版のマイページをリニューアルしました🎉
— YOUTRUST(キャリアSNS) (@YOUTRUSTinc) 2022年8月4日
いつもキャリアSNS「YOUTRUST」をご利用いただきありがとうございます！
WebPC版のマイページのデザインが変わり、よりユーザー様のキャリアが伝わりやすくなりました👏
この機会にプロフィール更新をしてみませんか？https://t.co/zyIiqjrFwB pic.twitter.com/t6BT00UT8c
ということで、今回はYOUTRUSTのユーザーの詳細ページ（PC版のみ）をリニューアルした話を、ちょっと自分の振り返りというのも含めてしていこうかな～とおもいます！
✨リニューアルの背景
そもそもなんでリニューアルしたんじゃいという話なのですが、 この4年間ほど数々の試行錯誤や仕様変更に対して、リファクタリング工数が中々取れなかったため様々なスタイルやコンポーネントなどが誕生していて、 理想とするユーザー体験・情報設計の実現や開発効率・プロダクト品質そのものに悪影響が出てきていました。
そのため、ここいらで本腰を入れて理想の形に近づける活動ができないと、今後もズルズルいってしまってどんどん理想的な体験・設計がしづらくなっていくし、開発体験としてもよろしくない方に流れていってしまうな～と考え『ガッとやるぞ！』というので始めました！
🤔どういうかんじにやった？
🧭方針ぎめ
今までは、コンポーネントの作り方等々が明確に定まっていなかったというのがあったので、そこから決めていくことにしました。
まずLADR*1を書き、リニューアルにかかわるコアメンバーで各構成についてをレビュー等々し設計方針を決めました。
その方針にそってディレクトリをつくり各ディレクトリにREADMEを配置し、ここは何を置く場所でどう作っていくのがよいとされているか等も書いていきました（そんなに大量の文章ではないですが…ないよりマシ程度）。
実際にどんな感じにしたかというと、
v2 ---- dove # 後述しますが、弊社のデザインシステム的なもののコンポーネント等々を格納している場所
`-- app ---- components # 各画面で使う共通のコンポーネントを配置する
|-- scenes # 各場面のコンポーネントを配置、またその画面内でしか使わないコンポーネントを配置する
|-- hooks # 各コンポーネントで使えるカスタムフック、例えばAPIを叩くためのカスタムフックとかを配置する
`-- helpers # いわゆるutil的なものを配置する
こんな感じです。
これは実際によく使っているところだけを抜いてきています。
LADRで決めたものとしては他にもあるのですが、現状うまく使えていないのでどうするかは引き続き考えていかねばならんなとなっています。
🕊自社のデザインシステム的なもの Dove
リニューアルする上で、ただ「キレイにするぞ！」だけだと、今までの開発と同様に都度コンポーネントを作る等々になってしまい、結局今まで通りの問題が起きうるためデザインシステム的なものをちゃんと作ってコードとしてちゃんとつくろうというのを実行しました。
そしてできたデザインシステム的なものの名前はDove(ダブ）です。白い鳩とかそういう意味っぽいですね。
（どうでもいい情報ですが、このDoveという命名についてですが、かつてYOUTRUSTには「ぽ太郎」というキャラ*2が存在しており、そこから「鳩」をどっかで使えないかみたいなアレからきています。またキレイにするぞ！という意味をこめて「白い鳩」を指すそれにしたみたいなところもあります。）
これについてはいずれSmartHRさんのように公開できるとよいなと考えておりますので、時期がきたらまた公開とブログとかを書ければなと考えております！
ともかく、できる限り同じコンポーネント・スタイル等を再生成し続けるのは避けねばならぬと考え、リニューアル作業を全力ではじめるぞ！となる前に、デザイナーと共同で最低限必要な低レベルなコンポーネントを各種揃えて色やフォントサイズ等々も変にブレないように整備しました。
これのお陰で今までと違いそれなりに作りやすい形にはなっているのかなぁと考えています。
とはいえまだまだ足りていない部分や、設計が甘いところが多々あるのでここも日々改善修正し続けないといけないなとなっています。
Hygen
今までは各エンジニアにどのようにコンポーネントを作るか等々を任せていましたが、リニューアルするにあたってどうしてもStorybookを入れたかったということやその他強制したい事項があったので、「これならもうコンポーネントを生成できるなにかをちゃんと作ったほうがいいね。」ということでHygenを導入しました。
これでほぼ何も考えなくても特定のコマンドをいれることで、守ってほしいいくつかのことを含んだ状態でコンポーネントを作れるようになりました。
このテンプレートにテストを入れようか迷ったけど、今回は必須事項としてはいれませんでした。
理由としてはテストを書こうにも各種まだ整備できていないため*3ほぼかけないということや、書ける部分は書いたとて大して意味をなさないな…となったためです。
近いうちにこのあたりの各整備を済ませてテストを書けるようにはしていきたい所存です…。 大変ではありますが、やっぱりテストはあるべきだと思うのでやっていきたいところですね。
Storybook
リニューアルにあたって、各コンポーネントをつくって徐々に適応していくという手法は正直現状のYOUTRUSTだと厳しいものがあったため、なにかでコンポーネントが見れる環境が必要でした。 また今後の開発を考えたときにもStorybookを使って各コンポーネントのカタログをみれることはとても良いことであるため導入しました。
導入した結果、各コンポーネントの開発・確認がだいぶ楽になって「よかった」の一言です。
各APIとかとのつなぎ込みやReduxのstateへのアクセスとかは実際につなぎこまないと正しく動くかというのがわからないのでそこだけアレではあったのですが、とはいえコンポーネント自体の開発の体験はほんとによくなったのでよかったです。
なにか特段工夫しているところは無いのですが、一点だけ地味に大変だったところがあります。
Storybookを入れた際に当時使っていた react-router のバージョンが古く（メジャーバージョンが一つ古かった）、Storybookで使っている react-router のほうが新しくそっちで上書きされてしまいオワタ＼(^o^)／しました。
そこでまあこの際だしということで react-router のバージョンをあげるか。と軽い気持ちではじめたらまぁ大変で…。 ということがありました。
定期的に、各ライブラリはバージョン追従していかないと痛い目を見るというのをマジマジとアレしました…。
💪あとはガシガシ進めるだけ
という感じでもろもろ進めるために準備を行い、ある程度の品質を担保できる状態をつくり実際にメンバー各位とガッと進めていきました。 ユーザーの詳細ページはなんだかんだいろんな機能があるためそれなりに時間がかかってしまいました。（他の各施策も進めていたので全力でやるというのはできていなかったというのもあります。）
📝QA大会
そして出来上がったものをそのまま出すわけにはいかないので、QAとして既存の機能リストを作りそれが実現できているか、落としても問題ないものなのか等を確認していきました。
YOUTRUSTには「公式リクルーター」というものが存在しており、「公式リクルーター」であるか否かで諸々の情報やユーザーがとることのできるアクションを出し分けたりしています。
また「同所属」、「ブロックされている」、「ブロックしている」、「つながっている」「つながっていない」「申請している」「相手が2次のつながり」…etc...
と言った具合に非常に複雑になっているところがちょいちょいあります。
結果、確認項目としてはPC版のユーザーの詳細ページのみで700以上という感じになっていました。 果てしないな～（）という感じでしたが、先述通り各種複雑な分岐等々が存在しており「まあそうなるよね（）」というような感じでした。
結果いろいろな部分で「ここがおかしい」という箇所がいくつかでてきてました。 また実際にリリースしたあとも各種問題も出てきていました。
反省点としては - サービスへの理解・仕様の理解が足りていなかった - 本番同様のデータを使いテストすべきだった
というのがあります。
サービスへの理解・仕様の理解が足りていなかった
先述通り、YOUTRUSTでは自分の状態・相手の状態等々で何が見えて何ができるのかというのがとても複雑になっています。
これは、サービスの性質上「同じ所属の人にはこれを見せない」ということや、「2次のつながりまでにスカウトが送れる」といったところ等々があり必要である部分があるところではあるのですが、誰がどういう行動を取ってほしいのかといったところへの解像度が低いまま進めてしまったというのが大きく問題があったのかなと考えています。
その上で「これは今ほんとうに必要なのか？」というような仕様等も存在しており、それがどういった背景で作られたものなのか等もわからないところがちょいちょいありました。
とは言っても、このタイミングで仕様の背景に関して、改めて確認ができたり分からないところが何かを知れたのは、よかった点としてあるのかなと考えています。
このあたりは日々自分たちもサービスを積極的に使いながら、サービスへの理解や複雑な仕様へ向き合って適切な形にしていけるようにしていくべきだなと深く思いました。
本番同様のデータを使いテストすべきだった
YOUTRUSTはサービスの特性上、いろんな登場人物が必要でそれがそろってやっととれるアクション、見える情報等々があります。 特定のロールで見えるものやそのロールだから見えないもの、各状態によって様々です。
なので、こういった複雑な状況をつくらないとテストができないというふうになっていました。
複雑な状況はつくることができ確認自体もできてはいたのですが、それでもさらにもう一つ条件が増えた場合等々がありそこまでちゃんと見切れていなかったという箇所がいくつかありました。
またなにかの数がn以上m以下だと問題が発生する等々もあり、テストの環境ではそういったところまで気が回らず見切れていなかったというのがありました。
そういうのがあったため、やはりこういうものの確認は本番同様の環境・データを使用したほうがよいなと思いました。
まとめ
もろもろ振り返ってみて、現状の設計に向き合い良い形にしていくという活動はやはり大事だなぁと感じました。 ずっと作り続けていると今の状態を見直すというのはなかなか難しくなっていくのかなぁというのがあり、気づいたタイミングで少しづつでもやっていけるようにするのは大事だなぁととても感じました。
今回はPCのユーザーのプロフィール画面のみ置き換えた形でしたが、引き続き理想のユーザー体験を実現できるようにするための活動は続けていきたいと思います！
🙋採用情報
YOUTRUSTでは、理想のユーザー体験を実現するために、共に開発していく仲間を探しています！
*1:LADRは Lightweight Architecture Decision Records のことで簡単に説明すると、アーキテクチャ等々を決める上で「どういうことを導入したか」「しなかったか」という判断（Decision）を記録し残していくドキュメントになります。 これを書き残しておくことで、当時なぜそれを「選定したのか」「しなかったのか」というの判断の情報が残り、あとから見た際に「なるほどな～～～」となりやすくなります（雑）。 詳しくはLADRでググるともっとちゃんとした記事がでてくると思いますのでよろしくお願いします🙏
