みなさん、こんにちは。開発本部のエンジニア・平木です。 表題の通りなんですが、メドレーは今年からテックカンファレンスの協賛を本格的に開始しています。その内の 1 つが 9/15〜17 に早稲田大学で開かれた iOSDC Japan 2017 (以下 iOSDC)です。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 メドレーは今回、ゴールドスポンサーとして協力させていただきました。ブース出展はしていないのですが、CLINICS の iOS 版をメインで担当している高井と一緒に参加してきました。 会場の雰囲気 まず第一印象として人が多かったです。 会場は 4 つに分かれていたのですが、一番大きいトラック A 以外はセッションが始まるころになると満席になっていることが多く、自分が見たセッションでは大体立ち見が出ている感じでした。 企業ブースを出展している企業さんの中では、サイバーエージェントさんのブースが iOS 開発に関するアンケートを取っていたようで、盛況でした。 スタッフさんの人数も多かったということもあるのか、スケジュール通りにセッションが進んでいるのが印象的でした。機材トラブルなどもほとんど 見受けられなかったので、運営がとてもスムーズでした。 また、朝にオープニングムービーが流れてスポンサーの紹介などをしている映像が流れるのですが、まさかの三石琴乃さんがナレーションでビビりました。 すげえ。 video: https://youtu.be/AC7C5CY1Meo?t=4m55s iOSDC ではランチが配られる形式なのですが、来場者が多かったはずなのに、食べる場所がない…みたいなこともなく良かったですね。 ランチはサンドイッチで、大変おいしかったです。席が近いからか知らない人とも話しやすい雰囲気を感じました。 セッション 一口に iOS 関連といってもセッションはかなりバラエティに富んだ内容です。Swift に関するもの、設計に関するもの、運用に関わるものなどなど…。 ちょいちょいと Android や Kotlin と関係したセッションがあったのは意外でした。が、考えてみると両方をやってるエンジニアの方も多いでしょうし、 Swift と Kotlin も文法なんかは割と似てるということで、親和性があるんでしょうね。 全体としては、やはり、iPhone X や iOS11 の話題がちらほらと出ており、さすが専門のカンファレンスだけあってわりとつっこんだ話が聞けたのが良かったです。 個人的には言語の話なども面白かったんですが、運用周りの話をしてるセッションがとても面白かったです。 リニューアル周りの話題や CI での運用の話などは大変に参考になりましたし、特にトレタさんの ロギング の話はぜひ弊社でも実践せねばという話でした。 LT の時間前にビールが配られて、飲みながら参加できるのは大変ポイントが高いですね! 最後に iOSDC は自分は初めての参加だったのですが、大変よいイベントだなと感じました。 iOS だと特に大体毎年新しいバージョンや新しい機種が出てきますし、 そうなると新しい SDK や API もどんどん出てくるという感じです。もちろんネットの情報などで知識をアップデートしたりするのも必要ですが、こういったイベントでより新鮮な知見などを共有できるというのは、やはり素晴しいなあという感想です。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 https://www.wantedly.com/companies/medley 開発本部の雰囲気を知りたい方はこちらからどうぞ。 https://www.medley.jp/recruit/creative.html

