こんにちは、メドレー広報の阿部です。先日開催された Developers Summit（デブサミ）2018 に、メドレーの CTO ・平山が登壇しました。 デブサミの今回のテーマは「 変わるもの × 変わらないもの 」。 レガシーな業界がインターネットの力で変わりつつある、その面白さをエンジニアに知ってもらえたらいいですね、と CodeZine ／ EdTechZine 編集長の斉木さんと盛り上がったことで、トークセッションが実現。 「医療 ×IT」としてメドレー CTO ・平山が、「金融 ×IT」としてマネーフォワード CTO ・中出さんが、「飲食 ×IT」としてトレタ CTO ・増井さん が登壇。ファシリテーターに   CodeZine／EdTechZine 編集長の斉木さんをお迎えしての実施となりました。 どんな話が飛び出したのか、一部ではありますが紹介します！ そもそも X-Tech って？  斉木さんは冒頭で、X-Tech について「 IT の導入が遅れている業界において、 スタートアップが洗練された IT 技術により新たな価値や仕組みを提供する動き 」と定義。実際に各事業ではどういう感じか？と話が進みました。 Fintech の将来像として「 キャッシュレス社会を実現したい 。お店にとって、現金って本当は不便なもののはず。毎日お釣り金を準備しないといけないし、あまり大金をお店に置いておけないから、定期的に銀行に入金しに行ったりしているのが現状。そういう煩わしさを、少しずつ無くしていきたいですね」と、マネーフォワード・中出さん。 お金＝現金というような”当たり前”が深く根ざしているのは、医療の世界も同様です。 「医療は、未だに紙のカルテや FAX 文化が残っていたり、そもそもインターネットが浸透していない。もちろん医療システムもありますが、医師や医療従事者の言うことをそのまま聞いて作ったというものも多くて、 全体最適が取れていない という課題もあります」と弊社・平山も話します。 多くの店舗に共通する課題を本質的に解決していくことが大切 X-Tech では、インターネットサービスにより大きな変化がおこる分、これまで使い慣れていないサービスだけに、様々な改善要望が入ることも少なくありません。 「実際にサービスを使って頂いている飲食店から様々な要望を頂くのですが、弊社は一切カスタマイズをしない、というスタンスをとっています。飲食店の価格やタイプは様々だけど、突き詰めると実は課題は共通していたりする。ヒアリングしながら、 本質的な課題を見つけて、解決策を提供する ようにしています」と、予約/顧客管理サービス「 トレタ 」を提供するトレタ・増井さん。 これは医療でも同様で「レガシーな業界だと、医師のいう通りにプロダクトを作ることに従うなどの関係性も生まれやすいという状況はあります。でもそこは、 専門分野が違う対等な存在と捉えて、プライドを持って議論をできることが大切 ですよね」と平山も答えます。 X-Tech で活躍できるエンジニアは？ CTO 対談ということもあり、話は「X-Tech を支える組織作り」に。 会社で働くエンジニアの特徴や求められるものを聞かれると、 「飲食経験者が多いわけではないのですが、食べるのが好きな人は多い。社員同士で食事に行くことも多く、たまにエンゲル計数大丈夫かなと思います（笑）。スタートアップだからこそ、求められる役割が固定されず日々変わっています。有機的に変わることに抵抗感がないことが大切ですね」と、増井さん。 中出さんも「たしかに、世の中の課題解決へのモチベーションが強いと思う」とこれに同意。さらに平山も「 プロダクトに誇りを持っている人が多い ですよね」と続けました。 X-Tech ならではの開発チームって？ 最後に、組織づくりや採用で気をつけていることには、各社こんな回答がありました。 「マネーフォワードでは、プロダクトごとにチームを組んでいて、 スモールチームで運営することを心がけています 。技術選定も含めて、そのチームが使うべきと判断したらいいと。共有化も大切ですが、それが足かせになることもある。私が CTO になってから、そういうものは最低限に整理しました。」 （中出さん） 「採用はずっと頑張っているけど、ずっと足りていません。もともと経験的にシニア〜ミドル層を採用したいと考えていましたが、現在はジュニアまで幅を広げています。ただ、スタートアップでは残念ながらゼロからプログラムを教える余裕はないことが多い。だからこそ” 僕らが何を与えられるのか”をすごく考えています 。技術やビジネスマナーのイロハは十分に教えられないけれど、業界や技術の面白さはトレタだからこそ与えられることがあると思う。」（増井さん） 「今メドレーはエンジニアとデザイナー、ディレクター、医師で 30 人くらいの開発チームですが、 職種間の隙間をなくすことを徹底しています 。iOS エンジニア、サーバサイド、フロントエンド、と担当を分けることで情報断絶が起きる。ミッションによって人をアサインし、職種を横断して取り組める環境を作っています」（平山） 最後に平山は「X-Tech は Web エンジニアのものと思われがちですが、toB 向けに広く展開しているプロダクトが多く、（デブサミの参加者に多いような）SIer 系のエンジニアの方にも近しい匂いを感じてもらえる世界だと思う。ぜひ次のキャリアとして、インターネットの会社も選択肢にあるんだというのを思っていただけると嬉しいです！」と力強くコメントして、セッションを締めました。 2 月には「 日経 xTECH 」が創刊されるなど、ますます注目の X-Tech 分野。 どんなことができる業界なのか、メドレーはどんなビジョンに向けて動いているのかなど、もっと話を聞いてみたいという方は、ぜひご連絡ください！ www.wantedly.com

こんにちは、メドレー広報の阿部です。先日開催された Developers Summit（デブサミ）2018 に、メドレーの CTO ・平山が登壇しました。 デブサミの今回のテーマは「 変わるもの × 変わらないもの 」。 レガシーな業界がインターネットの力で変わりつつある、その面白さをエンジニアに知ってもらえたらいいですね、と CodeZine ／ EdTechZine 編集長の斉木さんと盛り上がったことで、トークセッションが実現。 「医療 ×IT」としてメドレー CTO ・平山が、「金融 ×IT」としてマネーフォワード CTO ・中出さんが、「飲食 ×IT」としてトレタ CTO ・増井さん が登壇。ファシリテーターに   CodeZine／EdTechZine 編集長の斉木さんをお迎えしての実施となりました。 どんな話が飛び出したのか、一部ではありますが紹介します！ そもそも X-Tech って？  斉木さんは冒頭で、X-Tech について「 IT の導入が遅れている業界において、 スタートアップが洗練された IT 技術により新たな価値や仕組みを提供する動き 」と定義。実際に各事業ではどういう感じか？と話が進みました。 Fintech の将来像として「 キャッシュレス社会を実現したい 。お店にとって、現金って本当は不便なもののはず。毎日お釣り金を準備しないといけないし、あまり大金をお店に置いておけないから、定期的に銀行に入金しに行ったりしているのが現状。そういう煩わしさを、少しずつ無くしていきたいですね」と、マネーフォワード・中出さん。 お金＝現金というような”当たり前”が深く根ざしているのは、医療の世界も同様です。 「医療は、未だに紙のカルテや FAX 文化が残っていたり、そもそもインターネットが浸透していない。もちろん医療システムもありますが、医師や医療従事者の言うことをそのまま聞いて作ったというものも多くて、 全体最適が取れていない という課題もあります」と弊社・平山も話します。 多くの店舗に共通する課題を本質的に解決していくことが大切 X-Tech では、インターネットサービスにより大きな変化がおこる分、これまで使い慣れていないサービスだけに、様々な改善要望が入ることも少なくありません。 「実際にサービスを使って頂いている飲食店から様々な要望を頂くのですが、弊社は一切カスタマイズをしない、というスタンスをとっています。飲食店の価格やタイプは様々だけど、突き詰めると実は課題は共通していたりする。ヒアリングしながら、 本質的な課題を見つけて、解決策を提供する ようにしています」と、予約/顧客管理サービス「 トレタ 」を提供するトレタ・増井さん。 これは医療でも同様で「レガシーな業界だと、医師のいう通りにプロダクトを作ることに従うなどの関係性も生まれやすいという状況はあります。でもそこは、 専門分野が違う対等な存在と捉えて、プライドを持って議論をできることが大切 ですよね」と平山も答えます。 X-Tech で活躍できるエンジニアは？ CTO 対談ということもあり、話は「X-Tech を支える組織作り」に。 会社で働くエンジニアの特徴や求められるものを聞かれると、 「飲食経験者が多いわけではないのですが、食べるのが好きな人は多い。社員同士で食事に行くことも多く、たまにエンゲル計数大丈夫かなと思います（笑）。スタートアップだからこそ、求められる役割が固定されず日々変わっています。有機的に変わることに抵抗感がないことが大切ですね」と、増井さん。 中出さんも「たしかに、世の中の課題解決へのモチベーションが強いと思う」とこれに同意。さらに平山も「 プロダクトに誇りを持っている人が多い ですよね」と続けました。 X-Tech ならではの開発チームって？ 最後に、組織づくりや採用で気をつけていることには、各社こんな回答がありました。 「マネーフォワードでは、プロダクトごとにチームを組んでいて、 スモールチームで運営することを心がけています 。技術選定も含めて、そのチームが使うべきと判断したらいいと。共有化も大切ですが、それが足かせになることもある。私が CTO になってから、そういうものは最低限に整理しました。」 （中出さん） 「採用はずっと頑張っているけど、ずっと足りていません。もともと経験的にシニア〜ミドル層を採用したいと考えていましたが、現在はジュニアまで幅を広げています。ただ、スタートアップでは残念ながらゼロからプログラムを教える余裕はないことが多い。だからこそ” 僕らが何を与えられるのか”をすごく考えています 。技術やビジネスマナーのイロハは十分に教えられないけれど、業界や技術の面白さはトレタだからこそ与えられることがあると思う。」（増井さん） 「今メドレーはエンジニアとデザイナー、ディレクター、医師で 30 人くらいの開発チームですが、 職種間の隙間をなくすことを徹底しています 。iOS エンジニア、サーバサイド、フロントエンド、と担当を分けることで情報断絶が起きる。ミッションによって人をアサインし、職種を横断して取り組める環境を作っています」（平山） 最後に平山は「X-Tech は Web エンジニアのものと思われがちですが、toB 向けに広く展開しているプロダクトが多く、（デブサミの参加者に多いような）SIer 系のエンジニアの方にも近しい匂いを感じてもらえる世界だと思う。ぜひ次のキャリアとして、インターネットの会社も選択肢にあるんだというのを思っていただけると嬉しいです！」と力強くコメントして、セッションを締めました。 2 月には「 日経 xTECH 」が創刊されるなど、ますます注目の X-Tech 分野。 どんなことができる業界なのか、メドレーはどんなビジョンに向けて動いているのかなど、もっと話を聞いてみたいという方は、ぜひご連絡ください！ www.wantedly.com

こんにちは、メドレー広報の阿部です。先日開催された Developers Summit（デブサミ）2018 に、メドレーの CTO ・平山が登壇しました。 デブサミの今回のテーマは「 変わるもの × 変わらないもの 」。 レガシーな業界がインターネットの力で変わりつつある、その面白さをエンジニアに知ってもらえたらいいですね、と CodeZine ／ EdTechZine 編集長の斉木さんと盛り上がったことで、トークセッションが実現。 「医療 ×IT」としてメドレー CTO ・平山が、「金融 ×IT」としてマネーフォワード CTO ・中出さんが、「飲食 ×IT」としてトレタ CTO ・増井さん が登壇。ファシリテーターに   CodeZine／EdTechZine 編集長の斉木さんをお迎えしての実施となりました。 どんな話が飛び出したのか、一部ではありますが紹介します！ そもそも X-Tech って？  斉木さんは冒頭で、X-Tech について「 IT の導入が遅れている業界において、 スタートアップが洗練された IT 技術により新たな価値や仕組みを提供する動き 」と定義。実際に各事業ではどういう感じか？と話が進みました。 Fintech の将来像として「 キャッシュレス社会を実現したい 。お店にとって、現金って本当は不便なもののはず。毎日お釣り金を準備しないといけないし、あまり大金をお店に置いておけないから、定期的に銀行に入金しに行ったりしているのが現状。そういう煩わしさを、少しずつ無くしていきたいですね」と、マネーフォワード・中出さん。 お金＝現金というような”当たり前”が深く根ざしているのは、医療の世界も同様です。 「医療は、未だに紙のカルテや FAX 文化が残っていたり、そもそもインターネットが浸透していない。もちろん医療システムもありますが、医師や医療従事者の言うことをそのまま聞いて作ったというものも多くて、 全体最適が取れていない という課題もあります」と弊社・平山も話します。 多くの店舗に共通する課題を本質的に解決していくことが大切 X-Tech では、インターネットサービスにより大きな変化がおこる分、これまで使い慣れていないサービスだけに、様々な改善要望が入ることも少なくありません。 「実際にサービスを使って頂いている飲食店から様々な要望を頂くのですが、弊社は一切カスタマイズをしない、というスタンスをとっています。飲食店の価格やタイプは様々だけど、突き詰めると実は課題は共通していたりする。ヒアリングしながら、 本質的な課題を見つけて、解決策を提供する ようにしています」と、予約/顧客管理サービス「 トレタ 」を提供するトレタ・増井さん。 これは医療でも同様で「レガシーな業界だと、医師のいう通りにプロダクトを作ることに従うなどの関係性も生まれやすいという状況はあります。でもそこは、 専門分野が違う対等な存在と捉えて、プライドを持って議論をできることが大切 ですよね」と平山も答えます。 X-Tech で活躍できるエンジニアは？ CTO 対談ということもあり、話は「X-Tech を支える組織作り」に。 会社で働くエンジニアの特徴や求められるものを聞かれると、 「飲食経験者が多いわけではないのですが、食べるのが好きな人は多い。社員同士で食事に行くことも多く、たまにエンゲル計数大丈夫かなと思います（笑）。スタートアップだからこそ、求められる役割が固定されず日々変わっています。有機的に変わることに抵抗感がないことが大切ですね」と、増井さん。 中出さんも「たしかに、世の中の課題解決へのモチベーションが強いと思う」とこれに同意。さらに平山も「 プロダクトに誇りを持っている人が多い ですよね」と続けました。 X-Tech ならではの開発チームって？ 最後に、組織づくりや採用で気をつけていることには、各社こんな回答がありました。 「マネーフォワードでは、プロダクトごとにチームを組んでいて、 スモールチームで運営することを心がけています 。技術選定も含めて、そのチームが使うべきと判断したらいいと。共有化も大切ですが、それが足かせになることもある。私が CTO になってから、そういうものは最低限に整理しました。」 （中出さん） 「採用はずっと頑張っているけど、ずっと足りていません。もともと経験的にシニア〜ミドル層を採用したいと考えていましたが、現在はジュニアまで幅を広げています。ただ、スタートアップでは残念ながらゼロからプログラムを教える余裕はないことが多い。だからこそ” 僕らが何を与えられるのか”をすごく考えています 。技術やビジネスマナーのイロハは十分に教えられないけれど、業界や技術の面白さはトレタだからこそ与えられることがあると思う。」（増井さん） 「今メドレーはエンジニアとデザイナー、ディレクター、医師で 30 人くらいの開発チームですが、 職種間の隙間をなくすことを徹底しています 。iOS エンジニア、サーバサイド、フロントエンド、と担当を分けることで情報断絶が起きる。ミッションによって人をアサインし、職種を横断して取り組める環境を作っています」（平山） 最後に平山は「X-Tech は Web エンジニアのものと思われがちですが、toB 向けに広く展開しているプロダクトが多く、（デブサミの参加者に多いような）SIer 系のエンジニアの方にも近しい匂いを感じてもらえる世界だと思う。ぜひ次のキャリアとして、インターネットの会社も選択肢にあるんだというのを思っていただけると嬉しいです！」と力強くコメントして、セッションを締めました。 2 月には「 日経 xTECH 」が創刊されるなど、ますます注目の X-Tech 分野。 どんなことができる業界なのか、メドレーはどんなビジョンに向けて動いているのかなど、もっと話を聞いてみたいという方は、ぜひご連絡ください！ www.wantedly.com

こんにちは、メドレー広報の阿部です。先日開催された Developers Summit（デブサミ）2018 に、メドレーの CTO ・平山が登壇しました。 デブサミの今回のテーマは「 変わるもの × 変わらないもの 」。 レガシーな業界がインターネットの力で変わりつつある、その面白さをエンジニアに知ってもらえたらいいですね、と CodeZine ／ EdTechZine 編集長の斉木さんと盛り上がったことで、トークセッションが実現。 「医療 ×IT」としてメドレー CTO ・平山が、「金融 ×IT」としてマネーフォワード CTO ・中出さんが、「飲食 ×IT」としてトレタ CTO ・増井さん が登壇。ファシリテーターに   CodeZine／EdTechZine 編集長の斉木さんをお迎えしての実施となりました。 どんな話が飛び出したのか、一部ではありますが紹介します！ そもそも X-Tech って？  斉木さんは冒頭で、X-Tech について「 IT の導入が遅れている業界において、 スタートアップが洗練された IT 技術により新たな価値や仕組みを提供する動き 」と定義。実際に各事業ではどういう感じか？と話が進みました。 Fintech の将来像として「 キャッシュレス社会を実現したい 。お店にとって、現金って本当は不便なもののはず。毎日お釣り金を準備しないといけないし、あまり大金をお店に置いておけないから、定期的に銀行に入金しに行ったりしているのが現状。そういう煩わしさを、少しずつ無くしていきたいですね」と、マネーフォワード・中出さん。 お金＝現金というような”当たり前”が深く根ざしているのは、医療の世界も同様です。 「医療は、未だに紙のカルテや FAX 文化が残っていたり、そもそもインターネットが浸透していない。もちろん医療システムもありますが、医師や医療従事者の言うことをそのまま聞いて作ったというものも多くて、 全体最適が取れていない という課題もあります」と弊社・平山も話します。 多くの店舗に共通する課題を本質的に解決していくことが大切 X-Tech では、インターネットサービスにより大きな変化がおこる分、これまで使い慣れていないサービスだけに、様々な改善要望が入ることも少なくありません。 「実際にサービスを使って頂いている飲食店から様々な要望を頂くのですが、弊社は一切カスタマイズをしない、というスタンスをとっています。飲食店の価格やタイプは様々だけど、突き詰めると実は課題は共通していたりする。ヒアリングしながら、 本質的な課題を見つけて、解決策を提供する ようにしています」と、予約/顧客管理サービス「 トレタ 」を提供するトレタ・増井さん。 これは医療でも同様で「レガシーな業界だと、医師のいう通りにプロダクトを作ることに従うなどの関係性も生まれやすいという状況はあります。でもそこは、 専門分野が違う対等な存在と捉えて、プライドを持って議論をできることが大切 ですよね」と平山も答えます。 X-Tech で活躍できるエンジニアは？ CTO 対談ということもあり、話は「X-Tech を支える組織作り」に。 会社で働くエンジニアの特徴や求められるものを聞かれると、 「飲食経験者が多いわけではないのですが、食べるのが好きな人は多い。社員同士で食事に行くことも多く、たまにエンゲル計数大丈夫かなと思います（笑）。スタートアップだからこそ、求められる役割が固定されず日々変わっています。有機的に変わることに抵抗感がないことが大切ですね」と、増井さん。 中出さんも「たしかに、世の中の課題解決へのモチベーションが強いと思う」とこれに同意。さらに平山も「 プロダクトに誇りを持っている人が多い ですよね」と続けました。 X-Tech ならではの開発チームって？ 最後に、組織づくりや採用で気をつけていることには、各社こんな回答がありました。 「マネーフォワードでは、プロダクトごとにチームを組んでいて、 スモールチームで運営することを心がけています 。技術選定も含めて、そのチームが使うべきと判断したらいいと。共有化も大切ですが、それが足かせになることもある。私が CTO になってから、そういうものは最低限に整理しました。」 （中出さん） 「採用はずっと頑張っているけど、ずっと足りていません。もともと経験的にシニア〜ミドル層を採用したいと考えていましたが、現在はジュニアまで幅を広げています。ただ、スタートアップでは残念ながらゼロからプログラムを教える余裕はないことが多い。だからこそ” 僕らが何を与えられるのか”をすごく考えています 。技術やビジネスマナーのイロハは十分に教えられないけれど、業界や技術の面白さはトレタだからこそ与えられることがあると思う。」（増井さん） 「今メドレーはエンジニアとデザイナー、ディレクター、医師で 30 人くらいの開発チームですが、 職種間の隙間をなくすことを徹底しています 。iOS エンジニア、サーバサイド、フロントエンド、と担当を分けることで情報断絶が起きる。ミッションによって人をアサインし、職種を横断して取り組める環境を作っています」（平山） 最後に平山は「X-Tech は Web エンジニアのものと思われがちですが、toB 向けに広く展開しているプロダクトが多く、（デブサミの参加者に多いような）SIer 系のエンジニアの方にも近しい匂いを感じてもらえる世界だと思う。ぜひ次のキャリアとして、インターネットの会社も選択肢にあるんだというのを思っていただけると嬉しいです！」と力強くコメントして、セッションを締めました。 2 月には「 日経 xTECH 」が創刊されるなど、ますます注目の X-Tech 分野。 どんなことができる業界なのか、メドレーはどんなビジョンに向けて動いているのかなど、もっと話を聞いてみたいという方は、ぜひご連絡ください！ www.wantedly.com

