こんにちは、開発本部の横尾です。 これまで介護施設の口コミサイト「 介護のほんね 」の立ち上げや医療介護の人材採用システム「 ジョブメドレー 」のディレクター・コンテンツ編集などを経験し、現在はオンライン診療アプリ「 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

こんにちは、開発本部 平木です。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 で統計情報を収集する 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 で統計情報を収集する 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 で統計情報を収集する 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 メドレー公式note｜note 「医療ヘルスケアの未来をつくる」というミッションのもと、様々な医療課題を解決するためのデジタル活用を推進する【株式会社メドレー】の公式noteです。https://www.medley.jp/ www.medley.jp

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にて Prometheus を使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。 Prometheus 先日 2.0 がリリースされた ばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報を Grafana と連携してグラフィカルに表示したり、 アラートマネージャ機能 を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、Prometheus は Pull 型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。（Prometheus 自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います 🙏） Prometheus は前職時代にもお世話になっており、そのときには Go で書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトは Rails を利用しているため、今回は Prometheus を利用して、Rails アプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。 アプリケーションパフォーマンスのモニタリング アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的なボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化（改善/悪化）を早期に発見することに繋がると考えています。 アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelic の APM は代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。また その他様々なツール でも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング（マネジメント）ツールについては こちら に良くまとまっていましたので、合わせて見ていただくと良いかもしれません。 メトリクスについて Prometheus も様々な機能がありますが、監視対象となるサーバは Exporter と表現されます。この Exporter に対して、Prometheus Server がデータを取りに来る格好です。 https://github.com/prometheus/client_ruby というライブラリが公式に提供されています。こちらにある Prometheus::Middleware::Collector と Prometheus::Middleware::Exporter という２つの Rack middleware を利用することで設定に数行追加するだけで以下に記載した情報を Prometheus Server から利用する準備が整います。 key 意味 http_server_requests_total アプリケーションの処理したリクエスト総数 http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム http_server_request_duration_seconds_sum 上記の合計値 http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数 http_server_exceptions_total アプリケーションで発生した例外の合計数 ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラム の計算などの際に利用します。 これらを用いて、 直近 10 分のエンドポイント毎のレイテンシ rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m]) API のエンドポイント毎のステータスコードが 200 以外となったレスポンスの数 sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path) などを PromQL という Prometheus の独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。 実際に発表した際のスライドはこちら。 まとめ 今回は Prometheus を利用した Rails アプリケーションのモニタリングについてご紹介しました。 Prometheus がどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特に Rails 等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。 現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。