こんにちは。開発本部の医療メディアチームでデザインをしている波切です。 メドレー開発本部で行われている勉強会「TechLunch」で、デザイナー以外の方も知っておいて損はない「ブランドとは？」というお話をさせていただきました。多くの方が何となく知っていることも多いかもしれませんが、再入門的に参考にしていただけると嬉しいです。 背景 メドレーでは時期を問わずプロダクトの在り方について常日頃から様々な場面で議論がなされています。 こういった議論の中でブランドとしてどのように見せられるのが良いだろうか、といった検討をすることも多々あり、改めてブランドについて学び直したいと思ったのが今回のきっかけになります。 TechLunch ではエンジニア・デザイナー・ディレクター・医師（！）と様々な職種の人が参加しています。 この時代では当たり前かもしれないブランドの基礎を改めて学び直し、デザイナー以外の職種の方にも共有しましたので、ブログでもご紹介させていただければと思います。 ブランドってなんでしょう ブランドとブランディングの違いって？ まずは混合しやすいブランドとブランディングの定義から。 ある特定の商品やサービスが消費者・顧客によって識別されているとき、 その商品やサービスを「ブランド」と呼ぶ ※製品名、パッケージング、広告、価格、使用経験などにより、その製品につけられた製品特性と価値（機能的および非機能的）とのユニークなコンビネーション。消費者・顧客の目から見た場合、その製品を競合から差別化するもの。 (via ブランド・マネージャー認定協会 用語集 ) ブランディングとは、ブランドに対する共感や信頼などを通じて顧客にとっての価値を高めていく、企業と組織のマーケティング戦略の 1 つ。ブランドとして認知されていないものをブランドに育て上げる、あるいはブランド構成要素を強化し、活性・維持管理していくこと。また、その手法。ここでいうブランドとは高級消費財に限らず、その対象としては、商品やサービス、それらを供給する企業や団体のほか、人物・建築物・史跡・地域 ・祭事など、あらゆるものが該当する。 (via wikipedia:ブランディング ) ブランド とは「企業・製品に対して消費者が持っているイメージ(記号)であり、競合との差別化を生み出す価値の総体」を指し、 ブランディング は「ブランド価値を与えるための手段」と捉えることができると思います。 この定義になぞらえてコカ・コーラを例にブランドとして認知される具体的なステップとして紹介すると、以下のようになります。 ロゴなどの識別記号が記憶される コカ･コーラのロゴが記憶される (生活者の頭の中に、ロゴなどの識別記号が記憶される) 記号から体験が思い浮かぶ コカ･コーラのロゴを見れば炭酸飲料であることや、爽やかな気分になれることが思い浮ぶ (識別記号を見れば、知覚体験を想起できる) 体験から記号を思い出す 爽やかな気分になりたいと思ったら、コカ･コーラを思い出す。ロゴが思い浮かぶ (知覚価値が頭に浮かんだら、識別記号が想起される)  「ブランド連想」「ブランド資産」といった言葉もあり、ブランド（識別記号と知覚体験）に対してポジティブな印象を築き蓄積させることがブランディングのカギになってきます。 ブランド構築 前述の記号をブランドの土台とするとコーポレートアイデンティティ（CI）やヴィジュアルアイデンティティ（VI）といったクリエイティブが大きな役割を果たしますが、現在ではユーザーはブランドを知覚する機会が多く、差別化のためにもブランドは顧客体験をベースに作っていくことも重要になります。 ｢良い顧客体験を提供しブランドの競争力を高める｣ という考え方に基づいて、ブランド戦略を考える順番は理想的な体験を描いてから必要なモノや技術を考えます。これはブランドに限らず様々な場面で意識したいことです。 ブランドに大事な一貫性 魅力的なブランドは顧客体験が蓄積して形成されていきます。蓄積されるブランド体験の要素は「体験の魅力度」「体験の量と時間」「体験の一貫性」と 3 つあり、ブランドの価値はこの 3 つの要素のかけ算にあります。 体験が魅力的であり、その体験の回数が多く長い時間にわたって経験し、体験自体に一貫性があるブランドがユーザーとって良いものとされます。 3 つのうち特に重要なものは最後の ｢体験の一貫性｣ にあり、この一貫性は 2 つに分けることができます。 時系列で一貫性 ：時代で左右されない顧客体験がブランドから提供される 接点の一貫性 ：ブランドを買ったり利用する前から、購入プロセス、購入後の利用シーンにおいて、一貫した顧客体験ができる 「モノとコト」にも例えやすいところですが、製品としての一貫性に加えて体験する前後のグランドデザインにも一貫性を持たすことが重要になります。 例としてスターバックスは広告費をほとんどかけずに今のブランド認知度を築いたことは有名ですが、そこにはブランドの価値を築くためのブランディングに一貫性があり、かつそれらが時代性とマッチしたのが要因ではないかと思います。 ブランディングのメリット 選択意思決定の単純化・固定化 顧客の知識が整理されることで競合と差別化され再び同じ物を選ぶようになる ユーザーのロイヤル化 親しみや信頼が増大されることでブランドロイヤリティが形成される なぜブランドにこだわるのか、という点でもこれらメリットを実現していくことが重要です。 デザイナーとして気遣い溢れる UI や、サービスの思想を記号に落とし込んだ VI などモノづくり視点でのこだわりや重要さを踏まえた上で、他職種の方にもこれらのメリットや競争としての必要であることを理解してもらえるよう働きかけることを意識していきたいところです。 ブランディングの悩みどころ ここからは基礎を踏まえて、実践的に行われているブランディングで悩みやすいところを事例で紹介しながら簡単なディスカッションをしていきました。一部だけ抜粋してご紹介します。 製品ブランドの管理 会社のブランド管理の思想を定義できても、変化の早い業界であればイメージ通りになかなか通らないことも多々有りえます。 少ないブランド資産を活用する意味でもスタートアップは横串型に整理されることが多くありますが、ある程度の規模感になって基礎体力がある企業であると個別適応型でもブランドとして信頼性を保てますし、横串型に比べて動きやすさがあると思います。 一方で、プラットフォーマーとして存在したいなら横串のブランド価値からファンを囲い込むべきかもしれません。Techlunch の中でもメドレーであればどうあると良いかについて議論ができました。 ブランディングのタイミング 顧客体験の蓄積が重要なブランドでありますが、どの段階でブランディングに取り組むかは状況によりますが意見が出やすいところだと思います。 ICC FUKUOKA2017 にてブランディングについてのセッションがあり、取り組むタイミングについての議論がうまくまとめられていたため Techlunch で事例として共有しました。プロダクトとしての差別化が基本であることに加えて、ブランドの在り方を組織にインストールさせるためにブランディングに取り組むケースも紹介されています。 僕はブランドが常に必要かと言うと“No”だと思います。 コモディティ化し始めたり、競争が始まって差別化しなくてはならない時に、プロダクトの機能などで差別化ができない、または必ずしもパフォーマンスで差別化ができない時に唯一残された選択が、ブランドを作るということであると思います。 [株式会社 Bloom&Co. 彌野泰弘] ユーザーを獲りにいくというフェーズですよね。 メルカリの場合、やはり最初の 100 万ダウンロードくらいまでは、結構チューニングをしながらオンラインのマーケティングで（ユーザーを）獲得してきてきました。 中略 やはり 100 万ダウンロードくらいあって、リテンションレートが高くユーザーが積み上がる状態になっていれば、大きくマスマーケティング（TVCM）をやっても獲得したユーザーは残りますからね。 [株式会社メルカリ 小泉文明] 僕は、ユーザーを獲得する手前でブランドが必要だと思っているんですよね。 ブランドというのは必ずしも外に対してだけではなくて、（組織の）中の人に対して必要であることもすごく多いのです。 中略 資生堂は当時 130 年くらい経っている会社だったので、その 130 年もこの後の 130 年も、世の中を美しくするとか、人を美しくするとか、それは女性に限らず、お化粧に限らず美しくするということが必要だよね、軸だよねという話になって、そのスローガンと共に前田新社長体制で進んでいくことになりました。 [株式会社 dof 齋藤太郎] (via スタートアップのブランディングはいつから必要か？【F17-7C #3】 ) 共有した後には、リリース当初からブランドやクリエイティブが作り込まれたプロダクトが最近話題になることが多いということも話に上がりました。 もちろんブランディングのタイミングは状況により千差万別ですが、プロダクトをゼロから作る際には、プロダクトの在り方と合わせてどんなブランドを作って行きたいのかも早めに考えられることが必要だ、など具体的なディスカッションも出来ました。 新たなブランドが受け入れられないことも 基本的にブランドを新しくすることは見慣れたものが変わってしまう恐怖から反発を生むケースが多いですが、その中でも GAP はロゴの 2010 年リニューアル公表後ネット上からの反発が強くわずか 6 日間という短期間で新しいロゴの使用を止め、元のロゴに戻してしまうという一件がありました。（この件は 株価 にも大きな影響を与えました） 一方、同じような境遇で Airbnb も 2014 年のリニューアル当初ロゴは不評でしたが今ではリニューアルの成功例として扱われる存在になっています。 Techlunch でも歴史の有無が差になったのか、など様々な意見が出てきました。この件はロゴとしての王道を極めようとした以上の背景を提示出来なかった Gap に対して、 Airbnb はサービスのストーリーをロゴに内包 し、地道にロゴを介したコミュニケーションに徹したことが明暗を分けたように思います。 この事例はロゴのアイデンティティをどこまで確立させられたかの違いにあることに加えて、デザインの意思決定を一時的な多数意見に委ねた事例としても学ぶことが多いです。 まとめ 私個人が元々グラフィックデザインをしていた経験もあり、今まではブランディングの中でも興味が CI や VI に傾倒していましたが、体験全体がブランドに大きな影響を与えるこの時代、組織としてブランド構築をしていく意識が重要であることが今回の大きな学びでした。 また基礎を学ぶ上で書籍を読んでいましたが、最近の事例などを学ぶ際にはブログなどでの情報収集がとても有効で、学び方も変わってきているなと思いました。今回紹介した内容はあくまで入門編なので、興味があれば今回参考にさせていただいた本とブログ・記事からより深堀りが出来るのでオススメします。 プラットフォームブランディング コーポレート・アイデンティティ戦略―デザインが企業経営を変える ブランド・エクイティ研究の展望 ～価値をめぐる議論の系譜を中心に～ UX とブランド ブランドアイデンティティとは｜ブランド構築を成果に導く BI の創り方｜成功事例有 スタートアップのブランディングはいつから必要か？ ロゴのリデザインーなぜ Gap が失敗し Airbnb が受け入れられたのか 武器になる「ロゴ」を生み出す、CI デザインとは何か？ Techlunch ではデザイナー以外の方からも事例に対して意見が出たり、疑問に対して参加者でディスカッションが出来たことがとても有意義でした。今後はこれらを意識しながらブランドの土台となる価値や在り方をデザイン出来るようにしていきたいと思います。 お知らせ  メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 興味のある方、ぜひメドレーへ遊びにいらしてください。 www.medley.jp

こんにちは。開発本部の医療メディアチームでデザインをしている波切です。 メドレー開発本部で行われている勉強会「TechLunch」で、デザイナー以外の方も知っておいて損はない「ブランドとは？」というお話をさせていただきました。多くの方が何となく知っていることも多いかもしれませんが、再入門的に参考にしていただけると嬉しいです。 背景 メドレーでは時期を問わずプロダクトの在り方について常日頃から様々な場面で議論がなされています。 こういった議論の中でブランドとしてどのように見せられるのが良いだろうか、といった検討をすることも多々あり、改めてブランドについて学び直したいと思ったのが今回のきっかけになります。 TechLunch ではエンジニア・デザイナー・ディレクター・医師（！）と様々な職種の人が参加しています。 この時代では当たり前かもしれないブランドの基礎を改めて学び直し、デザイナー以外の職種の方にも共有しましたので、ブログでもご紹介させていただければと思います。 ブランドってなんでしょう ブランドとブランディングの違いって？ まずは混合しやすいブランドとブランディングの定義から。 ある特定の商品やサービスが消費者・顧客によって識別されているとき、 その商品やサービスを「ブランド」と呼ぶ ※製品名、パッケージング、広告、価格、使用経験などにより、その製品につけられた製品特性と価値（機能的および非機能的）とのユニークなコンビネーション。消費者・顧客の目から見た場合、その製品を競合から差別化するもの。 (via ブランド・マネージャー認定協会 用語集 ) ブランディングとは、ブランドに対する共感や信頼などを通じて顧客にとっての価値を高めていく、企業と組織のマーケティング戦略の 1 つ。ブランドとして認知されていないものをブランドに育て上げる、あるいはブランド構成要素を強化し、活性・維持管理していくこと。また、その手法。ここでいうブランドとは高級消費財に限らず、その対象としては、商品やサービス、それらを供給する企業や団体のほか、人物・建築物・史跡・地域 ・祭事など、あらゆるものが該当する。 (via wikipedia:ブランディング ) ブランド とは「企業・製品に対して消費者が持っているイメージ(記号)であり、競合との差別化を生み出す価値の総体」を指し、 ブランディング は「ブランド価値を与えるための手段」と捉えることができると思います。 この定義になぞらえてコカ・コーラを例にブランドとして認知される具体的なステップとして紹介すると、以下のようになります。 ロゴなどの識別記号が記憶される コカ･コーラのロゴが記憶される (生活者の頭の中に、ロゴなどの識別記号が記憶される) 記号から体験が思い浮かぶ コカ･コーラのロゴを見れば炭酸飲料であることや、爽やかな気分になれることが思い浮ぶ (識別記号を見れば、知覚体験を想起できる) 体験から記号を思い出す 爽やかな気分になりたいと思ったら、コカ･コーラを思い出す。ロゴが思い浮かぶ (知覚価値が頭に浮かんだら、識別記号が想起される)  「ブランド連想」「ブランド資産」といった言葉もあり、ブランド（識別記号と知覚体験）に対してポジティブな印象を築き蓄積させることがブランディングのカギになってきます。 ブランド構築 前述の記号をブランドの土台とするとコーポレートアイデンティティ（CI）やヴィジュアルアイデンティティ（VI）といったクリエイティブが大きな役割を果たしますが、現在ではユーザーはブランドを知覚する機会が多く、差別化のためにもブランドは顧客体験をベースに作っていくことも重要になります。 ｢良い顧客体験を提供しブランドの競争力を高める｣ という考え方に基づいて、ブランド戦略を考える順番は理想的な体験を描いてから必要なモノや技術を考えます。これはブランドに限らず様々な場面で意識したいことです。 ブランドに大事な一貫性 魅力的なブランドは顧客体験が蓄積して形成されていきます。蓄積されるブランド体験の要素は「体験の魅力度」「体験の量と時間」「体験の一貫性」と 3 つあり、ブランドの価値はこの 3 つの要素のかけ算にあります。 体験が魅力的であり、その体験の回数が多く長い時間にわたって経験し、体験自体に一貫性があるブランドがユーザーとって良いものとされます。 3 つのうち特に重要なものは最後の ｢体験の一貫性｣ にあり、この一貫性は 2 つに分けることができます。 時系列で一貫性 ：時代で左右されない顧客体験がブランドから提供される 接点の一貫性 ：ブランドを買ったり利用する前から、購入プロセス、購入後の利用シーンにおいて、一貫した顧客体験ができる 「モノとコト」にも例えやすいところですが、製品としての一貫性に加えて体験する前後のグランドデザインにも一貫性を持たすことが重要になります。 例としてスターバックスは広告費をほとんどかけずに今のブランド認知度を築いたことは有名ですが、そこにはブランドの価値を築くためのブランディングに一貫性があり、かつそれらが時代性とマッチしたのが要因ではないかと思います。 ブランディングのメリット 選択意思決定の単純化・固定化 顧客の知識が整理されることで競合と差別化され再び同じ物を選ぶようになる ユーザーのロイヤル化 親しみや信頼が増大されることでブランドロイヤリティが形成される なぜブランドにこだわるのか、という点でもこれらメリットを実現していくことが重要です。 デザイナーとして気遣い溢れる UI や、サービスの思想を記号に落とし込んだ VI などモノづくり視点でのこだわりや重要さを踏まえた上で、他職種の方にもこれらのメリットや競争としての必要であることを理解してもらえるよう働きかけることを意識していきたいところです。 ブランディングの悩みどころ ここからは基礎を踏まえて、実践的に行われているブランディングで悩みやすいところを事例で紹介しながら簡単なディスカッションをしていきました。一部だけ抜粋してご紹介します。 製品ブランドの管理 会社のブランド管理の思想を定義できても、変化の早い業界であればイメージ通りになかなか通らないことも多々有りえます。 少ないブランド資産を活用する意味でもスタートアップは横串型に整理されることが多くありますが、ある程度の規模感になって基礎体力がある企業であると個別適応型でもブランドとして信頼性を保てますし、横串型に比べて動きやすさがあると思います。 一方で、プラットフォーマーとして存在したいなら横串のブランド価値からファンを囲い込むべきかもしれません。Techlunch の中でもメドレーであればどうあると良いかについて議論ができました。 ブランディングのタイミング 顧客体験の蓄積が重要なブランドでありますが、どの段階でブランディングに取り組むかは状況によりますが意見が出やすいところだと思います。 ICC FUKUOKA2017 にてブランディングについてのセッションがあり、取り組むタイミングについての議論がうまくまとめられていたため Techlunch で事例として共有しました。プロダクトとしての差別化が基本であることに加えて、ブランドの在り方を組織にインストールさせるためにブランディングに取り組むケースも紹介されています。 僕はブランドが常に必要かと言うと“No”だと思います。 コモディティ化し始めたり、競争が始まって差別化しなくてはならない時に、プロダクトの機能などで差別化ができない、または必ずしもパフォーマンスで差別化ができない時に唯一残された選択が、ブランドを作るということであると思います。 [株式会社 Bloom&Co. 彌野泰弘] ユーザーを獲りにいくというフェーズですよね。 メルカリの場合、やはり最初の 100 万ダウンロードくらいまでは、結構チューニングをしながらオンラインのマーケティングで（ユーザーを）獲得してきてきました。 中略 やはり 100 万ダウンロードくらいあって、リテンションレートが高くユーザーが積み上がる状態になっていれば、大きくマスマーケティング（TVCM）をやっても獲得したユーザーは残りますからね。 [株式会社メルカリ 小泉文明] 僕は、ユーザーを獲得する手前でブランドが必要だと思っているんですよね。 ブランドというのは必ずしも外に対してだけではなくて、（組織の）中の人に対して必要であることもすごく多いのです。 中略 資生堂は当時 130 年くらい経っている会社だったので、その 130 年もこの後の 130 年も、世の中を美しくするとか、人を美しくするとか、それは女性に限らず、お化粧に限らず美しくするということが必要だよね、軸だよねという話になって、そのスローガンと共に前田新社長体制で進んでいくことになりました。 [株式会社 dof 齋藤太郎] (via スタートアップのブランディングはいつから必要か？【F17-7C #3】 ) 共有した後には、リリース当初からブランドやクリエイティブが作り込まれたプロダクトが最近話題になることが多いということも話に上がりました。 もちろんブランディングのタイミングは状況により千差万別ですが、プロダクトをゼロから作る際には、プロダクトの在り方と合わせてどんなブランドを作って行きたいのかも早めに考えられることが必要だ、など具体的なディスカッションも出来ました。 新たなブランドが受け入れられないことも 基本的にブランドを新しくすることは見慣れたものが変わってしまう恐怖から反発を生むケースが多いですが、その中でも GAP はロゴの 2010 年リニューアル公表後ネット上からの反発が強くわずか 6 日間という短期間で新しいロゴの使用を止め、元のロゴに戻してしまうという一件がありました。（この件は 株価 にも大きな影響を与えました） 一方、同じような境遇で Airbnb も 2014 年のリニューアル当初ロゴは不評でしたが今ではリニューアルの成功例として扱われる存在になっています。 Techlunch でも歴史の有無が差になったのか、など様々な意見が出てきました。この件はロゴとしての王道を極めようとした以上の背景を提示出来なかった Gap に対して、 Airbnb はサービスのストーリーをロゴに内包 し、地道にロゴを介したコミュニケーションに徹したことが明暗を分けたように思います。 この事例はロゴのアイデンティティをどこまで確立させられたかの違いにあることに加えて、デザインの意思決定を一時的な多数意見に委ねた事例としても学ぶことが多いです。 まとめ 私個人が元々グラフィックデザインをしていた経験もあり、今まではブランディングの中でも興味が CI や VI に傾倒していましたが、体験全体がブランドに大きな影響を与えるこの時代、組織としてブランド構築をしていく意識が重要であることが今回の大きな学びでした。 また基礎を学ぶ上で書籍を読んでいましたが、最近の事例などを学ぶ際にはブログなどでの情報収集がとても有効で、学び方も変わってきているなと思いました。今回紹介した内容はあくまで入門編なので、興味があれば今回参考にさせていただいた本とブログ・記事からより深堀りが出来るのでオススメします。 プラットフォームブランディング コーポレート・アイデンティティ戦略―デザインが企業経営を変える ブランド・エクイティ研究の展望 ～価値をめぐる議論の系譜を中心に～ UX とブランド ブランドアイデンティティとは｜ブランド構築を成果に導く BI の創り方｜成功事例有 スタートアップのブランディングはいつから必要か？ ロゴのリデザインーなぜ Gap が失敗し Airbnb が受け入れられたのか 武器になる「ロゴ」を生み出す、CI デザインとは何か？ Techlunch ではデザイナー以外の方からも事例に対して意見が出たり、疑問に対して参加者でディスカッションが出来たことがとても有意義でした。今後はこれらを意識しながらブランドの土台となる価値や在り方をデザイン出来るようにしていきたいと思います。 お知らせ  メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 興味のある方、ぜひメドレーへ遊びにいらしてください。 www.medley.jp

こんにちは。開発本部の医療メディアチームでデザインをしている波切です。 メドレー開発本部で行われている勉強会「TechLunch」で、デザイナー以外の方も知っておいて損はない「ブランドとは？」というお話をさせていただきました。多くの方が何となく知っていることも多いかもしれませんが、再入門的に参考にしていただけると嬉しいです。 背景 メドレーでは時期を問わずプロダクトの在り方について常日頃から様々な場面で議論がなされています。 こういった議論の中でブランドとしてどのように見せられるのが良いだろうか、といった検討をすることも多々あり、改めてブランドについて学び直したいと思ったのが今回のきっかけになります。 TechLunch ではエンジニア・デザイナー・ディレクター・医師（！）と様々な職種の人が参加しています。 この時代では当たり前かもしれないブランドの基礎を改めて学び直し、デザイナー以外の職種の方にも共有しましたので、ブログでもご紹介させていただければと思います。 ブランドってなんでしょう ブランドとブランディングの違いって？ まずは混合しやすいブランドとブランディングの定義から。 ある特定の商品やサービスが消費者・顧客によって識別されているとき、 その商品やサービスを「ブランド」と呼ぶ ※製品名、パッケージング、広告、価格、使用経験などにより、その製品につけられた製品特性と価値（機能的および非機能的）とのユニークなコンビネーション。消費者・顧客の目から見た場合、その製品を競合から差別化するもの。 (via ブランド・マネージャー認定協会 用語集 ) ブランディングとは、ブランドに対する共感や信頼などを通じて顧客にとっての価値を高めていく、企業と組織のマーケティング戦略の 1 つ。ブランドとして認知されていないものをブランドに育て上げる、あるいはブランド構成要素を強化し、活性・維持管理していくこと。また、その手法。ここでいうブランドとは高級消費財に限らず、その対象としては、商品やサービス、それらを供給する企業や団体のほか、人物・建築物・史跡・地域 ・祭事など、あらゆるものが該当する。 (via wikipedia:ブランディング ) ブランド とは「企業・製品に対して消費者が持っているイメージ(記号)であり、競合との差別化を生み出す価値の総体」を指し、 ブランディング は「ブランド価値を与えるための手段」と捉えることができると思います。 この定義になぞらえてコカ・コーラを例にブランドとして認知される具体的なステップとして紹介すると、以下のようになります。 ロゴなどの識別記号が記憶される コカ･コーラのロゴが記憶される (生活者の頭の中に、ロゴなどの識別記号が記憶される) 記号から体験が思い浮かぶ コカ･コーラのロゴを見れば炭酸飲料であることや、爽やかな気分になれることが思い浮ぶ (識別記号を見れば、知覚体験を想起できる) 体験から記号を思い出す 爽やかな気分になりたいと思ったら、コカ･コーラを思い出す。ロゴが思い浮かぶ (知覚価値が頭に浮かんだら、識別記号が想起される)  「ブランド連想」「ブランド資産」といった言葉もあり、ブランド（識別記号と知覚体験）に対してポジティブな印象を築き蓄積させることがブランディングのカギになってきます。 ブランド構築 前述の記号をブランドの土台とするとコーポレートアイデンティティ（CI）やヴィジュアルアイデンティティ（VI）といったクリエイティブが大きな役割を果たしますが、現在ではユーザーはブランドを知覚する機会が多く、差別化のためにもブランドは顧客体験をベースに作っていくことも重要になります。 ｢良い顧客体験を提供しブランドの競争力を高める｣ という考え方に基づいて、ブランド戦略を考える順番は理想的な体験を描いてから必要なモノや技術を考えます。これはブランドに限らず様々な場面で意識したいことです。 ブランドに大事な一貫性 魅力的なブランドは顧客体験が蓄積して形成されていきます。蓄積されるブランド体験の要素は「体験の魅力度」「体験の量と時間」「体験の一貫性」と 3 つあり、ブランドの価値はこの 3 つの要素のかけ算にあります。 体験が魅力的であり、その体験の回数が多く長い時間にわたって経験し、体験自体に一貫性があるブランドがユーザーとって良いものとされます。 3 つのうち特に重要なものは最後の ｢体験の一貫性｣ にあり、この一貫性は 2 つに分けることができます。 時系列で一貫性 ：時代で左右されない顧客体験がブランドから提供される 接点の一貫性 ：ブランドを買ったり利用する前から、購入プロセス、購入後の利用シーンにおいて、一貫した顧客体験ができる 「モノとコト」にも例えやすいところですが、製品としての一貫性に加えて体験する前後のグランドデザインにも一貫性を持たすことが重要になります。 例としてスターバックスは広告費をほとんどかけずに今のブランド認知度を築いたことは有名ですが、そこにはブランドの価値を築くためのブランディングに一貫性があり、かつそれらが時代性とマッチしたのが要因ではないかと思います。 ブランディングのメリット 選択意思決定の単純化・固定化 顧客の知識が整理されることで競合と差別化され再び同じ物を選ぶようになる ユーザーのロイヤル化 親しみや信頼が増大されることでブランドロイヤリティが形成される なぜブランドにこだわるのか、という点でもこれらメリットを実現していくことが重要です。 デザイナーとして気遣い溢れる UI や、サービスの思想を記号に落とし込んだ VI などモノづくり視点でのこだわりや重要さを踏まえた上で、他職種の方にもこれらのメリットや競争としての必要であることを理解してもらえるよう働きかけることを意識していきたいところです。 ブランディングの悩みどころ ここからは基礎を踏まえて、実践的に行われているブランディングで悩みやすいところを事例で紹介しながら簡単なディスカッションをしていきました。一部だけ抜粋してご紹介します。 製品ブランドの管理 会社のブランド管理の思想を定義できても、変化の早い業界であればイメージ通りになかなか通らないことも多々有りえます。 少ないブランド資産を活用する意味でもスタートアップは横串型に整理されることが多くありますが、ある程度の規模感になって基礎体力がある企業であると個別適応型でもブランドとして信頼性を保てますし、横串型に比べて動きやすさがあると思います。 一方で、プラットフォーマーとして存在したいなら横串のブランド価値からファンを囲い込むべきかもしれません。Techlunch の中でもメドレーであればどうあると良いかについて議論ができました。 ブランディングのタイミング 顧客体験の蓄積が重要なブランドでありますが、どの段階でブランディングに取り組むかは状況によりますが意見が出やすいところだと思います。 ICC FUKUOKA2017 にてブランディングについてのセッションがあり、取り組むタイミングについての議論がうまくまとめられていたため Techlunch で事例として共有しました。プロダクトとしての差別化が基本であることに加えて、ブランドの在り方を組織にインストールさせるためにブランディングに取り組むケースも紹介されています。 僕はブランドが常に必要かと言うと“No”だと思います。 コモディティ化し始めたり、競争が始まって差別化しなくてはならない時に、プロダクトの機能などで差別化ができない、または必ずしもパフォーマンスで差別化ができない時に唯一残された選択が、ブランドを作るということであると思います。 [株式会社 Bloom&Co. 彌野泰弘] ユーザーを獲りにいくというフェーズですよね。 メルカリの場合、やはり最初の 100 万ダウンロードくらいまでは、結構チューニングをしながらオンラインのマーケティングで（ユーザーを）獲得してきてきました。 中略 やはり 100 万ダウンロードくらいあって、リテンションレートが高くユーザーが積み上がる状態になっていれば、大きくマスマーケティング（TVCM）をやっても獲得したユーザーは残りますからね。 [株式会社メルカリ 小泉文明] 僕は、ユーザーを獲得する手前でブランドが必要だと思っているんですよね。 ブランドというのは必ずしも外に対してだけではなくて、（組織の）中の人に対して必要であることもすごく多いのです。 中略 資生堂は当時 130 年くらい経っている会社だったので、その 130 年もこの後の 130 年も、世の中を美しくするとか、人を美しくするとか、それは女性に限らず、お化粧に限らず美しくするということが必要だよね、軸だよねという話になって、そのスローガンと共に前田新社長体制で進んでいくことになりました。 [株式会社 dof 齋藤太郎] (via スタートアップのブランディングはいつから必要か？【F17-7C #3】 ) 共有した後には、リリース当初からブランドやクリエイティブが作り込まれたプロダクトが最近話題になることが多いということも話に上がりました。 もちろんブランディングのタイミングは状況により千差万別ですが、プロダクトをゼロから作る際には、プロダクトの在り方と合わせてどんなブランドを作って行きたいのかも早めに考えられることが必要だ、など具体的なディスカッションも出来ました。 新たなブランドが受け入れられないことも 基本的にブランドを新しくすることは見慣れたものが変わってしまう恐怖から反発を生むケースが多いですが、その中でも GAP はロゴの 2010 年リニューアル公表後ネット上からの反発が強くわずか 6 日間という短期間で新しいロゴの使用を止め、元のロゴに戻してしまうという一件がありました。（この件は 株価 にも大きな影響を与えました） 一方、同じような境遇で Airbnb も 2014 年のリニューアル当初ロゴは不評でしたが今ではリニューアルの成功例として扱われる存在になっています。 Techlunch でも歴史の有無が差になったのか、など様々な意見が出てきました。この件はロゴとしての王道を極めようとした以上の背景を提示出来なかった Gap に対して、 Airbnb はサービスのストーリーをロゴに内包 し、地道にロゴを介したコミュニケーションに徹したことが明暗を分けたように思います。 この事例はロゴのアイデンティティをどこまで確立させられたかの違いにあることに加えて、デザインの意思決定を一時的な多数意見に委ねた事例としても学ぶことが多いです。 まとめ 私個人が元々グラフィックデザインをしていた経験もあり、今まではブランディングの中でも興味が CI や VI に傾倒していましたが、体験全体がブランドに大きな影響を与えるこの時代、組織としてブランド構築をしていく意識が重要であることが今回の大きな学びでした。 また基礎を学ぶ上で書籍を読んでいましたが、最近の事例などを学ぶ際にはブログなどでの情報収集がとても有効で、学び方も変わってきているなと思いました。今回紹介した内容はあくまで入門編なので、興味があれば今回参考にさせていただいた本とブログ・記事からより深堀りが出来るのでオススメします。 プラットフォームブランディング コーポレート・アイデンティティ戦略―デザインが企業経営を変える ブランド・エクイティ研究の展望 ～価値をめぐる議論の系譜を中心に～ UX とブランド ブランドアイデンティティとは｜ブランド構築を成果に導く BI の創り方｜成功事例有 スタートアップのブランディングはいつから必要か？ ロゴのリデザインーなぜ Gap が失敗し Airbnb が受け入れられたのか 武器になる「ロゴ」を生み出す、CI デザインとは何か？ Techlunch ではデザイナー以外の方からも事例に対して意見が出たり、疑問に対して参加者でディスカッションが出来たことがとても有意義でした。今後はこれらを意識しながらブランドの土台となる価値や在り方をデザイン出来るようにしていきたいと思います。 お知らせ  メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 興味のある方、ぜひメドレーへ遊びにいらしてください。 www.medley.jp

こんにちは。開発本部の医療メディアチームでデザインをしている波切です。 メドレー開発本部で行われている勉強会「TechLunch」で、デザイナー以外の方も知っておいて損はない「ブランドとは？」というお話をさせていただきました。多くの方が何となく知っていることも多いかもしれませんが、再入門的に参考にしていただけると嬉しいです。 背景 メドレーでは時期を問わずプロダクトの在り方について常日頃から様々な場面で議論がなされています。 こういった議論の中でブランドとしてどのように見せられるのが良いだろうか、といった検討をすることも多々あり、改めてブランドについて学び直したいと思ったのが今回のきっかけになります。 TechLunch ではエンジニア・デザイナー・ディレクター・医師（！）と様々な職種の人が参加しています。 この時代では当たり前かもしれないブランドの基礎を改めて学び直し、デザイナー以外の職種の方にも共有しましたので、ブログでもご紹介させていただければと思います。 ブランドってなんでしょう ブランドとブランディングの違いって？ まずは混合しやすいブランドとブランディングの定義から。 ある特定の商品やサービスが消費者・顧客によって識別されているとき、 その商品やサービスを「ブランド」と呼ぶ ※製品名、パッケージング、広告、価格、使用経験などにより、その製品につけられた製品特性と価値（機能的および非機能的）とのユニークなコンビネーション。消費者・顧客の目から見た場合、その製品を競合から差別化するもの。 (via ブランド・マネージャー認定協会 用語集 ) ブランディングとは、ブランドに対する共感や信頼などを通じて顧客にとっての価値を高めていく、企業と組織のマーケティング戦略の 1 つ。ブランドとして認知されていないものをブランドに育て上げる、あるいはブランド構成要素を強化し、活性・維持管理していくこと。また、その手法。ここでいうブランドとは高級消費財に限らず、その対象としては、商品やサービス、それらを供給する企業や団体のほか、人物・建築物・史跡・地域 ・祭事など、あらゆるものが該当する。 (via wikipedia:ブランディング ) ブランド とは「企業・製品に対して消費者が持っているイメージ(記号)であり、競合との差別化を生み出す価値の総体」を指し、 ブランディング は「ブランド価値を与えるための手段」と捉えることができると思います。 この定義になぞらえてコカ・コーラを例にブランドとして認知される具体的なステップとして紹介すると、以下のようになります。 ロゴなどの識別記号が記憶される コカ･コーラのロゴが記憶される (生活者の頭の中に、ロゴなどの識別記号が記憶される) 記号から体験が思い浮かぶ コカ･コーラのロゴを見れば炭酸飲料であることや、爽やかな気分になれることが思い浮ぶ (識別記号を見れば、知覚体験を想起できる) 体験から記号を思い出す 爽やかな気分になりたいと思ったら、コカ･コーラを思い出す。ロゴが思い浮かぶ (知覚価値が頭に浮かんだら、識別記号が想起される)  「ブランド連想」「ブランド資産」といった言葉もあり、ブランド（識別記号と知覚体験）に対してポジティブな印象を築き蓄積させることがブランディングのカギになってきます。 ブランド構築 前述の記号をブランドの土台とするとコーポレートアイデンティティ（CI）やヴィジュアルアイデンティティ（VI）といったクリエイティブが大きな役割を果たしますが、現在ではユーザーはブランドを知覚する機会が多く、差別化のためにもブランドは顧客体験をベースに作っていくことも重要になります。 ｢良い顧客体験を提供しブランドの競争力を高める｣ という考え方に基づいて、ブランド戦略を考える順番は理想的な体験を描いてから必要なモノや技術を考えます。これはブランドに限らず様々な場面で意識したいことです。 ブランドに大事な一貫性 魅力的なブランドは顧客体験が蓄積して形成されていきます。蓄積されるブランド体験の要素は「体験の魅力度」「体験の量と時間」「体験の一貫性」と 3 つあり、ブランドの価値はこの 3 つの要素のかけ算にあります。 体験が魅力的であり、その体験の回数が多く長い時間にわたって経験し、体験自体に一貫性があるブランドがユーザーとって良いものとされます。 3 つのうち特に重要なものは最後の ｢体験の一貫性｣ にあり、この一貫性は 2 つに分けることができます。 時系列で一貫性 ：時代で左右されない顧客体験がブランドから提供される 接点の一貫性 ：ブランドを買ったり利用する前から、購入プロセス、購入後の利用シーンにおいて、一貫した顧客体験ができる 「モノとコト」にも例えやすいところですが、製品としての一貫性に加えて体験する前後のグランドデザインにも一貫性を持たすことが重要になります。 例としてスターバックスは広告費をほとんどかけずに今のブランド認知度を築いたことは有名ですが、そこにはブランドの価値を築くためのブランディングに一貫性があり、かつそれらが時代性とマッチしたのが要因ではないかと思います。 ブランディングのメリット 選択意思決定の単純化・固定化 顧客の知識が整理されることで競合と差別化され再び同じ物を選ぶようになる ユーザーのロイヤル化 親しみや信頼が増大されることでブランドロイヤリティが形成される なぜブランドにこだわるのか、という点でもこれらメリットを実現していくことが重要です。 デザイナーとして気遣い溢れる UI や、サービスの思想を記号に落とし込んだ VI などモノづくり視点でのこだわりや重要さを踏まえた上で、他職種の方にもこれらのメリットや競争としての必要であることを理解してもらえるよう働きかけることを意識していきたいところです。 ブランディングの悩みどころ ここからは基礎を踏まえて、実践的に行われているブランディングで悩みやすいところを事例で紹介しながら簡単なディスカッションをしていきました。一部だけ抜粋してご紹介します。 製品ブランドの管理 会社のブランド管理の思想を定義できても、変化の早い業界であればイメージ通りになかなか通らないことも多々有りえます。 少ないブランド資産を活用する意味でもスタートアップは横串型に整理されることが多くありますが、ある程度の規模感になって基礎体力がある企業であると個別適応型でもブランドとして信頼性を保てますし、横串型に比べて動きやすさがあると思います。 一方で、プラットフォーマーとして存在したいなら横串のブランド価値からファンを囲い込むべきかもしれません。Techlunch の中でもメドレーであればどうあると良いかについて議論ができました。 ブランディングのタイミング 顧客体験の蓄積が重要なブランドでありますが、どの段階でブランディングに取り組むかは状況によりますが意見が出やすいところだと思います。 ICC FUKUOKA2017 にてブランディングについてのセッションがあり、取り組むタイミングについての議論がうまくまとめられていたため Techlunch で事例として共有しました。プロダクトとしての差別化が基本であることに加えて、ブランドの在り方を組織にインストールさせるためにブランディングに取り組むケースも紹介されています。 僕はブランドが常に必要かと言うと“No”だと思います。 コモディティ化し始めたり、競争が始まって差別化しなくてはならない時に、プロダクトの機能などで差別化ができない、または必ずしもパフォーマンスで差別化ができない時に唯一残された選択が、ブランドを作るということであると思います。 [株式会社 Bloom&Co. 彌野泰弘] ユーザーを獲りにいくというフェーズですよね。 メルカリの場合、やはり最初の 100 万ダウンロードくらいまでは、結構チューニングをしながらオンラインのマーケティングで（ユーザーを）獲得してきてきました。 中略 やはり 100 万ダウンロードくらいあって、リテンションレートが高くユーザーが積み上がる状態になっていれば、大きくマスマーケティング（TVCM）をやっても獲得したユーザーは残りますからね。 [株式会社メルカリ 小泉文明] 僕は、ユーザーを獲得する手前でブランドが必要だと思っているんですよね。 ブランドというのは必ずしも外に対してだけではなくて、（組織の）中の人に対して必要であることもすごく多いのです。 中略 資生堂は当時 130 年くらい経っている会社だったので、その 130 年もこの後の 130 年も、世の中を美しくするとか、人を美しくするとか、それは女性に限らず、お化粧に限らず美しくするということが必要だよね、軸だよねという話になって、そのスローガンと共に前田新社長体制で進んでいくことになりました。 [株式会社 dof 齋藤太郎] (via スタートアップのブランディングはいつから必要か？【F17-7C #3】 ) 共有した後には、リリース当初からブランドやクリエイティブが作り込まれたプロダクトが最近話題になることが多いということも話に上がりました。 もちろんブランディングのタイミングは状況により千差万別ですが、プロダクトをゼロから作る際には、プロダクトの在り方と合わせてどんなブランドを作って行きたいのかも早めに考えられることが必要だ、など具体的なディスカッションも出来ました。 新たなブランドが受け入れられないことも 基本的にブランドを新しくすることは見慣れたものが変わってしまう恐怖から反発を生むケースが多いですが、その中でも GAP はロゴの 2010 年リニューアル公表後ネット上からの反発が強くわずか 6 日間という短期間で新しいロゴの使用を止め、元のロゴに戻してしまうという一件がありました。（この件は 株価 にも大きな影響を与えました） 一方、同じような境遇で Airbnb も 2014 年のリニューアル当初ロゴは不評でしたが今ではリニューアルの成功例として扱われる存在になっています。 Techlunch でも歴史の有無が差になったのか、など様々な意見が出てきました。この件はロゴとしての王道を極めようとした以上の背景を提示出来なかった Gap に対して、 Airbnb はサービスのストーリーをロゴに内包 し、地道にロゴを介したコミュニケーションに徹したことが明暗を分けたように思います。 この事例はロゴのアイデンティティをどこまで確立させられたかの違いにあることに加えて、デザインの意思決定を一時的な多数意見に委ねた事例としても学ぶことが多いです。 まとめ 私個人が元々グラフィックデザインをしていた経験もあり、今まではブランディングの中でも興味が CI や VI に傾倒していましたが、体験全体がブランドに大きな影響を与えるこの時代、組織としてブランド構築をしていく意識が重要であることが今回の大きな学びでした。 また基礎を学ぶ上で書籍を読んでいましたが、最近の事例などを学ぶ際にはブログなどでの情報収集がとても有効で、学び方も変わってきているなと思いました。今回紹介した内容はあくまで入門編なので、興味があれば今回参考にさせていただいた本とブログ・記事からより深堀りが出来るのでオススメします。 プラットフォームブランディング コーポレート・アイデンティティ戦略―デザインが企業経営を変える ブランド・エクイティ研究の展望 ～価値をめぐる議論の系譜を中心に～ UX とブランド ブランドアイデンティティとは｜ブランド構築を成果に導く BI の創り方｜成功事例有 スタートアップのブランディングはいつから必要か？ ロゴのリデザインーなぜ Gap が失敗し Airbnb が受け入れられたのか 武器になる「ロゴ」を生み出す、CI デザインとは何か？ Techlunch ではデザイナー以外の方からも事例に対して意見が出たり、疑問に対して参加者でディスカッションが出来たことがとても有意義でした。今後はこれらを意識しながらブランドの土台となる価値や在り方をデザイン出来るようにしていきたいと思います。 お知らせ  メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 興味のある方、ぜひメドレーへ遊びにいらしてください。 www.medley.jp

こんにちは。開発本部の医療メディアチームでデザインをしている波切です。 メドレー開発本部で行われている勉強会「TechLunch」で、デザイナー以外の方も知っておいて損はない「ブランドとは？」というお話をさせていただきました。多くの方が何となく知っていることも多いかもしれませんが、再入門的に参考にしていただけると嬉しいです。 背景 メドレーでは時期を問わずプロダクトの在り方について常日頃から様々な場面で議論がなされています。 こういった議論の中でブランドとしてどのように見せられるのが良いだろうか、といった検討をすることも多々あり、改めてブランドについて学び直したいと思ったのが今回のきっかけになります。 TechLunch ではエンジニア・デザイナー・ディレクター・医師（！）と様々な職種の人が参加しています。 この時代では当たり前かもしれないブランドの基礎を改めて学び直し、デザイナー以外の職種の方にも共有しましたので、ブログでもご紹介させていただければと思います。 ブランドってなんでしょう ブランドとブランディングの違いって？ まずは混合しやすいブランドとブランディングの定義から。 ある特定の商品やサービスが消費者・顧客によって識別されているとき、 その商品やサービスを「ブランド」と呼ぶ ※製品名、パッケージング、広告、価格、使用経験などにより、その製品につけられた製品特性と価値（機能的および非機能的）とのユニークなコンビネーション。消費者・顧客の目から見た場合、その製品を競合から差別化するもの。 (via ブランド・マネージャー認定協会 用語集 ) ブランディングとは、ブランドに対する共感や信頼などを通じて顧客にとっての価値を高めていく、企業と組織のマーケティング戦略の 1 つ。ブランドとして認知されていないものをブランドに育て上げる、あるいはブランド構成要素を強化し、活性・維持管理していくこと。また、その手法。ここでいうブランドとは高級消費財に限らず、その対象としては、商品やサービス、それらを供給する企業や団体のほか、人物・建築物・史跡・地域 ・祭事など、あらゆるものが該当する。 (via wikipedia:ブランディング ) ブランド とは「企業・製品に対して消費者が持っているイメージ(記号)であり、競合との差別化を生み出す価値の総体」を指し、 ブランディング は「ブランド価値を与えるための手段」と捉えることができると思います。 この定義になぞらえてコカ・コーラを例にブランドとして認知される具体的なステップとして紹介すると、以下のようになります。 ロゴなどの識別記号が記憶される コカ･コーラのロゴが記憶される (生活者の頭の中に、ロゴなどの識別記号が記憶される) 記号から体験が思い浮かぶ コカ･コーラのロゴを見れば炭酸飲料であることや、爽やかな気分になれることが思い浮ぶ (識別記号を見れば、知覚体験を想起できる) 体験から記号を思い出す 爽やかな気分になりたいと思ったら、コカ･コーラを思い出す。ロゴが思い浮かぶ (知覚価値が頭に浮かんだら、識別記号が想起される)  「ブランド連想」「ブランド資産」といった言葉もあり、ブランド（識別記号と知覚体験）に対してポジティブな印象を築き蓄積させることがブランディングのカギになってきます。 ブランド構築 前述の記号をブランドの土台とするとコーポレートアイデンティティ（CI）やヴィジュアルアイデンティティ（VI）といったクリエイティブが大きな役割を果たしますが、現在ではユーザーはブランドを知覚する機会が多く、差別化のためにもブランドは顧客体験をベースに作っていくことも重要になります。 ｢良い顧客体験を提供しブランドの競争力を高める｣ という考え方に基づいて、ブランド戦略を考える順番は理想的な体験を描いてから必要なモノや技術を考えます。これはブランドに限らず様々な場面で意識したいことです。 ブランドに大事な一貫性 魅力的なブランドは顧客体験が蓄積して形成されていきます。蓄積されるブランド体験の要素は「体験の魅力度」「体験の量と時間」「体験の一貫性」と 3 つあり、ブランドの価値はこの 3 つの要素のかけ算にあります。 体験が魅力的であり、その体験の回数が多く長い時間にわたって経験し、体験自体に一貫性があるブランドがユーザーとって良いものとされます。 3 つのうち特に重要なものは最後の ｢体験の一貫性｣ にあり、この一貫性は 2 つに分けることができます。 時系列で一貫性 ：時代で左右されない顧客体験がブランドから提供される 接点の一貫性 ：ブランドを買ったり利用する前から、購入プロセス、購入後の利用シーンにおいて、一貫した顧客体験ができる 「モノとコト」にも例えやすいところですが、製品としての一貫性に加えて体験する前後のグランドデザインにも一貫性を持たすことが重要になります。 例としてスターバックスは広告費をほとんどかけずに今のブランド認知度を築いたことは有名ですが、そこにはブランドの価値を築くためのブランディングに一貫性があり、かつそれらが時代性とマッチしたのが要因ではないかと思います。 ブランディングのメリット 選択意思決定の単純化・固定化 顧客の知識が整理されることで競合と差別化され再び同じ物を選ぶようになる ユーザーのロイヤル化 親しみや信頼が増大されることでブランドロイヤリティが形成される なぜブランドにこだわるのか、という点でもこれらメリットを実現していくことが重要です。 デザイナーとして気遣い溢れる UI や、サービスの思想を記号に落とし込んだ VI などモノづくり視点でのこだわりや重要さを踏まえた上で、他職種の方にもこれらのメリットや競争としての必要であることを理解してもらえるよう働きかけることを意識していきたいところです。 ブランディングの悩みどころ ここからは基礎を踏まえて、実践的に行われているブランディングで悩みやすいところを事例で紹介しながら簡単なディスカッションをしていきました。一部だけ抜粋してご紹介します。 製品ブランドの管理 会社のブランド管理の思想を定義できても、変化の早い業界であればイメージ通りになかなか通らないことも多々有りえます。 少ないブランド資産を活用する意味でもスタートアップは横串型に整理されることが多くありますが、ある程度の規模感になって基礎体力がある企業であると個別適応型でもブランドとして信頼性を保てますし、横串型に比べて動きやすさがあると思います。 一方で、プラットフォーマーとして存在したいなら横串のブランド価値からファンを囲い込むべきかもしれません。Techlunch の中でもメドレーであればどうあると良いかについて議論ができました。 ブランディングのタイミング 顧客体験の蓄積が重要なブランドでありますが、どの段階でブランディングに取り組むかは状況によりますが意見が出やすいところだと思います。 ICC FUKUOKA2017 にてブランディングについてのセッションがあり、取り組むタイミングについての議論がうまくまとめられていたため Techlunch で事例として共有しました。プロダクトとしての差別化が基本であることに加えて、ブランドの在り方を組織にインストールさせるためにブランディングに取り組むケースも紹介されています。 僕はブランドが常に必要かと言うと“No”だと思います。 コモディティ化し始めたり、競争が始まって差別化しなくてはならない時に、プロダクトの機能などで差別化ができない、または必ずしもパフォーマンスで差別化ができない時に唯一残された選択が、ブランドを作るということであると思います。 [株式会社 Bloom&Co. 彌野泰弘] ユーザーを獲りにいくというフェーズですよね。 メルカリの場合、やはり最初の 100 万ダウンロードくらいまでは、結構チューニングをしながらオンラインのマーケティングで（ユーザーを）獲得してきてきました。 中略 やはり 100 万ダウンロードくらいあって、リテンションレートが高くユーザーが積み上がる状態になっていれば、大きくマスマーケティング（TVCM）をやっても獲得したユーザーは残りますからね。 [株式会社メルカリ 小泉文明] 僕は、ユーザーを獲得する手前でブランドが必要だと思っているんですよね。 ブランドというのは必ずしも外に対してだけではなくて、（組織の）中の人に対して必要であることもすごく多いのです。 中略 資生堂は当時 130 年くらい経っている会社だったので、その 130 年もこの後の 130 年も、世の中を美しくするとか、人を美しくするとか、それは女性に限らず、お化粧に限らず美しくするということが必要だよね、軸だよねという話になって、そのスローガンと共に前田新社長体制で進んでいくことになりました。 [株式会社 dof 齋藤太郎] (via スタートアップのブランディングはいつから必要か？【F17-7C #3】 ) 共有した後には、リリース当初からブランドやクリエイティブが作り込まれたプロダクトが最近話題になることが多いということも話に上がりました。 もちろんブランディングのタイミングは状況により千差万別ですが、プロダクトをゼロから作る際には、プロダクトの在り方と合わせてどんなブランドを作って行きたいのかも早めに考えられることが必要だ、など具体的なディスカッションも出来ました。 新たなブランドが受け入れられないことも 基本的にブランドを新しくすることは見慣れたものが変わってしまう恐怖から反発を生むケースが多いですが、その中でも GAP はロゴの 2010 年リニューアル公表後ネット上からの反発が強くわずか 6 日間という短期間で新しいロゴの使用を止め、元のロゴに戻してしまうという一件がありました。（この件は 株価 にも大きな影響を与えました） 一方、同じような境遇で Airbnb も 2014 年のリニューアル当初ロゴは不評でしたが今ではリニューアルの成功例として扱われる存在になっています。 Techlunch でも歴史の有無が差になったのか、など様々な意見が出てきました。この件はロゴとしての王道を極めようとした以上の背景を提示出来なかった Gap に対して、 Airbnb はサービスのストーリーをロゴに内包 し、地道にロゴを介したコミュニケーションに徹したことが明暗を分けたように思います。 この事例はロゴのアイデンティティをどこまで確立させられたかの違いにあることに加えて、デザインの意思決定を一時的な多数意見に委ねた事例としても学ぶことが多いです。 まとめ 私個人が元々グラフィックデザインをしていた経験もあり、今まではブランディングの中でも興味が CI や VI に傾倒していましたが、体験全体がブランドに大きな影響を与えるこの時代、組織としてブランド構築をしていく意識が重要であることが今回の大きな学びでした。 また基礎を学ぶ上で書籍を読んでいましたが、最近の事例などを学ぶ際にはブログなどでの情報収集がとても有効で、学び方も変わってきているなと思いました。今回紹介した内容はあくまで入門編なので、興味があれば今回参考にさせていただいた本とブログ・記事からより深堀りが出来るのでオススメします。 プラットフォームブランディング コーポレート・アイデンティティ戦略―デザインが企業経営を変える ブランド・エクイティ研究の展望 ～価値をめぐる議論の系譜を中心に～ UX とブランド ブランドアイデンティティとは｜ブランド構築を成果に導く BI の創り方｜成功事例有 スタートアップのブランディングはいつから必要か？ ロゴのリデザインーなぜ Gap が失敗し Airbnb が受け入れられたのか 武器になる「ロゴ」を生み出す、CI デザインとは何か？ Techlunch ではデザイナー以外の方からも事例に対して意見が出たり、疑問に対して参加者でディスカッションが出来たことがとても有意義でした。今後はこれらを意識しながらブランドの土台となる価値や在り方をデザイン出来るようにしていきたいと思います。 お知らせ  メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 興味のある方、ぜひメドレーへ遊びにいらしてください。 www.medley.jp

こんにちは、メドレー広報の阿部です。先日開催された 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

こんにちは、メドレー広報の阿部です。先日開催された 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