みなさん、こんにちは。開発本部のエンジニア・平木です。 表題の通りなんですが、メドレーは今年からテックカンファレンスの協賛を本格的に開始しています。その内の 1 つが 9/15〜17 に早稲田大学で開かれた iOSDC Japan 2017 (以下 iOSDC)です。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 メドレーは今回、ゴールドスポンサーとして協力させていただきました。ブース出展はしていないのですが、CLINICS の iOS 版をメインで担当している高井と一緒に参加してきました。 会場の雰囲気 まず第一印象として人が多かったです。 会場は 4 つに分かれていたのですが、一番大きいトラック A 以外はセッションが始まるころになると満席になっていることが多く、自分が見たセッションでは大体立ち見が出ている感じでした。 企業ブースを出展している企業さんの中では、サイバーエージェントさんのブースが iOS 開発に関するアンケートを取っていたようで、盛況でした。 スタッフさんの人数も多かったということもあるのか、スケジュール通りにセッションが進んでいるのが印象的でした。機材トラブルなどもほとんど 見受けられなかったので、運営がとてもスムーズでした。 また、朝にオープニングムービーが流れてスポンサーの紹介などをしている映像が流れるのですが、まさかの三石琴乃さんがナレーションでビビりました。 すげえ。 video: https://youtu.be/AC7C5CY1Meo?t=4m55s iOSDC ではランチが配られる形式なのですが、来場者が多かったはずなのに、食べる場所がない…みたいなこともなく良かったですね。 ランチはサンドイッチで、大変おいしかったです。席が近いからか知らない人とも話しやすい雰囲気を感じました。 セッション 一口に iOS 関連といってもセッションはかなりバラエティに富んだ内容です。Swift に関するもの、設計に関するもの、運用に関わるものなどなど…。 ちょいちょいと Android や Kotlin と関係したセッションがあったのは意外でした。が、考えてみると両方をやってるエンジニアの方も多いでしょうし、 Swift と Kotlin も文法なんかは割と似てるということで、親和性があるんでしょうね。 全体としては、やはり、iPhone X や iOS11 の話題がちらほらと出ており、さすが専門のカンファレンスだけあってわりとつっこんだ話が聞けたのが良かったです。 個人的には言語の話なども面白かったんですが、運用周りの話をしてるセッションがとても面白かったです。 リニューアル周りの話題や CI での運用の話などは大変に参考になりましたし、特にトレタさんの ロギング の話はぜひ弊社でも実践せねばという話でした。 LT の時間前にビールが配られて、飲みながら参加できるのは大変ポイントが高いですね! 最後に iOSDC は自分は初めての参加だったのですが、大変よいイベントだなと感じました。 iOS だと特に大体毎年新しいバージョンや新しい機種が出てきますし、 そうなると新しい SDK や API もどんどん出てくるという感じです。もちろんネットの情報などで知識をアップデートしたりするのも必要ですが、こういったイベントでより新鮮な知見などを共有できるというのは、やはり素晴しいなあという感想です。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気を知りたい方はこちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発本部のエンジニア・平木です。 表題の通りなんですが、メドレーは今年からテックカンファレンスの協賛を本格的に開始しています。その内の 1 つが 9/15〜17 に早稲田大学で開かれた iOSDC Japan 2017 (以下 iOSDC)です。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 メドレーは今回、ゴールドスポンサーとして協力させていただきました。ブース出展はしていないのですが、CLINICS の iOS 版をメインで担当している高井と一緒に参加してきました。 会場の雰囲気 まず第一印象として人が多かったです。 会場は 4 つに分かれていたのですが、一番大きいトラック A 以外はセッションが始まるころになると満席になっていることが多く、自分が見たセッションでは大体立ち見が出ている感じでした。 企業ブースを出展している企業さんの中では、サイバーエージェントさんのブースが iOS 開発に関するアンケートを取っていたようで、盛況でした。 スタッフさんの人数も多かったということもあるのか、スケジュール通りにセッションが進んでいるのが印象的でした。機材トラブルなどもほとんど 見受けられなかったので、運営がとてもスムーズでした。 また、朝にオープニングムービーが流れてスポンサーの紹介などをしている映像が流れるのですが、まさかの三石琴乃さんがナレーションでビビりました。 すげえ。 video: https://youtu.be/AC7C5CY1Meo?t=4m55s iOSDC ではランチが配られる形式なのですが、来場者が多かったはずなのに、食べる場所がない…みたいなこともなく良かったですね。 ランチはサンドイッチで、大変おいしかったです。席が近いからか知らない人とも話しやすい雰囲気を感じました。 セッション 一口に iOS 関連といってもセッションはかなりバラエティに富んだ内容です。Swift に関するもの、設計に関するもの、運用に関わるものなどなど…。 ちょいちょいと Android や Kotlin と関係したセッションがあったのは意外でした。が、考えてみると両方をやってるエンジニアの方も多いでしょうし、 Swift と Kotlin も文法なんかは割と似てるということで、親和性があるんでしょうね。 全体としては、やはり、iPhone X や iOS11 の話題がちらほらと出ており、さすが専門のカンファレンスだけあってわりとつっこんだ話が聞けたのが良かったです。 個人的には言語の話なども面白かったんですが、運用周りの話をしてるセッションがとても面白かったです。 リニューアル周りの話題や CI での運用の話などは大変に参考になりましたし、特にトレタさんの ロギング の話はぜひ弊社でも実践せねばという話でした。 LT の時間前にビールが配られて、飲みながら参加できるのは大変ポイントが高いですね! 最後に iOSDC は自分は初めての参加だったのですが、大変よいイベントだなと感じました。 iOS だと特に大体毎年新しいバージョンや新しい機種が出てきますし、 そうなると新しい SDK や API もどんどん出てくるという感じです。もちろんネットの情報などで知識をアップデートしたりするのも必要ですが、こういったイベントでより新鮮な知見などを共有できるというのは、やはり素晴しいなあという感想です。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気を知りたい方はこちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発本部のエンジニア・平木です。 表題の通りなんですが、メドレーは今年からテックカンファレンスの協賛を本格的に開始しています。その内の 1 つが 9/15〜17 に早稲田大学で開かれた iOSDC Japan 2017 (以下 iOSDC)です。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 メドレーは今回、ゴールドスポンサーとして協力させていただきました。ブース出展はしていないのですが、CLINICS の iOS 版をメインで担当している高井と一緒に参加してきました。 会場の雰囲気 まず第一印象として人が多かったです。 会場は 4 つに分かれていたのですが、一番大きいトラック A 以外はセッションが始まるころになると満席になっていることが多く、自分が見たセッションでは大体立ち見が出ている感じでした。 企業ブースを出展している企業さんの中では、サイバーエージェントさんのブースが iOS 開発に関するアンケートを取っていたようで、盛況でした。 スタッフさんの人数も多かったということもあるのか、スケジュール通りにセッションが進んでいるのが印象的でした。機材トラブルなどもほとんど 見受けられなかったので、運営がとてもスムーズでした。 また、朝にオープニングムービーが流れてスポンサーの紹介などをしている映像が流れるのですが、まさかの三石琴乃さんがナレーションでビビりました。 すげえ。 video: https://youtu.be/AC7C5CY1Meo?t=4m55s iOSDC ではランチが配られる形式なのですが、来場者が多かったはずなのに、食べる場所がない…みたいなこともなく良かったですね。 ランチはサンドイッチで、大変おいしかったです。席が近いからか知らない人とも話しやすい雰囲気を感じました。 セッション 一口に iOS 関連といってもセッションはかなりバラエティに富んだ内容です。Swift に関するもの、設計に関するもの、運用に関わるものなどなど…。 ちょいちょいと Android や Kotlin と関係したセッションがあったのは意外でした。が、考えてみると両方をやってるエンジニアの方も多いでしょうし、 Swift と Kotlin も文法なんかは割と似てるということで、親和性があるんでしょうね。 全体としては、やはり、iPhone X や iOS11 の話題がちらほらと出ており、さすが専門のカンファレンスだけあってわりとつっこんだ話が聞けたのが良かったです。 個人的には言語の話なども面白かったんですが、運用周りの話をしてるセッションがとても面白かったです。 リニューアル周りの話題や CI での運用の話などは大変に参考になりましたし、特にトレタさんの ロギング の話はぜひ弊社でも実践せねばという話でした。 LT の時間前にビールが配られて、飲みながら参加できるのは大変ポイントが高いですね! 最後に iOSDC は自分は初めての参加だったのですが、大変よいイベントだなと感じました。 iOS だと特に大体毎年新しいバージョンや新しい機種が出てきますし、 そうなると新しい SDK や API もどんどん出てくるという感じです。もちろんネットの情報などで知識をアップデートしたりするのも必要ですが、こういったイベントでより新鮮な知見などを共有できるというのは、やはり素晴しいなあという感想です。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気を知りたい方はこちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発本部のエンジニア・平木です。 表題の通りなんですが、メドレーは今年からテックカンファレンスの協賛を本格的に開始しています。その内の 1 つが 9/15〜17 に早稲田大学で開かれた iOSDC Japan 2017 (以下 iOSDC)です。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 メドレーは今回、ゴールドスポンサーとして協力させていただきました。ブース出展はしていないのですが、CLINICS の iOS 版をメインで担当している高井と一緒に参加してきました。 会場の雰囲気 まず第一印象として人が多かったです。 会場は 4 つに分かれていたのですが、一番大きいトラック A 以外はセッションが始まるころになると満席になっていることが多く、自分が見たセッションでは大体立ち見が出ている感じでした。 企業ブースを出展している企業さんの中では、サイバーエージェントさんのブースが iOS 開発に関するアンケートを取っていたようで、盛況でした。 スタッフさんの人数も多かったということもあるのか、スケジュール通りにセッションが進んでいるのが印象的でした。機材トラブルなどもほとんど 見受けられなかったので、運営がとてもスムーズでした。 また、朝にオープニングムービーが流れてスポンサーの紹介などをしている映像が流れるのですが、まさかの三石琴乃さんがナレーションでビビりました。 すげえ。 video: https://youtu.be/AC7C5CY1Meo?t=4m55s iOSDC ではランチが配られる形式なのですが、来場者が多かったはずなのに、食べる場所がない…みたいなこともなく良かったですね。 ランチはサンドイッチで、大変おいしかったです。席が近いからか知らない人とも話しやすい雰囲気を感じました。 セッション 一口に iOS 関連といってもセッションはかなりバラエティに富んだ内容です。Swift に関するもの、設計に関するもの、運用に関わるものなどなど…。 ちょいちょいと Android や Kotlin と関係したセッションがあったのは意外でした。が、考えてみると両方をやってるエンジニアの方も多いでしょうし、 Swift と Kotlin も文法なんかは割と似てるということで、親和性があるんでしょうね。 全体としては、やはり、iPhone X や iOS11 の話題がちらほらと出ており、さすが専門のカンファレンスだけあってわりとつっこんだ話が聞けたのが良かったです。 個人的には言語の話なども面白かったんですが、運用周りの話をしてるセッションがとても面白かったです。 リニューアル周りの話題や CI での運用の話などは大変に参考になりましたし、特にトレタさんの ロギング の話はぜひ弊社でも実践せねばという話でした。 LT の時間前にビールが配られて、飲みながら参加できるのは大変ポイントが高いですね! 最後に iOSDC は自分は初めての参加だったのですが、大変よいイベントだなと感じました。 iOS だと特に大体毎年新しいバージョンや新しい機種が出てきますし、 そうなると新しい SDK や API もどんどん出てくるという感じです。もちろんネットの情報などで知識をアップデートしたりするのも必要ですが、こういったイベントでより新鮮な知見などを共有できるというのは、やはり素晴しいなあという感想です。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気を知りたい方はこちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発本部のエンジニア・平木です。 表題の通りなんですが、メドレーは今年からテックカンファレンスの協賛を本格的に開始しています。その内の 1 つが 9/15〜17 に早稲田大学で開かれた iOSDC Japan 2017 (以下 iOSDC)です。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 メドレーは今回、ゴールドスポンサーとして協力させていただきました。ブース出展はしていないのですが、CLINICS の iOS 版をメインで担当している高井と一緒に参加してきました。 会場の雰囲気 まず第一印象として人が多かったです。 会場は 4 つに分かれていたのですが、一番大きいトラック A 以外はセッションが始まるころになると満席になっていることが多く、自分が見たセッションでは大体立ち見が出ている感じでした。 企業ブースを出展している企業さんの中では、サイバーエージェントさんのブースが iOS 開発に関するアンケートを取っていたようで、盛況でした。 スタッフさんの人数も多かったということもあるのか、スケジュール通りにセッションが進んでいるのが印象的でした。機材トラブルなどもほとんど 見受けられなかったので、運営がとてもスムーズでした。 また、朝にオープニングムービーが流れてスポンサーの紹介などをしている映像が流れるのですが、まさかの三石琴乃さんがナレーションでビビりました。 すげえ。 video: https://youtu.be/AC7C5CY1Meo?t=4m55s iOSDC ではランチが配られる形式なのですが、来場者が多かったはずなのに、食べる場所がない…みたいなこともなく良かったですね。 ランチはサンドイッチで、大変おいしかったです。席が近いからか知らない人とも話しやすい雰囲気を感じました。 セッション 一口に iOS 関連といってもセッションはかなりバラエティに富んだ内容です。Swift に関するもの、設計に関するもの、運用に関わるものなどなど…。 ちょいちょいと Android や Kotlin と関係したセッションがあったのは意外でした。が、考えてみると両方をやってるエンジニアの方も多いでしょうし、 Swift と Kotlin も文法なんかは割と似てるということで、親和性があるんでしょうね。 全体としては、やはり、iPhone X や iOS11 の話題がちらほらと出ており、さすが専門のカンファレンスだけあってわりとつっこんだ話が聞けたのが良かったです。 個人的には言語の話なども面白かったんですが、運用周りの話をしてるセッションがとても面白かったです。 リニューアル周りの話題や CI での運用の話などは大変に参考になりましたし、特にトレタさんの ロギング の話はぜひ弊社でも実践せねばという話でした。 LT の時間前にビールが配られて、飲みながら参加できるのは大変ポイントが高いですね! 最後に iOSDC は自分は初めての参加だったのですが、大変よいイベントだなと感じました。 iOS だと特に大体毎年新しいバージョンや新しい機種が出てきますし、 そうなると新しい SDK や API もどんどん出てくるという感じです。もちろんネットの情報などで知識をアップデートしたりするのも必要ですが、こういったイベントでより新鮮な知見などを共有できるというのは、やはり素晴しいなあという感想です。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気を知りたい方はこちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発本部のエンジニア・平木です。 表題の通りなんですが、メドレーは今年からテックカンファレンスの協賛を本格的に開始しています。その内の 1 つが 9/15〜17 に早稲田大学で開かれた iOSDC Japan 2017 (以下 iOSDC)です。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 メドレーは今回、ゴールドスポンサーとして協力させていただきました。ブース出展はしていないのですが、CLINICS の iOS 版をメインで担当している高井と一緒に参加してきました。 会場の雰囲気 まず第一印象として人が多かったです。 会場は 4 つに分かれていたのですが、一番大きいトラック A 以外はセッションが始まるころになると満席になっていることが多く、自分が見たセッションでは大体立ち見が出ている感じでした。 企業ブースを出展している企業さんの中では、サイバーエージェントさんのブースが iOS 開発に関するアンケートを取っていたようで、盛況でした。 スタッフさんの人数も多かったということもあるのか、スケジュール通りにセッションが進んでいるのが印象的でした。機材トラブルなどもほとんど 見受けられなかったので、運営がとてもスムーズでした。 また、朝にオープニングムービーが流れてスポンサーの紹介などをしている映像が流れるのですが、まさかの三石琴乃さんがナレーションでビビりました。 すげえ。 video: https://youtu.be/AC7C5CY1Meo?t=4m55s iOSDC ではランチが配られる形式なのですが、来場者が多かったはずなのに、食べる場所がない…みたいなこともなく良かったですね。 ランチはサンドイッチで、大変おいしかったです。席が近いからか知らない人とも話しやすい雰囲気を感じました。 セッション 一口に iOS 関連といってもセッションはかなりバラエティに富んだ内容です。Swift に関するもの、設計に関するもの、運用に関わるものなどなど…。 ちょいちょいと Android や Kotlin と関係したセッションがあったのは意外でした。が、考えてみると両方をやってるエンジニアの方も多いでしょうし、 Swift と Kotlin も文法なんかは割と似てるということで、親和性があるんでしょうね。 全体としては、やはり、iPhone X や iOS11 の話題がちらほらと出ており、さすが専門のカンファレンスだけあってわりとつっこんだ話が聞けたのが良かったです。 個人的には言語の話なども面白かったんですが、運用周りの話をしてるセッションがとても面白かったです。 リニューアル周りの話題や CI での運用の話などは大変に参考になりましたし、特にトレタさんの ロギング の話はぜひ弊社でも実践せねばという話でした。 LT の時間前にビールが配られて、飲みながら参加できるのは大変ポイントが高いですね! 最後に iOSDC は自分は初めての参加だったのですが、大変よいイベントだなと感じました。 iOS だと特に大体毎年新しいバージョンや新しい機種が出てきますし、 そうなると新しい SDK や API もどんどん出てくるという感じです。もちろんネットの情報などで知識をアップデートしたりするのも必要ですが、こういったイベントでより新鮮な知見などを共有できるというのは、やはり素晴しいなあという感想です。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気を知りたい方はこちらからどうぞ。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

みなさん、こんにちは。開発本部のエンジニア・平木です。 表題の通りなんですが、メドレーは今年からテックカンファレンスの協賛を本格的に開始しています。その内の 1 つが 9/15〜17 に早稲田大学で開かれた iOSDC Japan 2017 (以下 iOSDC)です。 みなさんご存知かと思いますが、iOSDC は国内の iOS イベントの中では try! Swift と並ぶ最大級のイベントです。 メドレーは今回、ゴールドスポンサーとして協力させていただきました。ブース出展はしていないのですが、CLINICS の iOS 版をメインで担当している高井と一緒に参加してきました。 会場の雰囲気 まず第一印象として人が多かったです。 会場は 4 つに分かれていたのですが、一番大きいトラック A 以外はセッションが始まるころになると満席になっていることが多く、自分が見たセッションでは大体立ち見が出ている感じでした。 企業ブースを出展している企業さんの中では、サイバーエージェントさんのブースが iOS 開発に関するアンケートを取っていたようで、盛況でした。 スタッフさんの人数も多かったということもあるのか、スケジュール通りにセッションが進んでいるのが印象的でした。機材トラブルなどもほとんど 見受けられなかったので、運営がとてもスムーズでした。 また、朝にオープニングムービーが流れてスポンサーの紹介などをしている映像が流れるのですが、まさかの三石琴乃さんがナレーションでビビりました。 すげえ。 video: https://youtu.be/AC7C5CY1Meo?t=4m55s iOSDC ではランチが配られる形式なのですが、来場者が多かったはずなのに、食べる場所がない…みたいなこともなく良かったですね。 ランチはサンドイッチで、大変おいしかったです。席が近いからか知らない人とも話しやすい雰囲気を感じました。 セッション 一口に iOS 関連といってもセッションはかなりバラエティに富んだ内容です。Swift に関するもの、設計に関するもの、運用に関わるものなどなど…。 ちょいちょいと Android や Kotlin と関係したセッションがあったのは意外でした。が、考えてみると両方をやってるエンジニアの方も多いでしょうし、 Swift と Kotlin も文法なんかは割と似てるということで、親和性があるんでしょうね。 全体としては、やはり、iPhone X や iOS11 の話題がちらほらと出ており、さすが専門のカンファレンスだけあってわりとつっこんだ話が聞けたのが良かったです。 個人的には言語の話なども面白かったんですが、運用周りの話をしてるセッションがとても面白かったです。 リニューアル周りの話題や CI での運用の話などは大変に参考になりましたし、特にトレタさんの ロギング の話はぜひ弊社でも実践せねばという話でした。 LT の時間前にビールが配られて、飲みながら参加できるのは大変ポイントが高いですね! 最後に iOSDC は自分は初めての参加だったのですが、大変よいイベントだなと感じました。 iOS だと特に大体毎年新しいバージョンや新しい機種が出てきますし、 そうなると新しい SDK や API もどんどん出てくるという感じです。もちろんネットの情報などで知識をアップデートしたりするのも必要ですが、こういったイベントでより新鮮な知見などを共有できるというのは、やはり素晴しいなあという感想です。 弊社のアプリ開発でもそういった知見などを活かして開発していける仲間を引き続き募集しています! 興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 株式会社メドレーの会社情報 - Wantedly 株式会社メドレーの魅力を伝えるコンテンツと、住所や代表・従業員などの会社情報です。急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com 開発本部の雰囲気を知りたい方はこちらからどうぞ。 メドレー公式note｜note 「医療ヘルスケアの未来をつくる」というミッションのもと、様々な医療課題を解決するためのデジタル活用を推進する【株式会社メドレー】の公式noteです。https://www.medley.jp/ www.medley.jp

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 https://www.medley.jp/recruit/creative.html メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは、開発本部の宮内です。 さて、これまで弊社のオンライン診療アプリ「 CLINICS 」では、ローンチ時より Heroku を利用しておりました。 Heroku とは、PaaS の一種で Web アプリケーションを簡単にデプロイ、ホスティングできるサービスです。 ある程度の制約はつきますが、(大体の制約は金で解決できるので)使っているかたも多いのではないでしょうか。 今回、事情により Heroku から AWS Elastic Beanstalk (以下、EB)へ移行することになりましたので、そのあたりでやったことを共有できればと思います。 Private PaaS にしないの？ まずはじめに移行にあたり、Priavte PaaS を構築する方法を模索しました。 ですが、これらのクラスタの構築はできても、専任の(Ops|SRE|インフラ)チームがいないため、日々の管理や運用に手が回らないだろうという思いから、Private PaaS の構築は見送りました。 この辺りは今後チーム人数が増えたら挑戦していきたいです…。 検討時、参考にしたリンク PAAS comparison - Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm (2017) Convox Deis Flynn なぜ AWS Elastic Beanstalk にしたの？ EB には Rails や Sinatra で作成されたウェブアプリケーションを実行するための Ruby プラットフォーム が予め用意されております。 ただし、今回の移行では、アプリケーションへの変更を一切加えずに行いたかったため、Ruby プラットフォームを利用しませんでした。 代わりに Docker コンテナが実行できる プラットフォーム があったため、そちらを使うことにしました。 herokuish で Docker イメージを作成 アプリケーションの Docker イメージ化には、 gliderlabs/herokuish を使いました。 これは buildpack を使いアプリケーションを slug 化したり、slug を実行するためのツールです。 Docker イメージ作成の手順は以下の通りです。 herokuish buildpack build と herokuish slug generate でアプリケーションを slug にする herokuish slug import で slug をインポートして完成 それでは、それぞれ簡単に説明していきたいと思います。 アプリケーションを slug にする docker pull gliderlabs/herokuish docker run \ -v "/path/to/app:/tmp/build" \ -v "/path/to/cache:/tmp/cache" \ -v "/path/to/slug:/tmp/slug" \ gliderlabs/herokuish \ /bin/bash -c 'herokuish buildpack build && herokuish slug generate && herokuish slug export > /tmp/slug/slug.tgz' herokuish は特定のディレクトリに対して処理を行います。↑ ではビルドするアプリケーションまでのディレクトリパスを /tmp/build にマッピングしています。 /tmp/cache は buildpack が利用するキャッシュ置き場です。このディレクトリを次回以降のビルドでもマッピングしておくとビルドの高速化が見込めます。 最後の /tmp/slug はビルドした slug をコンテナからホストへコピーするために指定しています。(これは herokuish で用意されてるものではなくコンテナからホストへファイルをコピーする方法を悩んだ末のアドホックな対応です…) 他にも様々なディレクトリがあります。詳しくは ドキュメント をご覧ください。 slug をインポートする 次に作成した slug を使いアプリケーションの Docker イメージをつくります。 cd $( mktemp -d ) mv /path/to/slug/slug.tgz . echo ' FROM gliderlabs/herokuish COPY slug.tgz /tmp/slug.tgz RUN cat /tmp/slug.tgz | herokuish slug import && rm /tmp/slug.tgz EXPOSE 5000 ' > Dockerfile docker build -f Dockerfile . docker build 時に Context としてカレントディレクトリ全体が送られるため、一時ディレクトリを作成しその中で docker build を行っています。 終わり CLINICS では上記のような手段で作成した Docker イメージを Amazon EC2 Container Registry にアップロードし EB 上で実行しています。 本来であれば、アプリケーションを slug にする部分と、slug をインポートする部分を分割しなくても良いと思いますが、CircleCI で Docker イメージを作成する関係上でこのような方法になりました。 先日 GA となった CircleCI 2.0 にはまだ対応できていないので、今後の課題としたいと思います。 お知らせ メドレーでは、CLINICS だけでなく、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！

はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、 前田 に引き続き私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「思考とデザインスキル」です。発表資料は記事の最後をご覧ください。 テーマに入るまえに… みなさん『黄金比』ってご存知ですか？ 黄金比は美しいとされる物の形に共通してみられる比率で、古くから絵画や彫刻、建築などに使われています。デザイナーであれば、一度以上は使ったことあるのではないでしょうか？私もデザイナーなので何度も使っています。 ただ使ってはいるものの、なぜ美しくなるのか上手く説明ができません。当たり前のように世の中に広まっていて『困ったときの黄金比！』といった安易な思考で使っています。三十路を軽く超えたのでそれではいけないと思い、すこし調べてみました。 そもそも黄金比はエウクレイデスというユーグリッド幾何学を体系化した数学者が見つけた比率なのですが、そのとき彼は『黄金比＝美しい』とは明言していないそうです。自然物や人工物の形には一定の比率で成り立っていると考え、その比率に黄金比と名付けだけとのこと。 その後、その使いやすさから至るところで活用され、その比率に親しみが芽生え巷で受け入れられるようになりました。 認知心理学では、それを『 単純接触効果 』と呼びます。たくさん触れるうちに親しみが沸く機能が人にはもともと備わっていて、黄金比をつかったものが美しく見えるのもその影響ではないか？と言われています。この説を聞いた時、基礎的なのに原理が曖昧なデザイナーのスキルの輪郭がすこしだけハッキリしてきました。 今回の TechLunch では、曖昧だったデザインのスキルを人の思考や心理現象という視点から捉え直してみると、新しい発見があるのかも？と考え、『思考とデザインスキル』のテーマを選びました。 『早い思考』と『遅い思考』 まず最初に人の思考がどういう構造になっているか整理したいと思います。 ＊思考の捉え方には幅があるため、今回は Wikipedia で【思考】の狭義にあたる『情報処理』の内容になります。 ここで 3 つの質問を左から順に答えてください。 大抵の人であれば 2 問目までは瞬時に答えが出たと思います。3 問目はどうでしょうか？ 3 問目は他よりも時間がかかったかと思います。情報を処理するときの思考には 1 問目と 2 問目のように瞬時に答えれるのは『 早い思考 』、3 問目のように少し時間は必要な『 遅い思考 』の 2 つがあります。 行動経済学では、この早い思考を『 システム 1 』、遅い思考を『 システム 2 』と呼んでいます。 システム 1 は、自動的に直感で動く では次にこちらをご覧ください。 どちらの直線が長いでしょうか？答えはどちらも同じです。この問題をご存知の方でも見た瞬間は A が長く見えるのではないでしょうか？ ではこちらではどうでしょうか？ こちらの文字をみたときに、海水浴していて溺れている、もしくはそれに近いシーンを思い浮かべてないでしょうか？　この二語のあいだには『りんご　あまい』というような直接の相関はありません。それにもかかわらず出来れば避けたくなるようなことでも無意識に関連づけられ、シーンが思い浮かんだはずです。 システム 1 には、さきほどの直線の長さのように間違っていたとしても『 見たまま 』を認識する機能と 2 つの文字から『 関連づけ 』をおこないストーリーを組み立てる機能があります。そのどちらもが自分の意識とは関係なく自動で、しかも強力に働いています。 システム 2 は、手動で論理的に動く 最初の二桁の掛け算を思い出してください。日本で算数を学んだ人であれば、二桁の掛け算のとき『考える』段階に移ると思います。これがシステム 2 のスイッチです。システム 1 は常時スイッチが入っていてほぼ自動で答えを出しますが、システム 2 は意識的に『考える』というステップを踏まないと動きません。システム 1 は自動ですが、システム 2 は手動です。 手動のため手間かかりますが、システム 1 にはない用心深さと慎重さがあります。こちらの問題をご覧ください。 『 バットとボールで 110 円、バットはボールより 100 円高い、ボールの値段は？ 』 即答で答えた人は 10 円と答える方が多いようです。こういう問題にはシステム 2 がうってつけで、論理的かつ正確に答えを出そうとします。答えは 5 円です。なかには頭の回転が早く即答できる人がいらっしゃることだと思います。そんな方にはこちらの問題を答えていだだきましょう。 3 日前から食べた夕飯の献立を口に出して発表しながら、『26x673』『245x287』『346x4546』の 3 問を 90 秒以内に解答してください。 いかがでしょうか？システム 2 は手動でうごき論理的で正確に答え出そうとしますが、複雑すぎる演算やマルチタスクにめっぽう弱くスタミナもありません。あきらめて電卓を叩いた方は、システム 2 がギブアップしたということかもしれません。 システム 1 と 2 の特徴は以下。どちらも良いところとそうでないところがあります。 デザインを再構築 これらシステム 1&2 の特性を踏まえた上で簡単なニュース記事のタイポグラフィを整理してみました。 発表資料の 58 ページからご覧ください。 speakerdeck.com こと細かく情報をシステム 1&2 のフィルターを通すことで、タイトルやリード、本文の行間、文字サイズ、それらがシステム 2 が情報を理解しやすくするための１つ機能として捉えることができます。当たり前に使っていたスキルや機能を別の視点で捉えることで違った深い意味を見出せるようになり、大きな発見につながりました。 今回はタイポグラフィだったのでシステム 2 寄りのものでしたが、ビジュアルアイデンティティが強く抽象的なデザインは、意図的にシステム 2 を封じ込めシステム 1 の直感性を利用して内容を理解してもらうこともできます。 システム 1&2 の 2 つの特性を踏まえて使いこなすことで、スキルの深い理解はもちろんですが、感覚とは違うデザインの伝え方の新しいヒントにもなりそうです。 さいごに YouTube や Instagram、LINE はどちらかというと直感性を促すシステム 1 が活躍するアプリです。それだけでなく身の回りにあるサービス全体がその傾向という印象をうけます。システム 1 は普段からスイッチが入っているため、比較的に簡易なステップで働きかけることができます。 一方でシステム 2 は複雑な演算には耐えれず、しっかりとケアしながらでないと十分な運用ができません。ただケアをしっかりすると恩恵も大きいといえます。 金融、教育、雇用、そして医療と、20 年前とは比較にならないほどインターネットは人生の節目に深く関わるようになったからです。人生に関わる選択をネットで行うとき、 直感だけでなくシステム 2 を働かせて熟考し納得のいく決断を行うことが、よりユーザーの利益につながる と私は考えています。 メドレーで提供しているサービスはユーザーの人生に少なからず関わる性質をもっています。すぐに結論づけしてもらうより、ユーザーにとって正しいと思える判断ができるように、 システム 2 をうまく働かせることができる環境をデザイナーとしてつくっていきたい と思います。 おまけ 今回のテックランチで参考にさせていただいた書籍は以下のものになります。 『 ファスト＆スロー（上・下） 』ダニエル・カーネマン 『 予想通りに不合理 』ダン・アリエリ 『 錯覚の科学 』クリストファー・チャブルス＆ダニエル・シモンズ 『 UI デザインの心理学 』ジェフ・ジョンソン 今回のお話は、本当に本当に表面の部分になります。流し読みでも参考になるので手に取って見てください。またこういうことに興味がわいたデザイナーさん・エンジニアさん、是非是非メドレーに遊びに来てください！（絶賛募集中です！） お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 今後ともメドレーを、よろしくお願いいたします！