こんにちは、メドレー広報の阿部です。先日開催された Developers Summit（デブサミ）2018 に、メドレーの CTO ・平山が登壇しました。 デブサミの今回のテーマは「 変わるもの × 変わらないもの 」。 レガシーな業界がインターネットの力で変わりつつある、その面白さをエンジニアに知ってもらえたらいいですね、と CodeZine ／ EdTechZine 編集長の斉木さんと盛り上がったことで、トークセッションが実現。 「医療 ×IT」としてメドレー CTO ・平山が、「金融 ×IT」としてマネーフォワード CTO ・中出さんが、「飲食 ×IT」としてトレタ CTO ・増井さん が登壇。ファシリテーターに   CodeZine／EdTechZine 編集長の斉木さんをお迎えしての実施となりました。 どんな話が飛び出したのか、一部ではありますが紹介します！ そもそも X-Tech って？  斉木さんは冒頭で、X-Tech について「 IT の導入が遅れている業界において、 スタートアップが洗練された IT 技術により新たな価値や仕組みを提供する動き 」と定義。実際に各事業ではどういう感じか？と話が進みました。 Fintech の将来像として「 キャッシュレス社会を実現したい 。お店にとって、現金って本当は不便なもののはず。毎日お釣り金を準備しないといけないし、あまり大金をお店に置いておけないから、定期的に銀行に入金しに行ったりしているのが現状。そういう煩わしさを、少しずつ無くしていきたいですね」と、マネーフォワード・中出さん。 お金＝現金というような”当たり前”が深く根ざしているのは、医療の世界も同様です。 「医療は、未だに紙のカルテや FAX 文化が残っていたり、そもそもインターネットが浸透していない。もちろん医療システムもありますが、医師や医療従事者の言うことをそのまま聞いて作ったというものも多くて、 全体最適が取れていない という課題もあります」と弊社・平山も話します。 多くの店舗に共通する課題を本質的に解決していくことが大切 X-Tech では、インターネットサービスにより大きな変化がおこる分、これまで使い慣れていないサービスだけに、様々な改善要望が入ることも少なくありません。 「実際にサービスを使って頂いている飲食店から様々な要望を頂くのですが、弊社は一切カスタマイズをしない、というスタンスをとっています。飲食店の価格やタイプは様々だけど、突き詰めると実は課題は共通していたりする。ヒアリングしながら、 本質的な課題を見つけて、解決策を提供する ようにしています」と、予約/顧客管理サービス「 トレタ 」を提供するトレタ・増井さん。 これは医療でも同様で「レガシーな業界だと、医師のいう通りにプロダクトを作ることに従うなどの関係性も生まれやすいという状況はあります。でもそこは、 専門分野が違う対等な存在と捉えて、プライドを持って議論をできることが大切 ですよね」と平山も答えます。 X-Tech で活躍できるエンジニアは？ CTO 対談ということもあり、話は「X-Tech を支える組織作り」に。 会社で働くエンジニアの特徴や求められるものを聞かれると、 「飲食経験者が多いわけではないのですが、食べるのが好きな人は多い。社員同士で食事に行くことも多く、たまにエンゲル計数大丈夫かなと思います（笑）。スタートアップだからこそ、求められる役割が固定されず日々変わっています。有機的に変わることに抵抗感がないことが大切ですね」と、増井さん。 中出さんも「たしかに、世の中の課題解決へのモチベーションが強いと思う」とこれに同意。さらに平山も「 プロダクトに誇りを持っている人が多い ですよね」と続けました。 X-Tech ならではの開発チームって？ 最後に、組織づくりや採用で気をつけていることには、各社こんな回答がありました。 「マネーフォワードでは、プロダクトごとにチームを組んでいて、 スモールチームで運営することを心がけています 。技術選定も含めて、そのチームが使うべきと判断したらいいと。共有化も大切ですが、それが足かせになることもある。私が CTO になってから、そういうものは最低限に整理しました。」 （中出さん） 「採用はずっと頑張っているけど、ずっと足りていません。もともと経験的にシニア〜ミドル層を採用したいと考えていましたが、現在はジュニアまで幅を広げています。ただ、スタートアップでは残念ながらゼロからプログラムを教える余裕はないことが多い。だからこそ” 僕らが何を与えられるのか”をすごく考えています 。技術やビジネスマナーのイロハは十分に教えられないけれど、業界や技術の面白さはトレタだからこそ与えられることがあると思う。」（増井さん） 「今メドレーはエンジニアとデザイナー、ディレクター、医師で 30 人くらいの開発チームですが、 職種間の隙間をなくすことを徹底しています 。iOS エンジニア、サーバサイド、フロントエンド、と担当を分けることで情報断絶が起きる。ミッションによって人をアサインし、職種を横断して取り組める環境を作っています」（平山） 最後に平山は「X-Tech は Web エンジニアのものと思われがちですが、toB 向けに広く展開しているプロダクトが多く、（デブサミの参加者に多いような）SIer 系のエンジニアの方にも近しい匂いを感じてもらえる世界だと思う。ぜひ次のキャリアとして、インターネットの会社も選択肢にあるんだというのを思っていただけると嬉しいです！」と力強くコメントして、セッションを締めました。 2 月には「 日経 xTECH 」が創刊されるなど、ますます注目の X-Tech 分野。 どんなことができる業界なのか、メドレーはどんなビジョンに向けて動いているのかなど、もっと話を聞いてみたいという方は、ぜひご連絡ください！ www.wantedly.com

こんにちは、メドレー広報の阿部です。先日開催された Developers Summit（デブサミ）2018 に、メドレーの CTO ・平山が登壇しました。 デブサミの今回のテーマは「 変わるもの × 変わらないもの 」。 レガシーな業界がインターネットの力で変わりつつある、その面白さをエンジニアに知ってもらえたらいいですね、と CodeZine ／ EdTechZine 編集長の斉木さんと盛り上がったことで、トークセッションが実現。 「医療 ×IT」としてメドレー CTO ・平山が、「金融 ×IT」としてマネーフォワード CTO ・中出さんが、「飲食 ×IT」としてトレタ CTO ・増井さん が登壇。ファシリテーターに   CodeZine／EdTechZine 編集長の斉木さんをお迎えしての実施となりました。 どんな話が飛び出したのか、一部ではありますが紹介します！ そもそも X-Tech って？  斉木さんは冒頭で、X-Tech について「 IT の導入が遅れている業界において、 スタートアップが洗練された IT 技術により新たな価値や仕組みを提供する動き 」と定義。実際に各事業ではどういう感じか？と話が進みました。 Fintech の将来像として「 キャッシュレス社会を実現したい 。お店にとって、現金って本当は不便なもののはず。毎日お釣り金を準備しないといけないし、あまり大金をお店に置いておけないから、定期的に銀行に入金しに行ったりしているのが現状。そういう煩わしさを、少しずつ無くしていきたいですね」と、マネーフォワード・中出さん。 お金＝現金というような”当たり前”が深く根ざしているのは、医療の世界も同様です。 「医療は、未だに紙のカルテや FAX 文化が残っていたり、そもそもインターネットが浸透していない。もちろん医療システムもありますが、医師や医療従事者の言うことをそのまま聞いて作ったというものも多くて、 全体最適が取れていない という課題もあります」と弊社・平山も話します。 多くの店舗に共通する課題を本質的に解決していくことが大切 X-Tech では、インターネットサービスにより大きな変化がおこる分、これまで使い慣れていないサービスだけに、様々な改善要望が入ることも少なくありません。 「実際にサービスを使って頂いている飲食店から様々な要望を頂くのですが、弊社は一切カスタマイズをしない、というスタンスをとっています。飲食店の価格やタイプは様々だけど、突き詰めると実は課題は共通していたりする。ヒアリングしながら、 本質的な課題を見つけて、解決策を提供する ようにしています」と、予約/顧客管理サービス「 トレタ 」を提供するトレタ・増井さん。 これは医療でも同様で「レガシーな業界だと、医師のいう通りにプロダクトを作ることに従うなどの関係性も生まれやすいという状況はあります。でもそこは、 専門分野が違う対等な存在と捉えて、プライドを持って議論をできることが大切 ですよね」と平山も答えます。 X-Tech で活躍できるエンジニアは？ CTO 対談ということもあり、話は「X-Tech を支える組織作り」に。 会社で働くエンジニアの特徴や求められるものを聞かれると、 「飲食経験者が多いわけではないのですが、食べるのが好きな人は多い。社員同士で食事に行くことも多く、たまにエンゲル計数大丈夫かなと思います（笑）。スタートアップだからこそ、求められる役割が固定されず日々変わっています。有機的に変わることに抵抗感がないことが大切ですね」と、増井さん。 中出さんも「たしかに、世の中の課題解決へのモチベーションが強いと思う」とこれに同意。さらに平山も「 プロダクトに誇りを持っている人が多い ですよね」と続けました。 X-Tech ならではの開発チームって？ 最後に、組織づくりや採用で気をつけていることには、各社こんな回答がありました。 「マネーフォワードでは、プロダクトごとにチームを組んでいて、 スモールチームで運営することを心がけています 。技術選定も含めて、そのチームが使うべきと判断したらいいと。共有化も大切ですが、それが足かせになることもある。私が CTO になってから、そういうものは最低限に整理しました。」 （中出さん） 「採用はずっと頑張っているけど、ずっと足りていません。もともと経験的にシニア〜ミドル層を採用したいと考えていましたが、現在はジュニアまで幅を広げています。ただ、スタートアップでは残念ながらゼロからプログラムを教える余裕はないことが多い。だからこそ” 僕らが何を与えられるのか”をすごく考えています 。技術やビジネスマナーのイロハは十分に教えられないけれど、業界や技術の面白さはトレタだからこそ与えられることがあると思う。」（増井さん） 「今メドレーはエンジニアとデザイナー、ディレクター、医師で 30 人くらいの開発チームですが、 職種間の隙間をなくすことを徹底しています 。iOS エンジニア、サーバサイド、フロントエンド、と担当を分けることで情報断絶が起きる。ミッションによって人をアサインし、職種を横断して取り組める環境を作っています」（平山） 最後に平山は「X-Tech は Web エンジニアのものと思われがちですが、toB 向けに広く展開しているプロダクトが多く、（デブサミの参加者に多いような）SIer 系のエンジニアの方にも近しい匂いを感じてもらえる世界だと思う。ぜひ次のキャリアとして、インターネットの会社も選択肢にあるんだというのを思っていただけると嬉しいです！」と力強くコメントして、セッションを締めました。 2 月には「 日経 xTECH 」が創刊されるなど、ますます注目の X-Tech 分野。 どんなことができる業界なのか、メドレーはどんなビジョンに向けて動いているのかなど、もっと話を聞いてみたいという方は、ぜひご連絡ください！ www.wantedly.com

こんにちは、メドレー広報の阿部です。先日開催された Developers Summit（デブサミ）2018 に、メドレーの CTO ・平山が登壇しました。 デブサミの今回のテーマは「 変わるもの × 変わらないもの 」。 レガシーな業界がインターネットの力で変わりつつある、その面白さをエンジニアに知ってもらえたらいいですね、と CodeZine ／ EdTechZine 編集長の斉木さんと盛り上がったことで、トークセッションが実現。 「医療 ×IT」としてメドレー CTO ・平山が、「金融 ×IT」としてマネーフォワード CTO ・中出さんが、「飲食 ×IT」としてトレタ CTO ・増井さん が登壇。ファシリテーターに   CodeZine／EdTechZine 編集長の斉木さんをお迎えしての実施となりました。 どんな話が飛び出したのか、一部ではありますが紹介します！ そもそも X-Tech って？  斉木さんは冒頭で、X-Tech について「 IT の導入が遅れている業界において、 スタートアップが洗練された IT 技術により新たな価値や仕組みを提供する動き 」と定義。実際に各事業ではどういう感じか？と話が進みました。 Fintech の将来像として「 キャッシュレス社会を実現したい 。お店にとって、現金って本当は不便なもののはず。毎日お釣り金を準備しないといけないし、あまり大金をお店に置いておけないから、定期的に銀行に入金しに行ったりしているのが現状。そういう煩わしさを、少しずつ無くしていきたいですね」と、マネーフォワード・中出さん。 お金＝現金というような”当たり前”が深く根ざしているのは、医療の世界も同様です。 「医療は、未だに紙のカルテや FAX 文化が残っていたり、そもそもインターネットが浸透していない。もちろん医療システムもありますが、医師や医療従事者の言うことをそのまま聞いて作ったというものも多くて、 全体最適が取れていない という課題もあります」と弊社・平山も話します。 多くの店舗に共通する課題を本質的に解決していくことが大切 X-Tech では、インターネットサービスにより大きな変化がおこる分、これまで使い慣れていないサービスだけに、様々な改善要望が入ることも少なくありません。 「実際にサービスを使って頂いている飲食店から様々な要望を頂くのですが、弊社は一切カスタマイズをしない、というスタンスをとっています。飲食店の価格やタイプは様々だけど、突き詰めると実は課題は共通していたりする。ヒアリングしながら、 本質的な課題を見つけて、解決策を提供する ようにしています」と、予約/顧客管理サービス「 トレタ 」を提供するトレタ・増井さん。 これは医療でも同様で「レガシーな業界だと、医師のいう通りにプロダクトを作ることに従うなどの関係性も生まれやすいという状況はあります。でもそこは、 専門分野が違う対等な存在と捉えて、プライドを持って議論をできることが大切 ですよね」と平山も答えます。 X-Tech で活躍できるエンジニアは？ CTO 対談ということもあり、話は「X-Tech を支える組織作り」に。 会社で働くエンジニアの特徴や求められるものを聞かれると、 「飲食経験者が多いわけではないのですが、食べるのが好きな人は多い。社員同士で食事に行くことも多く、たまにエンゲル計数大丈夫かなと思います（笑）。スタートアップだからこそ、求められる役割が固定されず日々変わっています。有機的に変わることに抵抗感がないことが大切ですね」と、増井さん。 中出さんも「たしかに、世の中の課題解決へのモチベーションが強いと思う」とこれに同意。さらに平山も「 プロダクトに誇りを持っている人が多い ですよね」と続けました。 X-Tech ならではの開発チームって？ 最後に、組織づくりや採用で気をつけていることには、各社こんな回答がありました。 「マネーフォワードでは、プロダクトごとにチームを組んでいて、 スモールチームで運営することを心がけています 。技術選定も含めて、そのチームが使うべきと判断したらいいと。共有化も大切ですが、それが足かせになることもある。私が CTO になってから、そういうものは最低限に整理しました。」 （中出さん） 「採用はずっと頑張っているけど、ずっと足りていません。もともと経験的にシニア〜ミドル層を採用したいと考えていましたが、現在はジュニアまで幅を広げています。ただ、スタートアップでは残念ながらゼロからプログラムを教える余裕はないことが多い。だからこそ” 僕らが何を与えられるのか”をすごく考えています 。技術やビジネスマナーのイロハは十分に教えられないけれど、業界や技術の面白さはトレタだからこそ与えられることがあると思う。」（増井さん） 「今メドレーはエンジニアとデザイナー、ディレクター、医師で 30 人くらいの開発チームですが、 職種間の隙間をなくすことを徹底しています 。iOS エンジニア、サーバサイド、フロントエンド、と担当を分けることで情報断絶が起きる。ミッションによって人をアサインし、職種を横断して取り組める環境を作っています」（平山） 最後に平山は「X-Tech は Web エンジニアのものと思われがちですが、toB 向けに広く展開しているプロダクトが多く、（デブサミの参加者に多いような）SIer 系のエンジニアの方にも近しい匂いを感じてもらえる世界だと思う。ぜひ次のキャリアとして、インターネットの会社も選択肢にあるんだというのを思っていただけると嬉しいです！」と力強くコメントして、セッションを締めました。 2 月には「 日経 xTECH 」が創刊されるなど、ますます注目の X-Tech 分野。 どんなことができる業界なのか、メドレーはどんなビジョンに向けて動いているのかなど、もっと話を聞いてみたいという方は、ぜひご連絡ください！ www.wantedly.com

こんにちは、開発本部の舘野です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しています。 昨年、ジョブメドレーでは事業所が利用する採用管理画面の UI リニューアルを行いました。ユーザが使いやすい UI づくりを目指すために、長期間にわたり誰が開発しても一貫性ある UI を実現できるようなシステムが必要です。そこで今回は「Composable」な UI システムの実現をテーマに、どのように開発を行ったのかについて、共有させていただきます。 背景：画面や機能追加のたびに UI の一貫性がなくなっていた ジョブメドレーの採用管理画面とは、医療機関や介護施設の採用担当者が求人情報の管理や応募者の選考状況の管理などを行う画面です。 この採用管理画面ですが、リニューアル以前は Angular をフレームワークとして採用した SPA で、UI に関しては AngularUI の Bootstrap を利用して、それぞれのエンジニアが実装を行っていました。 それなりの UI をスピーディーに実現できる点においては、Bootsrap のような UI フレームワークを利用することで受けられる恩恵は大きかったのですが、一方で、包括的に UI 設計を行っているわけではなく、 各人が局所的に UI を作っていくので、画面や機能を追加していく中で一貫性がない UI が増えていく状態 になっていました。 実際にユーザインタビューなどを行ってみると、「ログインした後どうすれば良いのか分からない」、「〇〇という機能があることを今まで知らなかった」、「xx がどこにあるのか分からない」などの意見が多々あり、全面的な UI の見直しが必要になっていました。 医療や介護の現場での人材不足を解消するために採用担当者に提供するツールとして、今後さらに機能拡充していくことが求められていましたが、機能拡充していくことに耐えうる状態にはないというのがプロダクトチームのメンバーの共通認識でした。 そこで、全体的に情報設計から見直してデザインを刷新し、今後プロダクトを成長させていく上でスケール可能な UI を提供できるようにするため、UI リニューアルを決定しました。 フロントエンドで必要だったこと Bootstrap を用いてエンジニアのみで UI を作っていたのとは異なり、リニューアルでは社内のデザイナーが現状の UI 上の課題を整理したデザインを作成しました。 これに伴って、自前で全ての UI パーツを作成することになりましたが、Bootstrap に頼りきっていたときとは違い、堅牢性と柔軟性を伴った UI システムを自分たちで構築する必要がありました。 リニューアル前の採用管理画面の UI は一貫性に欠けており、ユーザは非常に多くの操作を学ぶ必要がありましたが、この責任はデザイナーだけでなく UI 開発をするエンジニアにも大いにあります。 良いデザインができても、最終的にプロダクトの UI はコードによって作り上げられるものなので、エンジニア次第で一貫性に欠ける UI になってしまうことは十分にあり得ると思います。 往々にして起こり得るのは、目にする機会が比較的少ない画面であったり、改修対象ではない部分などが気づいたら崩れていたり、意図しない UI になってしまっていたりということですが、こういった状況に陥る大きな要因としてはフロントエンドの部分で一貫性に対する配慮ができてないことが 1 つだと思います。 そこで、すでにある採用管理画面を使いやすくするのはもちろん、今後スケールしていく中で 一貫性のある UI を担保し続けていくためには、リニューアルでフロントエンドも堅牢で柔軟な UI システムへと変える必要がありました 。 UI リニューアルで開発上大切にしたこと UI の一貫性を保つとなると、今のフロントエンドではもはや当然のことかもしれませんが、コンポーネント指向で構成することになると思います。 技術選定としては、上述の通りリニューアル以前は Angular（v1.4.11）を利用していましたが、リニューアルのタイミングで React へ移行しました。 React を選択した理由としては、学習コストの点やコミュニティが活発でエコシステムが充実している点、単一方向のデータフロー、シンプルな API などを総合的に判断してのものですが、目下の課題である UI コンポーネントのメンテナビリティに関しても適切な選択肢であると考えました。 CSS の方はというと、リニューアル前は Bootstrap でまかなえない部分は Sass でそれぞれのエンジニアが書きたいように書くという状態でしたが、リニューアルで Sass に加えて一部 PostCSS という構成に変更して、設計は ITCSS、Lint を stylelint で行う、という形にしました。 ITCSS を選択した背景としては、その詳細度順のレイヤー階層によってカスケードを管理しやすい点やレイヤーの増減で容易にスケールできる点などから選択しました。 CSS in JS も考慮はしましたが、リニューアルの時点ではこれという決定的な選択肢が無かったこともあり（まだ styled-components も正式リリースされてなかった）、 classnames を利用しました。 フレームワークやライブラリの選定も重要ですが、UI システムを刷新する上で 開発上最も重視したのは「Composability（コンポーネントの組み合わせが容易であること）」 でした。 Composable であるということは、つまり様々な状況において組み込み可能な状態であり、再利用性が高いということになります。 それぞれのコンポーネントを組み合わせることが容易に出来るとともに、複数のコンポーネントを組み合わせた状態から 1 つ 1 つ分解することも容易な状態が望ましく、結果的にそれで UI が構築しやすく改修しやすい状態に自然となるはずです。 モーダルを例にあげると、モーダルの中で表示するコンテンツ要素やモーダルの背面に敷くオーバーレイコンポーネントは、モーダルコンポーネント自体には含まず別のコンポーネントとして切り出した方が再利用しやすく、組み合わせやすい、ということです。 < ModalFrame > < Modal > < ModalHead > ... </ ModalHead > < ModalBody > ... </ ModalBody > </ Modal > < Overlay /> </ ModalFrame > 上記の例でいうと、モーダルを画面の中央に配置することは <ModalFrame /> が行い、 <Modal /> 自体はモーダルに内包されるコンテンツのコンテナとしての役割だけを持ちます。 <Overlay /> も独立したコンポーネントの 1 つで、モーダル以外とも組み合わせて利用しています。 コンテナとなるコンポーネントとその子となるコンポーネントは、別コンポーネントに分離されていることで、お互いに依存しないようになります。 また、Sass ファイルもこのコンポーネント構成に合わせて分けています。 ITCSS において、 <ModalFrame /> のようなレイアウトのみの役割を持つ場合のスタイルは Objects レイヤー（装飾を持たない UI パターンのレイヤー）となり、装飾を持つ <Modal /> や <Overlay /> は Components レイヤーとして扱います。 @import “objects.modal-frame”; @import “components.modal”; @import “components.overlay”; CSS はその特有のカスケードや詳細度によって決定されるスタイルがあり、依存関係を持たない状態を作ることが困難ですが、ITCSS の考えに則ってそれらの CSS の特徴に逆らわないように詳細度の低いものから順番に @import するようにしています。 Sass ファイルの中身ですが、 _objecst.modal-frame.scss は <ModalFrame /> のスタイルのみを記述するようにします。 .o-modal-frame { position : fixed ; top : 0 ; left : 0 ; right : 0 ; bottom : 0 ; z-index : map-get( $zIndexMap , modalFrame ) ; } _components.modal.scss も同様に <Modal /> のスタイルのみを記述します。 .c-modal { position : relative ; margin : 0 auto ; width : 900 px ; min-width : 640 px ; background-color : $JM-White ; box-shadow : 0 1 px 6 px 0 rgba( $JM-Black , 0.2 ) ; z-index : map-get( $zIndexMap , modal ) ; } このように Sass と React コンポーネント毎に 1 対 1 の関係になるようにしています。 プレフィックスとして付与している c- や o- は ITCSS のレイヤーのことを指します。 o- は Objects レイヤーのプレフィックスで、 c- は Components レイヤーのプレフィックスです。 基本的に React の UI コンポーネント内では、コンポーネントの種別に応じて c- か o- のプレフィックスを持つクラスと、状態によって付けたり外したりする State レイヤーの s- プレフィックスのクラスのみを使用します。 話を React に戻すと、下記のようなヘッダー要素を画面上部に固定表示するだけの役割を持つ <AppBar /> コンポーネントは、 props.children で子要素を受け取れるようになっているだけで、その内容には関知しないようになっています。 const AppBar = ( props ) => { return < div className = "o-app-bar" > { props . children } </ div > ; }; 内包する子コンポーネントが何であれ、 <AppBar /> は自分自身の責任だけを果たせば良いので、開発上もシンプルに考えられます。 className に渡している o-app-bar は ITCSS の Objects レイヤーのクラスです。 .o-app-bar { position : fixed ; top : 0 ; left : 0 ; right : 0 ; z-index : map-get( $zIndexMap , appBar ) ; } ヘッダー要素を画面上部に固定表示する、レイアウトのみの役割を持つコンポーネントなので、Objects レイヤーとなり、 o-app-bar にはレイアウト目的のスタイルのみを持たせます。 ジョブメドレーの採用管理画面では、医療機関や介護施設から求職者に向けた情報を入力していただくために多くのフォーム要素があり、非常に煩雑になりがちですが、 それぞれの役割を果たすコンポーネントを組み合わせることで、UI 開発上の堅牢性、柔軟性を高められる ように努めました。 実際のリニューアル開発時には、全ての UI コンポーネントを実装する前に、開発側ではデザイナーが用意した Sketch から、全ての UI パーツを洗い出す作業を行い、その中で分解不可能なレベルまでコンポーネントを分解していき、実装すべきコンポーネントを一覧化しました。 その後、作成したコンポーネント一覧から全 UI コンポーネントを Storybook に実装していきました。 Storybook は、UI コンポーネント開発のサンドボックス環境として、React や Vue を利用した開発では割と一般的に利用されるようになっていると思います。リニューアル時も各コンポーネントの開発環境として利用して、コンポーネントのパターンや組み合わせの確認などを Storybook 上で行いました。 画面を作っていく段階では、 用意した UI コンポーネントを組み合わせて利用すれば画面全体の大半の UI が出来上がる ようになっていました。 細かい部分では、事前に用意するコンポーネントに不足があったり、実装した後で仕様の変更によりコンポーネント自体を削除することや、分解不可能な状態まで落とし込めてないコンポーネントが見つかったりと、様々な反省点はありました。ですがリニューアル全体を通して振り返ると、Composable な UI コンポーネントで堅牢で柔軟性のある構成にするということに一定の成果は出せたかなと思います。 まとめ UI リニューアル以降、採用管理画面ではリニューアル時の UI システムを土台にして、継続的に機能を追加・改修しています。 プロダクトで設けている KPI も順調に遷移していて、顧客からの問い合わせもリニューアル以前のような、UI 上の問題で利用が困難であるというものは減少し、ポジティブな結果が得られています。 開発をする上でも Composable になるようにコンポーネント群を作成したことで、 リニューアル以降は UI の改修がシンプルに行えるようになり、開発メンバーのスキルセットに左右される部分が少なくなり、開発効率が上がりました 。 このような点からリニューアル自体は良かったと思うと同時に、一方でさらに良い UI を提供するために取り組むべきことは、少なくないと感じます。 例えば採用管理画面が十分にアクセシブルだとは言えないし、パフォーマンス面でもより一層の努力が求められます。もちろん UI コンポーネントの堅牢性もまだ十分とは言えません。 より良いプロダクトを提供するためにそういった課題に対しても継続して取り組んでいきたいと思います。 お知らせ メドレーでは、エンジニア・デザイナーを募集しています。 メドレーでの開発にご興味ある方は、こちらをご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しています。 昨年、ジョブメドレーでは事業所が利用する採用管理画面の UI リニューアルを行いました。ユーザが使いやすい UI づくりを目指すために、長期間にわたり誰が開発しても一貫性ある UI を実現できるようなシステムが必要です。そこで今回は「Composable」な UI システムの実現をテーマに、どのように開発を行ったのかについて、共有させていただきます。 背景：画面や機能追加のたびに UI の一貫性がなくなっていた ジョブメドレーの採用管理画面とは、医療機関や介護施設の採用担当者が求人情報の管理や応募者の選考状況の管理などを行う画面です。 この採用管理画面ですが、リニューアル以前は Angular をフレームワークとして採用した SPA で、UI に関しては AngularUI の Bootstrap を利用して、それぞれのエンジニアが実装を行っていました。 それなりの UI をスピーディーに実現できる点においては、Bootsrap のような UI フレームワークを利用することで受けられる恩恵は大きかったのですが、一方で、包括的に UI 設計を行っているわけではなく、 各人が局所的に UI を作っていくので、画面や機能を追加していく中で一貫性がない UI が増えていく状態 になっていました。 実際にユーザインタビューなどを行ってみると、「ログインした後どうすれば良いのか分からない」、「〇〇という機能があることを今まで知らなかった」、「xx がどこにあるのか分からない」などの意見が多々あり、全面的な UI の見直しが必要になっていました。 医療や介護の現場での人材不足を解消するために採用担当者に提供するツールとして、今後さらに機能拡充していくことが求められていましたが、機能拡充していくことに耐えうる状態にはないというのがプロダクトチームのメンバーの共通認識でした。 そこで、全体的に情報設計から見直してデザインを刷新し、今後プロダクトを成長させていく上でスケール可能な UI を提供できるようにするため、UI リニューアルを決定しました。 フロントエンドで必要だったこと Bootstrap を用いてエンジニアのみで UI を作っていたのとは異なり、リニューアルでは社内のデザイナーが現状の UI 上の課題を整理したデザインを作成しました。 これに伴って、自前で全ての UI パーツを作成することになりましたが、Bootstrap に頼りきっていたときとは違い、堅牢性と柔軟性を伴った UI システムを自分たちで構築する必要がありました。 リニューアル前の採用管理画面の UI は一貫性に欠けており、ユーザは非常に多くの操作を学ぶ必要がありましたが、この責任はデザイナーだけでなく UI 開発をするエンジニアにも大いにあります。 良いデザインができても、最終的にプロダクトの UI はコードによって作り上げられるものなので、エンジニア次第で一貫性に欠ける UI になってしまうことは十分にあり得ると思います。 往々にして起こり得るのは、目にする機会が比較的少ない画面であったり、改修対象ではない部分などが気づいたら崩れていたり、意図しない UI になってしまっていたりということですが、こういった状況に陥る大きな要因としてはフロントエンドの部分で一貫性に対する配慮ができてないことが 1 つだと思います。 そこで、すでにある採用管理画面を使いやすくするのはもちろん、今後スケールしていく中で 一貫性のある UI を担保し続けていくためには、リニューアルでフロントエンドも堅牢で柔軟な UI システムへと変える必要がありました 。 UI リニューアルで開発上大切にしたこと UI の一貫性を保つとなると、今のフロントエンドではもはや当然のことかもしれませんが、コンポーネント指向で構成することになると思います。 技術選定としては、上述の通りリニューアル以前は Angular（v1.4.11）を利用していましたが、リニューアルのタイミングで React へ移行しました。 React を選択した理由としては、学習コストの点やコミュニティが活発でエコシステムが充実している点、単一方向のデータフロー、シンプルな API などを総合的に判断してのものですが、目下の課題である UI コンポーネントのメンテナビリティに関しても適切な選択肢であると考えました。 CSS の方はというと、リニューアル前は Bootstrap でまかなえない部分は Sass でそれぞれのエンジニアが書きたいように書くという状態でしたが、リニューアルで Sass に加えて一部 PostCSS という構成に変更して、設計は ITCSS、Lint を stylelint で行う、という形にしました。 ITCSS を選択した背景としては、その詳細度順のレイヤー階層によってカスケードを管理しやすい点やレイヤーの増減で容易にスケールできる点などから選択しました。 CSS in JS も考慮はしましたが、リニューアルの時点ではこれという決定的な選択肢が無かったこともあり（まだ styled-components も正式リリースされてなかった）、 classnames を利用しました。 フレームワークやライブラリの選定も重要ですが、UI システムを刷新する上で 開発上最も重視したのは「Composability（コンポーネントの組み合わせが容易であること）」 でした。 Composable であるということは、つまり様々な状況において組み込み可能な状態であり、再利用性が高いということになります。 それぞれのコンポーネントを組み合わせることが容易に出来るとともに、複数のコンポーネントを組み合わせた状態から 1 つ 1 つ分解することも容易な状態が望ましく、結果的にそれで UI が構築しやすく改修しやすい状態に自然となるはずです。 モーダルを例にあげると、モーダルの中で表示するコンテンツ要素やモーダルの背面に敷くオーバーレイコンポーネントは、モーダルコンポーネント自体には含まず別のコンポーネントとして切り出した方が再利用しやすく、組み合わせやすい、ということです。 < ModalFrame > < Modal > < ModalHead > ... </ ModalHead > < ModalBody > ... </ ModalBody > </ Modal > < Overlay /> </ ModalFrame > 上記の例でいうと、モーダルを画面の中央に配置することは <ModalFrame /> が行い、 <Modal /> 自体はモーダルに内包されるコンテンツのコンテナとしての役割だけを持ちます。 <Overlay /> も独立したコンポーネントの 1 つで、モーダル以外とも組み合わせて利用しています。 コンテナとなるコンポーネントとその子となるコンポーネントは、別コンポーネントに分離されていることで、お互いに依存しないようになります。 また、Sass ファイルもこのコンポーネント構成に合わせて分けています。 ITCSS において、 <ModalFrame /> のようなレイアウトのみの役割を持つ場合のスタイルは Objects レイヤー（装飾を持たない UI パターンのレイヤー）となり、装飾を持つ <Modal /> や <Overlay /> は Components レイヤーとして扱います。 @import “objects.modal-frame”; @import “components.modal”; @import “components.overlay”; CSS はその特有のカスケードや詳細度によって決定されるスタイルがあり、依存関係を持たない状態を作ることが困難ですが、ITCSS の考えに則ってそれらの CSS の特徴に逆らわないように詳細度の低いものから順番に @import するようにしています。 Sass ファイルの中身ですが、 _objecst.modal-frame.scss は <ModalFrame /> のスタイルのみを記述するようにします。 .o-modal-frame { position : fixed ; top : 0 ; left : 0 ; right : 0 ; bottom : 0 ; z-index : map-get( $zIndexMap , modalFrame ) ; } _components.modal.scss も同様に <Modal /> のスタイルのみを記述します。 .c-modal { position : relative ; margin : 0 auto ; width : 900 px ; min-width : 640 px ; background-color : $JM-White ; box-shadow : 0 1 px 6 px 0 rgba( $JM-Black , 0.2 ) ; z-index : map-get( $zIndexMap , modal ) ; } このように Sass と React コンポーネント毎に 1 対 1 の関係になるようにしています。 プレフィックスとして付与している c- や o- は ITCSS のレイヤーのことを指します。 o- は Objects レイヤーのプレフィックスで、 c- は Components レイヤーのプレフィックスです。 基本的に React の UI コンポーネント内では、コンポーネントの種別に応じて c- か o- のプレフィックスを持つクラスと、状態によって付けたり外したりする State レイヤーの s- プレフィックスのクラスのみを使用します。 話を React に戻すと、下記のようなヘッダー要素を画面上部に固定表示するだけの役割を持つ <AppBar /> コンポーネントは、 props.children で子要素を受け取れるようになっているだけで、その内容には関知しないようになっています。 const AppBar = ( props ) => { return < div className = "o-app-bar" > { props . children } </ div > ; }; 内包する子コンポーネントが何であれ、 <AppBar /> は自分自身の責任だけを果たせば良いので、開発上もシンプルに考えられます。 className に渡している o-app-bar は ITCSS の Objects レイヤーのクラスです。 .o-app-bar { position : fixed ; top : 0 ; left : 0 ; right : 0 ; z-index : map-get( $zIndexMap , appBar ) ; } ヘッダー要素を画面上部に固定表示する、レイアウトのみの役割を持つコンポーネントなので、Objects レイヤーとなり、 o-app-bar にはレイアウト目的のスタイルのみを持たせます。 ジョブメドレーの採用管理画面では、医療機関や介護施設から求職者に向けた情報を入力していただくために多くのフォーム要素があり、非常に煩雑になりがちですが、 それぞれの役割を果たすコンポーネントを組み合わせることで、UI 開発上の堅牢性、柔軟性を高められる ように努めました。 実際のリニューアル開発時には、全ての UI コンポーネントを実装する前に、開発側ではデザイナーが用意した Sketch から、全ての UI パーツを洗い出す作業を行い、その中で分解不可能なレベルまでコンポーネントを分解していき、実装すべきコンポーネントを一覧化しました。 その後、作成したコンポーネント一覧から全 UI コンポーネントを Storybook に実装していきました。 Storybook は、UI コンポーネント開発のサンドボックス環境として、React や Vue を利用した開発では割と一般的に利用されるようになっていると思います。リニューアル時も各コンポーネントの開発環境として利用して、コンポーネントのパターンや組み合わせの確認などを Storybook 上で行いました。 画面を作っていく段階では、 用意した UI コンポーネントを組み合わせて利用すれば画面全体の大半の UI が出来上がる ようになっていました。 細かい部分では、事前に用意するコンポーネントに不足があったり、実装した後で仕様の変更によりコンポーネント自体を削除することや、分解不可能な状態まで落とし込めてないコンポーネントが見つかったりと、様々な反省点はありました。ですがリニューアル全体を通して振り返ると、Composable な UI コンポーネントで堅牢で柔軟性のある構成にするということに一定の成果は出せたかなと思います。 まとめ UI リニューアル以降、採用管理画面ではリニューアル時の UI システムを土台にして、継続的に機能を追加・改修しています。 プロダクトで設けている KPI も順調に遷移していて、顧客からの問い合わせもリニューアル以前のような、UI 上の問題で利用が困難であるというものは減少し、ポジティブな結果が得られています。 開発をする上でも Composable になるようにコンポーネント群を作成したことで、 リニューアル以降は UI の改修がシンプルに行えるようになり、開発メンバーのスキルセットに左右される部分が少なくなり、開発効率が上がりました 。 このような点からリニューアル自体は良かったと思うと同時に、一方でさらに良い UI を提供するために取り組むべきことは、少なくないと感じます。 例えば採用管理画面が十分にアクセシブルだとは言えないし、パフォーマンス面でもより一層の努力が求められます。もちろん UI コンポーネントの堅牢性もまだ十分とは言えません。 より良いプロダクトを提供するためにそういった課題に対しても継続して取り組んでいきたいと思います。 お知らせ メドレーでは、エンジニア・デザイナーを募集しています。 メドレーでの開発にご興味ある方は、こちらをご覧ください。 https://www.medley.jp/recruit/creative.html

こんにちは、開発本部の舘野です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しています。 昨年、ジョブメドレーでは事業所が利用する採用管理画面の UI リニューアルを行いました。ユーザが使いやすい UI づくりを目指すために、長期間にわたり誰が開発しても一貫性ある UI を実現できるようなシステムが必要です。そこで今回は「Composable」な UI システムの実現をテーマに、どのように開発を行ったのかについて、共有させていただきます。 背景：画面や機能追加のたびに UI の一貫性がなくなっていた ジョブメドレーの採用管理画面とは、医療機関や介護施設の採用担当者が求人情報の管理や応募者の選考状況の管理などを行う画面です。 この採用管理画面ですが、リニューアル以前は Angular をフレームワークとして採用した SPA で、UI に関しては AngularUI の Bootstrap を利用して、それぞれのエンジニアが実装を行っていました。 それなりの UI をスピーディーに実現できる点においては、Bootsrap のような UI フレームワークを利用することで受けられる恩恵は大きかったのですが、一方で、包括的に UI 設計を行っているわけではなく、 各人が局所的に UI を作っていくので、画面や機能を追加していく中で一貫性がない UI が増えていく状態 になっていました。 実際にユーザインタビューなどを行ってみると、「ログインした後どうすれば良いのか分からない」、「〇〇という機能があることを今まで知らなかった」、「xx がどこにあるのか分からない」などの意見が多々あり、全面的な UI の見直しが必要になっていました。 医療や介護の現場での人材不足を解消するために採用担当者に提供するツールとして、今後さらに機能拡充していくことが求められていましたが、機能拡充していくことに耐えうる状態にはないというのがプロダクトチームのメンバーの共通認識でした。 そこで、全体的に情報設計から見直してデザインを刷新し、今後プロダクトを成長させていく上でスケール可能な UI を提供できるようにするため、UI リニューアルを決定しました。 フロントエンドで必要だったこと Bootstrap を用いてエンジニアのみで UI を作っていたのとは異なり、リニューアルでは社内のデザイナーが現状の UI 上の課題を整理したデザインを作成しました。 これに伴って、自前で全ての UI パーツを作成することになりましたが、Bootstrap に頼りきっていたときとは違い、堅牢性と柔軟性を伴った UI システムを自分たちで構築する必要がありました。 リニューアル前の採用管理画面の UI は一貫性に欠けており、ユーザは非常に多くの操作を学ぶ必要がありましたが、この責任はデザイナーだけでなく UI 開発をするエンジニアにも大いにあります。 良いデザインができても、最終的にプロダクトの UI はコードによって作り上げられるものなので、エンジニア次第で一貫性に欠ける UI になってしまうことは十分にあり得ると思います。 往々にして起こり得るのは、目にする機会が比較的少ない画面であったり、改修対象ではない部分などが気づいたら崩れていたり、意図しない UI になってしまっていたりということですが、こういった状況に陥る大きな要因としてはフロントエンドの部分で一貫性に対する配慮ができてないことが 1 つだと思います。 そこで、すでにある採用管理画面を使いやすくするのはもちろん、今後スケールしていく中で 一貫性のある UI を担保し続けていくためには、リニューアルでフロントエンドも堅牢で柔軟な UI システムへと変える必要がありました 。 UI リニューアルで開発上大切にしたこと UI の一貫性を保つとなると、今のフロントエンドではもはや当然のことかもしれませんが、コンポーネント指向で構成することになると思います。 技術選定としては、上述の通りリニューアル以前は Angular（v1.4.11）を利用していましたが、リニューアルのタイミングで React へ移行しました。 React を選択した理由としては、学習コストの点やコミュニティが活発でエコシステムが充実している点、単一方向のデータフロー、シンプルな API などを総合的に判断してのものですが、目下の課題である UI コンポーネントのメンテナビリティに関しても適切な選択肢であると考えました。 CSS の方はというと、リニューアル前は Bootstrap でまかなえない部分は Sass でそれぞれのエンジニアが書きたいように書くという状態でしたが、リニューアルで Sass に加えて一部 PostCSS という構成に変更して、設計は ITCSS、Lint を stylelint で行う、という形にしました。 ITCSS を選択した背景としては、その詳細度順のレイヤー階層によってカスケードを管理しやすい点やレイヤーの増減で容易にスケールできる点などから選択しました。 CSS in JS も考慮はしましたが、リニューアルの時点ではこれという決定的な選択肢が無かったこともあり（まだ styled-components も正式リリースされてなかった）、 classnames を利用しました。 フレームワークやライブラリの選定も重要ですが、UI システムを刷新する上で 開発上最も重視したのは「Composability（コンポーネントの組み合わせが容易であること）」 でした。 Composable であるということは、つまり様々な状況において組み込み可能な状態であり、再利用性が高いということになります。 それぞれのコンポーネントを組み合わせることが容易に出来るとともに、複数のコンポーネントを組み合わせた状態から 1 つ 1 つ分解することも容易な状態が望ましく、結果的にそれで UI が構築しやすく改修しやすい状態に自然となるはずです。 モーダルを例にあげると、モーダルの中で表示するコンテンツ要素やモーダルの背面に敷くオーバーレイコンポーネントは、モーダルコンポーネント自体には含まず別のコンポーネントとして切り出した方が再利用しやすく、組み合わせやすい、ということです。 < ModalFrame > < Modal > < ModalHead > ... </ ModalHead > < ModalBody > ... </ ModalBody > </ Modal > < Overlay /> </ ModalFrame > 上記の例でいうと、モーダルを画面の中央に配置することは <ModalFrame /> が行い、 <Modal /> 自体はモーダルに内包されるコンテンツのコンテナとしての役割だけを持ちます。 <Overlay /> も独立したコンポーネントの 1 つで、モーダル以外とも組み合わせて利用しています。 コンテナとなるコンポーネントとその子となるコンポーネントは、別コンポーネントに分離されていることで、お互いに依存しないようになります。 また、Sass ファイルもこのコンポーネント構成に合わせて分けています。 ITCSS において、 <ModalFrame /> のようなレイアウトのみの役割を持つ場合のスタイルは Objects レイヤー（装飾を持たない UI パターンのレイヤー）となり、装飾を持つ <Modal /> や <Overlay /> は Components レイヤーとして扱います。 @import “objects.modal-frame”; @import “components.modal”; @import “components.overlay”; CSS はその特有のカスケードや詳細度によって決定されるスタイルがあり、依存関係を持たない状態を作ることが困難ですが、ITCSS の考えに則ってそれらの CSS の特徴に逆らわないように詳細度の低いものから順番に @import するようにしています。 Sass ファイルの中身ですが、 _objecst.modal-frame.scss は <ModalFrame /> のスタイルのみを記述するようにします。 .o-modal-frame { position : fixed ; top : 0 ; left : 0 ; right : 0 ; bottom : 0 ; z-index : map-get( $zIndexMap , modalFrame ) ; } _components.modal.scss も同様に <Modal /> のスタイルのみを記述します。 .c-modal { position : relative ; margin : 0 auto ; width : 900 px ; min-width : 640 px ; background-color : $JM-White ; box-shadow : 0 1 px 6 px 0 rgba( $JM-Black , 0.2 ) ; z-index : map-get( $zIndexMap , modal ) ; } このように Sass と React コンポーネント毎に 1 対 1 の関係になるようにしています。 プレフィックスとして付与している c- や o- は ITCSS のレイヤーのことを指します。 o- は Objects レイヤーのプレフィックスで、 c- は Components レイヤーのプレフィックスです。 基本的に React の UI コンポーネント内では、コンポーネントの種別に応じて c- か o- のプレフィックスを持つクラスと、状態によって付けたり外したりする State レイヤーの s- プレフィックスのクラスのみを使用します。 話を React に戻すと、下記のようなヘッダー要素を画面上部に固定表示するだけの役割を持つ <AppBar /> コンポーネントは、 props.children で子要素を受け取れるようになっているだけで、その内容には関知しないようになっています。 const AppBar = ( props ) => { return < div className = "o-app-bar" > { props . children } </ div > ; }; 内包する子コンポーネントが何であれ、 <AppBar /> は自分自身の責任だけを果たせば良いので、開発上もシンプルに考えられます。 className に渡している o-app-bar は ITCSS の Objects レイヤーのクラスです。 .o-app-bar { position : fixed ; top : 0 ; left : 0 ; right : 0 ; z-index : map-get( $zIndexMap , appBar ) ; } ヘッダー要素を画面上部に固定表示する、レイアウトのみの役割を持つコンポーネントなので、Objects レイヤーとなり、 o-app-bar にはレイアウト目的のスタイルのみを持たせます。 ジョブメドレーの採用管理画面では、医療機関や介護施設から求職者に向けた情報を入力していただくために多くのフォーム要素があり、非常に煩雑になりがちですが、 それぞれの役割を果たすコンポーネントを組み合わせることで、UI 開発上の堅牢性、柔軟性を高められる ように努めました。 実際のリニューアル開発時には、全ての UI コンポーネントを実装する前に、開発側ではデザイナーが用意した Sketch から、全ての UI パーツを洗い出す作業を行い、その中で分解不可能なレベルまでコンポーネントを分解していき、実装すべきコンポーネントを一覧化しました。 その後、作成したコンポーネント一覧から全 UI コンポーネントを Storybook に実装していきました。 Storybook は、UI コンポーネント開発のサンドボックス環境として、React や Vue を利用した開発では割と一般的に利用されるようになっていると思います。リニューアル時も各コンポーネントの開発環境として利用して、コンポーネントのパターンや組み合わせの確認などを Storybook 上で行いました。 画面を作っていく段階では、 用意した UI コンポーネントを組み合わせて利用すれば画面全体の大半の UI が出来上がる ようになっていました。 細かい部分では、事前に用意するコンポーネントに不足があったり、実装した後で仕様の変更によりコンポーネント自体を削除することや、分解不可能な状態まで落とし込めてないコンポーネントが見つかったりと、様々な反省点はありました。ですがリニューアル全体を通して振り返ると、Composable な UI コンポーネントで堅牢で柔軟性のある構成にするということに一定の成果は出せたかなと思います。 まとめ UI リニューアル以降、採用管理画面ではリニューアル時の UI システムを土台にして、継続的に機能を追加・改修しています。 プロダクトで設けている KPI も順調に遷移していて、顧客からの問い合わせもリニューアル以前のような、UI 上の問題で利用が困難であるというものは減少し、ポジティブな結果が得られています。 開発をする上でも Composable になるようにコンポーネント群を作成したことで、 リニューアル以降は UI の改修がシンプルに行えるようになり、開発メンバーのスキルセットに左右される部分が少なくなり、開発効率が上がりました 。 このような点からリニューアル自体は良かったと思うと同時に、一方でさらに良い UI を提供するために取り組むべきことは、少なくないと感じます。 例えば採用管理画面が十分にアクセシブルだとは言えないし、パフォーマンス面でもより一層の努力が求められます。もちろん UI コンポーネントの堅牢性もまだ十分とは言えません。 より良いプロダクトを提供するためにそういった課題に対しても継続して取り組んでいきたいと思います。 お知らせ メドレーでは、エンジニア・デザイナーを募集しています。 メドレーでの開発にご興味ある方は、こちらをご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しています。 昨年、ジョブメドレーでは事業所が利用する採用管理画面の UI リニューアルを行いました。ユーザが使いやすい UI づくりを目指すために、長期間にわたり誰が開発しても一貫性ある UI を実現できるようなシステムが必要です。そこで今回は「Composable」な UI システムの実現をテーマに、どのように開発を行ったのかについて、共有させていただきます。 背景：画面や機能追加のたびに UI の一貫性がなくなっていた ジョブメドレーの採用管理画面とは、医療機関や介護施設の採用担当者が求人情報の管理や応募者の選考状況の管理などを行う画面です。 この採用管理画面ですが、リニューアル以前は Angular をフレームワークとして採用した SPA で、UI に関しては AngularUI の Bootstrap を利用して、それぞれのエンジニアが実装を行っていました。 それなりの UI をスピーディーに実現できる点においては、Bootsrap のような UI フレームワークを利用することで受けられる恩恵は大きかったのですが、一方で、包括的に UI 設計を行っているわけではなく、 各人が局所的に UI を作っていくので、画面や機能を追加していく中で一貫性がない UI が増えていく状態 になっていました。 実際にユーザインタビューなどを行ってみると、「ログインした後どうすれば良いのか分からない」、「〇〇という機能があることを今まで知らなかった」、「xx がどこにあるのか分からない」などの意見が多々あり、全面的な UI の見直しが必要になっていました。 医療や介護の現場での人材不足を解消するために採用担当者に提供するツールとして、今後さらに機能拡充していくことが求められていましたが、機能拡充していくことに耐えうる状態にはないというのがプロダクトチームのメンバーの共通認識でした。 そこで、全体的に情報設計から見直してデザインを刷新し、今後プロダクトを成長させていく上でスケール可能な UI を提供できるようにするため、UI リニューアルを決定しました。 フロントエンドで必要だったこと Bootstrap を用いてエンジニアのみで UI を作っていたのとは異なり、リニューアルでは社内のデザイナーが現状の UI 上の課題を整理したデザインを作成しました。 これに伴って、自前で全ての UI パーツを作成することになりましたが、Bootstrap に頼りきっていたときとは違い、堅牢性と柔軟性を伴った UI システムを自分たちで構築する必要がありました。 リニューアル前の採用管理画面の UI は一貫性に欠けており、ユーザは非常に多くの操作を学ぶ必要がありましたが、この責任はデザイナーだけでなく UI 開発をするエンジニアにも大いにあります。 良いデザインができても、最終的にプロダクトの UI はコードによって作り上げられるものなので、エンジニア次第で一貫性に欠ける UI になってしまうことは十分にあり得ると思います。 往々にして起こり得るのは、目にする機会が比較的少ない画面であったり、改修対象ではない部分などが気づいたら崩れていたり、意図しない UI になってしまっていたりということですが、こういった状況に陥る大きな要因としてはフロントエンドの部分で一貫性に対する配慮ができてないことが 1 つだと思います。 そこで、すでにある採用管理画面を使いやすくするのはもちろん、今後スケールしていく中で 一貫性のある UI を担保し続けていくためには、リニューアルでフロントエンドも堅牢で柔軟な UI システムへと変える必要がありました 。 UI リニューアルで開発上大切にしたこと UI の一貫性を保つとなると、今のフロントエンドではもはや当然のことかもしれませんが、コンポーネント指向で構成することになると思います。 技術選定としては、上述の通りリニューアル以前は Angular（v1.4.11）を利用していましたが、リニューアルのタイミングで React へ移行しました。 React を選択した理由としては、学習コストの点やコミュニティが活発でエコシステムが充実している点、単一方向のデータフロー、シンプルな API などを総合的に判断してのものですが、目下の課題である UI コンポーネントのメンテナビリティに関しても適切な選択肢であると考えました。 CSS の方はというと、リニューアル前は Bootstrap でまかなえない部分は Sass でそれぞれのエンジニアが書きたいように書くという状態でしたが、リニューアルで Sass に加えて一部 PostCSS という構成に変更して、設計は ITCSS、Lint を stylelint で行う、という形にしました。 ITCSS を選択した背景としては、その詳細度順のレイヤー階層によってカスケードを管理しやすい点やレイヤーの増減で容易にスケールできる点などから選択しました。 CSS in JS も考慮はしましたが、リニューアルの時点ではこれという決定的な選択肢が無かったこともあり（まだ styled-components も正式リリースされてなかった）、 classnames を利用しました。 フレームワークやライブラリの選定も重要ですが、UI システムを刷新する上で 開発上最も重視したのは「Composability（コンポーネントの組み合わせが容易であること）」 でした。 Composable であるということは、つまり様々な状況において組み込み可能な状態であり、再利用性が高いということになります。 それぞれのコンポーネントを組み合わせることが容易に出来るとともに、複数のコンポーネントを組み合わせた状態から 1 つ 1 つ分解することも容易な状態が望ましく、結果的にそれで UI が構築しやすく改修しやすい状態に自然となるはずです。 モーダルを例にあげると、モーダルの中で表示するコンテンツ要素やモーダルの背面に敷くオーバーレイコンポーネントは、モーダルコンポーネント自体には含まず別のコンポーネントとして切り出した方が再利用しやすく、組み合わせやすい、ということです。 < ModalFrame > < Modal > < ModalHead > ... </ ModalHead > < ModalBody > ... </ ModalBody > </ Modal > < Overlay /> </ ModalFrame > 上記の例でいうと、モーダルを画面の中央に配置することは <ModalFrame /> が行い、 <Modal /> 自体はモーダルに内包されるコンテンツのコンテナとしての役割だけを持ちます。 <Overlay /> も独立したコンポーネントの 1 つで、モーダル以外とも組み合わせて利用しています。 コンテナとなるコンポーネントとその子となるコンポーネントは、別コンポーネントに分離されていることで、お互いに依存しないようになります。 また、Sass ファイルもこのコンポーネント構成に合わせて分けています。 ITCSS において、 <ModalFrame /> のようなレイアウトのみの役割を持つ場合のスタイルは Objects レイヤー（装飾を持たない UI パターンのレイヤー）となり、装飾を持つ <Modal /> や <Overlay /> は Components レイヤーとして扱います。 @import “objects.modal-frame”; @import “components.modal”; @import “components.overlay”; CSS はその特有のカスケードや詳細度によって決定されるスタイルがあり、依存関係を持たない状態を作ることが困難ですが、ITCSS の考えに則ってそれらの CSS の特徴に逆らわないように詳細度の低いものから順番に @import するようにしています。 Sass ファイルの中身ですが、 _objecst.modal-frame.scss は <ModalFrame /> のスタイルのみを記述するようにします。 .o-modal-frame { position : fixed ; top : 0 ; left : 0 ; right : 0 ; bottom : 0 ; z-index : map-get( $zIndexMap , modalFrame ) ; } _components.modal.scss も同様に <Modal /> のスタイルのみを記述します。 .c-modal { position : relative ; margin : 0 auto ; width : 900 px ; min-width : 640 px ; background-color : $JM-White ; box-shadow : 0 1 px 6 px 0 rgba( $JM-Black , 0.2 ) ; z-index : map-get( $zIndexMap , modal ) ; } このように Sass と React コンポーネント毎に 1 対 1 の関係になるようにしています。 プレフィックスとして付与している c- や o- は ITCSS のレイヤーのことを指します。 o- は Objects レイヤーのプレフィックスで、 c- は Components レイヤーのプレフィックスです。 基本的に React の UI コンポーネント内では、コンポーネントの種別に応じて c- か o- のプレフィックスを持つクラスと、状態によって付けたり外したりする State レイヤーの s- プレフィックスのクラスのみを使用します。 話を React に戻すと、下記のようなヘッダー要素を画面上部に固定表示するだけの役割を持つ <AppBar /> コンポーネントは、 props.children で子要素を受け取れるようになっているだけで、その内容には関知しないようになっています。 const AppBar = ( props ) => { return < div className = "o-app-bar" > { props . children } </ div > ; }; 内包する子コンポーネントが何であれ、 <AppBar /> は自分自身の責任だけを果たせば良いので、開発上もシンプルに考えられます。 className に渡している o-app-bar は ITCSS の Objects レイヤーのクラスです。 .o-app-bar { position : fixed ; top : 0 ; left : 0 ; right : 0 ; z-index : map-get( $zIndexMap , appBar ) ; } ヘッダー要素を画面上部に固定表示する、レイアウトのみの役割を持つコンポーネントなので、Objects レイヤーとなり、 o-app-bar にはレイアウト目的のスタイルのみを持たせます。 ジョブメドレーの採用管理画面では、医療機関や介護施設から求職者に向けた情報を入力していただくために多くのフォーム要素があり、非常に煩雑になりがちですが、 それぞれの役割を果たすコンポーネントを組み合わせることで、UI 開発上の堅牢性、柔軟性を高められる ように努めました。 実際のリニューアル開発時には、全ての UI コンポーネントを実装する前に、開発側ではデザイナーが用意した Sketch から、全ての UI パーツを洗い出す作業を行い、その中で分解不可能なレベルまでコンポーネントを分解していき、実装すべきコンポーネントを一覧化しました。 その後、作成したコンポーネント一覧から全 UI コンポーネントを Storybook に実装していきました。 Storybook は、UI コンポーネント開発のサンドボックス環境として、React や Vue を利用した開発では割と一般的に利用されるようになっていると思います。リニューアル時も各コンポーネントの開発環境として利用して、コンポーネントのパターンや組み合わせの確認などを Storybook 上で行いました。 画面を作っていく段階では、 用意した UI コンポーネントを組み合わせて利用すれば画面全体の大半の UI が出来上がる ようになっていました。 細かい部分では、事前に用意するコンポーネントに不足があったり、実装した後で仕様の変更によりコンポーネント自体を削除することや、分解不可能な状態まで落とし込めてないコンポーネントが見つかったりと、様々な反省点はありました。ですがリニューアル全体を通して振り返ると、Composable な UI コンポーネントで堅牢で柔軟性のある構成にするということに一定の成果は出せたかなと思います。 まとめ UI リニューアル以降、採用管理画面ではリニューアル時の UI システムを土台にして、継続的に機能を追加・改修しています。 プロダクトで設けている KPI も順調に遷移していて、顧客からの問い合わせもリニューアル以前のような、UI 上の問題で利用が困難であるというものは減少し、ポジティブな結果が得られています。 開発をする上でも Composable になるようにコンポーネント群を作成したことで、 リニューアル以降は UI の改修がシンプルに行えるようになり、開発メンバーのスキルセットに左右される部分が少なくなり、開発効率が上がりました 。 このような点からリニューアル自体は良かったと思うと同時に、一方でさらに良い UI を提供するために取り組むべきことは、少なくないと感じます。 例えば採用管理画面が十分にアクセシブルだとは言えないし、パフォーマンス面でもより一層の努力が求められます。もちろん UI コンポーネントの堅牢性もまだ十分とは言えません。 より良いプロダクトを提供するためにそういった課題に対しても継続して取り組んでいきたいと思います。 お知らせ メドレーでは、エンジニア・デザイナーを募集しています。 メドレーでの開発にご興味ある方は、こちらをご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しています。 昨年、ジョブメドレーでは事業所が利用する採用管理画面の UI リニューアルを行いました。ユーザが使いやすい UI づくりを目指すために、長期間にわたり誰が開発しても一貫性ある UI を実現できるようなシステムが必要です。そこで今回は「Composable」な UI システムの実現をテーマに、どのように開発を行ったのかについて、共有させていただきます。 背景：画面や機能追加のたびに UI の一貫性がなくなっていた ジョブメドレーの採用管理画面とは、医療機関や介護施設の採用担当者が求人情報の管理や応募者の選考状況の管理などを行う画面です。 この採用管理画面ですが、リニューアル以前は Angular をフレームワークとして採用した SPA で、UI に関しては AngularUI の Bootstrap を利用して、それぞれのエンジニアが実装を行っていました。 それなりの UI をスピーディーに実現できる点においては、Bootsrap のような UI フレームワークを利用することで受けられる恩恵は大きかったのですが、一方で、包括的に UI 設計を行っているわけではなく、 各人が局所的に UI を作っていくので、画面や機能を追加していく中で一貫性がない UI が増えていく状態 になっていました。 実際にユーザインタビューなどを行ってみると、「ログインした後どうすれば良いのか分からない」、「〇〇という機能があることを今まで知らなかった」、「xx がどこにあるのか分からない」などの意見が多々あり、全面的な UI の見直しが必要になっていました。 医療や介護の現場での人材不足を解消するために採用担当者に提供するツールとして、今後さらに機能拡充していくことが求められていましたが、機能拡充していくことに耐えうる状態にはないというのがプロダクトチームのメンバーの共通認識でした。 そこで、全体的に情報設計から見直してデザインを刷新し、今後プロダクトを成長させていく上でスケール可能な UI を提供できるようにするため、UI リニューアルを決定しました。 フロントエンドで必要だったこと Bootstrap を用いてエンジニアのみで UI を作っていたのとは異なり、リニューアルでは社内のデザイナーが現状の UI 上の課題を整理したデザインを作成しました。 これに伴って、自前で全ての UI パーツを作成することになりましたが、Bootstrap に頼りきっていたときとは違い、堅牢性と柔軟性を伴った UI システムを自分たちで構築する必要がありました。 リニューアル前の採用管理画面の UI は一貫性に欠けており、ユーザは非常に多くの操作を学ぶ必要がありましたが、この責任はデザイナーだけでなく UI 開発をするエンジニアにも大いにあります。 良いデザインができても、最終的にプロダクトの UI はコードによって作り上げられるものなので、エンジニア次第で一貫性に欠ける UI になってしまうことは十分にあり得ると思います。 往々にして起こり得るのは、目にする機会が比較的少ない画面であったり、改修対象ではない部分などが気づいたら崩れていたり、意図しない UI になってしまっていたりということですが、こういった状況に陥る大きな要因としてはフロントエンドの部分で一貫性に対する配慮ができてないことが 1 つだと思います。 そこで、すでにある採用管理画面を使いやすくするのはもちろん、今後スケールしていく中で 一貫性のある UI を担保し続けていくためには、リニューアルでフロントエンドも堅牢で柔軟な UI システムへと変える必要がありました 。 UI リニューアルで開発上大切にしたこと UI の一貫性を保つとなると、今のフロントエンドではもはや当然のことかもしれませんが、コンポーネント指向で構成することになると思います。 技術選定としては、上述の通りリニューアル以前は Angular（v1.4.11）を利用していましたが、リニューアルのタイミングで React へ移行しました。 React を選択した理由としては、学習コストの点やコミュニティが活発でエコシステムが充実している点、単一方向のデータフロー、シンプルな API などを総合的に判断してのものですが、目下の課題である UI コンポーネントのメンテナビリティに関しても適切な選択肢であると考えました。 CSS の方はというと、リニューアル前は Bootstrap でまかなえない部分は Sass でそれぞれのエンジニアが書きたいように書くという状態でしたが、リニューアルで Sass に加えて一部 PostCSS という構成に変更して、設計は ITCSS、Lint を stylelint で行う、という形にしました。 ITCSS を選択した背景としては、その詳細度順のレイヤー階層によってカスケードを管理しやすい点やレイヤーの増減で容易にスケールできる点などから選択しました。 CSS in JS も考慮はしましたが、リニューアルの時点ではこれという決定的な選択肢が無かったこともあり（まだ styled-components も正式リリースされてなかった）、 classnames を利用しました。 フレームワークやライブラリの選定も重要ですが、UI システムを刷新する上で 開発上最も重視したのは「Composability（コンポーネントの組み合わせが容易であること）」 でした。 Composable であるということは、つまり様々な状況において組み込み可能な状態であり、再利用性が高いということになります。 それぞれのコンポーネントを組み合わせることが容易に出来るとともに、複数のコンポーネントを組み合わせた状態から 1 つ 1 つ分解することも容易な状態が望ましく、結果的にそれで UI が構築しやすく改修しやすい状態に自然となるはずです。 モーダルを例にあげると、モーダルの中で表示するコンテンツ要素やモーダルの背面に敷くオーバーレイコンポーネントは、モーダルコンポーネント自体には含まず別のコンポーネントとして切り出した方が再利用しやすく、組み合わせやすい、ということです。 < ModalFrame > < Modal > < ModalHead > ... </ ModalHead > < ModalBody > ... </ ModalBody > </ Modal > < Overlay /> </ ModalFrame > 上記の例でいうと、モーダルを画面の中央に配置することは <ModalFrame /> が行い、 <Modal /> 自体はモーダルに内包されるコンテンツのコンテナとしての役割だけを持ちます。 <Overlay /> も独立したコンポーネントの 1 つで、モーダル以外とも組み合わせて利用しています。 コンテナとなるコンポーネントとその子となるコンポーネントは、別コンポーネントに分離されていることで、お互いに依存しないようになります。 また、Sass ファイルもこのコンポーネント構成に合わせて分けています。 ITCSS において、 <ModalFrame /> のようなレイアウトのみの役割を持つ場合のスタイルは Objects レイヤー（装飾を持たない UI パターンのレイヤー）となり、装飾を持つ <Modal /> や <Overlay /> は Components レイヤーとして扱います。 @import “objects.modal-frame”; @import “components.modal”; @import “components.overlay”; CSS はその特有のカスケードや詳細度によって決定されるスタイルがあり、依存関係を持たない状態を作ることが困難ですが、ITCSS の考えに則ってそれらの CSS の特徴に逆らわないように詳細度の低いものから順番に @import するようにしています。 Sass ファイルの中身ですが、 _objecst.modal-frame.scss は <ModalFrame /> のスタイルのみを記述するようにします。 .o-modal-frame { position : fixed ; top : 0 ; left : 0 ; right : 0 ; bottom : 0 ; z-index : map-get( $zIndexMap , modalFrame ) ; } _components.modal.scss も同様に <Modal /> のスタイルのみを記述します。 .c-modal { position : relative ; margin : 0 auto ; width : 900 px ; min-width : 640 px ; background-color : $JM-White ; box-shadow : 0 1 px 6 px 0 rgba( $JM-Black , 0.2 ) ; z-index : map-get( $zIndexMap , modal ) ; } このように Sass と React コンポーネント毎に 1 対 1 の関係になるようにしています。 プレフィックスとして付与している c- や o- は ITCSS のレイヤーのことを指します。 o- は Objects レイヤーのプレフィックスで、 c- は Components レイヤーのプレフィックスです。 基本的に React の UI コンポーネント内では、コンポーネントの種別に応じて c- か o- のプレフィックスを持つクラスと、状態によって付けたり外したりする State レイヤーの s- プレフィックスのクラスのみを使用します。 話を React に戻すと、下記のようなヘッダー要素を画面上部に固定表示するだけの役割を持つ <AppBar /> コンポーネントは、 props.children で子要素を受け取れるようになっているだけで、その内容には関知しないようになっています。 const AppBar = ( props ) => { return < div className = "o-app-bar" > { props . children } </ div > ; }; 内包する子コンポーネントが何であれ、 <AppBar /> は自分自身の責任だけを果たせば良いので、開発上もシンプルに考えられます。 className に渡している o-app-bar は ITCSS の Objects レイヤーのクラスです。 .o-app-bar { position : fixed ; top : 0 ; left : 0 ; right : 0 ; z-index : map-get( $zIndexMap , appBar ) ; } ヘッダー要素を画面上部に固定表示する、レイアウトのみの役割を持つコンポーネントなので、Objects レイヤーとなり、 o-app-bar にはレイアウト目的のスタイルのみを持たせます。 ジョブメドレーの採用管理画面では、医療機関や介護施設から求職者に向けた情報を入力していただくために多くのフォーム要素があり、非常に煩雑になりがちですが、 それぞれの役割を果たすコンポーネントを組み合わせることで、UI 開発上の堅牢性、柔軟性を高められる ように努めました。 実際のリニューアル開発時には、全ての UI コンポーネントを実装する前に、開発側ではデザイナーが用意した Sketch から、全ての UI パーツを洗い出す作業を行い、その中で分解不可能なレベルまでコンポーネントを分解していき、実装すべきコンポーネントを一覧化しました。 その後、作成したコンポーネント一覧から全 UI コンポーネントを Storybook に実装していきました。 Storybook は、UI コンポーネント開発のサンドボックス環境として、React や Vue を利用した開発では割と一般的に利用されるようになっていると思います。リニューアル時も各コンポーネントの開発環境として利用して、コンポーネントのパターンや組み合わせの確認などを Storybook 上で行いました。 画面を作っていく段階では、 用意した UI コンポーネントを組み合わせて利用すれば画面全体の大半の UI が出来上がる ようになっていました。 細かい部分では、事前に用意するコンポーネントに不足があったり、実装した後で仕様の変更によりコンポーネント自体を削除することや、分解不可能な状態まで落とし込めてないコンポーネントが見つかったりと、様々な反省点はありました。ですがリニューアル全体を通して振り返ると、Composable な UI コンポーネントで堅牢で柔軟性のある構成にするということに一定の成果は出せたかなと思います。 まとめ UI リニューアル以降、採用管理画面ではリニューアル時の UI システムを土台にして、継続的に機能を追加・改修しています。 プロダクトで設けている KPI も順調に遷移していて、顧客からの問い合わせもリニューアル以前のような、UI 上の問題で利用が困難であるというものは減少し、ポジティブな結果が得られています。 開発をする上でも Composable になるようにコンポーネント群を作成したことで、 リニューアル以降は UI の改修がシンプルに行えるようになり、開発メンバーのスキルセットに左右される部分が少なくなり、開発効率が上がりました 。 このような点からリニューアル自体は良かったと思うと同時に、一方でさらに良い UI を提供するために取り組むべきことは、少なくないと感じます。 例えば採用管理画面が十分にアクセシブルだとは言えないし、パフォーマンス面でもより一層の努力が求められます。もちろん UI コンポーネントの堅牢性もまだ十分とは言えません。 より良いプロダクトを提供するためにそういった課題に対しても継続して取り組んでいきたいと思います。 お知らせ メドレーでは、エンジニア・デザイナーを募集しています。 メドレーでの開発にご興味ある方は、こちらをご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しています。 昨年、ジョブメドレーでは事業所が利用する採用管理画面の UI リニューアルを行いました。ユーザが使いやすい UI づくりを目指すために、長期間にわたり誰が開発しても一貫性ある UI を実現できるようなシステムが必要です。そこで今回は「Composable」な UI システムの実現をテーマに、どのように開発を行ったのかについて、共有させていただきます。 背景：画面や機能追加のたびに UI の一貫性がなくなっていた ジョブメドレーの採用管理画面とは、医療機関や介護施設の採用担当者が求人情報の管理や応募者の選考状況の管理などを行う画面です。 この採用管理画面ですが、リニューアル以前は Angular をフレームワークとして採用した SPA で、UI に関しては AngularUI の Bootstrap を利用して、それぞれのエンジニアが実装を行っていました。 それなりの UI をスピーディーに実現できる点においては、Bootsrap のような UI フレームワークを利用することで受けられる恩恵は大きかったのですが、一方で、包括的に UI 設計を行っているわけではなく、 各人が局所的に UI を作っていくので、画面や機能を追加していく中で一貫性がない UI が増えていく状態 になっていました。 実際にユーザインタビューなどを行ってみると、「ログインした後どうすれば良いのか分からない」、「〇〇という機能があることを今まで知らなかった」、「xx がどこにあるのか分からない」などの意見が多々あり、全面的な UI の見直しが必要になっていました。 医療や介護の現場での人材不足を解消するために採用担当者に提供するツールとして、今後さらに機能拡充していくことが求められていましたが、機能拡充していくことに耐えうる状態にはないというのがプロダクトチームのメンバーの共通認識でした。 そこで、全体的に情報設計から見直してデザインを刷新し、今後プロダクトを成長させていく上でスケール可能な UI を提供できるようにするため、UI リニューアルを決定しました。 フロントエンドで必要だったこと Bootstrap を用いてエンジニアのみで UI を作っていたのとは異なり、リニューアルでは社内のデザイナーが現状の UI 上の課題を整理したデザインを作成しました。 これに伴って、自前で全ての UI パーツを作成することになりましたが、Bootstrap に頼りきっていたときとは違い、堅牢性と柔軟性を伴った UI システムを自分たちで構築する必要がありました。 リニューアル前の採用管理画面の UI は一貫性に欠けており、ユーザは非常に多くの操作を学ぶ必要がありましたが、この責任はデザイナーだけでなく UI 開発をするエンジニアにも大いにあります。 良いデザインができても、最終的にプロダクトの UI はコードによって作り上げられるものなので、エンジニア次第で一貫性に欠ける UI になってしまうことは十分にあり得ると思います。 往々にして起こり得るのは、目にする機会が比較的少ない画面であったり、改修対象ではない部分などが気づいたら崩れていたり、意図しない UI になってしまっていたりということですが、こういった状況に陥る大きな要因としてはフロントエンドの部分で一貫性に対する配慮ができてないことが 1 つだと思います。 そこで、すでにある採用管理画面を使いやすくするのはもちろん、今後スケールしていく中で 一貫性のある UI を担保し続けていくためには、リニューアルでフロントエンドも堅牢で柔軟な UI システムへと変える必要がありました 。 UI リニューアルで開発上大切にしたこと UI の一貫性を保つとなると、今のフロントエンドではもはや当然のことかもしれませんが、コンポーネント指向で構成することになると思います。 技術選定としては、上述の通りリニューアル以前は Angular（v1.4.11）を利用していましたが、リニューアルのタイミングで React へ移行しました。 React を選択した理由としては、学習コストの点やコミュニティが活発でエコシステムが充実している点、単一方向のデータフロー、シンプルな API などを総合的に判断してのものですが、目下の課題である UI コンポーネントのメンテナビリティに関しても適切な選択肢であると考えました。 CSS の方はというと、リニューアル前は Bootstrap でまかなえない部分は Sass でそれぞれのエンジニアが書きたいように書くという状態でしたが、リニューアルで Sass に加えて一部 PostCSS という構成に変更して、設計は ITCSS、Lint を stylelint で行う、という形にしました。 ITCSS を選択した背景としては、その詳細度順のレイヤー階層によってカスケードを管理しやすい点やレイヤーの増減で容易にスケールできる点などから選択しました。 CSS in JS も考慮はしましたが、リニューアルの時点ではこれという決定的な選択肢が無かったこともあり（まだ styled-components も正式リリースされてなかった）、 classnames を利用しました。 フレームワークやライブラリの選定も重要ですが、UI システムを刷新する上で 開発上最も重視したのは「Composability（コンポーネントの組み合わせが容易であること）」 でした。 Composable であるということは、つまり様々な状況において組み込み可能な状態であり、再利用性が高いということになります。 それぞれのコンポーネントを組み合わせることが容易に出来るとともに、複数のコンポーネントを組み合わせた状態から 1 つ 1 つ分解することも容易な状態が望ましく、結果的にそれで UI が構築しやすく改修しやすい状態に自然となるはずです。 モーダルを例にあげると、モーダルの中で表示するコンテンツ要素やモーダルの背面に敷くオーバーレイコンポーネントは、モーダルコンポーネント自体には含まず別のコンポーネントとして切り出した方が再利用しやすく、組み合わせやすい、ということです。 < ModalFrame > < Modal > < ModalHead > ... </ ModalHead > < ModalBody > ... </ ModalBody > </ Modal > < Overlay /> </ ModalFrame > 上記の例でいうと、モーダルを画面の中央に配置することは <ModalFrame /> が行い、 <Modal /> 自体はモーダルに内包されるコンテンツのコンテナとしての役割だけを持ちます。 <Overlay /> も独立したコンポーネントの 1 つで、モーダル以外とも組み合わせて利用しています。 コンテナとなるコンポーネントとその子となるコンポーネントは、別コンポーネントに分離されていることで、お互いに依存しないようになります。 また、Sass ファイルもこのコンポーネント構成に合わせて分けています。 ITCSS において、 <ModalFrame /> のようなレイアウトのみの役割を持つ場合のスタイルは Objects レイヤー（装飾を持たない UI パターンのレイヤー）となり、装飾を持つ <Modal /> や <Overlay /> は Components レイヤーとして扱います。 @import “objects.modal-frame”; @import “components.modal”; @import “components.overlay”; CSS はその特有のカスケードや詳細度によって決定されるスタイルがあり、依存関係を持たない状態を作ることが困難ですが、ITCSS の考えに則ってそれらの CSS の特徴に逆らわないように詳細度の低いものから順番に @import するようにしています。 Sass ファイルの中身ですが、 _objecst.modal-frame.scss は <ModalFrame /> のスタイルのみを記述するようにします。 .o-modal-frame { position : fixed ; top : 0 ; left : 0 ; right : 0 ; bottom : 0 ; z-index : map-get( $zIndexMap , modalFrame ) ; } _components.modal.scss も同様に <Modal /> のスタイルのみを記述します。 .c-modal { position : relative ; margin : 0 auto ; width : 900 px ; min-width : 640 px ; background-color : $JM-White ; box-shadow : 0 1 px 6 px 0 rgba( $JM-Black , 0.2 ) ; z-index : map-get( $zIndexMap , modal ) ; } このように Sass と React コンポーネント毎に 1 対 1 の関係になるようにしています。 プレフィックスとして付与している c- や o- は ITCSS のレイヤーのことを指します。 o- は Objects レイヤーのプレフィックスで、 c- は Components レイヤーのプレフィックスです。 基本的に React の UI コンポーネント内では、コンポーネントの種別に応じて c- か o- のプレフィックスを持つクラスと、状態によって付けたり外したりする State レイヤーの s- プレフィックスのクラスのみを使用します。 話を React に戻すと、下記のようなヘッダー要素を画面上部に固定表示するだけの役割を持つ <AppBar /> コンポーネントは、 props.children で子要素を受け取れるようになっているだけで、その内容には関知しないようになっています。 const AppBar = ( props ) => { return < div className = "o-app-bar" > { props . children } </ div > ; }; 内包する子コンポーネントが何であれ、 <AppBar /> は自分自身の責任だけを果たせば良いので、開発上もシンプルに考えられます。 className に渡している o-app-bar は ITCSS の Objects レイヤーのクラスです。 .o-app-bar { position : fixed ; top : 0 ; left : 0 ; right : 0 ; z-index : map-get( $zIndexMap , appBar ) ; } ヘッダー要素を画面上部に固定表示する、レイアウトのみの役割を持つコンポーネントなので、Objects レイヤーとなり、 o-app-bar にはレイアウト目的のスタイルのみを持たせます。 ジョブメドレーの採用管理画面では、医療機関や介護施設から求職者に向けた情報を入力していただくために多くのフォーム要素があり、非常に煩雑になりがちですが、 それぞれの役割を果たすコンポーネントを組み合わせることで、UI 開発上の堅牢性、柔軟性を高められる ように努めました。 実際のリニューアル開発時には、全ての UI コンポーネントを実装する前に、開発側ではデザイナーが用意した Sketch から、全ての UI パーツを洗い出す作業を行い、その中で分解不可能なレベルまでコンポーネントを分解していき、実装すべきコンポーネントを一覧化しました。 その後、作成したコンポーネント一覧から全 UI コンポーネントを Storybook に実装していきました。 Storybook は、UI コンポーネント開発のサンドボックス環境として、React や Vue を利用した開発では割と一般的に利用されるようになっていると思います。リニューアル時も各コンポーネントの開発環境として利用して、コンポーネントのパターンや組み合わせの確認などを Storybook 上で行いました。 画面を作っていく段階では、 用意した UI コンポーネントを組み合わせて利用すれば画面全体の大半の UI が出来上がる ようになっていました。 細かい部分では、事前に用意するコンポーネントに不足があったり、実装した後で仕様の変更によりコンポーネント自体を削除することや、分解不可能な状態まで落とし込めてないコンポーネントが見つかったりと、様々な反省点はありました。ですがリニューアル全体を通して振り返ると、Composable な UI コンポーネントで堅牢で柔軟性のある構成にするということに一定の成果は出せたかなと思います。 まとめ UI リニューアル以降、採用管理画面ではリニューアル時の UI システムを土台にして、継続的に機能を追加・改修しています。 プロダクトで設けている KPI も順調に遷移していて、顧客からの問い合わせもリニューアル以前のような、UI 上の問題で利用が困難であるというものは減少し、ポジティブな結果が得られています。 開発をする上でも Composable になるようにコンポーネント群を作成したことで、 リニューアル以降は UI の改修がシンプルに行えるようになり、開発メンバーのスキルセットに左右される部分が少なくなり、開発効率が上がりました 。 このような点からリニューアル自体は良かったと思うと同時に、一方でさらに良い UI を提供するために取り組むべきことは、少なくないと感じます。 例えば採用管理画面が十分にアクセシブルだとは言えないし、パフォーマンス面でもより一層の努力が求められます。もちろん UI コンポーネントの堅牢性もまだ十分とは言えません。 より良いプロダクトを提供するためにそういった課題に対しても継続して取り組んでいきたいと思います。 お知らせ メドレーでは、エンジニア・デザイナーを募集しています。 メドレーでの開発にご興味ある方は、こちらをご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しています。 昨年、ジョブメドレーでは事業所が利用する採用管理画面の UI リニューアルを行いました。ユーザが使いやすい UI づくりを目指すために、長期間にわたり誰が開発しても一貫性ある UI を実現できるようなシステムが必要です。そこで今回は「Composable」な UI システムの実現をテーマに、どのように開発を行ったのかについて、共有させていただきます。 背景：画面や機能追加のたびに UI の一貫性がなくなっていた ジョブメドレーの採用管理画面とは、医療機関や介護施設の採用担当者が求人情報の管理や応募者の選考状況の管理などを行う画面です。 この採用管理画面ですが、リニューアル以前は Angular をフレームワークとして採用した SPA で、UI に関しては AngularUI の Bootstrap を利用して、それぞれのエンジニアが実装を行っていました。 それなりの UI をスピーディーに実現できる点においては、Bootsrap のような UI フレームワークを利用することで受けられる恩恵は大きかったのですが、一方で、包括的に UI 設計を行っているわけではなく、 各人が局所的に UI を作っていくので、画面や機能を追加していく中で一貫性がない UI が増えていく状態 になっていました。 実際にユーザインタビューなどを行ってみると、「ログインした後どうすれば良いのか分からない」、「〇〇という機能があることを今まで知らなかった」、「xx がどこにあるのか分からない」などの意見が多々あり、全面的な UI の見直しが必要になっていました。 医療や介護の現場での人材不足を解消するために採用担当者に提供するツールとして、今後さらに機能拡充していくことが求められていましたが、機能拡充していくことに耐えうる状態にはないというのがプロダクトチームのメンバーの共通認識でした。 そこで、全体的に情報設計から見直してデザインを刷新し、今後プロダクトを成長させていく上でスケール可能な UI を提供できるようにするため、UI リニューアルを決定しました。 フロントエンドで必要だったこと Bootstrap を用いてエンジニアのみで UI を作っていたのとは異なり、リニューアルでは社内のデザイナーが現状の UI 上の課題を整理したデザインを作成しました。 これに伴って、自前で全ての UI パーツを作成することになりましたが、Bootstrap に頼りきっていたときとは違い、堅牢性と柔軟性を伴った UI システムを自分たちで構築する必要がありました。 リニューアル前の採用管理画面の UI は一貫性に欠けており、ユーザは非常に多くの操作を学ぶ必要がありましたが、この責任はデザイナーだけでなく UI 開発をするエンジニアにも大いにあります。 良いデザインができても、最終的にプロダクトの UI はコードによって作り上げられるものなので、エンジニア次第で一貫性に欠ける UI になってしまうことは十分にあり得ると思います。 往々にして起こり得るのは、目にする機会が比較的少ない画面であったり、改修対象ではない部分などが気づいたら崩れていたり、意図しない UI になってしまっていたりということですが、こういった状況に陥る大きな要因としてはフロントエンドの部分で一貫性に対する配慮ができてないことが 1 つだと思います。 そこで、すでにある採用管理画面を使いやすくするのはもちろん、今後スケールしていく中で 一貫性のある UI を担保し続けていくためには、リニューアルでフロントエンドも堅牢で柔軟な UI システムへと変える必要がありました 。 UI リニューアルで開発上大切にしたこと UI の一貫性を保つとなると、今のフロントエンドではもはや当然のことかもしれませんが、コンポーネント指向で構成することになると思います。 技術選定としては、上述の通りリニューアル以前は Angular（v1.4.11）を利用していましたが、リニューアルのタイミングで React へ移行しました。 React を選択した理由としては、学習コストの点やコミュニティが活発でエコシステムが充実している点、単一方向のデータフロー、シンプルな API などを総合的に判断してのものですが、目下の課題である UI コンポーネントのメンテナビリティに関しても適切な選択肢であると考えました。 CSS の方はというと、リニューアル前は Bootstrap でまかなえない部分は Sass でそれぞれのエンジニアが書きたいように書くという状態でしたが、リニューアルで Sass に加えて一部 PostCSS という構成に変更して、設計は ITCSS、Lint を stylelint で行う、という形にしました。 ITCSS を選択した背景としては、その詳細度順のレイヤー階層によってカスケードを管理しやすい点やレイヤーの増減で容易にスケールできる点などから選択しました。 CSS in JS も考慮はしましたが、リニューアルの時点ではこれという決定的な選択肢が無かったこともあり（まだ styled-components も正式リリースされてなかった）、 classnames を利用しました。 フレームワークやライブラリの選定も重要ですが、UI システムを刷新する上で 開発上最も重視したのは「Composability（コンポーネントの組み合わせが容易であること）」 でした。 Composable であるということは、つまり様々な状況において組み込み可能な状態であり、再利用性が高いということになります。 それぞれのコンポーネントを組み合わせることが容易に出来るとともに、複数のコンポーネントを組み合わせた状態から 1 つ 1 つ分解することも容易な状態が望ましく、結果的にそれで UI が構築しやすく改修しやすい状態に自然となるはずです。 モーダルを例にあげると、モーダルの中で表示するコンテンツ要素やモーダルの背面に敷くオーバーレイコンポーネントは、モーダルコンポーネント自体には含まず別のコンポーネントとして切り出した方が再利用しやすく、組み合わせやすい、ということです。 < ModalFrame > < Modal > < ModalHead > ... </ ModalHead > < ModalBody > ... </ ModalBody > </ Modal > < Overlay /> </ ModalFrame > 上記の例でいうと、モーダルを画面の中央に配置することは <ModalFrame /> が行い、 <Modal /> 自体はモーダルに内包されるコンテンツのコンテナとしての役割だけを持ちます。 <Overlay /> も独立したコンポーネントの 1 つで、モーダル以外とも組み合わせて利用しています。 コンテナとなるコンポーネントとその子となるコンポーネントは、別コンポーネントに分離されていることで、お互いに依存しないようになります。 また、Sass ファイルもこのコンポーネント構成に合わせて分けています。 ITCSS において、 <ModalFrame /> のようなレイアウトのみの役割を持つ場合のスタイルは Objects レイヤー（装飾を持たない UI パターンのレイヤー）となり、装飾を持つ <Modal /> や <Overlay /> は Components レイヤーとして扱います。 @import “objects.modal-frame”; @import “components.modal”; @import “components.overlay”; CSS はその特有のカスケードや詳細度によって決定されるスタイルがあり、依存関係を持たない状態を作ることが困難ですが、ITCSS の考えに則ってそれらの CSS の特徴に逆らわないように詳細度の低いものから順番に @import するようにしています。 Sass ファイルの中身ですが、 _objecst.modal-frame.scss は <ModalFrame /> のスタイルのみを記述するようにします。 .o-modal-frame { position : fixed ; top : 0 ; left : 0 ; right : 0 ; bottom : 0 ; z-index : map-get( $zIndexMap , modalFrame ) ; } _components.modal.scss も同様に <Modal /> のスタイルのみを記述します。 .c-modal { position : relative ; margin : 0 auto ; width : 900 px ; min-width : 640 px ; background-color : $JM-White ; box-shadow : 0 1 px 6 px 0 rgba( $JM-Black , 0.2 ) ; z-index : map-get( $zIndexMap , modal ) ; } このように Sass と React コンポーネント毎に 1 対 1 の関係になるようにしています。 プレフィックスとして付与している c- や o- は ITCSS のレイヤーのことを指します。 o- は Objects レイヤーのプレフィックスで、 c- は Components レイヤーのプレフィックスです。 基本的に React の UI コンポーネント内では、コンポーネントの種別に応じて c- か o- のプレフィックスを持つクラスと、状態によって付けたり外したりする State レイヤーの s- プレフィックスのクラスのみを使用します。 話を React に戻すと、下記のようなヘッダー要素を画面上部に固定表示するだけの役割を持つ <AppBar /> コンポーネントは、 props.children で子要素を受け取れるようになっているだけで、その内容には関知しないようになっています。 const AppBar = ( props ) => { return < div className = "o-app-bar" > { props . children } </ div > ; }; 内包する子コンポーネントが何であれ、 <AppBar /> は自分自身の責任だけを果たせば良いので、開発上もシンプルに考えられます。 className に渡している o-app-bar は ITCSS の Objects レイヤーのクラスです。 .o-app-bar { position : fixed ; top : 0 ; left : 0 ; right : 0 ; z-index : map-get( $zIndexMap , appBar ) ; } ヘッダー要素を画面上部に固定表示する、レイアウトのみの役割を持つコンポーネントなので、Objects レイヤーとなり、 o-app-bar にはレイアウト目的のスタイルのみを持たせます。 ジョブメドレーの採用管理画面では、医療機関や介護施設から求職者に向けた情報を入力していただくために多くのフォーム要素があり、非常に煩雑になりがちですが、 それぞれの役割を果たすコンポーネントを組み合わせることで、UI 開発上の堅牢性、柔軟性を高められる ように努めました。 実際のリニューアル開発時には、全ての UI コンポーネントを実装する前に、開発側ではデザイナーが用意した Sketch から、全ての UI パーツを洗い出す作業を行い、その中で分解不可能なレベルまでコンポーネントを分解していき、実装すべきコンポーネントを一覧化しました。 その後、作成したコンポーネント一覧から全 UI コンポーネントを Storybook に実装していきました。 Storybook は、UI コンポーネント開発のサンドボックス環境として、React や Vue を利用した開発では割と一般的に利用されるようになっていると思います。リニューアル時も各コンポーネントの開発環境として利用して、コンポーネントのパターンや組み合わせの確認などを Storybook 上で行いました。 画面を作っていく段階では、 用意した UI コンポーネントを組み合わせて利用すれば画面全体の大半の UI が出来上がる ようになっていました。 細かい部分では、事前に用意するコンポーネントに不足があったり、実装した後で仕様の変更によりコンポーネント自体を削除することや、分解不可能な状態まで落とし込めてないコンポーネントが見つかったりと、様々な反省点はありました。ですがリニューアル全体を通して振り返ると、Composable な UI コンポーネントで堅牢で柔軟性のある構成にするということに一定の成果は出せたかなと思います。 まとめ UI リニューアル以降、採用管理画面ではリニューアル時の UI システムを土台にして、継続的に機能を追加・改修しています。 プロダクトで設けている KPI も順調に遷移していて、顧客からの問い合わせもリニューアル以前のような、UI 上の問題で利用が困難であるというものは減少し、ポジティブな結果が得られています。 開発をする上でも Composable になるようにコンポーネント群を作成したことで、 リニューアル以降は UI の改修がシンプルに行えるようになり、開発メンバーのスキルセットに左右される部分が少なくなり、開発効率が上がりました 。 このような点からリニューアル自体は良かったと思うと同時に、一方でさらに良い UI を提供するために取り組むべきことは、少なくないと感じます。 例えば採用管理画面が十分にアクセシブルだとは言えないし、パフォーマンス面でもより一層の努力が求められます。もちろん UI コンポーネントの堅牢性もまだ十分とは言えません。 より良いプロダクトを提供するためにそういった課題に対しても継続して取り組んでいきたいと思います。 お知らせ メドレーでは、エンジニア・デザイナーを募集しています。 メドレーでの開発にご興味ある方は、こちらをご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の舘野です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しています。 昨年、ジョブメドレーでは事業所が利用する採用管理画面の UI リニューアルを行いました。ユーザが使いやすい UI づくりを目指すために、長期間にわたり誰が開発しても一貫性ある UI を実現できるようなシステムが必要です。そこで今回は「Composable」な UI システムの実現をテーマに、どのように開発を行ったのかについて、共有させていただきます。 背景：画面や機能追加のたびに UI の一貫性がなくなっていた ジョブメドレーの採用管理画面とは、医療機関や介護施設の採用担当者が求人情報の管理や応募者の選考状況の管理などを行う画面です。 この採用管理画面ですが、リニューアル以前は Angular をフレームワークとして採用した SPA で、UI に関しては AngularUI の Bootstrap を利用して、それぞれのエンジニアが実装を行っていました。 それなりの UI をスピーディーに実現できる点においては、Bootsrap のような UI フレームワークを利用することで受けられる恩恵は大きかったのですが、一方で、包括的に UI 設計を行っているわけではなく、 各人が局所的に UI を作っていくので、画面や機能を追加していく中で一貫性がない UI が増えていく状態 になっていました。 実際にユーザインタビューなどを行ってみると、「ログインした後どうすれば良いのか分からない」、「〇〇という機能があることを今まで知らなかった」、「xx がどこにあるのか分からない」などの意見が多々あり、全面的な UI の見直しが必要になっていました。 医療や介護の現場での人材不足を解消するために採用担当者に提供するツールとして、今後さらに機能拡充していくことが求められていましたが、機能拡充していくことに耐えうる状態にはないというのがプロダクトチームのメンバーの共通認識でした。 そこで、全体的に情報設計から見直してデザインを刷新し、今後プロダクトを成長させていく上でスケール可能な UI を提供できるようにするため、UI リニューアルを決定しました。 フロントエンドで必要だったこと Bootstrap を用いてエンジニアのみで UI を作っていたのとは異なり、リニューアルでは社内のデザイナーが現状の UI 上の課題を整理したデザインを作成しました。 これに伴って、自前で全ての UI パーツを作成することになりましたが、Bootstrap に頼りきっていたときとは違い、堅牢性と柔軟性を伴った UI システムを自分たちで構築する必要がありました。 リニューアル前の採用管理画面の UI は一貫性に欠けており、ユーザは非常に多くの操作を学ぶ必要がありましたが、この責任はデザイナーだけでなく UI 開発をするエンジニアにも大いにあります。 良いデザインができても、最終的にプロダクトの UI はコードによって作り上げられるものなので、エンジニア次第で一貫性に欠ける UI になってしまうことは十分にあり得ると思います。 往々にして起こり得るのは、目にする機会が比較的少ない画面であったり、改修対象ではない部分などが気づいたら崩れていたり、意図しない UI になってしまっていたりということですが、こういった状況に陥る大きな要因としてはフロントエンドの部分で一貫性に対する配慮ができてないことが 1 つだと思います。 そこで、すでにある採用管理画面を使いやすくするのはもちろん、今後スケールしていく中で 一貫性のある UI を担保し続けていくためには、リニューアルでフロントエンドも堅牢で柔軟な UI システムへと変える必要がありました 。 UI リニューアルで開発上大切にしたこと UI の一貫性を保つとなると、今のフロントエンドではもはや当然のことかもしれませんが、コンポーネント指向で構成することになると思います。 技術選定としては、上述の通りリニューアル以前は Angular（v1.4.11）を利用していましたが、リニューアルのタイミングで React へ移行しました。 React を選択した理由としては、学習コストの点やコミュニティが活発でエコシステムが充実している点、単一方向のデータフロー、シンプルな API などを総合的に判断してのものですが、目下の課題である UI コンポーネントのメンテナビリティに関しても適切な選択肢であると考えました。 CSS の方はというと、リニューアル前は Bootstrap でまかなえない部分は Sass でそれぞれのエンジニアが書きたいように書くという状態でしたが、リニューアルで Sass に加えて一部 PostCSS という構成に変更して、設計は ITCSS、Lint を stylelint で行う、という形にしました。 ITCSS を選択した背景としては、その詳細度順のレイヤー階層によってカスケードを管理しやすい点やレイヤーの増減で容易にスケールできる点などから選択しました。 CSS in JS も考慮はしましたが、リニューアルの時点ではこれという決定的な選択肢が無かったこともあり（まだ styled-components も正式リリースされてなかった）、 classnames を利用しました。 フレームワークやライブラリの選定も重要ですが、UI システムを刷新する上で 開発上最も重視したのは「Composability（コンポーネントの組み合わせが容易であること）」 でした。 Composable であるということは、つまり様々な状況において組み込み可能な状態であり、再利用性が高いということになります。 それぞれのコンポーネントを組み合わせることが容易に出来るとともに、複数のコンポーネントを組み合わせた状態から 1 つ 1 つ分解することも容易な状態が望ましく、結果的にそれで UI が構築しやすく改修しやすい状態に自然となるはずです。 モーダルを例にあげると、モーダルの中で表示するコンテンツ要素やモーダルの背面に敷くオーバーレイコンポーネントは、モーダルコンポーネント自体には含まず別のコンポーネントとして切り出した方が再利用しやすく、組み合わせやすい、ということです。 < ModalFrame > < Modal > < ModalHead > ... </ ModalHead > < ModalBody > ... </ ModalBody > </ Modal > < Overlay /> </ ModalFrame > 上記の例でいうと、モーダルを画面の中央に配置することは <ModalFrame /> が行い、 <Modal /> 自体はモーダルに内包されるコンテンツのコンテナとしての役割だけを持ちます。 <Overlay /> も独立したコンポーネントの 1 つで、モーダル以外とも組み合わせて利用しています。 コンテナとなるコンポーネントとその子となるコンポーネントは、別コンポーネントに分離されていることで、お互いに依存しないようになります。 また、Sass ファイルもこのコンポーネント構成に合わせて分けています。 ITCSS において、 <ModalFrame /> のようなレイアウトのみの役割を持つ場合のスタイルは Objects レイヤー（装飾を持たない UI パターンのレイヤー）となり、装飾を持つ <Modal /> や <Overlay /> は Components レイヤーとして扱います。 @import “objects.modal-frame”; @import “components.modal”; @import “components.overlay”; CSS はその特有のカスケードや詳細度によって決定されるスタイルがあり、依存関係を持たない状態を作ることが困難ですが、ITCSS の考えに則ってそれらの CSS の特徴に逆らわないように詳細度の低いものから順番に @import するようにしています。 Sass ファイルの中身ですが、 _objecst.modal-frame.scss は <ModalFrame /> のスタイルのみを記述するようにします。 .o-modal-frame { position : fixed ; top : 0 ; left : 0 ; right : 0 ; bottom : 0 ; z-index : map-get( $zIndexMap , modalFrame ) ; } _components.modal.scss も同様に <Modal /> のスタイルのみを記述します。 .c-modal { position : relative ; margin : 0 auto ; width : 900 px ; min-width : 640 px ; background-color : $JM-White ; box-shadow : 0 1 px 6 px 0 rgba( $JM-Black , 0.2 ) ; z-index : map-get( $zIndexMap , modal ) ; } このように Sass と React コンポーネント毎に 1 対 1 の関係になるようにしています。 プレフィックスとして付与している c- や o- は ITCSS のレイヤーのことを指します。 o- は Objects レイヤーのプレフィックスで、 c- は Components レイヤーのプレフィックスです。 基本的に React の UI コンポーネント内では、コンポーネントの種別に応じて c- か o- のプレフィックスを持つクラスと、状態によって付けたり外したりする State レイヤーの s- プレフィックスのクラスのみを使用します。 話を React に戻すと、下記のようなヘッダー要素を画面上部に固定表示するだけの役割を持つ <AppBar /> コンポーネントは、 props.children で子要素を受け取れるようになっているだけで、その内容には関知しないようになっています。 const AppBar = ( props ) => { return < div className = "o-app-bar" > { props . children } </ div > ; }; 内包する子コンポーネントが何であれ、 <AppBar /> は自分自身の責任だけを果たせば良いので、開発上もシンプルに考えられます。 className に渡している o-app-bar は ITCSS の Objects レイヤーのクラスです。 .o-app-bar { position : fixed ; top : 0 ; left : 0 ; right : 0 ; z-index : map-get( $zIndexMap , appBar ) ; } ヘッダー要素を画面上部に固定表示する、レイアウトのみの役割を持つコンポーネントなので、Objects レイヤーとなり、 o-app-bar にはレイアウト目的のスタイルのみを持たせます。 ジョブメドレーの採用管理画面では、医療機関や介護施設から求職者に向けた情報を入力していただくために多くのフォーム要素があり、非常に煩雑になりがちですが、 それぞれの役割を果たすコンポーネントを組み合わせることで、UI 開発上の堅牢性、柔軟性を高められる ように努めました。 実際のリニューアル開発時には、全ての UI コンポーネントを実装する前に、開発側ではデザイナーが用意した Sketch から、全ての UI パーツを洗い出す作業を行い、その中で分解不可能なレベルまでコンポーネントを分解していき、実装すべきコンポーネントを一覧化しました。 その後、作成したコンポーネント一覧から全 UI コンポーネントを Storybook に実装していきました。 Storybook は、UI コンポーネント開発のサンドボックス環境として、React や Vue を利用した開発では割と一般的に利用されるようになっていると思います。リニューアル時も各コンポーネントの開発環境として利用して、コンポーネントのパターンや組み合わせの確認などを Storybook 上で行いました。 画面を作っていく段階では、 用意した UI コンポーネントを組み合わせて利用すれば画面全体の大半の UI が出来上がる ようになっていました。 細かい部分では、事前に用意するコンポーネントに不足があったり、実装した後で仕様の変更によりコンポーネント自体を削除することや、分解不可能な状態まで落とし込めてないコンポーネントが見つかったりと、様々な反省点はありました。ですがリニューアル全体を通して振り返ると、Composable な UI コンポーネントで堅牢で柔軟性のある構成にするということに一定の成果は出せたかなと思います。 まとめ UI リニューアル以降、採用管理画面ではリニューアル時の UI システムを土台にして、継続的に機能を追加・改修しています。 プロダクトで設けている KPI も順調に遷移していて、顧客からの問い合わせもリニューアル以前のような、UI 上の問題で利用が困難であるというものは減少し、ポジティブな結果が得られています。 開発をする上でも Composable になるようにコンポーネント群を作成したことで、 リニューアル以降は UI の改修がシンプルに行えるようになり、開発メンバーのスキルセットに左右される部分が少なくなり、開発効率が上がりました 。 このような点からリニューアル自体は良かったと思うと同時に、一方でさらに良い UI を提供するために取り組むべきことは、少なくないと感じます。 例えば採用管理画面が十分にアクセシブルだとは言えないし、パフォーマンス面でもより一層の努力が求められます。もちろん UI コンポーネントの堅牢性もまだ十分とは言えません。 より良いプロダクトを提供するためにそういった課題に対しても継続して取り組んでいきたいと思います。 お知らせ メドレーでは、エンジニア・デザイナーを募集しています。 メドレーでの開発にご興味ある方は、こちらをご覧ください。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の日下です。インターンを経て新卒としてメドレーに入り、現在は 1 年生エンジニアとして オンライン診療アプリ CLINICS の開発を担当しています。先日開発本部でキックオフ合宿を河口湖で行ってきましたので、詳細をレポートします。 年始のキックオフを合宿で行う意図 メドレーの開発本部では、チームビルディングを目的としてバーベキューなど全体でリフレッシュをする機会を年に数回設けています。 そのリフレッシュの一環として行っているメドレーの「年始のキックオフ合宿」は、昨年から行われています。昨年のレポートは こちら にあります。 メドレー開発本部全体のキックオフを合宿で行う意図は主に二つあります。 親睦を深める 一つ目の理由は親睦を深めることにあります。 リフレッシュを兼ねた 一体感の醸成、連携・親密感を深める場 を定期的に用意するようにしています。実際に合宿を終えて振り返ってみても、 合宿は日常より密な交流をする場として最高 だったなと思います。 方向性の共有 二つ目の理由は方向性の共有のためです。 昨年の合宿では、今後どういった方向を会社として、また各プロダクトとして目指して行くのかといった話を CTO ・平山から共有しました。普段の業務から離れた場所でこうした話に向き合えるという意味で、 共通の軸をより強く持つためには合宿が適切 だと実感し、今年も合宿を行うことになりました。 合宿先・アクティビティの選定 いわゆる開発合宿ではなかったため、選定には次の項目を重視しました。 二十数名を収容できるキャパシティがあること プライベートでも行きたい、思い出になるような場所であること アクティビティが近くにあること +α でバーベキューなどができること 上記の条件をすべて満たした場所を調査しましたが、「宿はあるがアクティビティがない」「アクティビティはあるが宿がない」のようになかなかマッチするところがなく苦労しました。 最終的にはこれら全てにマッチした先として、宿泊先を 河口湖カントリーコテージ さん に、アクティビティは カントリーレイクシステムズ さん にお世話になることにしました。 また、アクティビティに関しては、カヌー体験やほうとうづくりなど様々なものが用意されていましたが、次の観点から 洞窟探検 を選択しました。 普段座りっぱなしなので、運動が行えること 新しい刺激を受けられるように、非日常感が体験できること メンバーの普段見れない様子がでてきそうな、高揚感の高まる場所であること 非日常な体験ができる洞窟探検 当日、河口湖駅に集合した後はまずアクティビティに挑みました。 みんなで非日常を体験し、リフレッシュしてもらおうと選択したものでしたが、私も含め洞窟探検をした人はおらず、どういったものだろうとワクワクしながら富士の樹海を散策しました。 今回体験した洞窟は富士の青木ヶ原樹海にある 富士風穴 、初めて本格的な洞窟を見た我々は息を呑むような風景に圧倒されました。 先日の週刊メドレー で掲載された写真はまさに洞窟に入ろうとするメンバーでした。 思った以上に洞窟感のある洞窟が姿を表しおおーっとなりました。 天井に頭をぶつけたり、手をついて怪我をしたりする可能性がありましたが、ヘルメット・手袋・真っ赤なつなぎといったグッズがレンタルできたので、すべて装着して洞窟に挑みました。 洞窟の中は手すりや階段のない、自然そのままの洞窟らしく、岩がむき出しで天井が低かったりしたので思った以上に装備が役に立ちました。 氷柱がある中、奥の方まで進むメンバー 洞窟といえば氷柱！と思っていたのですが、ちょうど数日前に雨が降った影響で、普段より足元や天井から氷柱がたくさん生えていたので触ってみたり、初めての経験ばかりでした。 氷が多い影響で滑りかけることもありましたが、ガイドさんと先行しているメンバーからの助言に助けられつつ進むことができました。 無事に生還しました！ 普段は一緒に仕事をしている仲間と会社ではなく洞窟という空間で一緒にいるという不思議な状況と、適度な運動のせいか気分は高揚し、普段は見られないような同僚の一面を見ることができた良い経験になったと思います。 2018 年の開発本部キックオフ！ アクティビティで適度に運動をした後はコテージに移り、少しずつお酒を飲んでくつろぎ始めたタイミングで、2018 年のキックオフとして CTO ・平山によるプレゼンを行いました。 昨年 2017 年は四つのプロダクトのうちジョブメドレー・ MEDLEY ・ CLINICS の大規模リニューアルがあり、大きな変化の年となりました。 また、今後どういった会社にしていきたいか？医療業界にどういった形で我々が貢献していくのか？そしてそのために事業として、またプロダクトとして 2018 年はどういった体制で推進していくのかといった事柄が共有されました。 なぜやるのか？どうやってやるのか？といった根本的な指針を背景を元に共有してもらうことで、今後の仕事における一つの軸ができたキックオフになったかと思います。 私自身一年間 CLINICS に関わってきたため、肌身で感じてきた変化や苦労を思い出しつつ、プロダクト・事業が着実に成長していることを感じることができ、次の指針を確認する良い機会となりました。 平山のプロダクト・事業・会社に対する熱い思いは メドレー平山の中央突破 にも書かれていますので、ぜひご覧ください。 バーベキュー&飲み キックオフ後はバーベキュー！そして飲み！ 火に強いメンバーは肉を焼いたり、料理が得意なメンバーは焼きそばやパスタを作っては食べて飲んで談笑し、思い思いに合宿を楽しんでいました。 まずは肉を焼く火に強いメンバー 談笑するメンバー（酔いが回りピントがボケ気味） 思い思いにくつろぐメンバー 余談ですが、上の画像で全員が着ている灰色のパーカーはキックオフ直前に配られたメドレーオフィシャルグッズの一つ、 デザイン部長・マエダ がデザインしたメドレーパーカーです。 実はメドレーではパーカー以外にもうちわや T シャツ、絆創膏などグッズが増えています。 気がついたら増えているので収集は大変ですが、今年はどういったグッズが作られるのか今から楽しみです。 メンバー同士で飲んで食べてくつろぎながら、プロダクトへの思いやプライベートの話などを語り合う宴会が夜遅くまで続きました。 まとめ いかがだったでしょうか？メドレー開発本部のキックオフ合宿の様子が少しでも伝われば幸いです。 アクティビティやバーベキューを通じてより親密に、プレゼンを通じて認識の共有ができた良い合宿になったと思います。 なお、今回の宿泊先は 大人数でも対応可能なコテージが用意され 、また Wi-Fi などの通信設備も整い、受付の方の対応も丁寧で、プライベートでも利用したくなる素敵な宿でした。 開発合宿等の大人数での宿を探している方にご参考になれば幸いです。 最後に 最後になりましたが、今回の合宿の企画運営をリードしてくれた新居さんありがとうございました！ 来年またキックオフ合宿したいですね！（CTO が撮影してくれたので、CTO 不在の集合写真） メドレーでは、チームで新しい医療体験を提供するプロダクトを一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の日下です。インターンを経て新卒としてメドレーに入り、現在は 1 年生エンジニアとして オンライン診療アプリ CLINICS の開発を担当しています。先日開発本部でキックオフ合宿を河口湖で行ってきましたので、詳細をレポートします。 年始のキックオフを合宿で行う意図 メドレーの開発本部では、チームビルディングを目的としてバーベキューなど全体でリフレッシュをする機会を年に数回設けています。 そのリフレッシュの一環として行っているメドレーの「年始のキックオフ合宿」は、昨年から行われています。昨年のレポートは こちら にあります。 メドレー開発本部全体のキックオフを合宿で行う意図は主に二つあります。 親睦を深める 一つ目の理由は親睦を深めることにあります。 リフレッシュを兼ねた 一体感の醸成、連携・親密感を深める場 を定期的に用意するようにしています。実際に合宿を終えて振り返ってみても、 合宿は日常より密な交流をする場として最高 だったなと思います。 方向性の共有 二つ目の理由は方向性の共有のためです。 昨年の合宿では、今後どういった方向を会社として、また各プロダクトとして目指して行くのかといった話を CTO ・平山から共有しました。普段の業務から離れた場所でこうした話に向き合えるという意味で、 共通の軸をより強く持つためには合宿が適切 だと実感し、今年も合宿を行うことになりました。 合宿先・アクティビティの選定 いわゆる開発合宿ではなかったため、選定には次の項目を重視しました。 二十数名を収容できるキャパシティがあること プライベートでも行きたい、思い出になるような場所であること アクティビティが近くにあること +α でバーベキューなどができること 上記の条件をすべて満たした場所を調査しましたが、「宿はあるがアクティビティがない」「アクティビティはあるが宿がない」のようになかなかマッチするところがなく苦労しました。 最終的にはこれら全てにマッチした先として、宿泊先を 河口湖カントリーコテージ さん に、アクティビティは カントリーレイクシステムズ さん にお世話になることにしました。 また、アクティビティに関しては、カヌー体験やほうとうづくりなど様々なものが用意されていましたが、次の観点から 洞窟探検 を選択しました。 普段座りっぱなしなので、運動が行えること 新しい刺激を受けられるように、非日常感が体験できること メンバーの普段見れない様子がでてきそうな、高揚感の高まる場所であること 非日常な体験ができる洞窟探検 当日、河口湖駅に集合した後はまずアクティビティに挑みました。 みんなで非日常を体験し、リフレッシュしてもらおうと選択したものでしたが、私も含め洞窟探検をした人はおらず、どういったものだろうとワクワクしながら富士の樹海を散策しました。 今回体験した洞窟は富士の青木ヶ原樹海にある 富士風穴 、初めて本格的な洞窟を見た我々は息を呑むような風景に圧倒されました。 先日の週刊メドレー で掲載された写真はまさに洞窟に入ろうとするメンバーでした。 思った以上に洞窟感のある洞窟が姿を表しおおーっとなりました。 天井に頭をぶつけたり、手をついて怪我をしたりする可能性がありましたが、ヘルメット・手袋・真っ赤なつなぎといったグッズがレンタルできたので、すべて装着して洞窟に挑みました。 洞窟の中は手すりや階段のない、自然そのままの洞窟らしく、岩がむき出しで天井が低かったりしたので思った以上に装備が役に立ちました。 氷柱がある中、奥の方まで進むメンバー 洞窟といえば氷柱！と思っていたのですが、ちょうど数日前に雨が降った影響で、普段より足元や天井から氷柱がたくさん生えていたので触ってみたり、初めての経験ばかりでした。 氷が多い影響で滑りかけることもありましたが、ガイドさんと先行しているメンバーからの助言に助けられつつ進むことができました。 無事に生還しました！ 普段は一緒に仕事をしている仲間と会社ではなく洞窟という空間で一緒にいるという不思議な状況と、適度な運動のせいか気分は高揚し、普段は見られないような同僚の一面を見ることができた良い経験になったと思います。 2018 年の開発本部キックオフ！ アクティビティで適度に運動をした後はコテージに移り、少しずつお酒を飲んでくつろぎ始めたタイミングで、2018 年のキックオフとして CTO ・平山によるプレゼンを行いました。 昨年 2017 年は四つのプロダクトのうちジョブメドレー・ MEDLEY ・ CLINICS の大規模リニューアルがあり、大きな変化の年となりました。 また、今後どういった会社にしていきたいか？医療業界にどういった形で我々が貢献していくのか？そしてそのために事業として、またプロダクトとして 2018 年はどういった体制で推進していくのかといった事柄が共有されました。 なぜやるのか？どうやってやるのか？といった根本的な指針を背景を元に共有してもらうことで、今後の仕事における一つの軸ができたキックオフになったかと思います。 私自身一年間 CLINICS に関わってきたため、肌身で感じてきた変化や苦労を思い出しつつ、プロダクト・事業が着実に成長していることを感じることができ、次の指針を確認する良い機会となりました。 平山のプロダクト・事業・会社に対する熱い思いは メドレー平山の中央突破 にも書かれていますので、ぜひご覧ください。 バーベキュー&飲み キックオフ後はバーベキュー！そして飲み！ 火に強いメンバーは肉を焼いたり、料理が得意なメンバーは焼きそばやパスタを作っては食べて飲んで談笑し、思い思いに合宿を楽しんでいました。 まずは肉を焼く火に強いメンバー 談笑するメンバー（酔いが回りピントがボケ気味） 思い思いにくつろぐメンバー 余談ですが、上の画像で全員が着ている灰色のパーカーはキックオフ直前に配られたメドレーオフィシャルグッズの一つ、 デザイン部長・マエダ がデザインしたメドレーパーカーです。 実はメドレーではパーカー以外にもうちわや T シャツ、絆創膏などグッズが増えています。 気がついたら増えているので収集は大変ですが、今年はどういったグッズが作られるのか今から楽しみです。 メンバー同士で飲んで食べてくつろぎながら、プロダクトへの思いやプライベートの話などを語り合う宴会が夜遅くまで続きました。 まとめ いかがだったでしょうか？メドレー開発本部のキックオフ合宿の様子が少しでも伝われば幸いです。 アクティビティやバーベキューを通じてより親密に、プレゼンを通じて認識の共有ができた良い合宿になったと思います。 なお、今回の宿泊先は 大人数でも対応可能なコテージが用意され 、また Wi-Fi などの通信設備も整い、受付の方の対応も丁寧で、プライベートでも利用したくなる素敵な宿でした。 開発合宿等の大人数での宿を探している方にご参考になれば幸いです。 最後に 最後になりましたが、今回の合宿の企画運営をリードしてくれた新居さんありがとうございました！ 来年またキックオフ合宿したいですね！（CTO が撮影してくれたので、CTO 不在の集合写真） メドレーでは、チームで新しい医療体験を提供するプロダクトを一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ https://www.medley.jp/recruit/creative.html

こんにちは、開発本部の日下です。インターンを経て新卒としてメドレーに入り、現在は 1 年生エンジニアとして オンライン診療アプリ CLINICS の開発を担当しています。先日開発本部でキックオフ合宿を河口湖で行ってきましたので、詳細をレポートします。 年始のキックオフを合宿で行う意図 メドレーの開発本部では、チームビルディングを目的としてバーベキューなど全体でリフレッシュをする機会を年に数回設けています。 そのリフレッシュの一環として行っているメドレーの「年始のキックオフ合宿」は、昨年から行われています。昨年のレポートは こちら にあります。 メドレー開発本部全体のキックオフを合宿で行う意図は主に二つあります。 親睦を深める 一つ目の理由は親睦を深めることにあります。 リフレッシュを兼ねた 一体感の醸成、連携・親密感を深める場 を定期的に用意するようにしています。実際に合宿を終えて振り返ってみても、 合宿は日常より密な交流をする場として最高 だったなと思います。 方向性の共有 二つ目の理由は方向性の共有のためです。 昨年の合宿では、今後どういった方向を会社として、また各プロダクトとして目指して行くのかといった話を CTO ・平山から共有しました。普段の業務から離れた場所でこうした話に向き合えるという意味で、 共通の軸をより強く持つためには合宿が適切 だと実感し、今年も合宿を行うことになりました。 合宿先・アクティビティの選定 いわゆる開発合宿ではなかったため、選定には次の項目を重視しました。 二十数名を収容できるキャパシティがあること プライベートでも行きたい、思い出になるような場所であること アクティビティが近くにあること +α でバーベキューなどができること 上記の条件をすべて満たした場所を調査しましたが、「宿はあるがアクティビティがない」「アクティビティはあるが宿がない」のようになかなかマッチするところがなく苦労しました。 最終的にはこれら全てにマッチした先として、宿泊先を 河口湖カントリーコテージ さん に、アクティビティは カントリーレイクシステムズ さん にお世話になることにしました。 また、アクティビティに関しては、カヌー体験やほうとうづくりなど様々なものが用意されていましたが、次の観点から 洞窟探検 を選択しました。 普段座りっぱなしなので、運動が行えること 新しい刺激を受けられるように、非日常感が体験できること メンバーの普段見れない様子がでてきそうな、高揚感の高まる場所であること 非日常な体験ができる洞窟探検 当日、河口湖駅に集合した後はまずアクティビティに挑みました。 みんなで非日常を体験し、リフレッシュしてもらおうと選択したものでしたが、私も含め洞窟探検をした人はおらず、どういったものだろうとワクワクしながら富士の樹海を散策しました。 今回体験した洞窟は富士の青木ヶ原樹海にある 富士風穴 、初めて本格的な洞窟を見た我々は息を呑むような風景に圧倒されました。 先日の週刊メドレー で掲載された写真はまさに洞窟に入ろうとするメンバーでした。 思った以上に洞窟感のある洞窟が姿を表しおおーっとなりました。 天井に頭をぶつけたり、手をついて怪我をしたりする可能性がありましたが、ヘルメット・手袋・真っ赤なつなぎといったグッズがレンタルできたので、すべて装着して洞窟に挑みました。 洞窟の中は手すりや階段のない、自然そのままの洞窟らしく、岩がむき出しで天井が低かったりしたので思った以上に装備が役に立ちました。 氷柱がある中、奥の方まで進むメンバー 洞窟といえば氷柱！と思っていたのですが、ちょうど数日前に雨が降った影響で、普段より足元や天井から氷柱がたくさん生えていたので触ってみたり、初めての経験ばかりでした。 氷が多い影響で滑りかけることもありましたが、ガイドさんと先行しているメンバーからの助言に助けられつつ進むことができました。 無事に生還しました！ 普段は一緒に仕事をしている仲間と会社ではなく洞窟という空間で一緒にいるという不思議な状況と、適度な運動のせいか気分は高揚し、普段は見られないような同僚の一面を見ることができた良い経験になったと思います。 2018 年の開発本部キックオフ！ アクティビティで適度に運動をした後はコテージに移り、少しずつお酒を飲んでくつろぎ始めたタイミングで、2018 年のキックオフとして CTO ・平山によるプレゼンを行いました。 昨年 2017 年は四つのプロダクトのうちジョブメドレー・ MEDLEY ・ CLINICS の大規模リニューアルがあり、大きな変化の年となりました。 また、今後どういった会社にしていきたいか？医療業界にどういった形で我々が貢献していくのか？そしてそのために事業として、またプロダクトとして 2018 年はどういった体制で推進していくのかといった事柄が共有されました。 なぜやるのか？どうやってやるのか？といった根本的な指針を背景を元に共有してもらうことで、今後の仕事における一つの軸ができたキックオフになったかと思います。 私自身一年間 CLINICS に関わってきたため、肌身で感じてきた変化や苦労を思い出しつつ、プロダクト・事業が着実に成長していることを感じることができ、次の指針を確認する良い機会となりました。 平山のプロダクト・事業・会社に対する熱い思いは メドレー平山の中央突破 にも書かれていますので、ぜひご覧ください。 バーベキュー&飲み キックオフ後はバーベキュー！そして飲み！ 火に強いメンバーは肉を焼いたり、料理が得意なメンバーは焼きそばやパスタを作っては食べて飲んで談笑し、思い思いに合宿を楽しんでいました。 まずは肉を焼く火に強いメンバー 談笑するメンバー（酔いが回りピントがボケ気味） 思い思いにくつろぐメンバー 余談ですが、上の画像で全員が着ている灰色のパーカーはキックオフ直前に配られたメドレーオフィシャルグッズの一つ、 デザイン部長・マエダ がデザインしたメドレーパーカーです。 実はメドレーではパーカー以外にもうちわや T シャツ、絆創膏などグッズが増えています。 気がついたら増えているので収集は大変ですが、今年はどういったグッズが作られるのか今から楽しみです。 メンバー同士で飲んで食べてくつろぎながら、プロダクトへの思いやプライベートの話などを語り合う宴会が夜遅くまで続きました。 まとめ いかがだったでしょうか？メドレー開発本部のキックオフ合宿の様子が少しでも伝われば幸いです。 アクティビティやバーベキューを通じてより親密に、プレゼンを通じて認識の共有ができた良い合宿になったと思います。 なお、今回の宿泊先は 大人数でも対応可能なコテージが用意され 、また Wi-Fi などの通信設備も整い、受付の方の対応も丁寧で、プライベートでも利用したくなる素敵な宿でした。 開発合宿等の大人数での宿を探している方にご参考になれば幸いです。 最後に 最後になりましたが、今回の合宿の企画運営をリードしてくれた新居さんありがとうございました！ 来年またキックオフ合宿したいですね！（CTO が撮影してくれたので、CTO 不在の集合写真） メドレーでは、チームで新しい医療体験を提供するプロダクトを一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の日下です。インターンを経て新卒としてメドレーに入り、現在は 1 年生エンジニアとして オンライン診療アプリ CLINICS の開発を担当しています。先日開発本部でキックオフ合宿を河口湖で行ってきましたので、詳細をレポートします。 年始のキックオフを合宿で行う意図 メドレーの開発本部では、チームビルディングを目的としてバーベキューなど全体でリフレッシュをする機会を年に数回設けています。 そのリフレッシュの一環として行っているメドレーの「年始のキックオフ合宿」は、昨年から行われています。昨年のレポートは こちら にあります。 メドレー開発本部全体のキックオフを合宿で行う意図は主に二つあります。 親睦を深める 一つ目の理由は親睦を深めることにあります。 リフレッシュを兼ねた 一体感の醸成、連携・親密感を深める場 を定期的に用意するようにしています。実際に合宿を終えて振り返ってみても、 合宿は日常より密な交流をする場として最高 だったなと思います。 方向性の共有 二つ目の理由は方向性の共有のためです。 昨年の合宿では、今後どういった方向を会社として、また各プロダクトとして目指して行くのかといった話を CTO ・平山から共有しました。普段の業務から離れた場所でこうした話に向き合えるという意味で、 共通の軸をより強く持つためには合宿が適切 だと実感し、今年も合宿を行うことになりました。 合宿先・アクティビティの選定 いわゆる開発合宿ではなかったため、選定には次の項目を重視しました。 二十数名を収容できるキャパシティがあること プライベートでも行きたい、思い出になるような場所であること アクティビティが近くにあること +α でバーベキューなどができること 上記の条件をすべて満たした場所を調査しましたが、「宿はあるがアクティビティがない」「アクティビティはあるが宿がない」のようになかなかマッチするところがなく苦労しました。 最終的にはこれら全てにマッチした先として、宿泊先を 河口湖カントリーコテージ さん に、アクティビティは カントリーレイクシステムズ さん にお世話になることにしました。 また、アクティビティに関しては、カヌー体験やほうとうづくりなど様々なものが用意されていましたが、次の観点から 洞窟探検 を選択しました。 普段座りっぱなしなので、運動が行えること 新しい刺激を受けられるように、非日常感が体験できること メンバーの普段見れない様子がでてきそうな、高揚感の高まる場所であること 非日常な体験ができる洞窟探検 当日、河口湖駅に集合した後はまずアクティビティに挑みました。 みんなで非日常を体験し、リフレッシュしてもらおうと選択したものでしたが、私も含め洞窟探検をした人はおらず、どういったものだろうとワクワクしながら富士の樹海を散策しました。 今回体験した洞窟は富士の青木ヶ原樹海にある 富士風穴 、初めて本格的な洞窟を見た我々は息を呑むような風景に圧倒されました。 先日の週刊メドレー で掲載された写真はまさに洞窟に入ろうとするメンバーでした。 思った以上に洞窟感のある洞窟が姿を表しおおーっとなりました。 天井に頭をぶつけたり、手をついて怪我をしたりする可能性がありましたが、ヘルメット・手袋・真っ赤なつなぎといったグッズがレンタルできたので、すべて装着して洞窟に挑みました。 洞窟の中は手すりや階段のない、自然そのままの洞窟らしく、岩がむき出しで天井が低かったりしたので思った以上に装備が役に立ちました。 氷柱がある中、奥の方まで進むメンバー 洞窟といえば氷柱！と思っていたのですが、ちょうど数日前に雨が降った影響で、普段より足元や天井から氷柱がたくさん生えていたので触ってみたり、初めての経験ばかりでした。 氷が多い影響で滑りかけることもありましたが、ガイドさんと先行しているメンバーからの助言に助けられつつ進むことができました。 無事に生還しました！ 普段は一緒に仕事をしている仲間と会社ではなく洞窟という空間で一緒にいるという不思議な状況と、適度な運動のせいか気分は高揚し、普段は見られないような同僚の一面を見ることができた良い経験になったと思います。 2018 年の開発本部キックオフ！ アクティビティで適度に運動をした後はコテージに移り、少しずつお酒を飲んでくつろぎ始めたタイミングで、2018 年のキックオフとして CTO ・平山によるプレゼンを行いました。 昨年 2017 年は四つのプロダクトのうちジョブメドレー・ MEDLEY ・ CLINICS の大規模リニューアルがあり、大きな変化の年となりました。 また、今後どういった会社にしていきたいか？医療業界にどういった形で我々が貢献していくのか？そしてそのために事業として、またプロダクトとして 2018 年はどういった体制で推進していくのかといった事柄が共有されました。 なぜやるのか？どうやってやるのか？といった根本的な指針を背景を元に共有してもらうことで、今後の仕事における一つの軸ができたキックオフになったかと思います。 私自身一年間 CLINICS に関わってきたため、肌身で感じてきた変化や苦労を思い出しつつ、プロダクト・事業が着実に成長していることを感じることができ、次の指針を確認する良い機会となりました。 平山のプロダクト・事業・会社に対する熱い思いは メドレー平山の中央突破 にも書かれていますので、ぜひご覧ください。 バーベキュー&飲み キックオフ後はバーベキュー！そして飲み！ 火に強いメンバーは肉を焼いたり、料理が得意なメンバーは焼きそばやパスタを作っては食べて飲んで談笑し、思い思いに合宿を楽しんでいました。 まずは肉を焼く火に強いメンバー 談笑するメンバー（酔いが回りピントがボケ気味） 思い思いにくつろぐメンバー 余談ですが、上の画像で全員が着ている灰色のパーカーはキックオフ直前に配られたメドレーオフィシャルグッズの一つ、 デザイン部長・マエダ がデザインしたメドレーパーカーです。 実はメドレーではパーカー以外にもうちわや T シャツ、絆創膏などグッズが増えています。 気がついたら増えているので収集は大変ですが、今年はどういったグッズが作られるのか今から楽しみです。 メンバー同士で飲んで食べてくつろぎながら、プロダクトへの思いやプライベートの話などを語り合う宴会が夜遅くまで続きました。 まとめ いかがだったでしょうか？メドレー開発本部のキックオフ合宿の様子が少しでも伝われば幸いです。 アクティビティやバーベキューを通じてより親密に、プレゼンを通じて認識の共有ができた良い合宿になったと思います。 なお、今回の宿泊先は 大人数でも対応可能なコテージが用意され 、また Wi-Fi などの通信設備も整い、受付の方の対応も丁寧で、プライベートでも利用したくなる素敵な宿でした。 開発合宿等の大人数での宿を探している方にご参考になれば幸いです。 最後に 最後になりましたが、今回の合宿の企画運営をリードしてくれた新居さんありがとうございました！ 来年またキックオフ合宿したいですね！（CTO が撮影してくれたので、CTO 不在の集合写真） メドレーでは、チームで新しい医療体験を提供するプロダクトを一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の日下です。インターンを経て新卒としてメドレーに入り、現在は 1 年生エンジニアとして オンライン診療アプリ CLINICS の開発を担当しています。先日開発本部でキックオフ合宿を河口湖で行ってきましたので、詳細をレポートします。 年始のキックオフを合宿で行う意図 メドレーの開発本部では、チームビルディングを目的としてバーベキューなど全体でリフレッシュをする機会を年に数回設けています。 そのリフレッシュの一環として行っているメドレーの「年始のキックオフ合宿」は、昨年から行われています。昨年のレポートは こちら にあります。 メドレー開発本部全体のキックオフを合宿で行う意図は主に二つあります。 親睦を深める 一つ目の理由は親睦を深めることにあります。 リフレッシュを兼ねた 一体感の醸成、連携・親密感を深める場 を定期的に用意するようにしています。実際に合宿を終えて振り返ってみても、 合宿は日常より密な交流をする場として最高 だったなと思います。 方向性の共有 二つ目の理由は方向性の共有のためです。 昨年の合宿では、今後どういった方向を会社として、また各プロダクトとして目指して行くのかといった話を CTO ・平山から共有しました。普段の業務から離れた場所でこうした話に向き合えるという意味で、 共通の軸をより強く持つためには合宿が適切 だと実感し、今年も合宿を行うことになりました。 合宿先・アクティビティの選定 いわゆる開発合宿ではなかったため、選定には次の項目を重視しました。 二十数名を収容できるキャパシティがあること プライベートでも行きたい、思い出になるような場所であること アクティビティが近くにあること +α でバーベキューなどができること 上記の条件をすべて満たした場所を調査しましたが、「宿はあるがアクティビティがない」「アクティビティはあるが宿がない」のようになかなかマッチするところがなく苦労しました。 最終的にはこれら全てにマッチした先として、宿泊先を 河口湖カントリーコテージ さん に、アクティビティは カントリーレイクシステムズ さん にお世話になることにしました。 また、アクティビティに関しては、カヌー体験やほうとうづくりなど様々なものが用意されていましたが、次の観点から 洞窟探検 を選択しました。 普段座りっぱなしなので、運動が行えること 新しい刺激を受けられるように、非日常感が体験できること メンバーの普段見れない様子がでてきそうな、高揚感の高まる場所であること 非日常な体験ができる洞窟探検 当日、河口湖駅に集合した後はまずアクティビティに挑みました。 みんなで非日常を体験し、リフレッシュしてもらおうと選択したものでしたが、私も含め洞窟探検をした人はおらず、どういったものだろうとワクワクしながら富士の樹海を散策しました。 今回体験した洞窟は富士の青木ヶ原樹海にある 富士風穴 、初めて本格的な洞窟を見た我々は息を呑むような風景に圧倒されました。 先日の週刊メドレー で掲載された写真はまさに洞窟に入ろうとするメンバーでした。 思った以上に洞窟感のある洞窟が姿を表しおおーっとなりました。 天井に頭をぶつけたり、手をついて怪我をしたりする可能性がありましたが、ヘルメット・手袋・真っ赤なつなぎといったグッズがレンタルできたので、すべて装着して洞窟に挑みました。 洞窟の中は手すりや階段のない、自然そのままの洞窟らしく、岩がむき出しで天井が低かったりしたので思った以上に装備が役に立ちました。 氷柱がある中、奥の方まで進むメンバー 洞窟といえば氷柱！と思っていたのですが、ちょうど数日前に雨が降った影響で、普段より足元や天井から氷柱がたくさん生えていたので触ってみたり、初めての経験ばかりでした。 氷が多い影響で滑りかけることもありましたが、ガイドさんと先行しているメンバーからの助言に助けられつつ進むことができました。 無事に生還しました！ 普段は一緒に仕事をしている仲間と会社ではなく洞窟という空間で一緒にいるという不思議な状況と、適度な運動のせいか気分は高揚し、普段は見られないような同僚の一面を見ることができた良い経験になったと思います。 2018 年の開発本部キックオフ！ アクティビティで適度に運動をした後はコテージに移り、少しずつお酒を飲んでくつろぎ始めたタイミングで、2018 年のキックオフとして CTO ・平山によるプレゼンを行いました。 昨年 2017 年は四つのプロダクトのうちジョブメドレー・ MEDLEY ・ CLINICS の大規模リニューアルがあり、大きな変化の年となりました。 また、今後どういった会社にしていきたいか？医療業界にどういった形で我々が貢献していくのか？そしてそのために事業として、またプロダクトとして 2018 年はどういった体制で推進していくのかといった事柄が共有されました。 なぜやるのか？どうやってやるのか？といった根本的な指針を背景を元に共有してもらうことで、今後の仕事における一つの軸ができたキックオフになったかと思います。 私自身一年間 CLINICS に関わってきたため、肌身で感じてきた変化や苦労を思い出しつつ、プロダクト・事業が着実に成長していることを感じることができ、次の指針を確認する良い機会となりました。 平山のプロダクト・事業・会社に対する熱い思いは メドレー平山の中央突破 にも書かれていますので、ぜひご覧ください。 バーベキュー&飲み キックオフ後はバーベキュー！そして飲み！ 火に強いメンバーは肉を焼いたり、料理が得意なメンバーは焼きそばやパスタを作っては食べて飲んで談笑し、思い思いに合宿を楽しんでいました。 まずは肉を焼く火に強いメンバー 談笑するメンバー（酔いが回りピントがボケ気味） 思い思いにくつろぐメンバー 余談ですが、上の画像で全員が着ている灰色のパーカーはキックオフ直前に配られたメドレーオフィシャルグッズの一つ、 デザイン部長・マエダ がデザインしたメドレーパーカーです。 実はメドレーではパーカー以外にもうちわや T シャツ、絆創膏などグッズが増えています。 気がついたら増えているので収集は大変ですが、今年はどういったグッズが作られるのか今から楽しみです。 メンバー同士で飲んで食べてくつろぎながら、プロダクトへの思いやプライベートの話などを語り合う宴会が夜遅くまで続きました。 まとめ いかがだったでしょうか？メドレー開発本部のキックオフ合宿の様子が少しでも伝われば幸いです。 アクティビティやバーベキューを通じてより親密に、プレゼンを通じて認識の共有ができた良い合宿になったと思います。 なお、今回の宿泊先は 大人数でも対応可能なコテージが用意され 、また Wi-Fi などの通信設備も整い、受付の方の対応も丁寧で、プライベートでも利用したくなる素敵な宿でした。 開発合宿等の大人数での宿を探している方にご参考になれば幸いです。 最後に 最後になりましたが、今回の合宿の企画運営をリードしてくれた新居さんありがとうございました！ 来年またキックオフ合宿したいですね！（CTO が撮影してくれたので、CTO 不在の集合写真） メドレーでは、チームで新しい医療体験を提供するプロダクトを一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp