こんにちは。最近白髪が目立つようになりました。最初は蛍光灯の反射かな？とおもっていましたが実はそうじゃないらしいイケメン担当デザイナーの小山です。 私が担当しているジョブメドレーではサービスの改善をいくつも重ねますがその結果、全体の統一感が薄くなりデザインの改善をすることがあります。 こういった場合、もちろんユーザーの使いやすさを前提にリニューアルを考えますが、 自分たち（開発者）にも使いやすいデザイン はどういう姿か追いながら取り組むように心がけるようにしてみることにしました。 この試みの背景にはサービスの プロダクト基本理念 が関係しています。このエントリでは、先般行ったモバイル向けの求職者画面のデザインリニューアルを通して、プロダクト基本理念に基づいた「自分たちにも使いやすいデザイン」を実現した話をご紹介いたします。 開発工数を増大させるデザイン まず始めにジョブメドレーの求職者画面についてです。これは医療従事者向けの求人を探しているユーザー『求職者』のための画面で、求人の絞り込む検索、求人の詳細情報、職種の情報を発信するブログ、サービスのコンセプト紹介など多彩な情報で構成されています。 メドレーが運営しているサービスの中で最も歴史があり、求職者の希望に見合った求人をスマートに探すことができるように、リニューアルや機能拡充を繰り返しおこなってきました。おかげさまで毎年安定的な成長をとげています。 求職者画面の一部 ただその一方で、リニューアルに対応しきれなかったページも数多くあります。未対応のページは時期を改めて対応するはずでしたが、開発リソースの事情で全て対応できている状態ではありません。 そうした未対応がリニューアルごとに積み重なり、数世代分のデザインパーツが並行運用され、開発の作業効率がなかなか向上できない状況でした。 たとえばボタンやアイコンが同じであったとしても挙動や意味付けにズレが生じていたり、使われているはずがないデザインパーツが全く別の使われ方で存在していたり、全体の把握が追いついていない状況が所々ありました。 これは求職者にとって使い勝手が複雑になる上に、似たようなデザインパーツが増殖されたり誤った使い方をすることで、デザインのルールが曖昧になりエンジニアの作業工数が肥大化していきます。もちろんデザイナーの工数もです。 今回のデザインリニューアルの発端は、ユーザーのために更に使いやすさの改善と、用途が曖昧なデザインパーツの並行運用がもたらす開発上の問題を解決したいということもありました。 プロダクト基本理念に立ち返る 問題を解決するためにどういう方向性が良いか検討するため、まずプロダクト理念まで立ち返ってみました。 ジョブメドレーのプロダクト理念は、各部署が業務を行うための行動指針のようなものです。 プロダクトを一定の品質を保つため、求職者の求職活動を支えるキャリアサポート、事業所の効果的な求人掲載を提案するカスタマーサクセスやクリエイションチーム、これから求人を掲載したい事業所をサポートするセールスチーム、そして開発チームがこのプロダクト理念をもとに動いています。 求人を探すユーザー『求職者』と求人を出すユーザー『事業者』の双方が満足のいく意思決定をするためのこれら３つの理念を核としています。また、その理念を通して実現する サービスのミッション の達成に向かってメンバーは業務を行なっています。デザインパーツもこの理念をもとに制作されています。 ただ前述の通り、求職者画面が理念を守れる万全な状況にあるかというと、そうではありませんでした。必ずしも完璧なデザインが世の中にないように、ジョブメドレーももっと良くしていけるポイントはデザイン面で数多くあり、今回のリニューアルでは、そうした課題解決を目指しました。 さらに進めるにあたり、長期的にプロダクト理念に基づいた開発・デザインが行えるよう「求職者と開発の両方に働きかけられる環境」の整備を行うことにしました。 求職活動だけに集中できる環境 満足のいく意思決定を行う環境は、情報を読むことに悩むよう環境ではなくて、読んだ情報をじっくり考えられる環境だと私は考えています。 これまでのリニューアルで生まれた数世代ぶんの負債のために、字が読みにくいだとか、ボタン押したらどうなるかわからないだとか、そういった本質的ではない部分でつまづかない環境を作りました。 デザイナーがいなくても開発できる環境 いくら見栄えがよくユーザーにとって使い勝手が良かったとしても、それを運用するために開発のコストがかかるのであれば良い UI とは言えません。 使い勝手を維持するために開発を逼迫させ本来コストをかけるべきところに注力できずに別の部分の使い勝手を落とし、結果的にユーザーの不利益や不信感に繋がるかもしれないからです。これは極端な考えかもしれませんが、起こる可能性としては低くはないはずです。 それを解決する方法の１つとしてプロジェクトの関係者が把握できる内容にまでデザインを単純化させることなのではと私は考えています。デザイナーしか把握できないものではなく、むしろデザイナーが関わらなくても把握できるものを目指しました。 エンジニアだけで作れるデザイン 扱いやすいデザインとその意図 今回できたデザインは「普通」です。なるべく特殊はことは避け、デザイナー以外でもわかるデザインを目指しました。またデザインの意図もできる限りシンプルにまとめることに注力しました。 理路整然とした意図でも、それが複雑だとつくった本人しか扱えないものになります。なので聞きなれないワードや表現は控え、真に守らなくてはいけないことを抽出しました。またコンポーネントも限界まで削ぎ落とし最適化しました。 デザインの意図を明文化 把握しやすい数に色を減らす　左がリニューアル前：右がリニューアル後 この過程でプロジェクトでうれしい場面がありました。それはエンジニアさんから新しいデザインがあがったこと。 デザインパーツが足りず追加制作していたところ、既にエンジニアさんがデザイントーンを参考に足りないパーツを製作してくれていました。しかも私のデザインよりも良いもので。。。複雑な心境になりましたが、それぐらいデザインが扱いやすくなっているということでもあるのかなと 自分に言い聞かせました ポジティブに考えるようにしました。 左：私のデザイン　右：エンジニアのデザイン　どう見ても左より右が周囲と喧嘩してない。左はしゃしゃり出る 今回のプロジェクトは UI を綺麗にすることだけじゃなく、それ自体を関係者が扱いやすいものに改善する目的でもあったので、この出来事は当初考えていたこと以上の結果で良かったと思っています。 この要因は単純にルールが簡単で覚えやすかったことなのかもしれません。そうした覚えやすいデザインは学習コストが軽く、まわりめぐってユーザーにも扱いやすいものなると考えています。 デザインを維持できるコンポーネントの運用 昨今ではデザインシステムやスタイルガイドの普及により、デザインパーツ、コンポーネントなどを運用することはさほど特別なことではないと思います。 今回のリニューアルでは整備した環境を維持するためにスタンダードな運用にも着手します。こうした取り組みは以前にも行なっていたものの開発チームに明文化されていなかったので、改善を繰りかえし動かしていきたいと思います。 まとめ 今回のリニューアルはバラバラだったデザイントーンに統一感を持たせることでユーザーに使いやすさを担保する、その過程で自分たちにも使いやすいデザインを目指しました。 一般的にはリニューアルではユーザーを中心したものが多いかもしれません。今回はその中に自分たち（開発者）も加味して考え、サービスのミッションの達成のためのプロダクト基本理念を支えられる環境作りを目指しました。 デザインの役割は物事を綺麗にするだけではなく、理念のような根っこの部分に立ち返れる機会や根っこそのものを具現化させる役割を担っていると考えています。とはいえ今回はその第一歩。今後は更に運用方法やコンテンツ設計や導線設計に磨きをかける必要があります。 また進捗があり次第ご報告できればと思います。ここまで読んでいただきありがとうございました。 最後に メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 https://www.medley.jp/recruit/creative.html

こんにちは。最近白髪が目立つようになりました。最初は蛍光灯の反射かな？とおもっていましたが実はそうじゃないらしいイケメン担当デザイナーの小山です。 私が担当しているジョブメドレーではサービスの改善をいくつも重ねますがその結果、全体の統一感が薄くなりデザインの改善をすることがあります。 こういった場合、もちろんユーザーの使いやすさを前提にリニューアルを考えますが、 自分たち（開発者）にも使いやすいデザイン はどういう姿か追いながら取り組むように心がけるようにしてみることにしました。 この試みの背景にはサービスの プロダクト基本理念 が関係しています。このエントリでは、先般行ったモバイル向けの求職者画面のデザインリニューアルを通して、プロダクト基本理念に基づいた「自分たちにも使いやすいデザイン」を実現した話をご紹介いたします。 開発工数を増大させるデザイン まず始めにジョブメドレーの求職者画面についてです。これは医療従事者向けの求人を探しているユーザー『求職者』のための画面で、求人の絞り込む検索、求人の詳細情報、職種の情報を発信するブログ、サービスのコンセプト紹介など多彩な情報で構成されています。 メドレーが運営しているサービスの中で最も歴史があり、求職者の希望に見合った求人をスマートに探すことができるように、リニューアルや機能拡充を繰り返しおこなってきました。おかげさまで毎年安定的な成長をとげています。 求職者画面の一部 ただその一方で、リニューアルに対応しきれなかったページも数多くあります。未対応のページは時期を改めて対応するはずでしたが、開発リソースの事情で全て対応できている状態ではありません。 そうした未対応がリニューアルごとに積み重なり、数世代分のデザインパーツが並行運用され、開発の作業効率がなかなか向上できない状況でした。 たとえばボタンやアイコンが同じであったとしても挙動や意味付けにズレが生じていたり、使われているはずがないデザインパーツが全く別の使われ方で存在していたり、全体の把握が追いついていない状況が所々ありました。 これは求職者にとって使い勝手が複雑になる上に、似たようなデザインパーツが増殖されたり誤った使い方をすることで、デザインのルールが曖昧になりエンジニアの作業工数が肥大化していきます。もちろんデザイナーの工数もです。 今回のデザインリニューアルの発端は、ユーザーのために更に使いやすさの改善と、用途が曖昧なデザインパーツの並行運用がもたらす開発上の問題を解決したいということもありました。 プロダクト基本理念に立ち返る 問題を解決するためにどういう方向性が良いか検討するため、まずプロダクト理念まで立ち返ってみました。 ジョブメドレーのプロダクト理念は、各部署が業務を行うための行動指針のようなものです。 プロダクトを一定の品質を保つため、求職者の求職活動を支えるキャリアサポート、事業所の効果的な求人掲載を提案するカスタマーサクセスやクリエイションチーム、これから求人を掲載したい事業所をサポートするセールスチーム、そして開発チームがこのプロダクト理念をもとに動いています。 求人を探すユーザー『求職者』と求人を出すユーザー『事業者』の双方が満足のいく意思決定をするためのこれら３つの理念を核としています。また、その理念を通して実現する サービスのミッション の達成に向かってメンバーは業務を行なっています。デザインパーツもこの理念をもとに制作されています。 ただ前述の通り、求職者画面が理念を守れる万全な状況にあるかというと、そうではありませんでした。必ずしも完璧なデザインが世の中にないように、ジョブメドレーももっと良くしていけるポイントはデザイン面で数多くあり、今回のリニューアルでは、そうした課題解決を目指しました。 さらに進めるにあたり、長期的にプロダクト理念に基づいた開発・デザインが行えるよう「求職者と開発の両方に働きかけられる環境」の整備を行うことにしました。 求職活動だけに集中できる環境 満足のいく意思決定を行う環境は、情報を読むことに悩むよう環境ではなくて、読んだ情報をじっくり考えられる環境だと私は考えています。 これまでのリニューアルで生まれた数世代ぶんの負債のために、字が読みにくいだとか、ボタン押したらどうなるかわからないだとか、そういった本質的ではない部分でつまづかない環境を作りました。 デザイナーがいなくても開発できる環境 いくら見栄えがよくユーザーにとって使い勝手が良かったとしても、それを運用するために開発のコストがかかるのであれば良い UI とは言えません。 使い勝手を維持するために開発を逼迫させ本来コストをかけるべきところに注力できずに別の部分の使い勝手を落とし、結果的にユーザーの不利益や不信感に繋がるかもしれないからです。これは極端な考えかもしれませんが、起こる可能性としては低くはないはずです。 それを解決する方法の１つとしてプロジェクトの関係者が把握できる内容にまでデザインを単純化させることなのではと私は考えています。デザイナーしか把握できないものではなく、むしろデザイナーが関わらなくても把握できるものを目指しました。 エンジニアだけで作れるデザイン 扱いやすいデザインとその意図 今回できたデザインは「普通」です。なるべく特殊はことは避け、デザイナー以外でもわかるデザインを目指しました。またデザインの意図もできる限りシンプルにまとめることに注力しました。 理路整然とした意図でも、それが複雑だとつくった本人しか扱えないものになります。なので聞きなれないワードや表現は控え、真に守らなくてはいけないことを抽出しました。またコンポーネントも限界まで削ぎ落とし最適化しました。 デザインの意図を明文化 把握しやすい数に色を減らす　左がリニューアル前：右がリニューアル後 この過程でプロジェクトでうれしい場面がありました。それはエンジニアさんから新しいデザインがあがったこと。 デザインパーツが足りず追加制作していたところ、既にエンジニアさんがデザイントーンを参考に足りないパーツを製作してくれていました。しかも私のデザインよりも良いもので。。。複雑な心境になりましたが、それぐらいデザインが扱いやすくなっているということでもあるのかなと 自分に言い聞かせました ポジティブに考えるようにしました。 左：私のデザイン　右：エンジニアのデザイン　どう見ても左より右が周囲と喧嘩してない。左はしゃしゃり出る 今回のプロジェクトは UI を綺麗にすることだけじゃなく、それ自体を関係者が扱いやすいものに改善する目的でもあったので、この出来事は当初考えていたこと以上の結果で良かったと思っています。 この要因は単純にルールが簡単で覚えやすかったことなのかもしれません。そうした覚えやすいデザインは学習コストが軽く、まわりめぐってユーザーにも扱いやすいものなると考えています。 デザインを維持できるコンポーネントの運用 昨今ではデザインシステムやスタイルガイドの普及により、デザインパーツ、コンポーネントなどを運用することはさほど特別なことではないと思います。 今回のリニューアルでは整備した環境を維持するためにスタンダードな運用にも着手します。こうした取り組みは以前にも行なっていたものの開発チームに明文化されていなかったので、改善を繰りかえし動かしていきたいと思います。 まとめ 今回のリニューアルはバラバラだったデザイントーンに統一感を持たせることでユーザーに使いやすさを担保する、その過程で自分たちにも使いやすいデザインを目指しました。 一般的にはリニューアルではユーザーを中心したものが多いかもしれません。今回はその中に自分たち（開発者）も加味して考え、サービスのミッションの達成のためのプロダクト基本理念を支えられる環境作りを目指しました。 デザインの役割は物事を綺麗にするだけではなく、理念のような根っこの部分に立ち返れる機会や根っこそのものを具現化させる役割を担っていると考えています。とはいえ今回はその第一歩。今後は更に運用方法やコンテンツ設計や導線設計に磨きをかける必要があります。 また進捗があり次第ご報告できればと思います。ここまで読んでいただきありがとうございました。 最後に メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。最近白髪が目立つようになりました。最初は蛍光灯の反射かな？とおもっていましたが実はそうじゃないらしいイケメン担当デザイナーの小山です。 私が担当しているジョブメドレーではサービスの改善をいくつも重ねますがその結果、全体の統一感が薄くなりデザインの改善をすることがあります。 こういった場合、もちろんユーザーの使いやすさを前提にリニューアルを考えますが、 自分たち（開発者）にも使いやすいデザイン はどういう姿か追いながら取り組むように心がけるようにしてみることにしました。 この試みの背景にはサービスの プロダクト基本理念 が関係しています。このエントリでは、先般行ったモバイル向けの求職者画面のデザインリニューアルを通して、プロダクト基本理念に基づいた「自分たちにも使いやすいデザイン」を実現した話をご紹介いたします。 開発工数を増大させるデザイン まず始めにジョブメドレーの求職者画面についてです。これは医療従事者向けの求人を探しているユーザー『求職者』のための画面で、求人の絞り込む検索、求人の詳細情報、職種の情報を発信するブログ、サービスのコンセプト紹介など多彩な情報で構成されています。 メドレーが運営しているサービスの中で最も歴史があり、求職者の希望に見合った求人をスマートに探すことができるように、リニューアルや機能拡充を繰り返しおこなってきました。おかげさまで毎年安定的な成長をとげています。 求職者画面の一部 ただその一方で、リニューアルに対応しきれなかったページも数多くあります。未対応のページは時期を改めて対応するはずでしたが、開発リソースの事情で全て対応できている状態ではありません。 そうした未対応がリニューアルごとに積み重なり、数世代分のデザインパーツが並行運用され、開発の作業効率がなかなか向上できない状況でした。 たとえばボタンやアイコンが同じであったとしても挙動や意味付けにズレが生じていたり、使われているはずがないデザインパーツが全く別の使われ方で存在していたり、全体の把握が追いついていない状況が所々ありました。 これは求職者にとって使い勝手が複雑になる上に、似たようなデザインパーツが増殖されたり誤った使い方をすることで、デザインのルールが曖昧になりエンジニアの作業工数が肥大化していきます。もちろんデザイナーの工数もです。 今回のデザインリニューアルの発端は、ユーザーのために更に使いやすさの改善と、用途が曖昧なデザインパーツの並行運用がもたらす開発上の問題を解決したいということもありました。 プロダクト基本理念に立ち返る 問題を解決するためにどういう方向性が良いか検討するため、まずプロダクト理念まで立ち返ってみました。 ジョブメドレーのプロダクト理念は、各部署が業務を行うための行動指針のようなものです。 プロダクトを一定の品質を保つため、求職者の求職活動を支えるキャリアサポート、事業所の効果的な求人掲載を提案するカスタマーサクセスやクリエイションチーム、これから求人を掲載したい事業所をサポートするセールスチーム、そして開発チームがこのプロダクト理念をもとに動いています。 求人を探すユーザー『求職者』と求人を出すユーザー『事業者』の双方が満足のいく意思決定をするためのこれら３つの理念を核としています。また、その理念を通して実現する サービスのミッション の達成に向かってメンバーは業務を行なっています。デザインパーツもこの理念をもとに制作されています。 ただ前述の通り、求職者画面が理念を守れる万全な状況にあるかというと、そうではありませんでした。必ずしも完璧なデザインが世の中にないように、ジョブメドレーももっと良くしていけるポイントはデザイン面で数多くあり、今回のリニューアルでは、そうした課題解決を目指しました。 さらに進めるにあたり、長期的にプロダクト理念に基づいた開発・デザインが行えるよう「求職者と開発の両方に働きかけられる環境」の整備を行うことにしました。 求職活動だけに集中できる環境 満足のいく意思決定を行う環境は、情報を読むことに悩むよう環境ではなくて、読んだ情報をじっくり考えられる環境だと私は考えています。 これまでのリニューアルで生まれた数世代ぶんの負債のために、字が読みにくいだとか、ボタン押したらどうなるかわからないだとか、そういった本質的ではない部分でつまづかない環境を作りました。 デザイナーがいなくても開発できる環境 いくら見栄えがよくユーザーにとって使い勝手が良かったとしても、それを運用するために開発のコストがかかるのであれば良い UI とは言えません。 使い勝手を維持するために開発を逼迫させ本来コストをかけるべきところに注力できずに別の部分の使い勝手を落とし、結果的にユーザーの不利益や不信感に繋がるかもしれないからです。これは極端な考えかもしれませんが、起こる可能性としては低くはないはずです。 それを解決する方法の１つとしてプロジェクトの関係者が把握できる内容にまでデザインを単純化させることなのではと私は考えています。デザイナーしか把握できないものではなく、むしろデザイナーが関わらなくても把握できるものを目指しました。 エンジニアだけで作れるデザイン 扱いやすいデザインとその意図 今回できたデザインは「普通」です。なるべく特殊はことは避け、デザイナー以外でもわかるデザインを目指しました。またデザインの意図もできる限りシンプルにまとめることに注力しました。 理路整然とした意図でも、それが複雑だとつくった本人しか扱えないものになります。なので聞きなれないワードや表現は控え、真に守らなくてはいけないことを抽出しました。またコンポーネントも限界まで削ぎ落とし最適化しました。 デザインの意図を明文化 把握しやすい数に色を減らす　左がリニューアル前：右がリニューアル後 この過程でプロジェクトでうれしい場面がありました。それはエンジニアさんから新しいデザインがあがったこと。 デザインパーツが足りず追加制作していたところ、既にエンジニアさんがデザイントーンを参考に足りないパーツを製作してくれていました。しかも私のデザインよりも良いもので。。。複雑な心境になりましたが、それぐらいデザインが扱いやすくなっているということでもあるのかなと 自分に言い聞かせました ポジティブに考えるようにしました。 左：私のデザイン　右：エンジニアのデザイン　どう見ても左より右が周囲と喧嘩してない。左はしゃしゃり出る 今回のプロジェクトは UI を綺麗にすることだけじゃなく、それ自体を関係者が扱いやすいものに改善する目的でもあったので、この出来事は当初考えていたこと以上の結果で良かったと思っています。 この要因は単純にルールが簡単で覚えやすかったことなのかもしれません。そうした覚えやすいデザインは学習コストが軽く、まわりめぐってユーザーにも扱いやすいものなると考えています。 デザインを維持できるコンポーネントの運用 昨今ではデザインシステムやスタイルガイドの普及により、デザインパーツ、コンポーネントなどを運用することはさほど特別なことではないと思います。 今回のリニューアルでは整備した環境を維持するためにスタンダードな運用にも着手します。こうした取り組みは以前にも行なっていたものの開発チームに明文化されていなかったので、改善を繰りかえし動かしていきたいと思います。 まとめ 今回のリニューアルはバラバラだったデザイントーンに統一感を持たせることでユーザーに使いやすさを担保する、その過程で自分たちにも使いやすいデザインを目指しました。 一般的にはリニューアルではユーザーを中心したものが多いかもしれません。今回はその中に自分たち（開発者）も加味して考え、サービスのミッションの達成のためのプロダクト基本理念を支えられる環境作りを目指しました。 デザインの役割は物事を綺麗にするだけではなく、理念のような根っこの部分に立ち返れる機会や根っこそのものを具現化させる役割を担っていると考えています。とはいえ今回はその第一歩。今後は更に運用方法やコンテンツ設計や導線設計に磨きをかける必要があります。 また進捗があり次第ご報告できればと思います。ここまで読んでいただきありがとうございました。 最後に メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。最近白髪が目立つようになりました。最初は蛍光灯の反射かな？とおもっていましたが実はそうじゃないらしいイケメン担当デザイナーの小山です。 私が担当しているジョブメドレーではサービスの改善をいくつも重ねますがその結果、全体の統一感が薄くなりデザインの改善をすることがあります。 こういった場合、もちろんユーザーの使いやすさを前提にリニューアルを考えますが、 自分たち（開発者）にも使いやすいデザイン はどういう姿か追いながら取り組むように心がけるようにしてみることにしました。 この試みの背景にはサービスの プロダクト基本理念 が関係しています。このエントリでは、先般行ったモバイル向けの求職者画面のデザインリニューアルを通して、プロダクト基本理念に基づいた「自分たちにも使いやすいデザイン」を実現した話をご紹介いたします。 開発工数を増大させるデザイン まず始めにジョブメドレーの求職者画面についてです。これは医療従事者向けの求人を探しているユーザー『求職者』のための画面で、求人の絞り込む検索、求人の詳細情報、職種の情報を発信するブログ、サービスのコンセプト紹介など多彩な情報で構成されています。 メドレーが運営しているサービスの中で最も歴史があり、求職者の希望に見合った求人をスマートに探すことができるように、リニューアルや機能拡充を繰り返しおこなってきました。おかげさまで毎年安定的な成長をとげています。 求職者画面の一部 ただその一方で、リニューアルに対応しきれなかったページも数多くあります。未対応のページは時期を改めて対応するはずでしたが、開発リソースの事情で全て対応できている状態ではありません。 そうした未対応がリニューアルごとに積み重なり、数世代分のデザインパーツが並行運用され、開発の作業効率がなかなか向上できない状況でした。 たとえばボタンやアイコンが同じであったとしても挙動や意味付けにズレが生じていたり、使われているはずがないデザインパーツが全く別の使われ方で存在していたり、全体の把握が追いついていない状況が所々ありました。 これは求職者にとって使い勝手が複雑になる上に、似たようなデザインパーツが増殖されたり誤った使い方をすることで、デザインのルールが曖昧になりエンジニアの作業工数が肥大化していきます。もちろんデザイナーの工数もです。 今回のデザインリニューアルの発端は、ユーザーのために更に使いやすさの改善と、用途が曖昧なデザインパーツの並行運用がもたらす開発上の問題を解決したいということもありました。 プロダクト基本理念に立ち返る 問題を解決するためにどういう方向性が良いか検討するため、まずプロダクト理念まで立ち返ってみました。 ジョブメドレーのプロダクト理念は、各部署が業務を行うための行動指針のようなものです。 プロダクトを一定の品質を保つため、求職者の求職活動を支えるキャリアサポート、事業所の効果的な求人掲載を提案するカスタマーサクセスやクリエイションチーム、これから求人を掲載したい事業所をサポートするセールスチーム、そして開発チームがこのプロダクト理念をもとに動いています。 求人を探すユーザー『求職者』と求人を出すユーザー『事業者』の双方が満足のいく意思決定をするためのこれら３つの理念を核としています。また、その理念を通して実現する サービスのミッション の達成に向かってメンバーは業務を行なっています。デザインパーツもこの理念をもとに制作されています。 ただ前述の通り、求職者画面が理念を守れる万全な状況にあるかというと、そうではありませんでした。必ずしも完璧なデザインが世の中にないように、ジョブメドレーももっと良くしていけるポイントはデザイン面で数多くあり、今回のリニューアルでは、そうした課題解決を目指しました。 さらに進めるにあたり、長期的にプロダクト理念に基づいた開発・デザインが行えるよう「求職者と開発の両方に働きかけられる環境」の整備を行うことにしました。 求職活動だけに集中できる環境 満足のいく意思決定を行う環境は、情報を読むことに悩むよう環境ではなくて、読んだ情報をじっくり考えられる環境だと私は考えています。 これまでのリニューアルで生まれた数世代ぶんの負債のために、字が読みにくいだとか、ボタン押したらどうなるかわからないだとか、そういった本質的ではない部分でつまづかない環境を作りました。 デザイナーがいなくても開発できる環境 いくら見栄えがよくユーザーにとって使い勝手が良かったとしても、それを運用するために開発のコストがかかるのであれば良い UI とは言えません。 使い勝手を維持するために開発を逼迫させ本来コストをかけるべきところに注力できずに別の部分の使い勝手を落とし、結果的にユーザーの不利益や不信感に繋がるかもしれないからです。これは極端な考えかもしれませんが、起こる可能性としては低くはないはずです。 それを解決する方法の１つとしてプロジェクトの関係者が把握できる内容にまでデザインを単純化させることなのではと私は考えています。デザイナーしか把握できないものではなく、むしろデザイナーが関わらなくても把握できるものを目指しました。 エンジニアだけで作れるデザイン 扱いやすいデザインとその意図 今回できたデザインは「普通」です。なるべく特殊はことは避け、デザイナー以外でもわかるデザインを目指しました。またデザインの意図もできる限りシンプルにまとめることに注力しました。 理路整然とした意図でも、それが複雑だとつくった本人しか扱えないものになります。なので聞きなれないワードや表現は控え、真に守らなくてはいけないことを抽出しました。またコンポーネントも限界まで削ぎ落とし最適化しました。 デザインの意図を明文化 把握しやすい数に色を減らす　左がリニューアル前：右がリニューアル後 この過程でプロジェクトでうれしい場面がありました。それはエンジニアさんから新しいデザインがあがったこと。 デザインパーツが足りず追加制作していたところ、既にエンジニアさんがデザイントーンを参考に足りないパーツを製作してくれていました。しかも私のデザインよりも良いもので。。。複雑な心境になりましたが、それぐらいデザインが扱いやすくなっているということでもあるのかなと 自分に言い聞かせました ポジティブに考えるようにしました。 左：私のデザイン　右：エンジニアのデザイン　どう見ても左より右が周囲と喧嘩してない。左はしゃしゃり出る 今回のプロジェクトは UI を綺麗にすることだけじゃなく、それ自体を関係者が扱いやすいものに改善する目的でもあったので、この出来事は当初考えていたこと以上の結果で良かったと思っています。 この要因は単純にルールが簡単で覚えやすかったことなのかもしれません。そうした覚えやすいデザインは学習コストが軽く、まわりめぐってユーザーにも扱いやすいものなると考えています。 デザインを維持できるコンポーネントの運用 昨今ではデザインシステムやスタイルガイドの普及により、デザインパーツ、コンポーネントなどを運用することはさほど特別なことではないと思います。 今回のリニューアルでは整備した環境を維持するためにスタンダードな運用にも着手します。こうした取り組みは以前にも行なっていたものの開発チームに明文化されていなかったので、改善を繰りかえし動かしていきたいと思います。 まとめ 今回のリニューアルはバラバラだったデザイントーンに統一感を持たせることでユーザーに使いやすさを担保する、その過程で自分たちにも使いやすいデザインを目指しました。 一般的にはリニューアルではユーザーを中心したものが多いかもしれません。今回はその中に自分たち（開発者）も加味して考え、サービスのミッションの達成のためのプロダクト基本理念を支えられる環境作りを目指しました。 デザインの役割は物事を綺麗にするだけではなく、理念のような根っこの部分に立ち返れる機会や根っこそのものを具現化させる役割を担っていると考えています。とはいえ今回はその第一歩。今後は更に運用方法やコンテンツ設計や導線設計に磨きをかける必要があります。 また進捗があり次第ご報告できればと思います。ここまで読んでいただきありがとうございました。 最後に メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。最近白髪が目立つようになりました。最初は蛍光灯の反射かな？とおもっていましたが実はそうじゃないらしいイケメン担当デザイナーの小山です。 私が担当しているジョブメドレーではサービスの改善をいくつも重ねますがその結果、全体の統一感が薄くなりデザインの改善をすることがあります。 こういった場合、もちろんユーザーの使いやすさを前提にリニューアルを考えますが、 自分たち（開発者）にも使いやすいデザイン はどういう姿か追いながら取り組むように心がけるようにしてみることにしました。 この試みの背景にはサービスの プロダクト基本理念 が関係しています。このエントリでは、先般行ったモバイル向けの求職者画面のデザインリニューアルを通して、プロダクト基本理念に基づいた「自分たちにも使いやすいデザイン」を実現した話をご紹介いたします。 開発工数を増大させるデザイン まず始めにジョブメドレーの求職者画面についてです。これは医療従事者向けの求人を探しているユーザー『求職者』のための画面で、求人の絞り込む検索、求人の詳細情報、職種の情報を発信するブログ、サービスのコンセプト紹介など多彩な情報で構成されています。 メドレーが運営しているサービスの中で最も歴史があり、求職者の希望に見合った求人をスマートに探すことができるように、リニューアルや機能拡充を繰り返しおこなってきました。おかげさまで毎年安定的な成長をとげています。 求職者画面の一部 ただその一方で、リニューアルに対応しきれなかったページも数多くあります。未対応のページは時期を改めて対応するはずでしたが、開発リソースの事情で全て対応できている状態ではありません。 そうした未対応がリニューアルごとに積み重なり、数世代分のデザインパーツが並行運用され、開発の作業効率がなかなか向上できない状況でした。 たとえばボタンやアイコンが同じであったとしても挙動や意味付けにズレが生じていたり、使われているはずがないデザインパーツが全く別の使われ方で存在していたり、全体の把握が追いついていない状況が所々ありました。 これは求職者にとって使い勝手が複雑になる上に、似たようなデザインパーツが増殖されたり誤った使い方をすることで、デザインのルールが曖昧になりエンジニアの作業工数が肥大化していきます。もちろんデザイナーの工数もです。 今回のデザインリニューアルの発端は、ユーザーのために更に使いやすさの改善と、用途が曖昧なデザインパーツの並行運用がもたらす開発上の問題を解決したいということもありました。 プロダクト基本理念に立ち返る 問題を解決するためにどういう方向性が良いか検討するため、まずプロダクト理念まで立ち返ってみました。 ジョブメドレーのプロダクト理念は、各部署が業務を行うための行動指針のようなものです。 プロダクトを一定の品質を保つため、求職者の求職活動を支えるキャリアサポート、事業所の効果的な求人掲載を提案するカスタマーサクセスやクリエイションチーム、これから求人を掲載したい事業所をサポートするセールスチーム、そして開発チームがこのプロダクト理念をもとに動いています。 求人を探すユーザー『求職者』と求人を出すユーザー『事業者』の双方が満足のいく意思決定をするためのこれら３つの理念を核としています。また、その理念を通して実現する サービスのミッション の達成に向かってメンバーは業務を行なっています。デザインパーツもこの理念をもとに制作されています。 ただ前述の通り、求職者画面が理念を守れる万全な状況にあるかというと、そうではありませんでした。必ずしも完璧なデザインが世の中にないように、ジョブメドレーももっと良くしていけるポイントはデザイン面で数多くあり、今回のリニューアルでは、そうした課題解決を目指しました。 さらに進めるにあたり、長期的にプロダクト理念に基づいた開発・デザインが行えるよう「求職者と開発の両方に働きかけられる環境」の整備を行うことにしました。 求職活動だけに集中できる環境 満足のいく意思決定を行う環境は、情報を読むことに悩むよう環境ではなくて、読んだ情報をじっくり考えられる環境だと私は考えています。 これまでのリニューアルで生まれた数世代ぶんの負債のために、字が読みにくいだとか、ボタン押したらどうなるかわからないだとか、そういった本質的ではない部分でつまづかない環境を作りました。 デザイナーがいなくても開発できる環境 いくら見栄えがよくユーザーにとって使い勝手が良かったとしても、それを運用するために開発のコストがかかるのであれば良い UI とは言えません。 使い勝手を維持するために開発を逼迫させ本来コストをかけるべきところに注力できずに別の部分の使い勝手を落とし、結果的にユーザーの不利益や不信感に繋がるかもしれないからです。これは極端な考えかもしれませんが、起こる可能性としては低くはないはずです。 それを解決する方法の１つとしてプロジェクトの関係者が把握できる内容にまでデザインを単純化させることなのではと私は考えています。デザイナーしか把握できないものではなく、むしろデザイナーが関わらなくても把握できるものを目指しました。 エンジニアだけで作れるデザイン 扱いやすいデザインとその意図 今回できたデザインは「普通」です。なるべく特殊はことは避け、デザイナー以外でもわかるデザインを目指しました。またデザインの意図もできる限りシンプルにまとめることに注力しました。 理路整然とした意図でも、それが複雑だとつくった本人しか扱えないものになります。なので聞きなれないワードや表現は控え、真に守らなくてはいけないことを抽出しました。またコンポーネントも限界まで削ぎ落とし最適化しました。 デザインの意図を明文化 把握しやすい数に色を減らす　左がリニューアル前：右がリニューアル後 この過程でプロジェクトでうれしい場面がありました。それはエンジニアさんから新しいデザインがあがったこと。 デザインパーツが足りず追加制作していたところ、既にエンジニアさんがデザイントーンを参考に足りないパーツを製作してくれていました。しかも私のデザインよりも良いもので。。。複雑な心境になりましたが、それぐらいデザインが扱いやすくなっているということでもあるのかなと 自分に言い聞かせました ポジティブに考えるようにしました。 左：私のデザイン　右：エンジニアのデザイン　どう見ても左より右が周囲と喧嘩してない。左はしゃしゃり出る 今回のプロジェクトは UI を綺麗にすることだけじゃなく、それ自体を関係者が扱いやすいものに改善する目的でもあったので、この出来事は当初考えていたこと以上の結果で良かったと思っています。 この要因は単純にルールが簡単で覚えやすかったことなのかもしれません。そうした覚えやすいデザインは学習コストが軽く、まわりめぐってユーザーにも扱いやすいものなると考えています。 デザインを維持できるコンポーネントの運用 昨今ではデザインシステムやスタイルガイドの普及により、デザインパーツ、コンポーネントなどを運用することはさほど特別なことではないと思います。 今回のリニューアルでは整備した環境を維持するためにスタンダードな運用にも着手します。こうした取り組みは以前にも行なっていたものの開発チームに明文化されていなかったので、改善を繰りかえし動かしていきたいと思います。 まとめ 今回のリニューアルはバラバラだったデザイントーンに統一感を持たせることでユーザーに使いやすさを担保する、その過程で自分たちにも使いやすいデザインを目指しました。 一般的にはリニューアルではユーザーを中心したものが多いかもしれません。今回はその中に自分たち（開発者）も加味して考え、サービスのミッションの達成のためのプロダクト基本理念を支えられる環境作りを目指しました。 デザインの役割は物事を綺麗にするだけではなく、理念のような根っこの部分に立ち返れる機会や根っこそのものを具現化させる役割を担っていると考えています。とはいえ今回はその第一歩。今後は更に運用方法やコンテンツ設計や導線設計に磨きをかける必要があります。 また進捗があり次第ご報告できればと思います。ここまで読んでいただきありがとうございました。 最後に メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。最近白髪が目立つようになりました。最初は蛍光灯の反射かな？とおもっていましたが実はそうじゃないらしいイケメン担当デザイナーの小山です。 私が担当しているジョブメドレーではサービスの改善をいくつも重ねますがその結果、全体の統一感が薄くなりデザインの改善をすることがあります。 こういった場合、もちろんユーザーの使いやすさを前提にリニューアルを考えますが、 自分たち（開発者）にも使いやすいデザイン はどういう姿か追いながら取り組むように心がけるようにしてみることにしました。 この試みの背景にはサービスの プロダクト基本理念 が関係しています。このエントリでは、先般行ったモバイル向けの求職者画面のデザインリニューアルを通して、プロダクト基本理念に基づいた「自分たちにも使いやすいデザイン」を実現した話をご紹介いたします。 開発工数を増大させるデザイン まず始めにジョブメドレーの求職者画面についてです。これは医療従事者向けの求人を探しているユーザー『求職者』のための画面で、求人の絞り込む検索、求人の詳細情報、職種の情報を発信するブログ、サービスのコンセプト紹介など多彩な情報で構成されています。 メドレーが運営しているサービスの中で最も歴史があり、求職者の希望に見合った求人をスマートに探すことができるように、リニューアルや機能拡充を繰り返しおこなってきました。おかげさまで毎年安定的な成長をとげています。 求職者画面の一部 ただその一方で、リニューアルに対応しきれなかったページも数多くあります。未対応のページは時期を改めて対応するはずでしたが、開発リソースの事情で全て対応できている状態ではありません。 そうした未対応がリニューアルごとに積み重なり、数世代分のデザインパーツが並行運用され、開発の作業効率がなかなか向上できない状況でした。 たとえばボタンやアイコンが同じであったとしても挙動や意味付けにズレが生じていたり、使われているはずがないデザインパーツが全く別の使われ方で存在していたり、全体の把握が追いついていない状況が所々ありました。 これは求職者にとって使い勝手が複雑になる上に、似たようなデザインパーツが増殖されたり誤った使い方をすることで、デザインのルールが曖昧になりエンジニアの作業工数が肥大化していきます。もちろんデザイナーの工数もです。 今回のデザインリニューアルの発端は、ユーザーのために更に使いやすさの改善と、用途が曖昧なデザインパーツの並行運用がもたらす開発上の問題を解決したいということもありました。 プロダクト基本理念に立ち返る 問題を解決するためにどういう方向性が良いか検討するため、まずプロダクト理念まで立ち返ってみました。 ジョブメドレーのプロダクト理念は、各部署が業務を行うための行動指針のようなものです。 プロダクトを一定の品質を保つため、求職者の求職活動を支えるキャリアサポート、事業所の効果的な求人掲載を提案するカスタマーサクセスやクリエイションチーム、これから求人を掲載したい事業所をサポートするセールスチーム、そして開発チームがこのプロダクト理念をもとに動いています。 求人を探すユーザー『求職者』と求人を出すユーザー『事業者』の双方が満足のいく意思決定をするためのこれら３つの理念を核としています。また、その理念を通して実現する サービスのミッション の達成に向かってメンバーは業務を行なっています。デザインパーツもこの理念をもとに制作されています。 ただ前述の通り、求職者画面が理念を守れる万全な状況にあるかというと、そうではありませんでした。必ずしも完璧なデザインが世の中にないように、ジョブメドレーももっと良くしていけるポイントはデザイン面で数多くあり、今回のリニューアルでは、そうした課題解決を目指しました。 さらに進めるにあたり、長期的にプロダクト理念に基づいた開発・デザインが行えるよう「求職者と開発の両方に働きかけられる環境」の整備を行うことにしました。 求職活動だけに集中できる環境 満足のいく意思決定を行う環境は、情報を読むことに悩むよう環境ではなくて、読んだ情報をじっくり考えられる環境だと私は考えています。 これまでのリニューアルで生まれた数世代ぶんの負債のために、字が読みにくいだとか、ボタン押したらどうなるかわからないだとか、そういった本質的ではない部分でつまづかない環境を作りました。 デザイナーがいなくても開発できる環境 いくら見栄えがよくユーザーにとって使い勝手が良かったとしても、それを運用するために開発のコストがかかるのであれば良い UI とは言えません。 使い勝手を維持するために開発を逼迫させ本来コストをかけるべきところに注力できずに別の部分の使い勝手を落とし、結果的にユーザーの不利益や不信感に繋がるかもしれないからです。これは極端な考えかもしれませんが、起こる可能性としては低くはないはずです。 それを解決する方法の１つとしてプロジェクトの関係者が把握できる内容にまでデザインを単純化させることなのではと私は考えています。デザイナーしか把握できないものではなく、むしろデザイナーが関わらなくても把握できるものを目指しました。 エンジニアだけで作れるデザイン 扱いやすいデザインとその意図 今回できたデザインは「普通」です。なるべく特殊はことは避け、デザイナー以外でもわかるデザインを目指しました。またデザインの意図もできる限りシンプルにまとめることに注力しました。 理路整然とした意図でも、それが複雑だとつくった本人しか扱えないものになります。なので聞きなれないワードや表現は控え、真に守らなくてはいけないことを抽出しました。またコンポーネントも限界まで削ぎ落とし最適化しました。 デザインの意図を明文化 把握しやすい数に色を減らす　左がリニューアル前：右がリニューアル後 この過程でプロジェクトでうれしい場面がありました。それはエンジニアさんから新しいデザインがあがったこと。 デザインパーツが足りず追加制作していたところ、既にエンジニアさんがデザイントーンを参考に足りないパーツを製作してくれていました。しかも私のデザインよりも良いもので。。。複雑な心境になりましたが、それぐらいデザインが扱いやすくなっているということでもあるのかなと 自分に言い聞かせました ポジティブに考えるようにしました。 左：私のデザイン　右：エンジニアのデザイン　どう見ても左より右が周囲と喧嘩してない。左はしゃしゃり出る 今回のプロジェクトは UI を綺麗にすることだけじゃなく、それ自体を関係者が扱いやすいものに改善する目的でもあったので、この出来事は当初考えていたこと以上の結果で良かったと思っています。 この要因は単純にルールが簡単で覚えやすかったことなのかもしれません。そうした覚えやすいデザインは学習コストが軽く、まわりめぐってユーザーにも扱いやすいものなると考えています。 デザインを維持できるコンポーネントの運用 昨今ではデザインシステムやスタイルガイドの普及により、デザインパーツ、コンポーネントなどを運用することはさほど特別なことではないと思います。 今回のリニューアルでは整備した環境を維持するためにスタンダードな運用にも着手します。こうした取り組みは以前にも行なっていたものの開発チームに明文化されていなかったので、改善を繰りかえし動かしていきたいと思います。 まとめ 今回のリニューアルはバラバラだったデザイントーンに統一感を持たせることでユーザーに使いやすさを担保する、その過程で自分たちにも使いやすいデザインを目指しました。 一般的にはリニューアルではユーザーを中心したものが多いかもしれません。今回はその中に自分たち（開発者）も加味して考え、サービスのミッションの達成のためのプロダクト基本理念を支えられる環境作りを目指しました。 デザインの役割は物事を綺麗にするだけではなく、理念のような根っこの部分に立ち返れる機会や根っこそのものを具現化させる役割を担っていると考えています。とはいえ今回はその第一歩。今後は更に運用方法やコンテンツ設計や導線設計に磨きをかける必要があります。 また進捗があり次第ご報告できればと思います。ここまで読んでいただきありがとうございました。 最後に メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。最近白髪が目立つようになりました。最初は蛍光灯の反射かな？とおもっていましたが実はそうじゃないらしいイケメン担当デザイナーの小山です。 私が担当しているジョブメドレーではサービスの改善をいくつも重ねますがその結果、全体の統一感が薄くなりデザインの改善をすることがあります。 こういった場合、もちろんユーザーの使いやすさを前提にリニューアルを考えますが、 自分たち（開発者）にも使いやすいデザイン はどういう姿か追いながら取り組むように心がけるようにしてみることにしました。 この試みの背景にはサービスの プロダクト基本理念 が関係しています。このエントリでは、先般行ったモバイル向けの求職者画面のデザインリニューアルを通して、プロダクト基本理念に基づいた「自分たちにも使いやすいデザイン」を実現した話をご紹介いたします。 開発工数を増大させるデザイン まず始めにジョブメドレーの求職者画面についてです。これは医療従事者向けの求人を探しているユーザー『求職者』のための画面で、求人の絞り込む検索、求人の詳細情報、職種の情報を発信するブログ、サービスのコンセプト紹介など多彩な情報で構成されています。 メドレーが運営しているサービスの中で最も歴史があり、求職者の希望に見合った求人をスマートに探すことができるように、リニューアルや機能拡充を繰り返しおこなってきました。おかげさまで毎年安定的な成長をとげています。 求職者画面の一部 ただその一方で、リニューアルに対応しきれなかったページも数多くあります。未対応のページは時期を改めて対応するはずでしたが、開発リソースの事情で全て対応できている状態ではありません。 そうした未対応がリニューアルごとに積み重なり、数世代分のデザインパーツが並行運用され、開発の作業効率がなかなか向上できない状況でした。 たとえばボタンやアイコンが同じであったとしても挙動や意味付けにズレが生じていたり、使われているはずがないデザインパーツが全く別の使われ方で存在していたり、全体の把握が追いついていない状況が所々ありました。 これは求職者にとって使い勝手が複雑になる上に、似たようなデザインパーツが増殖されたり誤った使い方をすることで、デザインのルールが曖昧になりエンジニアの作業工数が肥大化していきます。もちろんデザイナーの工数もです。 今回のデザインリニューアルの発端は、ユーザーのために更に使いやすさの改善と、用途が曖昧なデザインパーツの並行運用がもたらす開発上の問題を解決したいということもありました。 プロダクト基本理念に立ち返る 問題を解決するためにどういう方向性が良いか検討するため、まずプロダクト理念まで立ち返ってみました。 ジョブメドレーのプロダクト理念は、各部署が業務を行うための行動指針のようなものです。 プロダクトを一定の品質を保つため、求職者の求職活動を支えるキャリアサポート、事業所の効果的な求人掲載を提案するカスタマーサクセスやクリエイションチーム、これから求人を掲載したい事業所をサポートするセールスチーム、そして開発チームがこのプロダクト理念をもとに動いています。 求人を探すユーザー『求職者』と求人を出すユーザー『事業者』の双方が満足のいく意思決定をするためのこれら３つの理念を核としています。また、その理念を通して実現する サービスのミッション の達成に向かってメンバーは業務を行なっています。デザインパーツもこの理念をもとに制作されています。 ただ前述の通り、求職者画面が理念を守れる万全な状況にあるかというと、そうではありませんでした。必ずしも完璧なデザインが世の中にないように、ジョブメドレーももっと良くしていけるポイントはデザイン面で数多くあり、今回のリニューアルでは、そうした課題解決を目指しました。 さらに進めるにあたり、長期的にプロダクト理念に基づいた開発・デザインが行えるよう「求職者と開発の両方に働きかけられる環境」の整備を行うことにしました。 求職活動だけに集中できる環境 満足のいく意思決定を行う環境は、情報を読むことに悩むよう環境ではなくて、読んだ情報をじっくり考えられる環境だと私は考えています。 これまでのリニューアルで生まれた数世代ぶんの負債のために、字が読みにくいだとか、ボタン押したらどうなるかわからないだとか、そういった本質的ではない部分でつまづかない環境を作りました。 デザイナーがいなくても開発できる環境 いくら見栄えがよくユーザーにとって使い勝手が良かったとしても、それを運用するために開発のコストがかかるのであれば良い UI とは言えません。 使い勝手を維持するために開発を逼迫させ本来コストをかけるべきところに注力できずに別の部分の使い勝手を落とし、結果的にユーザーの不利益や不信感に繋がるかもしれないからです。これは極端な考えかもしれませんが、起こる可能性としては低くはないはずです。 それを解決する方法の１つとしてプロジェクトの関係者が把握できる内容にまでデザインを単純化させることなのではと私は考えています。デザイナーしか把握できないものではなく、むしろデザイナーが関わらなくても把握できるものを目指しました。 エンジニアだけで作れるデザイン 扱いやすいデザインとその意図 今回できたデザインは「普通」です。なるべく特殊はことは避け、デザイナー以外でもわかるデザインを目指しました。またデザインの意図もできる限りシンプルにまとめることに注力しました。 理路整然とした意図でも、それが複雑だとつくった本人しか扱えないものになります。なので聞きなれないワードや表現は控え、真に守らなくてはいけないことを抽出しました。またコンポーネントも限界まで削ぎ落とし最適化しました。 デザインの意図を明文化 把握しやすい数に色を減らす　左がリニューアル前：右がリニューアル後 この過程でプロジェクトでうれしい場面がありました。それはエンジニアさんから新しいデザインがあがったこと。 デザインパーツが足りず追加制作していたところ、既にエンジニアさんがデザイントーンを参考に足りないパーツを製作してくれていました。しかも私のデザインよりも良いもので。。。複雑な心境になりましたが、それぐらいデザインが扱いやすくなっているということでもあるのかなと 自分に言い聞かせました ポジティブに考えるようにしました。 左：私のデザイン　右：エンジニアのデザイン　どう見ても左より右が周囲と喧嘩してない。左はしゃしゃり出る 今回のプロジェクトは UI を綺麗にすることだけじゃなく、それ自体を関係者が扱いやすいものに改善する目的でもあったので、この出来事は当初考えていたこと以上の結果で良かったと思っています。 この要因は単純にルールが簡単で覚えやすかったことなのかもしれません。そうした覚えやすいデザインは学習コストが軽く、まわりめぐってユーザーにも扱いやすいものなると考えています。 デザインを維持できるコンポーネントの運用 昨今ではデザインシステムやスタイルガイドの普及により、デザインパーツ、コンポーネントなどを運用することはさほど特別なことではないと思います。 今回のリニューアルでは整備した環境を維持するためにスタンダードな運用にも着手します。こうした取り組みは以前にも行なっていたものの開発チームに明文化されていなかったので、改善を繰りかえし動かしていきたいと思います。 まとめ 今回のリニューアルはバラバラだったデザイントーンに統一感を持たせることでユーザーに使いやすさを担保する、その過程で自分たちにも使いやすいデザインを目指しました。 一般的にはリニューアルではユーザーを中心したものが多いかもしれません。今回はその中に自分たち（開発者）も加味して考え、サービスのミッションの達成のためのプロダクト基本理念を支えられる環境作りを目指しました。 デザインの役割は物事を綺麗にするだけではなく、理念のような根っこの部分に立ち返れる機会や根っこそのものを具現化させる役割を担っていると考えています。とはいえ今回はその第一歩。今後は更に運用方法やコンテンツ設計や導線設計に磨きをかける必要があります。 また進捗があり次第ご報告できればと思います。ここまで読んでいただきありがとうございました。 最後に メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部の横尾です。 これまで介護施設の口コミサイト「 介護のほんね 」の立ち上げや医療介護の人材採用システム「 ジョブメドレー 」のディレクター・コンテンツ編集などを経験し、現在はオンライン診療アプリ「 CLINICS（クリニクス） 」のディレクターをしています。 CLINICS では、慎重さとスピード感を両立して開発できるよう、3 つの習慣を取り入れています。半年ほど実施してみて手法としてまとまってきましたので、ブログでも紹介させていただきます。 背景 CLINICS は、スマートフォンや PC からビデオチャットでかかりつけ医の診察を受けられるオンライン診療アプリです。医療機関向けにはブラウザで予約管理や問診、診察、会計を行うことができる機能も提供しています。CLINICS を開発する際は、医療に関するプロダクトゆえに特に意識しなければいけない点がいくつかあります。 一つは人の命に関わるということ。オンライン診療は症状の落ち着いている方が対象となりますが、少しの使いにくさやミスも誰かの生命・生活に何らか影響するかもしれない緊張感が常にあります。 もう一つは、老若男女幅広く使われていること。病院にかかったことのない人はほとんどいないように、さまざまな人が CLINICS を利用しているので、どんな人でも不安なくスムーズに使えることが重要になってきます。 このような背景から、CLINICS では 慎重にゴールを設定し、丁寧に検証しながら開発を進める必要があります 。一方で、あまりに 慎重・丁寧すぎても何もできなかったり迷走したりしてスピード感を失いかねません 。そこで、両者のバランスをうまく取り開発を推進するために次の 3 つを行っています。 CLINICS 開発をうまく進める 3 つの習慣 1. プロダクトプリンシプルを共有する プロダクトプリンシプルは、 サービスとしてのやること・やらないことを簡潔に言語化 したものです。 例えば CLINICS のプロダクトプリンシプルには「1UU の重み、活用率 100%を目指すこだわり：一人の人の命を預かっているという使命感を持ち、一人でも多くの人が使え、今まで使えていた人が使えなくなることが一人でもないようにする」というフレーズがあります。 前述の通り、CLINICS は人の命に関わるプロダクトであり老若男女幅広く使われています。そのためあえてターゲットを絞らず、すべての人が使えるプロダクトを目指していることをこのフレーズで共有しています。これにより、施策検討段階では一部の人にとってとても使いやすいが使いこなせない人がいる UI と、ほぼすべての人がそこそこ使える UI があった時、私たちは迷わず後者を選択でき、すぐに実装に取り掛かることができます。 プロダクトプリンシプルの作成にあたっては、日頃寄せられる患者の声・医療機関の声をよく聞き、医療の成り立ちや医療業界の構造なども深いところまで学習するようにしました。患者にとって、医療機関にとって、そして社会にとってのあるべきプロダクト像を理念として映し出すようにしています。 2. 年間・四半期ごとのロードマップを策定する ロードマップは、 いつ頃どんな課題に取り組むのかを概ね年間・四半期ごとに定めたもの です。こちらは比較的多くの開発現場で取り入れられている方法ではないでしょうか。 ロードマップをチームで意識するようにすると、先々に開発・リリースする機能を一人ひとりが理解でき、先回りして技術調査を進めたり関連する施策の効果分析の優先度を上げたりといったことができます。また、営業チームなど社内のほかの部署から開発提案があった際にはロードマップを見ながら今後の見通しを案内できるようになり、 他チームのメンバーからの信頼を得ながら開発に専念することができます。 ロードマップを策定する際は、プロダクトプリンシプルを開発内容として落とし込みつつ、事業として伸ばすべき数値や直近で解決すべきお問い合わせなども考慮するようにしています。また、四半期ごとに KPT 法を使ってロードマップを振り返り、開発の期間や体制を見直すようにしています。 3. 週次で計画し、日次で進捗を追う 週次の計画と日次の進捗確認には、 スタンディングミーティング を行っています。 CLINICS では GitHub のプロジェクト機能を使ってカンバンを作成しています。任意のタイミングでロードマップで挙げた課題をだいたい 1 週間程度で区切りのつくサイズの issue に落とし込み、カンバンの backlog にセットします。毎週月曜日の午前中に週次定例を行い、その週に着手する issue を backlog から in progress に移します。火曜以降は毎日 issue ごとに進捗を確認し、終わったものを done に移していきます。 このように週次・日次で計画と進捗確認を細かく繰り返すことで、一つひとつの issue をスピーディに進めるリズムができます。ミーティング時点で一つの issue も進んでいないということがないようにしようという意識が働き、個々人のパフォーマンスもアップします。 まとめ 今回は、開発推進のために CLINICS で取り入れている習慣をご紹介しました。 この 3 つの習慣は、 どれか 1 つのみを行うのでもだめで、3 つセットで実施することが今の CLINICS 開発のカギ になっています。プロダクトプリンシプルだけでは理想論のように思えたことも、ロードマップや計画になるとより具体的になって着手しやすくなり、また、計画で示しきれない改善の方向性はプロダクトプリンシプルに立ち返ることでお互いの認識をそろえやすくなります。 そうすれば不必要なルールの制定や社内コミュニケーションから解放され、日々やるべきことに集中でき、 結果的により早くより優れたプロダクトをユーザーに届けることができる と考えています。 メドレーでは、こうした様々な手法を取り入れながら新しい医療体験を提供するプロダクトを、一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ www.medley.jp www.medley.jp

こんにちは、開発本部の横尾です。 これまで介護施設の口コミサイト「 介護のほんね 」の立ち上げや医療介護の人材採用システム「 ジョブメドレー 」のディレクター・コンテンツ編集などを経験し、現在はオンライン診療アプリ「 CLINICS（クリニクス） 」のディレクターをしています。 CLINICS では、慎重さとスピード感を両立して開発できるよう、3 つの習慣を取り入れています。半年ほど実施してみて手法としてまとまってきましたので、ブログでも紹介させていただきます。 背景 CLINICS は、スマートフォンや PC からビデオチャットでかかりつけ医の診察を受けられるオンライン診療アプリです。医療機関向けにはブラウザで予約管理や問診、診察、会計を行うことができる機能も提供しています。CLINICS を開発する際は、医療に関するプロダクトゆえに特に意識しなければいけない点がいくつかあります。 一つは人の命に関わるということ。オンライン診療は症状の落ち着いている方が対象となりますが、少しの使いにくさやミスも誰かの生命・生活に何らか影響するかもしれない緊張感が常にあります。 もう一つは、老若男女幅広く使われていること。病院にかかったことのない人はほとんどいないように、さまざまな人が CLINICS を利用しているので、どんな人でも不安なくスムーズに使えることが重要になってきます。 このような背景から、CLINICS では 慎重にゴールを設定し、丁寧に検証しながら開発を進める必要があります 。一方で、あまりに 慎重・丁寧すぎても何もできなかったり迷走したりしてスピード感を失いかねません 。そこで、両者のバランスをうまく取り開発を推進するために次の 3 つを行っています。 CLINICS 開発をうまく進める 3 つの習慣 1. プロダクトプリンシプルを共有する プロダクトプリンシプルは、 サービスとしてのやること・やらないことを簡潔に言語化 したものです。 例えば CLINICS のプロダクトプリンシプルには「1UU の重み、活用率 100%を目指すこだわり：一人の人の命を預かっているという使命感を持ち、一人でも多くの人が使え、今まで使えていた人が使えなくなることが一人でもないようにする」というフレーズがあります。 前述の通り、CLINICS は人の命に関わるプロダクトであり老若男女幅広く使われています。そのためあえてターゲットを絞らず、すべての人が使えるプロダクトを目指していることをこのフレーズで共有しています。これにより、施策検討段階では一部の人にとってとても使いやすいが使いこなせない人がいる UI と、ほぼすべての人がそこそこ使える UI があった時、私たちは迷わず後者を選択でき、すぐに実装に取り掛かることができます。 プロダクトプリンシプルの作成にあたっては、日頃寄せられる患者の声・医療機関の声をよく聞き、医療の成り立ちや医療業界の構造なども深いところまで学習するようにしました。患者にとって、医療機関にとって、そして社会にとってのあるべきプロダクト像を理念として映し出すようにしています。 2. 年間・四半期ごとのロードマップを策定する ロードマップは、 いつ頃どんな課題に取り組むのかを概ね年間・四半期ごとに定めたもの です。こちらは比較的多くの開発現場で取り入れられている方法ではないでしょうか。 ロードマップをチームで意識するようにすると、先々に開発・リリースする機能を一人ひとりが理解でき、先回りして技術調査を進めたり関連する施策の効果分析の優先度を上げたりといったことができます。また、営業チームなど社内のほかの部署から開発提案があった際にはロードマップを見ながら今後の見通しを案内できるようになり、 他チームのメンバーからの信頼を得ながら開発に専念することができます。 ロードマップを策定する際は、プロダクトプリンシプルを開発内容として落とし込みつつ、事業として伸ばすべき数値や直近で解決すべきお問い合わせなども考慮するようにしています。また、四半期ごとに KPT 法を使ってロードマップを振り返り、開発の期間や体制を見直すようにしています。 3. 週次で計画し、日次で進捗を追う 週次の計画と日次の進捗確認には、 スタンディングミーティング を行っています。 CLINICS では GitHub のプロジェクト機能を使ってカンバンを作成しています。任意のタイミングでロードマップで挙げた課題をだいたい 1 週間程度で区切りのつくサイズの issue に落とし込み、カンバンの backlog にセットします。毎週月曜日の午前中に週次定例を行い、その週に着手する issue を backlog から in progress に移します。火曜以降は毎日 issue ごとに進捗を確認し、終わったものを done に移していきます。 このように週次・日次で計画と進捗確認を細かく繰り返すことで、一つひとつの issue をスピーディに進めるリズムができます。ミーティング時点で一つの issue も進んでいないということがないようにしようという意識が働き、個々人のパフォーマンスもアップします。 まとめ 今回は、開発推進のために CLINICS で取り入れている習慣をご紹介しました。 この 3 つの習慣は、 どれか 1 つのみを行うのでもだめで、3 つセットで実施することが今の CLINICS 開発のカギ になっています。プロダクトプリンシプルだけでは理想論のように思えたことも、ロードマップや計画になるとより具体的になって着手しやすくなり、また、計画で示しきれない改善の方向性はプロダクトプリンシプルに立ち返ることでお互いの認識をそろえやすくなります。 そうすれば不必要なルールの制定や社内コミュニケーションから解放され、日々やるべきことに集中でき、 結果的により早くより優れたプロダクトをユーザーに届けることができる と考えています。 メドレーでは、こうした様々な手法を取り入れながら新しい医療体験を提供するプロダクトを、一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ www.medley.jp www.medley.jp

こんにちは、開発本部の横尾です。 これまで介護施設の口コミサイト「 介護のほんね 」の立ち上げや医療介護の人材採用システム「 ジョブメドレー 」のディレクター・コンテンツ編集などを経験し、現在はオンライン診療アプリ「 CLINICS（クリニクス） 」のディレクターをしています。 CLINICS では、慎重さとスピード感を両立して開発できるよう、3 つの習慣を取り入れています。半年ほど実施してみて手法としてまとまってきましたので、ブログでも紹介させていただきます。 背景 CLINICS は、スマートフォンや PC からビデオチャットでかかりつけ医の診察を受けられるオンライン診療アプリです。医療機関向けにはブラウザで予約管理や問診、診察、会計を行うことができる機能も提供しています。CLINICS を開発する際は、医療に関するプロダクトゆえに特に意識しなければいけない点がいくつかあります。 一つは人の命に関わるということ。オンライン診療は症状の落ち着いている方が対象となりますが、少しの使いにくさやミスも誰かの生命・生活に何らか影響するかもしれない緊張感が常にあります。 もう一つは、老若男女幅広く使われていること。病院にかかったことのない人はほとんどいないように、さまざまな人が CLINICS を利用しているので、どんな人でも不安なくスムーズに使えることが重要になってきます。 このような背景から、CLINICS では 慎重にゴールを設定し、丁寧に検証しながら開発を進める必要があります 。一方で、あまりに 慎重・丁寧すぎても何もできなかったり迷走したりしてスピード感を失いかねません 。そこで、両者のバランスをうまく取り開発を推進するために次の 3 つを行っています。 CLINICS 開発をうまく進める 3 つの習慣 1. プロダクトプリンシプルを共有する プロダクトプリンシプルは、 サービスとしてのやること・やらないことを簡潔に言語化 したものです。 例えば CLINICS のプロダクトプリンシプルには「1UU の重み、活用率 100%を目指すこだわり：一人の人の命を預かっているという使命感を持ち、一人でも多くの人が使え、今まで使えていた人が使えなくなることが一人でもないようにする」というフレーズがあります。 前述の通り、CLINICS は人の命に関わるプロダクトであり老若男女幅広く使われています。そのためあえてターゲットを絞らず、すべての人が使えるプロダクトを目指していることをこのフレーズで共有しています。これにより、施策検討段階では一部の人にとってとても使いやすいが使いこなせない人がいる UI と、ほぼすべての人がそこそこ使える UI があった時、私たちは迷わず後者を選択でき、すぐに実装に取り掛かることができます。 プロダクトプリンシプルの作成にあたっては、日頃寄せられる患者の声・医療機関の声をよく聞き、医療の成り立ちや医療業界の構造なども深いところまで学習するようにしました。患者にとって、医療機関にとって、そして社会にとってのあるべきプロダクト像を理念として映し出すようにしています。 2. 年間・四半期ごとのロードマップを策定する ロードマップは、 いつ頃どんな課題に取り組むのかを概ね年間・四半期ごとに定めたもの です。こちらは比較的多くの開発現場で取り入れられている方法ではないでしょうか。 ロードマップをチームで意識するようにすると、先々に開発・リリースする機能を一人ひとりが理解でき、先回りして技術調査を進めたり関連する施策の効果分析の優先度を上げたりといったことができます。また、営業チームなど社内のほかの部署から開発提案があった際にはロードマップを見ながら今後の見通しを案内できるようになり、 他チームのメンバーからの信頼を得ながら開発に専念することができます。 ロードマップを策定する際は、プロダクトプリンシプルを開発内容として落とし込みつつ、事業として伸ばすべき数値や直近で解決すべきお問い合わせなども考慮するようにしています。また、四半期ごとに KPT 法を使ってロードマップを振り返り、開発の期間や体制を見直すようにしています。 3. 週次で計画し、日次で進捗を追う 週次の計画と日次の進捗確認には、 スタンディングミーティング を行っています。 CLINICS では GitHub のプロジェクト機能を使ってカンバンを作成しています。任意のタイミングでロードマップで挙げた課題をだいたい 1 週間程度で区切りのつくサイズの issue に落とし込み、カンバンの backlog にセットします。毎週月曜日の午前中に週次定例を行い、その週に着手する issue を backlog から in progress に移します。火曜以降は毎日 issue ごとに進捗を確認し、終わったものを done に移していきます。 このように週次・日次で計画と進捗確認を細かく繰り返すことで、一つひとつの issue をスピーディに進めるリズムができます。ミーティング時点で一つの issue も進んでいないということがないようにしようという意識が働き、個々人のパフォーマンスもアップします。 まとめ 今回は、開発推進のために CLINICS で取り入れている習慣をご紹介しました。 この 3 つの習慣は、 どれか 1 つのみを行うのでもだめで、3 つセットで実施することが今の CLINICS 開発のカギ になっています。プロダクトプリンシプルだけでは理想論のように思えたことも、ロードマップや計画になるとより具体的になって着手しやすくなり、また、計画で示しきれない改善の方向性はプロダクトプリンシプルに立ち返ることでお互いの認識をそろえやすくなります。 そうすれば不必要なルールの制定や社内コミュニケーションから解放され、日々やるべきことに集中でき、 結果的により早くより優れたプロダクトをユーザーに届けることができる と考えています。 メドレーでは、こうした様々な手法を取り入れながら新しい医療体験を提供するプロダクトを、一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ www.medley.jp www.medley.jp

こんにちは、開発本部の横尾です。 これまで介護施設の口コミサイト「 介護のほんね 」の立ち上げや医療介護の人材採用システム「 ジョブメドレー 」のディレクター・コンテンツ編集などを経験し、現在はオンライン診療アプリ「 CLINICS（クリニクス） 」のディレクターをしています。 CLINICS では、慎重さとスピード感を両立して開発できるよう、3 つの習慣を取り入れています。半年ほど実施してみて手法としてまとまってきましたので、ブログでも紹介させていただきます。 背景 CLINICS は、スマートフォンや PC からビデオチャットでかかりつけ医の診察を受けられるオンライン診療アプリです。医療機関向けにはブラウザで予約管理や問診、診察、会計を行うことができる機能も提供しています。CLINICS を開発する際は、医療に関するプロダクトゆえに特に意識しなければいけない点がいくつかあります。 一つは人の命に関わるということ。オンライン診療は症状の落ち着いている方が対象となりますが、少しの使いにくさやミスも誰かの生命・生活に何らか影響するかもしれない緊張感が常にあります。 もう一つは、老若男女幅広く使われていること。病院にかかったことのない人はほとんどいないように、さまざまな人が CLINICS を利用しているので、どんな人でも不安なくスムーズに使えることが重要になってきます。 このような背景から、CLINICS では 慎重にゴールを設定し、丁寧に検証しながら開発を進める必要があります 。一方で、あまりに 慎重・丁寧すぎても何もできなかったり迷走したりしてスピード感を失いかねません 。そこで、両者のバランスをうまく取り開発を推進するために次の 3 つを行っています。 CLINICS 開発をうまく進める 3 つの習慣 1. プロダクトプリンシプルを共有する プロダクトプリンシプルは、 サービスとしてのやること・やらないことを簡潔に言語化 したものです。 例えば CLINICS のプロダクトプリンシプルには「1UU の重み、活用率 100%を目指すこだわり：一人の人の命を預かっているという使命感を持ち、一人でも多くの人が使え、今まで使えていた人が使えなくなることが一人でもないようにする」というフレーズがあります。 前述の通り、CLINICS は人の命に関わるプロダクトであり老若男女幅広く使われています。そのためあえてターゲットを絞らず、すべての人が使えるプロダクトを目指していることをこのフレーズで共有しています。これにより、施策検討段階では一部の人にとってとても使いやすいが使いこなせない人がいる UI と、ほぼすべての人がそこそこ使える UI があった時、私たちは迷わず後者を選択でき、すぐに実装に取り掛かることができます。 プロダクトプリンシプルの作成にあたっては、日頃寄せられる患者の声・医療機関の声をよく聞き、医療の成り立ちや医療業界の構造なども深いところまで学習するようにしました。患者にとって、医療機関にとって、そして社会にとってのあるべきプロダクト像を理念として映し出すようにしています。 2. 年間・四半期ごとのロードマップを策定する ロードマップは、 いつ頃どんな課題に取り組むのかを概ね年間・四半期ごとに定めたもの です。こちらは比較的多くの開発現場で取り入れられている方法ではないでしょうか。 ロードマップをチームで意識するようにすると、先々に開発・リリースする機能を一人ひとりが理解でき、先回りして技術調査を進めたり関連する施策の効果分析の優先度を上げたりといったことができます。また、営業チームなど社内のほかの部署から開発提案があった際にはロードマップを見ながら今後の見通しを案内できるようになり、 他チームのメンバーからの信頼を得ながら開発に専念することができます。 ロードマップを策定する際は、プロダクトプリンシプルを開発内容として落とし込みつつ、事業として伸ばすべき数値や直近で解決すべきお問い合わせなども考慮するようにしています。また、四半期ごとに KPT 法を使ってロードマップを振り返り、開発の期間や体制を見直すようにしています。 3. 週次で計画し、日次で進捗を追う 週次の計画と日次の進捗確認には、 スタンディングミーティング を行っています。 CLINICS では GitHub のプロジェクト機能を使ってカンバンを作成しています。任意のタイミングでロードマップで挙げた課題をだいたい 1 週間程度で区切りのつくサイズの issue に落とし込み、カンバンの backlog にセットします。毎週月曜日の午前中に週次定例を行い、その週に着手する issue を backlog から in progress に移します。火曜以降は毎日 issue ごとに進捗を確認し、終わったものを done に移していきます。 このように週次・日次で計画と進捗確認を細かく繰り返すことで、一つひとつの issue をスピーディに進めるリズムができます。ミーティング時点で一つの issue も進んでいないということがないようにしようという意識が働き、個々人のパフォーマンスもアップします。 まとめ 今回は、開発推進のために CLINICS で取り入れている習慣をご紹介しました。 この 3 つの習慣は、 どれか 1 つのみを行うのでもだめで、3 つセットで実施することが今の CLINICS 開発のカギ になっています。プロダクトプリンシプルだけでは理想論のように思えたことも、ロードマップや計画になるとより具体的になって着手しやすくなり、また、計画で示しきれない改善の方向性はプロダクトプリンシプルに立ち返ることでお互いの認識をそろえやすくなります。 そうすれば不必要なルールの制定や社内コミュニケーションから解放され、日々やるべきことに集中でき、 結果的により早くより優れたプロダクトをユーザーに届けることができる と考えています。 メドレーでは、こうした様々な手法を取り入れながら新しい医療体験を提供するプロダクトを、一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ www.medley.jp www.medley.jp

こんにちは、開発本部の横尾です。 これまで介護施設の口コミサイト「 介護のほんね 」の立ち上げや医療介護の人材採用システム「 ジョブメドレー 」のディレクター・コンテンツ編集などを経験し、現在はオンライン診療アプリ「 CLINICS（クリニクス） 」のディレクターをしています。 CLINICS では、慎重さとスピード感を両立して開発できるよう、3 つの習慣を取り入れています。半年ほど実施してみて手法としてまとまってきましたので、ブログでも紹介させていただきます。 背景 CLINICS は、スマートフォンや PC からビデオチャットでかかりつけ医の診察を受けられるオンライン診療アプリです。医療機関向けにはブラウザで予約管理や問診、診察、会計を行うことができる機能も提供しています。CLINICS を開発する際は、医療に関するプロダクトゆえに特に意識しなければいけない点がいくつかあります。 一つは人の命に関わるということ。オンライン診療は症状の落ち着いている方が対象となりますが、少しの使いにくさやミスも誰かの生命・生活に何らか影響するかもしれない緊張感が常にあります。 もう一つは、老若男女幅広く使われていること。病院にかかったことのない人はほとんどいないように、さまざまな人が CLINICS を利用しているので、どんな人でも不安なくスムーズに使えることが重要になってきます。 このような背景から、CLINICS では 慎重にゴールを設定し、丁寧に検証しながら開発を進める必要があります 。一方で、あまりに 慎重・丁寧すぎても何もできなかったり迷走したりしてスピード感を失いかねません 。そこで、両者のバランスをうまく取り開発を推進するために次の 3 つを行っています。 CLINICS 開発をうまく進める 3 つの習慣 1. プロダクトプリンシプルを共有する プロダクトプリンシプルは、 サービスとしてのやること・やらないことを簡潔に言語化 したものです。 例えば CLINICS のプロダクトプリンシプルには「1UU の重み、活用率 100%を目指すこだわり：一人の人の命を預かっているという使命感を持ち、一人でも多くの人が使え、今まで使えていた人が使えなくなることが一人でもないようにする」というフレーズがあります。 前述の通り、CLINICS は人の命に関わるプロダクトであり老若男女幅広く使われています。そのためあえてターゲットを絞らず、すべての人が使えるプロダクトを目指していることをこのフレーズで共有しています。これにより、施策検討段階では一部の人にとってとても使いやすいが使いこなせない人がいる UI と、ほぼすべての人がそこそこ使える UI があった時、私たちは迷わず後者を選択でき、すぐに実装に取り掛かることができます。 プロダクトプリンシプルの作成にあたっては、日頃寄せられる患者の声・医療機関の声をよく聞き、医療の成り立ちや医療業界の構造なども深いところまで学習するようにしました。患者にとって、医療機関にとって、そして社会にとってのあるべきプロダクト像を理念として映し出すようにしています。 2. 年間・四半期ごとのロードマップを策定する ロードマップは、 いつ頃どんな課題に取り組むのかを概ね年間・四半期ごとに定めたもの です。こちらは比較的多くの開発現場で取り入れられている方法ではないでしょうか。 ロードマップをチームで意識するようにすると、先々に開発・リリースする機能を一人ひとりが理解でき、先回りして技術調査を進めたり関連する施策の効果分析の優先度を上げたりといったことができます。また、営業チームなど社内のほかの部署から開発提案があった際にはロードマップを見ながら今後の見通しを案内できるようになり、 他チームのメンバーからの信頼を得ながら開発に専念することができます。 ロードマップを策定する際は、プロダクトプリンシプルを開発内容として落とし込みつつ、事業として伸ばすべき数値や直近で解決すべきお問い合わせなども考慮するようにしています。また、四半期ごとに KPT 法を使ってロードマップを振り返り、開発の期間や体制を見直すようにしています。 3. 週次で計画し、日次で進捗を追う 週次の計画と日次の進捗確認には、 スタンディングミーティング を行っています。 CLINICS では GitHub のプロジェクト機能を使ってカンバンを作成しています。任意のタイミングでロードマップで挙げた課題をだいたい 1 週間程度で区切りのつくサイズの issue に落とし込み、カンバンの backlog にセットします。毎週月曜日の午前中に週次定例を行い、その週に着手する issue を backlog から in progress に移します。火曜以降は毎日 issue ごとに進捗を確認し、終わったものを done に移していきます。 このように週次・日次で計画と進捗確認を細かく繰り返すことで、一つひとつの issue をスピーディに進めるリズムができます。ミーティング時点で一つの issue も進んでいないということがないようにしようという意識が働き、個々人のパフォーマンスもアップします。 まとめ 今回は、開発推進のために CLINICS で取り入れている習慣をご紹介しました。 この 3 つの習慣は、 どれか 1 つのみを行うのでもだめで、3 つセットで実施することが今の CLINICS 開発のカギ になっています。プロダクトプリンシプルだけでは理想論のように思えたことも、ロードマップや計画になるとより具体的になって着手しやすくなり、また、計画で示しきれない改善の方向性はプロダクトプリンシプルに立ち返ることでお互いの認識をそろえやすくなります。 そうすれば不必要なルールの制定や社内コミュニケーションから解放され、日々やるべきことに集中でき、 結果的により早くより優れたプロダクトをユーザーに届けることができる と考えています。 メドレーでは、こうした様々な手法を取り入れながら新しい医療体験を提供するプロダクトを、一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ www.medley.jp www.medley.jp

こんにちは、開発本部の横尾です。 これまで介護施設の口コミサイト「 介護のほんね 」の立ち上げや医療介護の人材採用システム「 ジョブメドレー 」のディレクター・コンテンツ編集などを経験し、現在はオンライン診療アプリ「 CLINICS（クリニクス） 」のディレクターをしています。 CLINICS では、慎重さとスピード感を両立して開発できるよう、3 つの習慣を取り入れています。半年ほど実施してみて手法としてまとまってきましたので、ブログでも紹介させていただきます。 背景 CLINICS は、スマートフォンや PC からビデオチャットでかかりつけ医の診察を受けられるオンライン診療アプリです。医療機関向けにはブラウザで予約管理や問診、診察、会計を行うことができる機能も提供しています。CLINICS を開発する際は、医療に関するプロダクトゆえに特に意識しなければいけない点がいくつかあります。 一つは人の命に関わるということ。オンライン診療は症状の落ち着いている方が対象となりますが、少しの使いにくさやミスも誰かの生命・生活に何らか影響するかもしれない緊張感が常にあります。 もう一つは、老若男女幅広く使われていること。病院にかかったことのない人はほとんどいないように、さまざまな人が CLINICS を利用しているので、どんな人でも不安なくスムーズに使えることが重要になってきます。 このような背景から、CLINICS では 慎重にゴールを設定し、丁寧に検証しながら開発を進める必要があります 。一方で、あまりに 慎重・丁寧すぎても何もできなかったり迷走したりしてスピード感を失いかねません 。そこで、両者のバランスをうまく取り開発を推進するために次の 3 つを行っています。 CLINICS 開発をうまく進める 3 つの習慣 1. プロダクトプリンシプルを共有する プロダクトプリンシプルは、 サービスとしてのやること・やらないことを簡潔に言語化 したものです。 例えば CLINICS のプロダクトプリンシプルには「1UU の重み、活用率 100%を目指すこだわり：一人の人の命を預かっているという使命感を持ち、一人でも多くの人が使え、今まで使えていた人が使えなくなることが一人でもないようにする」というフレーズがあります。 前述の通り、CLINICS は人の命に関わるプロダクトであり老若男女幅広く使われています。そのためあえてターゲットを絞らず、すべての人が使えるプロダクトを目指していることをこのフレーズで共有しています。これにより、施策検討段階では一部の人にとってとても使いやすいが使いこなせない人がいる UI と、ほぼすべての人がそこそこ使える UI があった時、私たちは迷わず後者を選択でき、すぐに実装に取り掛かることができます。 プロダクトプリンシプルの作成にあたっては、日頃寄せられる患者の声・医療機関の声をよく聞き、医療の成り立ちや医療業界の構造なども深いところまで学習するようにしました。患者にとって、医療機関にとって、そして社会にとってのあるべきプロダクト像を理念として映し出すようにしています。 2. 年間・四半期ごとのロードマップを策定する ロードマップは、 いつ頃どんな課題に取り組むのかを概ね年間・四半期ごとに定めたもの です。こちらは比較的多くの開発現場で取り入れられている方法ではないでしょうか。 ロードマップをチームで意識するようにすると、先々に開発・リリースする機能を一人ひとりが理解でき、先回りして技術調査を進めたり関連する施策の効果分析の優先度を上げたりといったことができます。また、営業チームなど社内のほかの部署から開発提案があった際にはロードマップを見ながら今後の見通しを案内できるようになり、 他チームのメンバーからの信頼を得ながら開発に専念することができます。 ロードマップを策定する際は、プロダクトプリンシプルを開発内容として落とし込みつつ、事業として伸ばすべき数値や直近で解決すべきお問い合わせなども考慮するようにしています。また、四半期ごとに KPT 法を使ってロードマップを振り返り、開発の期間や体制を見直すようにしています。 3. 週次で計画し、日次で進捗を追う 週次の計画と日次の進捗確認には、 スタンディングミーティング を行っています。 CLINICS では GitHub のプロジェクト機能を使ってカンバンを作成しています。任意のタイミングでロードマップで挙げた課題をだいたい 1 週間程度で区切りのつくサイズの issue に落とし込み、カンバンの backlog にセットします。毎週月曜日の午前中に週次定例を行い、その週に着手する issue を backlog から in progress に移します。火曜以降は毎日 issue ごとに進捗を確認し、終わったものを done に移していきます。 このように週次・日次で計画と進捗確認を細かく繰り返すことで、一つひとつの issue をスピーディに進めるリズムができます。ミーティング時点で一つの issue も進んでいないということがないようにしようという意識が働き、個々人のパフォーマンスもアップします。 まとめ 今回は、開発推進のために CLINICS で取り入れている習慣をご紹介しました。 この 3 つの習慣は、 どれか 1 つのみを行うのでもだめで、3 つセットで実施することが今の CLINICS 開発のカギ になっています。プロダクトプリンシプルだけでは理想論のように思えたことも、ロードマップや計画になるとより具体的になって着手しやすくなり、また、計画で示しきれない改善の方向性はプロダクトプリンシプルに立ち返ることでお互いの認識をそろえやすくなります。 そうすれば不必要なルールの制定や社内コミュニケーションから解放され、日々やるべきことに集中でき、 結果的により早くより優れたプロダクトをユーザーに届けることができる と考えています。 メドレーでは、こうした様々な手法を取り入れながら新しい医療体験を提供するプロダクトを、一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ www.medley.jp www.medley.jp

こんにちは、開発本部の横尾です。 これまで介護施設の口コミサイト「 介護のほんね 」の立ち上げや医療介護の人材採用システム「 ジョブメドレー 」のディレクター・コンテンツ編集などを経験し、現在はオンライン診療アプリ「 CLINICS（クリニクス） 」のディレクターをしています。 CLINICS では、慎重さとスピード感を両立して開発できるよう、3 つの習慣を取り入れています。半年ほど実施してみて手法としてまとまってきましたので、ブログでも紹介させていただきます。 背景 CLINICS は、スマートフォンや PC からビデオチャットでかかりつけ医の診察を受けられるオンライン診療アプリです。医療機関向けにはブラウザで予約管理や問診、診察、会計を行うことができる機能も提供しています。CLINICS を開発する際は、医療に関するプロダクトゆえに特に意識しなければいけない点がいくつかあります。 一つは人の命に関わるということ。オンライン診療は症状の落ち着いている方が対象となりますが、少しの使いにくさやミスも誰かの生命・生活に何らか影響するかもしれない緊張感が常にあります。 もう一つは、老若男女幅広く使われていること。病院にかかったことのない人はほとんどいないように、さまざまな人が CLINICS を利用しているので、どんな人でも不安なくスムーズに使えることが重要になってきます。 このような背景から、CLINICS では 慎重にゴールを設定し、丁寧に検証しながら開発を進める必要があります 。一方で、あまりに 慎重・丁寧すぎても何もできなかったり迷走したりしてスピード感を失いかねません 。そこで、両者のバランスをうまく取り開発を推進するために次の 3 つを行っています。 CLINICS 開発をうまく進める 3 つの習慣 1. プロダクトプリンシプルを共有する プロダクトプリンシプルは、 サービスとしてのやること・やらないことを簡潔に言語化 したものです。 例えば CLINICS のプロダクトプリンシプルには「1UU の重み、活用率 100%を目指すこだわり：一人の人の命を預かっているという使命感を持ち、一人でも多くの人が使え、今まで使えていた人が使えなくなることが一人でもないようにする」というフレーズがあります。 前述の通り、CLINICS は人の命に関わるプロダクトであり老若男女幅広く使われています。そのためあえてターゲットを絞らず、すべての人が使えるプロダクトを目指していることをこのフレーズで共有しています。これにより、施策検討段階では一部の人にとってとても使いやすいが使いこなせない人がいる UI と、ほぼすべての人がそこそこ使える UI があった時、私たちは迷わず後者を選択でき、すぐに実装に取り掛かることができます。 プロダクトプリンシプルの作成にあたっては、日頃寄せられる患者の声・医療機関の声をよく聞き、医療の成り立ちや医療業界の構造なども深いところまで学習するようにしました。患者にとって、医療機関にとって、そして社会にとってのあるべきプロダクト像を理念として映し出すようにしています。 2. 年間・四半期ごとのロードマップを策定する ロードマップは、 いつ頃どんな課題に取り組むのかを概ね年間・四半期ごとに定めたもの です。こちらは比較的多くの開発現場で取り入れられている方法ではないでしょうか。 ロードマップをチームで意識するようにすると、先々に開発・リリースする機能を一人ひとりが理解でき、先回りして技術調査を進めたり関連する施策の効果分析の優先度を上げたりといったことができます。また、営業チームなど社内のほかの部署から開発提案があった際にはロードマップを見ながら今後の見通しを案内できるようになり、 他チームのメンバーからの信頼を得ながら開発に専念することができます。 ロードマップを策定する際は、プロダクトプリンシプルを開発内容として落とし込みつつ、事業として伸ばすべき数値や直近で解決すべきお問い合わせなども考慮するようにしています。また、四半期ごとに KPT 法を使ってロードマップを振り返り、開発の期間や体制を見直すようにしています。 3. 週次で計画し、日次で進捗を追う 週次の計画と日次の進捗確認には、 スタンディングミーティング を行っています。 CLINICS では GitHub のプロジェクト機能を使ってカンバンを作成しています。任意のタイミングでロードマップで挙げた課題をだいたい 1 週間程度で区切りのつくサイズの issue に落とし込み、カンバンの backlog にセットします。毎週月曜日の午前中に週次定例を行い、その週に着手する issue を backlog から in progress に移します。火曜以降は毎日 issue ごとに進捗を確認し、終わったものを done に移していきます。 このように週次・日次で計画と進捗確認を細かく繰り返すことで、一つひとつの issue をスピーディに進めるリズムができます。ミーティング時点で一つの issue も進んでいないということがないようにしようという意識が働き、個々人のパフォーマンスもアップします。 まとめ 今回は、開発推進のために CLINICS で取り入れている習慣をご紹介しました。 この 3 つの習慣は、 どれか 1 つのみを行うのでもだめで、3 つセットで実施することが今の CLINICS 開発のカギ になっています。プロダクトプリンシプルだけでは理想論のように思えたことも、ロードマップや計画になるとより具体的になって着手しやすくなり、また、計画で示しきれない改善の方向性はプロダクトプリンシプルに立ち返ることでお互いの認識をそろえやすくなります。 そうすれば不必要なルールの制定や社内コミュニケーションから解放され、日々やるべきことに集中でき、 結果的により早くより優れたプロダクトをユーザーに届けることができる と考えています。 メドレーでは、こうした様々な手法を取り入れながら新しい医療体験を提供するプロダクトを、一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ www.medley.jp www.medley.jp

こんにちは、開発本部の横尾です。 これまで介護施設の口コミサイト「 介護のほんね 」の立ち上げや医療介護の人材採用システム「 ジョブメドレー 」のディレクター・コンテンツ編集などを経験し、現在はオンライン診療アプリ「 CLINICS（クリニクス） 」のディレクターをしています。 CLINICS では、慎重さとスピード感を両立して開発できるよう、3 つの習慣を取り入れています。半年ほど実施してみて手法としてまとまってきましたので、ブログでも紹介させていただきます。 背景 CLINICS は、スマートフォンや PC からビデオチャットでかかりつけ医の診察を受けられるオンライン診療アプリです。医療機関向けにはブラウザで予約管理や問診、診察、会計を行うことができる機能も提供しています。CLINICS を開発する際は、医療に関するプロダクトゆえに特に意識しなければいけない点がいくつかあります。 一つは人の命に関わるということ。オンライン診療は症状の落ち着いている方が対象となりますが、少しの使いにくさやミスも誰かの生命・生活に何らか影響するかもしれない緊張感が常にあります。 もう一つは、老若男女幅広く使われていること。病院にかかったことのない人はほとんどいないように、さまざまな人が CLINICS を利用しているので、どんな人でも不安なくスムーズに使えることが重要になってきます。 このような背景から、CLINICS では 慎重にゴールを設定し、丁寧に検証しながら開発を進める必要があります 。一方で、あまりに 慎重・丁寧すぎても何もできなかったり迷走したりしてスピード感を失いかねません 。そこで、両者のバランスをうまく取り開発を推進するために次の 3 つを行っています。 CLINICS 開発をうまく進める 3 つの習慣 1. プロダクトプリンシプルを共有する プロダクトプリンシプルは、 サービスとしてのやること・やらないことを簡潔に言語化 したものです。 例えば CLINICS のプロダクトプリンシプルには「1UU の重み、活用率 100%を目指すこだわり：一人の人の命を預かっているという使命感を持ち、一人でも多くの人が使え、今まで使えていた人が使えなくなることが一人でもないようにする」というフレーズがあります。 前述の通り、CLINICS は人の命に関わるプロダクトであり老若男女幅広く使われています。そのためあえてターゲットを絞らず、すべての人が使えるプロダクトを目指していることをこのフレーズで共有しています。これにより、施策検討段階では一部の人にとってとても使いやすいが使いこなせない人がいる UI と、ほぼすべての人がそこそこ使える UI があった時、私たちは迷わず後者を選択でき、すぐに実装に取り掛かることができます。 プロダクトプリンシプルの作成にあたっては、日頃寄せられる患者の声・医療機関の声をよく聞き、医療の成り立ちや医療業界の構造なども深いところまで学習するようにしました。患者にとって、医療機関にとって、そして社会にとってのあるべきプロダクト像を理念として映し出すようにしています。 2. 年間・四半期ごとのロードマップを策定する ロードマップは、 いつ頃どんな課題に取り組むのかを概ね年間・四半期ごとに定めたもの です。こちらは比較的多くの開発現場で取り入れられている方法ではないでしょうか。 ロードマップをチームで意識するようにすると、先々に開発・リリースする機能を一人ひとりが理解でき、先回りして技術調査を進めたり関連する施策の効果分析の優先度を上げたりといったことができます。また、営業チームなど社内のほかの部署から開発提案があった際にはロードマップを見ながら今後の見通しを案内できるようになり、 他チームのメンバーからの信頼を得ながら開発に専念することができます。 ロードマップを策定する際は、プロダクトプリンシプルを開発内容として落とし込みつつ、事業として伸ばすべき数値や直近で解決すべきお問い合わせなども考慮するようにしています。また、四半期ごとに KPT 法を使ってロードマップを振り返り、開発の期間や体制を見直すようにしています。 3. 週次で計画し、日次で進捗を追う 週次の計画と日次の進捗確認には、 スタンディングミーティング を行っています。 CLINICS では GitHub のプロジェクト機能を使ってカンバンを作成しています。任意のタイミングでロードマップで挙げた課題をだいたい 1 週間程度で区切りのつくサイズの issue に落とし込み、カンバンの backlog にセットします。毎週月曜日の午前中に週次定例を行い、その週に着手する issue を backlog から in progress に移します。火曜以降は毎日 issue ごとに進捗を確認し、終わったものを done に移していきます。 このように週次・日次で計画と進捗確認を細かく繰り返すことで、一つひとつの issue をスピーディに進めるリズムができます。ミーティング時点で一つの issue も進んでいないということがないようにしようという意識が働き、個々人のパフォーマンスもアップします。 まとめ 今回は、開発推進のために CLINICS で取り入れている習慣をご紹介しました。 この 3 つの習慣は、 どれか 1 つのみを行うのでもだめで、3 つセットで実施することが今の CLINICS 開発のカギ になっています。プロダクトプリンシプルだけでは理想論のように思えたことも、ロードマップや計画になるとより具体的になって着手しやすくなり、また、計画で示しきれない改善の方向性はプロダクトプリンシプルに立ち返ることでお互いの認識をそろえやすくなります。 そうすれば不必要なルールの制定や社内コミュニケーションから解放され、日々やるべきことに集中でき、 結果的により早くより優れたプロダクトをユーザーに届けることができる と考えています。 メドレーでは、こうした様々な手法を取り入れながら新しい医療体験を提供するプロダクトを、一緒に創るディレクターやエンジニア、デザイナーを募集しています。 ご興味ある方は、まずはお気軽に話を聞きにお越しください！ www.medley.jp www.medley.jp

こんにちは、開発本部 平木です。2017/12/04(月)に SkyWay UG Tokyo #1 という勉強会がありました。弊社から開発本部の宍戸がセッション枠で発表させていただきましたので、イベントレポートをお送りします。 はじめに 弊社の運営サービスの 1 つである オンライン診察アプリ「CLINICS」 では運用初期の頃から医療機関と患者さんとの診察に SkyWay を使ったビデオチャットを導入しており、現在も Web / iOS / Android の各プラットフォームで SkyWay が稼動しています。 そのようなご縁もあり今回の勉強会では、CLINICS で SkyWay をどのように利用しているかをお話させていただきました。 セッション それでは、各セッションの流れなどをご紹介していきたいと思います。 はじめに 勉強会の冒頭、UG のキックオフと参加者の自己紹介タイムがありました。 UG キックオフ NTT コミュニケーションズの仲さんから、SkyWay UG をなぜ作るのか?というキックオフから会がスタートしました。 SkyWay の大きなミッションとして リアルタイムコミュニケーションを身近にする というものがあり、そのためには 開発者にサービス自体がフレンドリーであるべき であるという理念があるそうです。 開発者フレンドリーであるための一環として 開発者コミュニティの運用をしていく ということになりこの SkyWay UG Tokyo が発足されたという経緯が説明されました。 確かにこのような形で使っているサービスの UG が開催されると、サービスの開発者の方々や参加している他のユーザさん達と気軽に交流できるなというのを今回参加して実感しました。 SkyWay UG は東京だけではなく 関西 や 福岡 でも続々と発足するとのことで、他の開発者サービスと同じように盛り上がっていくのではないでしょうか。 参加者自己紹介 キックオフが終わったところで、参加者の自己紹介タイムとなりました。 30 人近くの参加者が順々に自己紹介していくという形だったのですが、個人的には珍しいなと思うのと同時に、懇親会で何をやっている方なのか?というのが分かりつつ話をすることができたという良さがありました。(参加者として自己紹介する勉強会は初めてでした!) 参加者の感想としては 自分達と同じ Web 業界の方がメイン…というわけでもなく、組み込みなどを仕事にしている方なども 1/3 くらいの割合でいたのが印象的だった 実際にサービスやプロダクトに SkyWay を使っているという参加者の方が多かった とはいえ使ってないが、興味があって参加したという方も 中には弊社の CLINICS に興味があると言っていただけたりもした という感じでした。ハードウェアに SkyWay を組み込んで使うということをやっている方も多く、改めて幅広い開発者に受け入れられてるプラットフォームだと感じました。 Skype から SkyWay へ 最初のセッションは会場を提供されていた レアジョブ の Inoue さんからの発表でした。 Inoue さんは現在は主にフロントエンド開発をされているそうで、このセッションも JavaScript SDK の知見がいろいろされた有意義なものでした。 レアジョブさんでは創業時から Skype を使ってサービスを運用していたそうなのですが、サードパーティに依存しすぎるとビジネスとして危ういということで、SkyWay への切り換えをしていっているそうです。 SkyWay は 9 月からトライアル版から正式版を提供されていますが、まだなかなか情報が少ないということで、新 JavaScript SDK で開発していくなかで得た Tips が発表されました。 実サービスを運用してる方ならではの、 ビデオ・マイクのミュート や ビデオチャット中のページ離脱防止策 などの対応などは実用的で役立つものでした。 Inoue さんもこの後の LT で発表された仲さんもおっしゃっていましたが、SkyWay というか WebRTC のデバッグには chrome://webrtc-internls が重要だと改めて思った次第です。 オンライン診察アプリの作り方 弊社の宍戸の発表です。 まずはメドレーと運営しているプロダクト紹介から始まり、そもそも CLINICS で実現したかったビデオチャットはどのような条件があったか?SkyWay を選んだ理由、SkyWay と Firebase Realtime Database を併用したオンライン診察の実装内容などをご紹介しました。 駆け足でのご紹介にはなりましたが、実際に商用サービスでの事例ということもあり、おかげさまで好評でした。 スライド中でも紹介した SkyWay と Firebase を使った通話制御は他のプロダクトでも使ってることが多いらしく、相性的にもお勧めなのではないでしょうか。 LT セッション枠が終わり LT となったのですが、この LT が SkyWay の中の方達が担当するという豪華なものでした。 WebRTC で統計情報を収集する WebRTCで統計情報を収集する - Qiita 統計情報とは？ WebRTCでは、基盤となるネットワーク環境や送受信されるメディアの情報を監視することが出来るようにように、統計情報のAPIが規定されています。 最新の仕様書は https://w3c.github.io/webrtc-stats/ です。 このAPIで取... qiita.com NTT コミュニケーションズ仲さんの LT です。 chrome://webrtc-internls で表示されるような統計情報を JavaScript SDK を使って表示することができるという解説とデモでした。 WebRTC のデバッグや、ユーザからの問い合わせなどにすぐに使えそうな実践的な内容でした。が、現バージョンでは残念ながら、Android / iOS ではこの統計情報が取れない…とのことだったので、将来的には取れるようになると弊社でもデバックが捗るので首を長くして待ちたいと思います。 紹介されている callstats.io は知らなかったので、参考になりました。行く行くは使ってみたいですね。 reCAPTCHA と API 認証で手軽に利用できて不正利用に強いアプリを作ろう reCAPTCHA と SkyWay の API 認証で手軽に利用できて不正利用に強いアプリを作ろう from Ryosuke Otsuya NTT コミュニケーションズ大津谷さんの LT です。SkyWay では 2018/9 月に API 認証 機能がリリースされたため、この機能と reCAPTCHA を使い API キーの不正利用を防ぎながらログインが不要なサービスを作れるというものでした。 reCAPTCHA はこういう風に使えるんだ!という驚きと同時にプロトタイプなどをサッと作ったりするの大変よさそうな機能だと感じました。 まとめ 以上、SkyWay UG Tokyo #1 のレポートでした。SkyWay を現在使っている・使いたいというような開発者には気軽に情報交換もでき大変よいイベントでした。また、SkyWay 開発陣がユーザからの意見などをすぐに吸い上げてくれるのが改めて分かりました。 次回の東京での開催はまだ未定なようですが、ご興味ある方はぜひいかがでしょうか。 弊社では、SkyWay(WebRTC)を使った開発に興味があるエンジニアさん、ビデオチャットの UI を良くしたい!と思っているデザイナーさんの募集をしています。ご応募お待ちしています。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部 平木です。2017/12/04(月)に SkyWay UG Tokyo #1 という勉強会がありました。弊社から開発本部の宍戸がセッション枠で発表させていただきましたので、イベントレポートをお送りします。 はじめに 弊社の運営サービスの 1 つである オンライン診察アプリ「CLINICS」 では運用初期の頃から医療機関と患者さんとの診察に SkyWay を使ったビデオチャットを導入しており、現在も Web / iOS / Android の各プラットフォームで SkyWay が稼動しています。 そのようなご縁もあり今回の勉強会では、CLINICS で SkyWay をどのように利用しているかをお話させていただきました。 セッション それでは、各セッションの流れなどをご紹介していきたいと思います。 はじめに 勉強会の冒頭、UG のキックオフと参加者の自己紹介タイムがありました。 UG キックオフ NTT コミュニケーションズの仲さんから、SkyWay UG をなぜ作るのか?というキックオフから会がスタートしました。 SkyWay の大きなミッションとして リアルタイムコミュニケーションを身近にする というものがあり、そのためには 開発者にサービス自体がフレンドリーであるべき であるという理念があるそうです。 開発者フレンドリーであるための一環として 開発者コミュニティの運用をしていく ということになりこの SkyWay UG Tokyo が発足されたという経緯が説明されました。 確かにこのような形で使っているサービスの UG が開催されると、サービスの開発者の方々や参加している他のユーザさん達と気軽に交流できるなというのを今回参加して実感しました。 SkyWay UG は東京だけではなく 関西 や 福岡 でも続々と発足するとのことで、他の開発者サービスと同じように盛り上がっていくのではないでしょうか。 参加者自己紹介 キックオフが終わったところで、参加者の自己紹介タイムとなりました。 30 人近くの参加者が順々に自己紹介していくという形だったのですが、個人的には珍しいなと思うのと同時に、懇親会で何をやっている方なのか?というのが分かりつつ話をすることができたという良さがありました。(参加者として自己紹介する勉強会は初めてでした!) 参加者の感想としては 自分達と同じ Web 業界の方がメイン…というわけでもなく、組み込みなどを仕事にしている方なども 1/3 くらいの割合でいたのが印象的だった 実際にサービスやプロダクトに SkyWay を使っているという参加者の方が多かった とはいえ使ってないが、興味があって参加したという方も 中には弊社の CLINICS に興味があると言っていただけたりもした という感じでした。ハードウェアに SkyWay を組み込んで使うということをやっている方も多く、改めて幅広い開発者に受け入れられてるプラットフォームだと感じました。 Skype から SkyWay へ 最初のセッションは会場を提供されていた レアジョブ の Inoue さんからの発表でした。 Inoue さんは現在は主にフロントエンド開発をされているそうで、このセッションも JavaScript SDK の知見がいろいろされた有意義なものでした。 レアジョブさんでは創業時から Skype を使ってサービスを運用していたそうなのですが、サードパーティに依存しすぎるとビジネスとして危ういということで、SkyWay への切り換えをしていっているそうです。 SkyWay は 9 月からトライアル版から正式版を提供されていますが、まだなかなか情報が少ないということで、新 JavaScript SDK で開発していくなかで得た Tips が発表されました。 実サービスを運用してる方ならではの、 ビデオ・マイクのミュート や ビデオチャット中のページ離脱防止策 などの対応などは実用的で役立つものでした。 Inoue さんもこの後の LT で発表された仲さんもおっしゃっていましたが、SkyWay というか WebRTC のデバッグには chrome://webrtc-internls が重要だと改めて思った次第です。 オンライン診察アプリの作り方 弊社の宍戸の発表です。 まずはメドレーと運営しているプロダクト紹介から始まり、そもそも CLINICS で実現したかったビデオチャットはどのような条件があったか?SkyWay を選んだ理由、SkyWay と Firebase Realtime Database を併用したオンライン診察の実装内容などをご紹介しました。 駆け足でのご紹介にはなりましたが、実際に商用サービスでの事例ということもあり、おかげさまで好評でした。 スライド中でも紹介した SkyWay と Firebase を使った通話制御は他のプロダクトでも使ってることが多いらしく、相性的にもお勧めなのではないでしょうか。 LT セッション枠が終わり LT となったのですが、この LT が SkyWay の中の方達が担当するという豪華なものでした。 WebRTC で統計情報を収集する https://qiita.com/yusuke84/items/dc6e5a4ed109c4631b66 NTT コミュニケーションズ仲さんの LT です。 chrome://webrtc-internls で表示されるような統計情報を JavaScript SDK を使って表示することができるという解説とデモでした。 WebRTC のデバッグや、ユーザからの問い合わせなどにすぐに使えそうな実践的な内容でした。が、現バージョンでは残念ながら、Android / iOS ではこの統計情報が取れない…とのことだったので、将来的には取れるようになると弊社でもデバックが捗るので首を長くして待ちたいと思います。 紹介されている callstats.io は知らなかったので、参考になりました。行く行くは使ってみたいですね。 reCAPTCHA と API 認証で手軽に利用できて不正利用に強いアプリを作ろう reCAPTCHA と SkyWay の API 認証で手軽に利用できて不正利用に強いアプリを作ろう from Ryosuke Otsuya NTT コミュニケーションズ大津谷さんの LT です。SkyWay では 2018/9 月に API 認証 機能がリリースされたため、この機能と reCAPTCHA を使い API キーの不正利用を防ぎながらログインが不要なサービスを作れるというものでした。 reCAPTCHA はこういう風に使えるんだ!という驚きと同時にプロトタイプなどをサッと作ったりするの大変よさそうな機能だと感じました。 まとめ 以上、SkyWay UG Tokyo #1 のレポートでした。SkyWay を現在使っている・使いたいというような開発者には気軽に情報交換もでき大変よいイベントでした。また、SkyWay 開発陣がユーザからの意見などをすぐに吸い上げてくれるのが改めて分かりました。 次回の東京での開催はまだ未定なようですが、ご興味ある方はぜひいかがでしょうか。 弊社では、SkyWay(WebRTC)を使った開発に興味があるエンジニアさん、ビデオチャットの UI を良くしたい!と思っているデザイナーさんの募集をしています。ご応募お待ちしています。 https://www.medley.jp/jobs/ https://www.medley.jp/team/creator-story.html

こんにちは、開発本部 平木です。2017/12/04(月)に SkyWay UG Tokyo #1 という勉強会がありました。弊社から開発本部の宍戸がセッション枠で発表させていただきましたので、イベントレポートをお送りします。 はじめに 弊社の運営サービスの 1 つである オンライン診察アプリ「CLINICS」 では運用初期の頃から医療機関と患者さんとの診察に SkyWay を使ったビデオチャットを導入しており、現在も Web / iOS / Android の各プラットフォームで SkyWay が稼動しています。 そのようなご縁もあり今回の勉強会では、CLINICS で SkyWay をどのように利用しているかをお話させていただきました。 セッション それでは、各セッションの流れなどをご紹介していきたいと思います。 はじめに 勉強会の冒頭、UG のキックオフと参加者の自己紹介タイムがありました。 UG キックオフ NTT コミュニケーションズの仲さんから、SkyWay UG をなぜ作るのか?というキックオフから会がスタートしました。 SkyWay の大きなミッションとして リアルタイムコミュニケーションを身近にする というものがあり、そのためには 開発者にサービス自体がフレンドリーであるべき であるという理念があるそうです。 開発者フレンドリーであるための一環として 開発者コミュニティの運用をしていく ということになりこの SkyWay UG Tokyo が発足されたという経緯が説明されました。 確かにこのような形で使っているサービスの UG が開催されると、サービスの開発者の方々や参加している他のユーザさん達と気軽に交流できるなというのを今回参加して実感しました。 SkyWay UG は東京だけではなく 関西 や 福岡 でも続々と発足するとのことで、他の開発者サービスと同じように盛り上がっていくのではないでしょうか。 参加者自己紹介 キックオフが終わったところで、参加者の自己紹介タイムとなりました。 30 人近くの参加者が順々に自己紹介していくという形だったのですが、個人的には珍しいなと思うのと同時に、懇親会で何をやっている方なのか?というのが分かりつつ話をすることができたという良さがありました。(参加者として自己紹介する勉強会は初めてでした!) 参加者の感想としては 自分達と同じ Web 業界の方がメイン…というわけでもなく、組み込みなどを仕事にしている方なども 1/3 くらいの割合でいたのが印象的だった 実際にサービスやプロダクトに SkyWay を使っているという参加者の方が多かった とはいえ使ってないが、興味があって参加したという方も 中には弊社の CLINICS に興味があると言っていただけたりもした という感じでした。ハードウェアに SkyWay を組み込んで使うということをやっている方も多く、改めて幅広い開発者に受け入れられてるプラットフォームだと感じました。 Skype から SkyWay へ 最初のセッションは会場を提供されていた レアジョブ の Inoue さんからの発表でした。 Inoue さんは現在は主にフロントエンド開発をされているそうで、このセッションも JavaScript SDK の知見がいろいろされた有意義なものでした。 レアジョブさんでは創業時から Skype を使ってサービスを運用していたそうなのですが、サードパーティに依存しすぎるとビジネスとして危ういということで、SkyWay への切り換えをしていっているそうです。 SkyWay は 9 月からトライアル版から正式版を提供されていますが、まだなかなか情報が少ないということで、新 JavaScript SDK で開発していくなかで得た Tips が発表されました。 実サービスを運用してる方ならではの、 ビデオ・マイクのミュート や ビデオチャット中のページ離脱防止策 などの対応などは実用的で役立つものでした。 Inoue さんもこの後の LT で発表された仲さんもおっしゃっていましたが、SkyWay というか WebRTC のデバッグには chrome://webrtc-internls が重要だと改めて思った次第です。 オンライン診察アプリの作り方 弊社の宍戸の発表です。 まずはメドレーと運営しているプロダクト紹介から始まり、そもそも CLINICS で実現したかったビデオチャットはどのような条件があったか?SkyWay を選んだ理由、SkyWay と Firebase Realtime Database を併用したオンライン診察の実装内容などをご紹介しました。 駆け足でのご紹介にはなりましたが、実際に商用サービスでの事例ということもあり、おかげさまで好評でした。 スライド中でも紹介した SkyWay と Firebase を使った通話制御は他のプロダクトでも使ってることが多いらしく、相性的にもお勧めなのではないでしょうか。 LT セッション枠が終わり LT となったのですが、この LT が SkyWay の中の方達が担当するという豪華なものでした。 WebRTC で統計情報を収集する WebRTCで統計情報を収集する - Qiita 統計情報とは？WebRTCでは、基盤となるネットワーク環境や送受信されるメディアの情報を監視することが出来るようにように、統計情報のAPIが規定されています。最新の仕様書は https://w3… qiita.com NTT コミュニケーションズ仲さんの LT です。 chrome://webrtc-internls で表示されるような統計情報を JavaScript SDK を使って表示することができるという解説とデモでした。 WebRTC のデバッグや、ユーザからの問い合わせなどにすぐに使えそうな実践的な内容でした。が、現バージョンでは残念ながら、Android / iOS ではこの統計情報が取れない…とのことだったので、将来的には取れるようになると弊社でもデバックが捗るので首を長くして待ちたいと思います。 紹介されている callstats.io は知らなかったので、参考になりました。行く行くは使ってみたいですね。 reCAPTCHA と API 認証で手軽に利用できて不正利用に強いアプリを作ろう reCAPTCHA と SkyWay の API 認証で手軽に利用できて不正利用に強いアプリを作ろう from Ryosuke Otsuya NTT コミュニケーションズ大津谷さんの LT です。SkyWay では 2018/9 月に API 認証 機能がリリースされたため、この機能と reCAPTCHA を使い API キーの不正利用を防ぎながらログインが不要なサービスを作れるというものでした。 reCAPTCHA はこういう風に使えるんだ!という驚きと同時にプロトタイプなどをサッと作ったりするの大変よさそうな機能だと感じました。 まとめ 以上、SkyWay UG Tokyo #1 のレポートでした。SkyWay を現在使っている・使いたいというような開発者には気軽に情報交換もでき大変よいイベントでした。また、SkyWay 開発陣がユーザからの意見などをすぐに吸い上げてくれるのが改めて分かりました。 次回の東京での開催はまだ未定なようですが、ご興味ある方はぜひいかがでしょうか。 弊社では、SkyWay(WebRTC)を使った開発に興味があるエンジニアさん、ビデオチャットの UI を良くしたい!と思っているデザイナーさんの募集をしています。ご応募お待ちしています。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部 平木です。2017/12/04(月)に SkyWay UG Tokyo #1 という勉強会がありました。弊社から開発本部の宍戸がセッション枠で発表させていただきましたので、イベントレポートをお送りします。 はじめに 弊社の運営サービスの 1 つである オンライン診察アプリ「CLINICS」 では運用初期の頃から医療機関と患者さんとの診察に SkyWay を使ったビデオチャットを導入しており、現在も Web / iOS / Android の各プラットフォームで SkyWay が稼動しています。 そのようなご縁もあり今回の勉強会では、CLINICS で SkyWay をどのように利用しているかをお話させていただきました。 セッション それでは、各セッションの流れなどをご紹介していきたいと思います。 はじめに 勉強会の冒頭、UG のキックオフと参加者の自己紹介タイムがありました。 UG キックオフ NTT コミュニケーションズの仲さんから、SkyWay UG をなぜ作るのか?というキックオフから会がスタートしました。 SkyWay の大きなミッションとして リアルタイムコミュニケーションを身近にする というものがあり、そのためには 開発者にサービス自体がフレンドリーであるべき であるという理念があるそうです。 開発者フレンドリーであるための一環として 開発者コミュニティの運用をしていく ということになりこの SkyWay UG Tokyo が発足されたという経緯が説明されました。 確かにこのような形で使っているサービスの UG が開催されると、サービスの開発者の方々や参加している他のユーザさん達と気軽に交流できるなというのを今回参加して実感しました。 SkyWay UG は東京だけではなく 関西 や 福岡 でも続々と発足するとのことで、他の開発者サービスと同じように盛り上がっていくのではないでしょうか。 参加者自己紹介 キックオフが終わったところで、参加者の自己紹介タイムとなりました。 30 人近くの参加者が順々に自己紹介していくという形だったのですが、個人的には珍しいなと思うのと同時に、懇親会で何をやっている方なのか?というのが分かりつつ話をすることができたという良さがありました。(参加者として自己紹介する勉強会は初めてでした!) 参加者の感想としては 自分達と同じ Web 業界の方がメイン…というわけでもなく、組み込みなどを仕事にしている方なども 1/3 くらいの割合でいたのが印象的だった 実際にサービスやプロダクトに SkyWay を使っているという参加者の方が多かった とはいえ使ってないが、興味があって参加したという方も 中には弊社の CLINICS に興味があると言っていただけたりもした という感じでした。ハードウェアに SkyWay を組み込んで使うということをやっている方も多く、改めて幅広い開発者に受け入れられてるプラットフォームだと感じました。 Skype から SkyWay へ 最初のセッションは会場を提供されていた レアジョブ の Inoue さんからの発表でした。 Inoue さんは現在は主にフロントエンド開発をされているそうで、このセッションも JavaScript SDK の知見がいろいろされた有意義なものでした。 レアジョブさんでは創業時から Skype を使ってサービスを運用していたそうなのですが、サードパーティに依存しすぎるとビジネスとして危ういということで、SkyWay への切り換えをしていっているそうです。 SkyWay は 9 月からトライアル版から正式版を提供されていますが、まだなかなか情報が少ないということで、新 JavaScript SDK で開発していくなかで得た Tips が発表されました。 実サービスを運用してる方ならではの、 ビデオ・マイクのミュート や ビデオチャット中のページ離脱防止策 などの対応などは実用的で役立つものでした。 Inoue さんもこの後の LT で発表された仲さんもおっしゃっていましたが、SkyWay というか WebRTC のデバッグには chrome://webrtc-internls が重要だと改めて思った次第です。 オンライン診察アプリの作り方 弊社の宍戸の発表です。 まずはメドレーと運営しているプロダクト紹介から始まり、そもそも CLINICS で実現したかったビデオチャットはどのような条件があったか?SkyWay を選んだ理由、SkyWay と Firebase Realtime Database を併用したオンライン診察の実装内容などをご紹介しました。 駆け足でのご紹介にはなりましたが、実際に商用サービスでの事例ということもあり、おかげさまで好評でした。 スライド中でも紹介した SkyWay と Firebase を使った通話制御は他のプロダクトでも使ってることが多いらしく、相性的にもお勧めなのではないでしょうか。 LT セッション枠が終わり LT となったのですが、この LT が SkyWay の中の方達が担当するという豪華なものでした。 WebRTC で統計情報を収集する WebRTCで統計情報を収集する - Qiita 統計情報とは？WebRTCでは、基盤となるネットワーク環境や送受信されるメディアの情報を監視することが出来るようにように、統計情報のAPIが規定されています。最新の仕様書は https://w3… qiita.com NTT コミュニケーションズ仲さんの LT です。 chrome://webrtc-internls で表示されるような統計情報を JavaScript SDK を使って表示することができるという解説とデモでした。 WebRTC のデバッグや、ユーザからの問い合わせなどにすぐに使えそうな実践的な内容でした。が、現バージョンでは残念ながら、Android / iOS ではこの統計情報が取れない…とのことだったので、将来的には取れるようになると弊社でもデバックが捗るので首を長くして待ちたいと思います。 紹介されている callstats.io は知らなかったので、参考になりました。行く行くは使ってみたいですね。 reCAPTCHA と API 認証で手軽に利用できて不正利用に強いアプリを作ろう reCAPTCHA と SkyWay の API 認証で手軽に利用できて不正利用に強いアプリを作ろう from Ryosuke Otsuya NTT コミュニケーションズ大津谷さんの LT です。SkyWay では 2018/9 月に API 認証 機能がリリースされたため、この機能と reCAPTCHA を使い API キーの不正利用を防ぎながらログインが不要なサービスを作れるというものでした。 reCAPTCHA はこういう風に使えるんだ!という驚きと同時にプロトタイプなどをサッと作ったりするの大変よさそうな機能だと感じました。 まとめ 以上、SkyWay UG Tokyo #1 のレポートでした。SkyWay を現在使っている・使いたいというような開発者には気軽に情報交換もでき大変よいイベントでした。また、SkyWay 開発陣がユーザからの意見などをすぐに吸い上げてくれるのが改めて分かりました。 次回の東京での開催はまだ未定なようですが、ご興味ある方はぜひいかがでしょうか。 弊社では、SkyWay(WebRTC)を使った開発に興味があるエンジニアさん、ビデオチャットの UI を良くしたい!と思っているデザイナーさんの募集をしています。ご応募お待ちしています。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは、開発本部 平木です。2017/12/04(月)に SkyWay UG Tokyo #1 という勉強会がありました。弊社から開発本部の宍戸がセッション枠で発表させていただきましたので、イベントレポートをお送りします。 はじめに 弊社の運営サービスの 1 つである オンライン診察アプリ「CLINICS」 では運用初期の頃から医療機関と患者さんとの診察に SkyWay を使ったビデオチャットを導入しており、現在も Web / iOS / Android の各プラットフォームで SkyWay が稼動しています。 そのようなご縁もあり今回の勉強会では、CLINICS で SkyWay をどのように利用しているかをお話させていただきました。 セッション それでは、各セッションの流れなどをご紹介していきたいと思います。 はじめに 勉強会の冒頭、UG のキックオフと参加者の自己紹介タイムがありました。 UG キックオフ NTT コミュニケーションズの仲さんから、SkyWay UG をなぜ作るのか?というキックオフから会がスタートしました。 SkyWay の大きなミッションとして リアルタイムコミュニケーションを身近にする というものがあり、そのためには 開発者にサービス自体がフレンドリーであるべき であるという理念があるそうです。 開発者フレンドリーであるための一環として 開発者コミュニティの運用をしていく ということになりこの SkyWay UG Tokyo が発足されたという経緯が説明されました。 確かにこのような形で使っているサービスの UG が開催されると、サービスの開発者の方々や参加している他のユーザさん達と気軽に交流できるなというのを今回参加して実感しました。 SkyWay UG は東京だけではなく 関西 や 福岡 でも続々と発足するとのことで、他の開発者サービスと同じように盛り上がっていくのではないでしょうか。 参加者自己紹介 キックオフが終わったところで、参加者の自己紹介タイムとなりました。 30 人近くの参加者が順々に自己紹介していくという形だったのですが、個人的には珍しいなと思うのと同時に、懇親会で何をやっている方なのか?というのが分かりつつ話をすることができたという良さがありました。(参加者として自己紹介する勉強会は初めてでした!) 参加者の感想としては 自分達と同じ Web 業界の方がメイン…というわけでもなく、組み込みなどを仕事にしている方なども 1/3 くらいの割合でいたのが印象的だった 実際にサービスやプロダクトに SkyWay を使っているという参加者の方が多かった とはいえ使ってないが、興味があって参加したという方も 中には弊社の CLINICS に興味があると言っていただけたりもした という感じでした。ハードウェアに SkyWay を組み込んで使うということをやっている方も多く、改めて幅広い開発者に受け入れられてるプラットフォームだと感じました。 Skype から SkyWay へ 最初のセッションは会場を提供されていた レアジョブ の Inoue さんからの発表でした。 Inoue さんは現在は主にフロントエンド開発をされているそうで、このセッションも JavaScript SDK の知見がいろいろされた有意義なものでした。 レアジョブさんでは創業時から Skype を使ってサービスを運用していたそうなのですが、サードパーティに依存しすぎるとビジネスとして危ういということで、SkyWay への切り換えをしていっているそうです。 SkyWay は 9 月からトライアル版から正式版を提供されていますが、まだなかなか情報が少ないということで、新 JavaScript SDK で開発していくなかで得た Tips が発表されました。 実サービスを運用してる方ならではの、 ビデオ・マイクのミュート や ビデオチャット中のページ離脱防止策 などの対応などは実用的で役立つものでした。 Inoue さんもこの後の LT で発表された仲さんもおっしゃっていましたが、SkyWay というか WebRTC のデバッグには chrome://webrtc-internls が重要だと改めて思った次第です。 オンライン診察アプリの作り方 弊社の宍戸の発表です。 まずはメドレーと運営しているプロダクト紹介から始まり、そもそも CLINICS で実現したかったビデオチャットはどのような条件があったか?SkyWay を選んだ理由、SkyWay と Firebase Realtime Database を併用したオンライン診察の実装内容などをご紹介しました。 駆け足でのご紹介にはなりましたが、実際に商用サービスでの事例ということもあり、おかげさまで好評でした。 スライド中でも紹介した SkyWay と Firebase を使った通話制御は他のプロダクトでも使ってることが多いらしく、相性的にもお勧めなのではないでしょうか。 LT セッション枠が終わり LT となったのですが、この LT が SkyWay の中の方達が担当するという豪華なものでした。 WebRTC で統計情報を収集する WebRTCで統計情報を収集する - Qiita 統計情報とは？ WebRTCでは、基盤となるネットワーク環境や送受信されるメディアの情報を監視することが出来るようにように、統計情報のAPIが規定されています。 最新の仕様書は https://w3c.github.io/webrtc-stats/ です。 このAPIで取... qiita.com NTT コミュニケーションズ仲さんの LT です。 chrome://webrtc-internls で表示されるような統計情報を JavaScript SDK を使って表示することができるという解説とデモでした。 WebRTC のデバッグや、ユーザからの問い合わせなどにすぐに使えそうな実践的な内容でした。が、現バージョンでは残念ながら、Android / iOS ではこの統計情報が取れない…とのことだったので、将来的には取れるようになると弊社でもデバックが捗るので首を長くして待ちたいと思います。 紹介されている callstats.io は知らなかったので、参考になりました。行く行くは使ってみたいですね。 reCAPTCHA と API 認証で手軽に利用できて不正利用に強いアプリを作ろう reCAPTCHA と SkyWay の API 認証で手軽に利用できて不正利用に強いアプリを作ろう from Ryosuke Otsuya NTT コミュニケーションズ大津谷さんの LT です。SkyWay では 2018/9 月に API 認証 機能がリリースされたため、この機能と reCAPTCHA を使い API キーの不正利用を防ぎながらログインが不要なサービスを作れるというものでした。 reCAPTCHA はこういう風に使えるんだ!という驚きと同時にプロトタイプなどをサッと作ったりするの大変よさそうな機能だと感じました。 まとめ 以上、SkyWay UG Tokyo #1 のレポートでした。SkyWay を現在使っている・使いたいというような開発者には気軽に情報交換もでき大変よいイベントでした。また、SkyWay 開発陣がユーザからの意見などをすぐに吸い上げてくれるのが改めて分かりました。 次回の東京での開催はまだ未定なようですが、ご興味ある方はぜひいかがでしょうか。 弊社では、SkyWay(WebRTC)を使った開発に興味があるエンジニアさん、ビデオチャットの UI を良くしたい!と思っているデザイナーさんの募集をしています。ご応募お待ちしています。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp