こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ www.wantedly.com www.wantedly.com その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ www.wantedly.com www.wantedly.com その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ www.wantedly.com www.wantedly.com その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

こんにちは。開発本部の 大岡 です。オンライン診療アプリ「 CLINICS 」の開発を担当しているエンジニアです。2017 年 6 月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。 メドレーでは、定期的に TechLunch という社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアが Ionic を触ってみた」です。 色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。 なぜ Ionic を触ろうと思ったか ウェブアプリ・ネイティブアプリ(このエントリーでは iOS/Android 各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。 最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリの UI が本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん！って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑 とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合に iOS/Android それぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionic を触ってみることにしました。 今回 TechLunch で発表したスライドは以下です。 スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。 ウェブアプリとネイティブアプリ ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。 項目 ウェブアプリ ネイティブアプリ 動作速度 遅め 早め デバイスの機能 使えるものもある 利用可 開発コスト 普通 多め 審査 無し 有り インストール 不要 必要 動作速度は遅めとはいえ、ゲームではなく EC サイトのようなものであれば、そこまで気にするほどではない思います（作りにもよると思いますが）。デバイスの機能に関しては Chrome なら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。 あとは何と言っても、ブラウザと URL さえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かす Progressive Web Application（以下 PWA）というワードもよく目にするようになりました。PWA は動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWA に必要な技術である Service Worker の実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。 個人的に以下のようなパターンの場合 ネイティブの実装が必要 重要だけど機能に更新がはいることがほぼない アプリを使う上で毎回必要なわけではない アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。 上記のようなことをネイティブアプリとして実現できるものに Apach Cordova（以下 Cordova）があります。ウェブアプリは WebView（ネイティブアプリ内でウェブページを表示する部品みたいなもの）に表示し、ネイティブ機能はプラグインとして提供されているのでそれを JavaScript から呼び出すことが可能です。 Ionic とは ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。 オープンソース Apach Cordova 上に構築されている HTML5 を用いたクロスプラットフォームなハイブッドアプリ(PWA 含む)の開発が可能 JavaScript のフレームワークは Angular Angular を採用しているので AltJS は TypeScript ​​UI コンポーネント がいい感じ ネイティブ機能をフルで利用可 実際に触ってみた 公式の Get started にもあるようにブラウザでアプリを表示するまでは 3 ステップです。 ※Node.js がインストールされていることが前提 # 1. ionic と cordova のインストール(この時の Ionic CLI は 3.18.0) $ npm install -g cordova ionic # 2. アプリケーションの作成 $ ionic start [アプリ名] [テンプレート] # 3. アプリケーション起動 $ cd [アプリ名] $ ionic serve テンプレート もよく見る形のものは用意されているのでこだわらなければサクッとそれっぽいものが作れます。下の画像は tabs テンプレートを使用しました。 Android/iOS の開発環境が整った状態ですと以下のコマンドで、エミュレータを起動しネイティブアプリとしてインストールすることができます。 # 1. 対象の OS を追加 $ ionic cordova platform add [ios/android] # 2. エミュレータ起動かつインストール $ ionic cordova run [ios/android] # 2.5 ウェブアセット更新と連動してアプリ更新させる場合 $ ionic cordova run [ios/android] --livereload ここまでは本当に簡単です。起動時に --livereload オプションをつけるとウェブのアセットが更新されるとアプリ内の画面も更新されるので便利です。ネイティブの機能を利用したくなった場合も多くのプラグインが提供されているのでウェブの知識だけでもある程度のアプリは作れると思います。 便利そうだし簡単にアプリ作れそう！となりますが、やりたいことがプラグインで提供されていなかった場合は自分で作成しないといけません。プラグインの作成は iOS/Android それぞれで作らないといけないため知識もそれぞれ必要です。そして、このプラグインを作るのがウェブの知識だけだと割と苦戦します。 SkyWay を利用してビデオチャットアプリを作ってみた SkyWay とは NTT コミュニケーションズが提供している WebRTC を利用したビデオチャット等ができるサービスです。今回この SkyWay を利用して、Android のみですがビデオチャットアプリを作ってみました。 Android プラグイン作成 SkyWay のプラグインがなかったのでプラグインを作成します。画面のあるプラグインの作成に結構はまりました（基本的なプラグイン作成の説明は、検索すればすぐに見つかると思うので省略させていただきます）。解決して思うようには動いたのですが、これでいいのかわかりません。いい感じの解決法があったら教えてください。 今回は SkyWay の Android サンプルコード に少し手を入れて利用させて頂きプラグインを作成してみました。ざっくりディレクトリ構成は以下のようになりました。 plugin-skyway ├── platform │ └── android │ └── AndroidStudio で作成したプロジェクト ( SkyWay サンプルソース ) └── plugin ├── package.json ├── plugin.xml ├── src │ ├── android │ │ ├── cordova-plugin-skyway.gradle │ │ ├── MainActivity.java │ │ ├── PeerListDialogFragment.java │ │ ├── SkyWay.java │ │ ├── layout │ │ │ ├── activity_main.xml │ │ │ └── fragment_dialog_peerlist.xml │ │ └── libs │ │ └── skyway.aar │ └── ios └── www └── SkyWay.js plugin-skyway/platform に各 OS のプラグイン用プロジェクトがある感じです。 plugin-skyway/plugin が Ionic のプロジェクトにインストールされるディレクトリです。 はじめは、 plugin-skyway/plugin/src/android に AndroidStudio で作成したプロジェクトを置いてました。しかし、Ionic のプロジェクトに作成したプラグインをスンストールすると不要なものまで含まれてしまったので、 plugin-skyway/platform/android にプロジェクトを作成し必要なファイルのみを plugin-skyway/plugin/src/android にコピーすることにしました。 AndroidStudio でプラグインを開発する際は、一度 Ionic のプロジェクトを Android でビルドし、Ionic プロジェクト内の platforms/android/CordovaLib/build/outputs/aar/CordovaLib-debug.aar をプラグインのプロジェクトで取り込まないといけないようです。 いざ Ionic プロジェクトにインストールしてビルドすると ConstraintLayout が無いとか SkyWay の SDK のバージョンがどうとか怒られますが、Android の開発の仕組みが理解できていなかったので下記の「パッケージ R は存在しません」というエラーに時間を取られました。 .. ./MainActivity.java:258: エラー: パッケージ R は存在しません Canvas canvas = (Canvas) findViewById( R.id.svLocalView ); のように R.java がないと怒られます。 AndroidStudio から GUI でポチポチと画面を作ると R.java というのができいい感じに解決してくれるようなのですが、今回のように xml のみを移動させるだけだと R.java が作られません。 そこで R.id.svLocalView のような R. の箇所を下記のように置き換えて、やっとビルドが通るようになりました。 getResources (). getIdentifier ( "svLocalView" , "id" , getPackageName ()) 最終的に以下のようなものができました。 SkyWay ボタンをタップするとネイティブの画面が立ち上がり、Android の SkyWay SDK を利用してテレビ電話をすることができます。 クローズボタンをタップするとネイティブ画面が終了し、WebView 部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。 ※アニメーション GIF の容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです まとめ 今回触ってみたというより指先が触れた程度ですが、全然 Ionic でもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、 使ってくれる人が求めるもの を提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。 お知らせ 12/6（水）、こんなイベント（というか飲み会）をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか？ www.wantedly.com www.wantedly.com その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。 About 株式会社メドレー - Wantedly You can read employee interviews and the latest company's initiative of 株式会社メドレー. 急速な高齢化や医療費の高騰、医療現場の疲弊が叫ばれる中で、このままでは家計を大きく圧迫して支えきれなくなり、日本の医療は崩壊してしまいます。この状態を解消するための鍵が「医療現場におけるクラウド活用を駆使した業務効率化」です。 しかし日本では、半数以上の医療機関がいまだに紙カルテを利用しているなど、クラウド化は疎かデジタル活用も進んでいないのが現状です。私たちはテクノロジーを活用した事業やプロジェクトを通じて、医療ヘルスケア分野のデジタル活用を推進し、日本の未来を作るための取り組みを行っていきます。 www.wantedly.com

最近 PS4 のグランツーリスモスポーツをやり始めて、自宅のネット環境の遅さに気づいたデザイナーの マエダ です。前回は DLS について ご紹介させていただきましたが、今回はメドレーに入社して感じた「デザインプロセスの違い」について自分なりにまとめてみました。 あとで読みたい人向けに、エレベーターピッチ風にまとめると、 [ CLINICS ] というサービスは [ 患者と医療機関向け ] それぞれサービスを提供しているが [ 提供価値の違い ] によって [ デザインの役割が異なる ] ことに気づいた 特に [ 医療機関向け ] は [ UI が重要 ] となり [ 伝えることを目的とした Web サイト ] とは違って [ UI デザインの良し悪しがプロダクト全体の品質に関わる ] ため [ 事業や技術を理解 ] した[ デザインオリエンテッド ] が求められる というような内容です。 ユーザーによって異なる提供価値 メドレーに入社してから、オンライン診療アプリ「 CLINICS（クリニクス） 」というサービスのデザインを主に担当しているのですが、患者と医療機関側で提供しているプロダクトの内容が異なります。 オンライン診療の内容を伝え、利用を促すための Web サイト（患者・医療機関双方） 患者がオンラインで通院を行うためのアプリ 医療機関側がオンラインで遠隔診療を行うためのシステム サービスの入り口となる Web サイト Web ページの役割としては、オンライン診療というものがどういったもので、CLINICS を利用するとどういう課題解決につながるのか、というサービスの特徴を患者と医療機関双方に「 伝えるためのデザイン 」が必要となります。 デザインするにあたって注力すべきポイントは、装飾やイメージ画像などシンボリックなデザインとストーリー性のある導線設計をすることで、視覚的に特徴を伝わりやすくし、またコンバージョンポイントへ誘導するため、ボタン等は目立たせるなど、適切に情報を伝え、行動を促すためのデザインが重要になります。 患者がオンライン診療を行うためのアプリ アプリは患者がオンライン診療をするための「病院検索」→「予約」→「問診」→「診察」→「決済」の機能をシームレスに繋げるためストレスのかからないユーザー体験を提供することが重要です。 そもそもオンライン診療のメリットとして、待ち時間の軽減や、落ち着いた環境で診察ができるなどが挙げられるため、そこに至るまでのユーザー体験を台無しにしてしまう UI では元も子もなくなってしまいます。 アプリでは「伝えるデザイン」よりも「 機能的なデザイン 」が必要になりますが、ユーザーの行動を途切れさせないよう、不必要な要素や導線を極力排除して、非常にシンプルな UI 設計をおこなっており、機能自体を主張しないデザインを心がけています。前回このブログでもとりあげた DLS も、そういった設計思想のもと開発を進めていたからこそ実現できたと思っています。 医療機関向けの遠隔診療システム 医療機関側に提供しているシステムは、オンライン診療を行うためのツールです。 Web サイトのように「伝えるデザイン」やコンバージョン重視ではなく、「 より機能的に使いやすいデザイン 」が重要になります。 このような画面を Bootstrap のような UI テンプレートそのままの見た目で構築してしまうと、技術的に素晴らしいものができたとしても、使い勝手が悪く貧弱な機能と見られかねないため、 デザイナーが管理画面の UI 設計に携わることは、ビジネス的にも非常に重要な要素 です。 特に CLINICS の医療機関向けのシステムは、実際にオンラインで患者の診察を行うツールのため、医療機関側が診療行為をつつがなく終えられるような UI 設計が重要です。 MVP 的な手法で、とりあえずリリースして検証を重ねていくというスタンスがとれないため、リリースするまでに機能的に不備がないか、医療従事者が迷わず正しく使える UI 設計になっているかなど、社内や実際の医療機関のテストを繰り返し、試行錯誤を経てリリースするという、プロダクトデザインをしている感覚になり「伝えるデザイン」とは違った思考でデザインに取り組んでいます。 機能重視なサービスこそ、直感的にシンプルな UI が重要 このように CLINICS という 1 つのサービスを構成する要素の中でも、ターゲットユーザーや提供価値の違いによって、デザインアプローチや重要視する視点が異なります。 たとえば、自分も業務でよく利用するプロトタイピングツールの inVision もログイン前は、利用シーンやより魅力的なサービスであるということを伝えるためのデザインをしており、ログイン後は直感的にわかりやすいシンプルな UI 設計で、ログイン前後でサービスの UI が異なります。 inVision も機能は豊富ですが、プロトタイピングを行う上で非常にシンプルな操作性を提供しており、無駄な説明や導線がなくても直感的に使える UI は、継続して利用できる安心感にもつながり、見習うべき UI だなと思っています。 （inVision の画面の違い） CLINICS の医療機関向けシステムも受付管理やスケジュール、オンライン診療を行う機能など複数の機能をひとつのサービスとして提供しているため、UI 的に複雑になりかねません。複雑な機能をまとめ、画面上にシンプルに落とし込めるかどうかというのを吟味し、作っては壊し、作っては壊しを繰り返しします。 これならいける！とおもった UI も、機能面での見落としなどがあったりすると導線に矛盾が生じたり、シンプルに表現したつもりが、逆に使い勝手の悪い UI になってしまったり。UI を考えるというのは、感性に訴えるデザインとは違ったよりロジカルな思考が必要で、デザインしながら四苦八苦して、ぶつぶつ独り言を言うことが多くなります w デザインオリエンテッドなプロダクト開発 Web サービスであればいかに目標としているコンバージョン率を高めるかどうか、分析〜調査〜開発というサイクルをベースとした運用になりますが、特に 医療機関向けのシステムの場合は、ムダな機能や使いづらい UI だとサービス的に不安要素を抱かせる要因にもなり、ビジネスの成功可否に直結します 。 そのため、リリースまでに UI を磨けるだけ磨き、実際に医療機関の現場に出向いてどういうフローで診察を行っているのかなどヒアリングしたり、出来上がった機能を試してもらうなどし、十分に検討した上でリリースしています。こうしたデザインを重視した開発が行える点はメドレーだからこその開発体制かもしれません。 このような デザインオリエンテッドなプロダクト開発を行う上で重要なポイントは、事業理解とエンジニアとの密な連携 です。表面的なデザインではなく、実際に使われる利用シーンを想像しつつも、体験することが難しい医療サービスだからこそ、前提の知識やヒアリング、ユーザーテストなどが重要となりますし、機能的な部分に関してはエンジニアと仕様について議論したり、ユースケースを踏まえてどのような UI に落とし込むべきかを考えながらデザインに落とし込んでいきます。インタラクティブな表現など inVision でも表現しきれない細かい動きや導線などは、実装時にエンジニアに伝わりやすいようフロントエンド部分のコーディングを自ら行うことでコードを通じてエンジニアとコミュニケーションが取りやすくもなるので、フロントエンドも把握しておくことは重要です。 まとめ 個人的には「伝えるデザイン」と「機能的なデザイン」で、明確に思考をわけて考えてデザインしてきたわけではなかったのですが、提供すべき価値の違いによって 左脳と右脳それぞれ使い分けてデザインしている かもしれないということに気付かされました。これは以前デザイナーの小山がブログで書いた システム 1（自動的に直感で動く”早い思考”）とシステム 2（手動で論理的に動く”遅い思考”） が自分の中で振り子のように行き来してるだろうなと感じたので、興味のある方は「思考とデザインスキル」も読んでもらうとわかりやすいです。 思考とデザインスキル 〜メドレー TechLunch〜 | MEDLEY Developer Portal はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、前田に引き続き... developer.medley.jp 最後に ふだんビールばっかり呑んで 適当な人とレッテルを貼られているマエダですが、今回は真面目なことを書いてみましたがいかがでしたでしょうか。このブログを書いてて正直疲れたので、システム 2 が働いてるに違いないと思います。こんな私と一緒に仕事がしたい、呑みたいというデザイナーやエンジニアさん。応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

最近 PS4 のグランツーリスモスポーツをやり始めて、自宅のネット環境の遅さに気づいたデザイナーの マエダ です。前回は DLS について ご紹介させていただきましたが、今回はメドレーに入社して感じた「デザインプロセスの違い」について自分なりにまとめてみました。 あとで読みたい人向けに、エレベーターピッチ風にまとめると、 [ CLINICS ] というサービスは [ 患者と医療機関向け ] それぞれサービスを提供しているが [ 提供価値の違い ] によって [ デザインの役割が異なる ] ことに気づいた 特に [ 医療機関向け ] は [ UI が重要 ] となり [ 伝えることを目的とした Web サイト ] とは違って [ UI デザインの良し悪しがプロダクト全体の品質に関わる ] ため [ 事業や技術を理解 ] した[ デザインオリエンテッド ] が求められる というような内容です。 ユーザーによって異なる提供価値 メドレーに入社してから、オンライン診療アプリ「 CLINICS（クリニクス） 」というサービスのデザインを主に担当しているのですが、患者と医療機関側で提供しているプロダクトの内容が異なります。 オンライン診療の内容を伝え、利用を促すための Web サイト（患者・医療機関双方） 患者がオンラインで通院を行うためのアプリ 医療機関側がオンラインで遠隔診療を行うためのシステム サービスの入り口となる Web サイト Web ページの役割としては、オンライン診療というものがどういったもので、CLINICS を利用するとどういう課題解決につながるのか、というサービスの特徴を患者と医療機関双方に「 伝えるためのデザイン 」が必要となります。 デザインするにあたって注力すべきポイントは、装飾やイメージ画像などシンボリックなデザインとストーリー性のある導線設計をすることで、視覚的に特徴を伝わりやすくし、またコンバージョンポイントへ誘導するため、ボタン等は目立たせるなど、適切に情報を伝え、行動を促すためのデザインが重要になります。 患者がオンライン診療を行うためのアプリ アプリは患者がオンライン診療をするための「病院検索」→「予約」→「問診」→「診察」→「決済」の機能をシームレスに繋げるためストレスのかからないユーザー体験を提供することが重要です。 そもそもオンライン診療のメリットとして、待ち時間の軽減や、落ち着いた環境で診察ができるなどが挙げられるため、そこに至るまでのユーザー体験を台無しにしてしまう UI では元も子もなくなってしまいます。 アプリでは「伝えるデザイン」よりも「 機能的なデザイン 」が必要になりますが、ユーザーの行動を途切れさせないよう、不必要な要素や導線を極力排除して、非常にシンプルな UI 設計をおこなっており、機能自体を主張しないデザインを心がけています。前回このブログでもとりあげた DLS も、そういった設計思想のもと開発を進めていたからこそ実現できたと思っています。 医療機関向けの遠隔診療システム 医療機関側に提供しているシステムは、オンライン診療を行うためのツールです。 Web サイトのように「伝えるデザイン」やコンバージョン重視ではなく、「 より機能的に使いやすいデザイン 」が重要になります。 このような画面を Bootstrap のような UI テンプレートそのままの見た目で構築してしまうと、技術的に素晴らしいものができたとしても、使い勝手が悪く貧弱な機能と見られかねないため、 デザイナーが管理画面の UI 設計に携わることは、ビジネス的にも非常に重要な要素 です。 特に CLINICS の医療機関向けのシステムは、実際にオンラインで患者の診察を行うツールのため、医療機関側が診療行為をつつがなく終えられるような UI 設計が重要です。 MVP 的な手法で、とりあえずリリースして検証を重ねていくというスタンスがとれないため、リリースするまでに機能的に不備がないか、医療従事者が迷わず正しく使える UI 設計になっているかなど、社内や実際の医療機関のテストを繰り返し、試行錯誤を経てリリースするという、プロダクトデザインをしている感覚になり「伝えるデザイン」とは違った思考でデザインに取り組んでいます。 機能重視なサービスこそ、直感的にシンプルな UI が重要 このように CLINICS という 1 つのサービスを構成する要素の中でも、ターゲットユーザーや提供価値の違いによって、デザインアプローチや重要視する視点が異なります。 たとえば、自分も業務でよく利用するプロトタイピングツールの inVision もログイン前は、利用シーンやより魅力的なサービスであるということを伝えるためのデザインをしており、ログイン後は直感的にわかりやすいシンプルな UI 設計で、ログイン前後でサービスの UI が異なります。 inVision も機能は豊富ですが、プロトタイピングを行う上で非常にシンプルな操作性を提供しており、無駄な説明や導線がなくても直感的に使える UI は、継続して利用できる安心感にもつながり、見習うべき UI だなと思っています。 （inVision の画面の違い） CLINICS の医療機関向けシステムも受付管理やスケジュール、オンライン診療を行う機能など複数の機能をひとつのサービスとして提供しているため、UI 的に複雑になりかねません。複雑な機能をまとめ、画面上にシンプルに落とし込めるかどうかというのを吟味し、作っては壊し、作っては壊しを繰り返しします。 これならいける！とおもった UI も、機能面での見落としなどがあったりすると導線に矛盾が生じたり、シンプルに表現したつもりが、逆に使い勝手の悪い UI になってしまったり。UI を考えるというのは、感性に訴えるデザインとは違ったよりロジカルな思考が必要で、デザインしながら四苦八苦して、ぶつぶつ独り言を言うことが多くなります w デザインオリエンテッドなプロダクト開発 Web サービスであればいかに目標としているコンバージョン率を高めるかどうか、分析〜調査〜開発というサイクルをベースとした運用になりますが、特に 医療機関向けのシステムの場合は、ムダな機能や使いづらい UI だとサービス的に不安要素を抱かせる要因にもなり、ビジネスの成功可否に直結します 。 そのため、リリースまでに UI を磨けるだけ磨き、実際に医療機関の現場に出向いてどういうフローで診察を行っているのかなどヒアリングしたり、出来上がった機能を試してもらうなどし、十分に検討した上でリリースしています。こうしたデザインを重視した開発が行える点はメドレーだからこその開発体制かもしれません。 このような デザインオリエンテッドなプロダクト開発を行う上で重要なポイントは、事業理解とエンジニアとの密な連携 です。表面的なデザインではなく、実際に使われる利用シーンを想像しつつも、体験することが難しい医療サービスだからこそ、前提の知識やヒアリング、ユーザーテストなどが重要となりますし、機能的な部分に関してはエンジニアと仕様について議論したり、ユースケースを踏まえてどのような UI に落とし込むべきかを考えながらデザインに落とし込んでいきます。インタラクティブな表現など inVision でも表現しきれない細かい動きや導線などは、実装時にエンジニアに伝わりやすいようフロントエンド部分のコーディングを自ら行うことでコードを通じてエンジニアとコミュニケーションが取りやすくもなるので、フロントエンドも把握しておくことは重要です。 まとめ 個人的には「伝えるデザイン」と「機能的なデザイン」で、明確に思考をわけて考えてデザインしてきたわけではなかったのですが、提供すべき価値の違いによって 左脳と右脳それぞれ使い分けてデザインしている かもしれないということに気付かされました。これは以前デザイナーの小山がブログで書いた システム 1（自動的に直感で動く”早い思考”）とシステム 2（手動で論理的に動く”遅い思考”） が自分の中で振り子のように行き来してるだろうなと感じたので、興味のある方は「思考とデザインスキル」も読んでもらうとわかりやすいです。 https://developer.medley.jp/entry/2017/09/14/132031 最後に ふだんビールばっかり呑んで 適当な人とレッテルを貼られているマエダですが、今回は真面目なことを書いてみましたがいかがでしたでしょうか。このブログを書いてて正直疲れたので、システム 2 が働いてるに違いないと思います。こんな私と一緒に仕事がしたい、呑みたいというデザイナーやエンジニアさん。応募お待ちしております。 https://www.medley.jp/jobs/ https://www.medley.jp/team/creator-story.html

最近 PS4 のグランツーリスモスポーツをやり始めて、自宅のネット環境の遅さに気づいたデザイナーの マエダ です。前回は DLS について ご紹介させていただきましたが、今回はメドレーに入社して感じた「デザインプロセスの違い」について自分なりにまとめてみました。 あとで読みたい人向けに、エレベーターピッチ風にまとめると、 [ CLINICS ] というサービスは [ 患者と医療機関向け ] それぞれサービスを提供しているが [ 提供価値の違い ] によって [ デザインの役割が異なる ] ことに気づいた 特に [ 医療機関向け ] は [ UI が重要 ] となり [ 伝えることを目的とした Web サイト ] とは違って [ UI デザインの良し悪しがプロダクト全体の品質に関わる ] ため [ 事業や技術を理解 ] した[ デザインオリエンテッド ] が求められる というような内容です。 ユーザーによって異なる提供価値 メドレーに入社してから、オンライン診療アプリ「 CLINICS（クリニクス） 」というサービスのデザインを主に担当しているのですが、患者と医療機関側で提供しているプロダクトの内容が異なります。 オンライン診療の内容を伝え、利用を促すための Web サイト（患者・医療機関双方） 患者がオンラインで通院を行うためのアプリ 医療機関側がオンラインで遠隔診療を行うためのシステム サービスの入り口となる Web サイト Web ページの役割としては、オンライン診療というものがどういったもので、CLINICS を利用するとどういう課題解決につながるのか、というサービスの特徴を患者と医療機関双方に「 伝えるためのデザイン 」が必要となります。 デザインするにあたって注力すべきポイントは、装飾やイメージ画像などシンボリックなデザインとストーリー性のある導線設計をすることで、視覚的に特徴を伝わりやすくし、またコンバージョンポイントへ誘導するため、ボタン等は目立たせるなど、適切に情報を伝え、行動を促すためのデザインが重要になります。 患者がオンライン診療を行うためのアプリ アプリは患者がオンライン診療をするための「病院検索」→「予約」→「問診」→「診察」→「決済」の機能をシームレスに繋げるためストレスのかからないユーザー体験を提供することが重要です。 そもそもオンライン診療のメリットとして、待ち時間の軽減や、落ち着いた環境で診察ができるなどが挙げられるため、そこに至るまでのユーザー体験を台無しにしてしまう UI では元も子もなくなってしまいます。 アプリでは「伝えるデザイン」よりも「 機能的なデザイン 」が必要になりますが、ユーザーの行動を途切れさせないよう、不必要な要素や導線を極力排除して、非常にシンプルな UI 設計をおこなっており、機能自体を主張しないデザインを心がけています。前回このブログでもとりあげた DLS も、そういった設計思想のもと開発を進めていたからこそ実現できたと思っています。 医療機関向けの遠隔診療システム 医療機関側に提供しているシステムは、オンライン診療を行うためのツールです。 Web サイトのように「伝えるデザイン」やコンバージョン重視ではなく、「 より機能的に使いやすいデザイン 」が重要になります。 このような画面を Bootstrap のような UI テンプレートそのままの見た目で構築してしまうと、技術的に素晴らしいものができたとしても、使い勝手が悪く貧弱な機能と見られかねないため、 デザイナーが管理画面の UI 設計に携わることは、ビジネス的にも非常に重要な要素 です。 特に CLINICS の医療機関向けのシステムは、実際にオンラインで患者の診察を行うツールのため、医療機関側が診療行為をつつがなく終えられるような UI 設計が重要です。 MVP 的な手法で、とりあえずリリースして検証を重ねていくというスタンスがとれないため、リリースするまでに機能的に不備がないか、医療従事者が迷わず正しく使える UI 設計になっているかなど、社内や実際の医療機関のテストを繰り返し、試行錯誤を経てリリースするという、プロダクトデザインをしている感覚になり「伝えるデザイン」とは違った思考でデザインに取り組んでいます。 機能重視なサービスこそ、直感的にシンプルな UI が重要 このように CLINICS という 1 つのサービスを構成する要素の中でも、ターゲットユーザーや提供価値の違いによって、デザインアプローチや重要視する視点が異なります。 たとえば、自分も業務でよく利用するプロトタイピングツールの inVision もログイン前は、利用シーンやより魅力的なサービスであるということを伝えるためのデザインをしており、ログイン後は直感的にわかりやすいシンプルな UI 設計で、ログイン前後でサービスの UI が異なります。 inVision も機能は豊富ですが、プロトタイピングを行う上で非常にシンプルな操作性を提供しており、無駄な説明や導線がなくても直感的に使える UI は、継続して利用できる安心感にもつながり、見習うべき UI だなと思っています。 （inVision の画面の違い） CLINICS の医療機関向けシステムも受付管理やスケジュール、オンライン診療を行う機能など複数の機能をひとつのサービスとして提供しているため、UI 的に複雑になりかねません。複雑な機能をまとめ、画面上にシンプルに落とし込めるかどうかというのを吟味し、作っては壊し、作っては壊しを繰り返しします。 これならいける！とおもった UI も、機能面での見落としなどがあったりすると導線に矛盾が生じたり、シンプルに表現したつもりが、逆に使い勝手の悪い UI になってしまったり。UI を考えるというのは、感性に訴えるデザインとは違ったよりロジカルな思考が必要で、デザインしながら四苦八苦して、ぶつぶつ独り言を言うことが多くなります w デザインオリエンテッドなプロダクト開発 Web サービスであればいかに目標としているコンバージョン率を高めるかどうか、分析〜調査〜開発というサイクルをベースとした運用になりますが、特に 医療機関向けのシステムの場合は、ムダな機能や使いづらい UI だとサービス的に不安要素を抱かせる要因にもなり、ビジネスの成功可否に直結します 。 そのため、リリースまでに UI を磨けるだけ磨き、実際に医療機関の現場に出向いてどういうフローで診察を行っているのかなどヒアリングしたり、出来上がった機能を試してもらうなどし、十分に検討した上でリリースしています。こうしたデザインを重視した開発が行える点はメドレーだからこその開発体制かもしれません。 このような デザインオリエンテッドなプロダクト開発を行う上で重要なポイントは、事業理解とエンジニアとの密な連携 です。表面的なデザインではなく、実際に使われる利用シーンを想像しつつも、体験することが難しい医療サービスだからこそ、前提の知識やヒアリング、ユーザーテストなどが重要となりますし、機能的な部分に関してはエンジニアと仕様について議論したり、ユースケースを踏まえてどのような UI に落とし込むべきかを考えながらデザインに落とし込んでいきます。インタラクティブな表現など inVision でも表現しきれない細かい動きや導線などは、実装時にエンジニアに伝わりやすいようフロントエンド部分のコーディングを自ら行うことでコードを通じてエンジニアとコミュニケーションが取りやすくもなるので、フロントエンドも把握しておくことは重要です。 まとめ 個人的には「伝えるデザイン」と「機能的なデザイン」で、明確に思考をわけて考えてデザインしてきたわけではなかったのですが、提供すべき価値の違いによって 左脳と右脳それぞれ使い分けてデザインしている かもしれないということに気付かされました。これは以前デザイナーの小山がブログで書いた システム 1（自動的に直感で動く”早い思考”）とシステム 2（手動で論理的に動く”遅い思考”） が自分の中で振り子のように行き来してるだろうなと感じたので、興味のある方は「思考とデザインスキル」も読んでもらうとわかりやすいです。 思考とデザインスキル 〜メドレー TechLunch〜 | MEDLEY Developer Portal はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、前田に引き続き... developer.medley.jp 最後に ふだんビールばっかり呑んで 適当な人とレッテルを貼られているマエダですが、今回は真面目なことを書いてみましたがいかがでしたでしょうか。このブログを書いてて正直疲れたので、システム 2 が働いてるに違いないと思います。こんな私と一緒に仕事がしたい、呑みたいというデザイナーやエンジニアさん。応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

最近 PS4 のグランツーリスモスポーツをやり始めて、自宅のネット環境の遅さに気づいたデザイナーの マエダ です。前回は DLS について ご紹介させていただきましたが、今回はメドレーに入社して感じた「デザインプロセスの違い」について自分なりにまとめてみました。 あとで読みたい人向けに、エレベーターピッチ風にまとめると、 [ CLINICS ] というサービスは [ 患者と医療機関向け ] それぞれサービスを提供しているが [ 提供価値の違い ] によって [ デザインの役割が異なる ] ことに気づいた 特に [ 医療機関向け ] は [ UI が重要 ] となり [ 伝えることを目的とした Web サイト ] とは違って [ UI デザインの良し悪しがプロダクト全体の品質に関わる ] ため [ 事業や技術を理解 ] した[ デザインオリエンテッド ] が求められる というような内容です。 ユーザーによって異なる提供価値 メドレーに入社してから、オンライン診療アプリ「 CLINICS（クリニクス） 」というサービスのデザインを主に担当しているのですが、患者と医療機関側で提供しているプロダクトの内容が異なります。 オンライン診療の内容を伝え、利用を促すための Web サイト（患者・医療機関双方） 患者がオンラインで通院を行うためのアプリ 医療機関側がオンラインで遠隔診療を行うためのシステム サービスの入り口となる Web サイト Web ページの役割としては、オンライン診療というものがどういったもので、CLINICS を利用するとどういう課題解決につながるのか、というサービスの特徴を患者と医療機関双方に「 伝えるためのデザイン 」が必要となります。 デザインするにあたって注力すべきポイントは、装飾やイメージ画像などシンボリックなデザインとストーリー性のある導線設計をすることで、視覚的に特徴を伝わりやすくし、またコンバージョンポイントへ誘導するため、ボタン等は目立たせるなど、適切に情報を伝え、行動を促すためのデザインが重要になります。 患者がオンライン診療を行うためのアプリ アプリは患者がオンライン診療をするための「病院検索」→「予約」→「問診」→「診察」→「決済」の機能をシームレスに繋げるためストレスのかからないユーザー体験を提供することが重要です。 そもそもオンライン診療のメリットとして、待ち時間の軽減や、落ち着いた環境で診察ができるなどが挙げられるため、そこに至るまでのユーザー体験を台無しにしてしまう UI では元も子もなくなってしまいます。 アプリでは「伝えるデザイン」よりも「 機能的なデザイン 」が必要になりますが、ユーザーの行動を途切れさせないよう、不必要な要素や導線を極力排除して、非常にシンプルな UI 設計をおこなっており、機能自体を主張しないデザインを心がけています。前回このブログでもとりあげた DLS も、そういった設計思想のもと開発を進めていたからこそ実現できたと思っています。 医療機関向けの遠隔診療システム 医療機関側に提供しているシステムは、オンライン診療を行うためのツールです。 Web サイトのように「伝えるデザイン」やコンバージョン重視ではなく、「 より機能的に使いやすいデザイン 」が重要になります。 このような画面を Bootstrap のような UI テンプレートそのままの見た目で構築してしまうと、技術的に素晴らしいものができたとしても、使い勝手が悪く貧弱な機能と見られかねないため、 デザイナーが管理画面の UI 設計に携わることは、ビジネス的にも非常に重要な要素 です。 特に CLINICS の医療機関向けのシステムは、実際にオンラインで患者の診察を行うツールのため、医療機関側が診療行為をつつがなく終えられるような UI 設計が重要です。 MVP 的な手法で、とりあえずリリースして検証を重ねていくというスタンスがとれないため、リリースするまでに機能的に不備がないか、医療従事者が迷わず正しく使える UI 設計になっているかなど、社内や実際の医療機関のテストを繰り返し、試行錯誤を経てリリースするという、プロダクトデザインをしている感覚になり「伝えるデザイン」とは違った思考でデザインに取り組んでいます。 機能重視なサービスこそ、直感的にシンプルな UI が重要 このように CLINICS という 1 つのサービスを構成する要素の中でも、ターゲットユーザーや提供価値の違いによって、デザインアプローチや重要視する視点が異なります。 たとえば、自分も業務でよく利用するプロトタイピングツールの inVision もログイン前は、利用シーンやより魅力的なサービスであるということを伝えるためのデザインをしており、ログイン後は直感的にわかりやすいシンプルな UI 設計で、ログイン前後でサービスの UI が異なります。 inVision も機能は豊富ですが、プロトタイピングを行う上で非常にシンプルな操作性を提供しており、無駄な説明や導線がなくても直感的に使える UI は、継続して利用できる安心感にもつながり、見習うべき UI だなと思っています。 （inVision の画面の違い） CLINICS の医療機関向けシステムも受付管理やスケジュール、オンライン診療を行う機能など複数の機能をひとつのサービスとして提供しているため、UI 的に複雑になりかねません。複雑な機能をまとめ、画面上にシンプルに落とし込めるかどうかというのを吟味し、作っては壊し、作っては壊しを繰り返しします。 これならいける！とおもった UI も、機能面での見落としなどがあったりすると導線に矛盾が生じたり、シンプルに表現したつもりが、逆に使い勝手の悪い UI になってしまったり。UI を考えるというのは、感性に訴えるデザインとは違ったよりロジカルな思考が必要で、デザインしながら四苦八苦して、ぶつぶつ独り言を言うことが多くなります w デザインオリエンテッドなプロダクト開発 Web サービスであればいかに目標としているコンバージョン率を高めるかどうか、分析〜調査〜開発というサイクルをベースとした運用になりますが、特に 医療機関向けのシステムの場合は、ムダな機能や使いづらい UI だとサービス的に不安要素を抱かせる要因にもなり、ビジネスの成功可否に直結します 。 そのため、リリースまでに UI を磨けるだけ磨き、実際に医療機関の現場に出向いてどういうフローで診察を行っているのかなどヒアリングしたり、出来上がった機能を試してもらうなどし、十分に検討した上でリリースしています。こうしたデザインを重視した開発が行える点はメドレーだからこその開発体制かもしれません。 このような デザインオリエンテッドなプロダクト開発を行う上で重要なポイントは、事業理解とエンジニアとの密な連携 です。表面的なデザインではなく、実際に使われる利用シーンを想像しつつも、体験することが難しい医療サービスだからこそ、前提の知識やヒアリング、ユーザーテストなどが重要となりますし、機能的な部分に関してはエンジニアと仕様について議論したり、ユースケースを踏まえてどのような UI に落とし込むべきかを考えながらデザインに落とし込んでいきます。インタラクティブな表現など inVision でも表現しきれない細かい動きや導線などは、実装時にエンジニアに伝わりやすいようフロントエンド部分のコーディングを自ら行うことでコードを通じてエンジニアとコミュニケーションが取りやすくもなるので、フロントエンドも把握しておくことは重要です。 まとめ 個人的には「伝えるデザイン」と「機能的なデザイン」で、明確に思考をわけて考えてデザインしてきたわけではなかったのですが、提供すべき価値の違いによって 左脳と右脳それぞれ使い分けてデザインしている かもしれないということに気付かされました。これは以前デザイナーの小山がブログで書いた システム 1（自動的に直感で動く”早い思考”）とシステム 2（手動で論理的に動く”遅い思考”） が自分の中で振り子のように行き来してるだろうなと感じたので、興味のある方は「思考とデザインスキル」も読んでもらうとわかりやすいです。 思考とデザインスキル 〜メドレー TechLunch〜 | MEDLEY Developer Portal はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、前田に引き続き... developer.medley.jp 最後に ふだんビールばっかり呑んで 適当な人とレッテルを貼られているマエダですが、今回は真面目なことを書いてみましたがいかがでしたでしょうか。このブログを書いてて正直疲れたので、システム 2 が働いてるに違いないと思います。こんな私と一緒に仕事がしたい、呑みたいというデザイナーやエンジニアさん。応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

最近 PS4 のグランツーリスモスポーツをやり始めて、自宅のネット環境の遅さに気づいたデザイナーの マエダ です。前回は DLS について ご紹介させていただきましたが、今回はメドレーに入社して感じた「デザインプロセスの違い」について自分なりにまとめてみました。 あとで読みたい人向けに、エレベーターピッチ風にまとめると、 [ CLINICS ] というサービスは [ 患者と医療機関向け ] それぞれサービスを提供しているが [ 提供価値の違い ] によって [ デザインの役割が異なる ] ことに気づいた 特に [ 医療機関向け ] は [ UI が重要 ] となり [ 伝えることを目的とした Web サイト ] とは違って [ UI デザインの良し悪しがプロダクト全体の品質に関わる ] ため [ 事業や技術を理解 ] した[ デザインオリエンテッド ] が求められる というような内容です。 ユーザーによって異なる提供価値 メドレーに入社してから、オンライン診療アプリ「 CLINICS（クリニクス） 」というサービスのデザインを主に担当しているのですが、患者と医療機関側で提供しているプロダクトの内容が異なります。 オンライン診療の内容を伝え、利用を促すための Web サイト（患者・医療機関双方） 患者がオンラインで通院を行うためのアプリ 医療機関側がオンラインで遠隔診療を行うためのシステム サービスの入り口となる Web サイト Web ページの役割としては、オンライン診療というものがどういったもので、CLINICS を利用するとどういう課題解決につながるのか、というサービスの特徴を患者と医療機関双方に「 伝えるためのデザイン 」が必要となります。 デザインするにあたって注力すべきポイントは、装飾やイメージ画像などシンボリックなデザインとストーリー性のある導線設計をすることで、視覚的に特徴を伝わりやすくし、またコンバージョンポイントへ誘導するため、ボタン等は目立たせるなど、適切に情報を伝え、行動を促すためのデザインが重要になります。 患者がオンライン診療を行うためのアプリ アプリは患者がオンライン診療をするための「病院検索」→「予約」→「問診」→「診察」→「決済」の機能をシームレスに繋げるためストレスのかからないユーザー体験を提供することが重要です。 そもそもオンライン診療のメリットとして、待ち時間の軽減や、落ち着いた環境で診察ができるなどが挙げられるため、そこに至るまでのユーザー体験を台無しにしてしまう UI では元も子もなくなってしまいます。 アプリでは「伝えるデザイン」よりも「 機能的なデザイン 」が必要になりますが、ユーザーの行動を途切れさせないよう、不必要な要素や導線を極力排除して、非常にシンプルな UI 設計をおこなっており、機能自体を主張しないデザインを心がけています。前回このブログでもとりあげた DLS も、そういった設計思想のもと開発を進めていたからこそ実現できたと思っています。 医療機関向けの遠隔診療システム 医療機関側に提供しているシステムは、オンライン診療を行うためのツールです。 Web サイトのように「伝えるデザイン」やコンバージョン重視ではなく、「 より機能的に使いやすいデザイン 」が重要になります。 このような画面を Bootstrap のような UI テンプレートそのままの見た目で構築してしまうと、技術的に素晴らしいものができたとしても、使い勝手が悪く貧弱な機能と見られかねないため、 デザイナーが管理画面の UI 設計に携わることは、ビジネス的にも非常に重要な要素 です。 特に CLINICS の医療機関向けのシステムは、実際にオンラインで患者の診察を行うツールのため、医療機関側が診療行為をつつがなく終えられるような UI 設計が重要です。 MVP 的な手法で、とりあえずリリースして検証を重ねていくというスタンスがとれないため、リリースするまでに機能的に不備がないか、医療従事者が迷わず正しく使える UI 設計になっているかなど、社内や実際の医療機関のテストを繰り返し、試行錯誤を経てリリースするという、プロダクトデザインをしている感覚になり「伝えるデザイン」とは違った思考でデザインに取り組んでいます。 機能重視なサービスこそ、直感的にシンプルな UI が重要 このように CLINICS という 1 つのサービスを構成する要素の中でも、ターゲットユーザーや提供価値の違いによって、デザインアプローチや重要視する視点が異なります。 たとえば、自分も業務でよく利用するプロトタイピングツールの inVision もログイン前は、利用シーンやより魅力的なサービスであるということを伝えるためのデザインをしており、ログイン後は直感的にわかりやすいシンプルな UI 設計で、ログイン前後でサービスの UI が異なります。 inVision も機能は豊富ですが、プロトタイピングを行う上で非常にシンプルな操作性を提供しており、無駄な説明や導線がなくても直感的に使える UI は、継続して利用できる安心感にもつながり、見習うべき UI だなと思っています。 （inVision の画面の違い） CLINICS の医療機関向けシステムも受付管理やスケジュール、オンライン診療を行う機能など複数の機能をひとつのサービスとして提供しているため、UI 的に複雑になりかねません。複雑な機能をまとめ、画面上にシンプルに落とし込めるかどうかというのを吟味し、作っては壊し、作っては壊しを繰り返しします。 これならいける！とおもった UI も、機能面での見落としなどがあったりすると導線に矛盾が生じたり、シンプルに表現したつもりが、逆に使い勝手の悪い UI になってしまったり。UI を考えるというのは、感性に訴えるデザインとは違ったよりロジカルな思考が必要で、デザインしながら四苦八苦して、ぶつぶつ独り言を言うことが多くなります w デザインオリエンテッドなプロダクト開発 Web サービスであればいかに目標としているコンバージョン率を高めるかどうか、分析〜調査〜開発というサイクルをベースとした運用になりますが、特に 医療機関向けのシステムの場合は、ムダな機能や使いづらい UI だとサービス的に不安要素を抱かせる要因にもなり、ビジネスの成功可否に直結します 。 そのため、リリースまでに UI を磨けるだけ磨き、実際に医療機関の現場に出向いてどういうフローで診察を行っているのかなどヒアリングしたり、出来上がった機能を試してもらうなどし、十分に検討した上でリリースしています。こうしたデザインを重視した開発が行える点はメドレーだからこその開発体制かもしれません。 このような デザインオリエンテッドなプロダクト開発を行う上で重要なポイントは、事業理解とエンジニアとの密な連携 です。表面的なデザインではなく、実際に使われる利用シーンを想像しつつも、体験することが難しい医療サービスだからこそ、前提の知識やヒアリング、ユーザーテストなどが重要となりますし、機能的な部分に関してはエンジニアと仕様について議論したり、ユースケースを踏まえてどのような UI に落とし込むべきかを考えながらデザインに落とし込んでいきます。インタラクティブな表現など inVision でも表現しきれない細かい動きや導線などは、実装時にエンジニアに伝わりやすいようフロントエンド部分のコーディングを自ら行うことでコードを通じてエンジニアとコミュニケーションが取りやすくもなるので、フロントエンドも把握しておくことは重要です。 まとめ 個人的には「伝えるデザイン」と「機能的なデザイン」で、明確に思考をわけて考えてデザインしてきたわけではなかったのですが、提供すべき価値の違いによって 左脳と右脳それぞれ使い分けてデザインしている かもしれないということに気付かされました。これは以前デザイナーの小山がブログで書いた システム 1（自動的に直感で動く”早い思考”）とシステム 2（手動で論理的に動く”遅い思考”） が自分の中で振り子のように行き来してるだろうなと感じたので、興味のある方は「思考とデザインスキル」も読んでもらうとわかりやすいです。 思考とデザインスキル 〜メドレー TechLunch〜 | MEDLEY Developer Portal はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、前田に引き続き... developer.medley.jp 最後に ふだんビールばっかり呑んで 適当な人とレッテルを貼られているマエダですが、今回は真面目なことを書いてみましたがいかがでしたでしょうか。このブログを書いてて正直疲れたので、システム 2 が働いてるに違いないと思います。こんな私と一緒に仕事がしたい、呑みたいというデザイナーやエンジニアさん。応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

最近 PS4 のグランツーリスモスポーツをやり始めて、自宅のネット環境の遅さに気づいたデザイナーの マエダ です。前回は DLS について ご紹介させていただきましたが、今回はメドレーに入社して感じた「デザインプロセスの違い」について自分なりにまとめてみました。 あとで読みたい人向けに、エレベーターピッチ風にまとめると、 [ CLINICS ] というサービスは [ 患者と医療機関向け ] それぞれサービスを提供しているが [ 提供価値の違い ] によって [ デザインの役割が異なる ] ことに気づいた 特に [ 医療機関向け ] は [ UI が重要 ] となり [ 伝えることを目的とした Web サイト ] とは違って [ UI デザインの良し悪しがプロダクト全体の品質に関わる ] ため [ 事業や技術を理解 ] した[ デザインオリエンテッド ] が求められる というような内容です。 ユーザーによって異なる提供価値 メドレーに入社してから、オンライン診療アプリ「 CLINICS（クリニクス） 」というサービスのデザインを主に担当しているのですが、患者と医療機関側で提供しているプロダクトの内容が異なります。 オンライン診療の内容を伝え、利用を促すための Web サイト（患者・医療機関双方） 患者がオンラインで通院を行うためのアプリ 医療機関側がオンラインで遠隔診療を行うためのシステム サービスの入り口となる Web サイト Web ページの役割としては、オンライン診療というものがどういったもので、CLINICS を利用するとどういう課題解決につながるのか、というサービスの特徴を患者と医療機関双方に「 伝えるためのデザイン 」が必要となります。 デザインするにあたって注力すべきポイントは、装飾やイメージ画像などシンボリックなデザインとストーリー性のある導線設計をすることで、視覚的に特徴を伝わりやすくし、またコンバージョンポイントへ誘導するため、ボタン等は目立たせるなど、適切に情報を伝え、行動を促すためのデザインが重要になります。 患者がオンライン診療を行うためのアプリ アプリは患者がオンライン診療をするための「病院検索」→「予約」→「問診」→「診察」→「決済」の機能をシームレスに繋げるためストレスのかからないユーザー体験を提供することが重要です。 そもそもオンライン診療のメリットとして、待ち時間の軽減や、落ち着いた環境で診察ができるなどが挙げられるため、そこに至るまでのユーザー体験を台無しにしてしまう UI では元も子もなくなってしまいます。 アプリでは「伝えるデザイン」よりも「 機能的なデザイン 」が必要になりますが、ユーザーの行動を途切れさせないよう、不必要な要素や導線を極力排除して、非常にシンプルな UI 設計をおこなっており、機能自体を主張しないデザインを心がけています。前回このブログでもとりあげた DLS も、そういった設計思想のもと開発を進めていたからこそ実現できたと思っています。 医療機関向けの遠隔診療システム 医療機関側に提供しているシステムは、オンライン診療を行うためのツールです。 Web サイトのように「伝えるデザイン」やコンバージョン重視ではなく、「 より機能的に使いやすいデザイン 」が重要になります。 このような画面を Bootstrap のような UI テンプレートそのままの見た目で構築してしまうと、技術的に素晴らしいものができたとしても、使い勝手が悪く貧弱な機能と見られかねないため、 デザイナーが管理画面の UI 設計に携わることは、ビジネス的にも非常に重要な要素 です。 特に CLINICS の医療機関向けのシステムは、実際にオンラインで患者の診察を行うツールのため、医療機関側が診療行為をつつがなく終えられるような UI 設計が重要です。 MVP 的な手法で、とりあえずリリースして検証を重ねていくというスタンスがとれないため、リリースするまでに機能的に不備がないか、医療従事者が迷わず正しく使える UI 設計になっているかなど、社内や実際の医療機関のテストを繰り返し、試行錯誤を経てリリースするという、プロダクトデザインをしている感覚になり「伝えるデザイン」とは違った思考でデザインに取り組んでいます。 機能重視なサービスこそ、直感的にシンプルな UI が重要 このように CLINICS という 1 つのサービスを構成する要素の中でも、ターゲットユーザーや提供価値の違いによって、デザインアプローチや重要視する視点が異なります。 たとえば、自分も業務でよく利用するプロトタイピングツールの inVision もログイン前は、利用シーンやより魅力的なサービスであるということを伝えるためのデザインをしており、ログイン後は直感的にわかりやすいシンプルな UI 設計で、ログイン前後でサービスの UI が異なります。 inVision も機能は豊富ですが、プロトタイピングを行う上で非常にシンプルな操作性を提供しており、無駄な説明や導線がなくても直感的に使える UI は、継続して利用できる安心感にもつながり、見習うべき UI だなと思っています。 （inVision の画面の違い） CLINICS の医療機関向けシステムも受付管理やスケジュール、オンライン診療を行う機能など複数の機能をひとつのサービスとして提供しているため、UI 的に複雑になりかねません。複雑な機能をまとめ、画面上にシンプルに落とし込めるかどうかというのを吟味し、作っては壊し、作っては壊しを繰り返しします。 これならいける！とおもった UI も、機能面での見落としなどがあったりすると導線に矛盾が生じたり、シンプルに表現したつもりが、逆に使い勝手の悪い UI になってしまったり。UI を考えるというのは、感性に訴えるデザインとは違ったよりロジカルな思考が必要で、デザインしながら四苦八苦して、ぶつぶつ独り言を言うことが多くなります w デザインオリエンテッドなプロダクト開発 Web サービスであればいかに目標としているコンバージョン率を高めるかどうか、分析〜調査〜開発というサイクルをベースとした運用になりますが、特に 医療機関向けのシステムの場合は、ムダな機能や使いづらい UI だとサービス的に不安要素を抱かせる要因にもなり、ビジネスの成功可否に直結します 。 そのため、リリースまでに UI を磨けるだけ磨き、実際に医療機関の現場に出向いてどういうフローで診察を行っているのかなどヒアリングしたり、出来上がった機能を試してもらうなどし、十分に検討した上でリリースしています。こうしたデザインを重視した開発が行える点はメドレーだからこその開発体制かもしれません。 このような デザインオリエンテッドなプロダクト開発を行う上で重要なポイントは、事業理解とエンジニアとの密な連携 です。表面的なデザインではなく、実際に使われる利用シーンを想像しつつも、体験することが難しい医療サービスだからこそ、前提の知識やヒアリング、ユーザーテストなどが重要となりますし、機能的な部分に関してはエンジニアと仕様について議論したり、ユースケースを踏まえてどのような UI に落とし込むべきかを考えながらデザインに落とし込んでいきます。インタラクティブな表現など inVision でも表現しきれない細かい動きや導線などは、実装時にエンジニアに伝わりやすいようフロントエンド部分のコーディングを自ら行うことでコードを通じてエンジニアとコミュニケーションが取りやすくもなるので、フロントエンドも把握しておくことは重要です。 まとめ 個人的には「伝えるデザイン」と「機能的なデザイン」で、明確に思考をわけて考えてデザインしてきたわけではなかったのですが、提供すべき価値の違いによって 左脳と右脳それぞれ使い分けてデザインしている かもしれないということに気付かされました。これは以前デザイナーの小山がブログで書いた システム 1（自動的に直感で動く”早い思考”）とシステム 2（手動で論理的に動く”遅い思考”） が自分の中で振り子のように行き来してるだろうなと感じたので、興味のある方は「思考とデザインスキル」も読んでもらうとわかりやすいです。 思考とデザインスキル 〜メドレー TechLunch〜 | MEDLEY Developer Portal はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、前田に引き続き... developer.medley.jp 最後に ふだんビールばっかり呑んで 適当な人とレッテルを貼られているマエダですが、今回は真面目なことを書いてみましたがいかがでしたでしょうか。このブログを書いてて正直疲れたので、システム 2 が働いてるに違いないと思います。こんな私と一緒に仕事がしたい、呑みたいというデザイナーやエンジニアさん。応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

最近 PS4 のグランツーリスモスポーツをやり始めて、自宅のネット環境の遅さに気づいたデザイナーの マエダ です。前回は DLS について ご紹介させていただきましたが、今回はメドレーに入社して感じた「デザインプロセスの違い」について自分なりにまとめてみました。 あとで読みたい人向けに、エレベーターピッチ風にまとめると、 [ CLINICS ] というサービスは [ 患者と医療機関向け ] それぞれサービスを提供しているが [ 提供価値の違い ] によって [ デザインの役割が異なる ] ことに気づいた 特に [ 医療機関向け ] は [ UI が重要 ] となり [ 伝えることを目的とした Web サイト ] とは違って [ UI デザインの良し悪しがプロダクト全体の品質に関わる ] ため [ 事業や技術を理解 ] した[ デザインオリエンテッド ] が求められる というような内容です。 ユーザーによって異なる提供価値 メドレーに入社してから、オンライン診療アプリ「 CLINICS（クリニクス） 」というサービスのデザインを主に担当しているのですが、患者と医療機関側で提供しているプロダクトの内容が異なります。 オンライン診療の内容を伝え、利用を促すための Web サイト（患者・医療機関双方） 患者がオンラインで通院を行うためのアプリ 医療機関側がオンラインで遠隔診療を行うためのシステム サービスの入り口となる Web サイト Web ページの役割としては、オンライン診療というものがどういったもので、CLINICS を利用するとどういう課題解決につながるのか、というサービスの特徴を患者と医療機関双方に「 伝えるためのデザイン 」が必要となります。 デザインするにあたって注力すべきポイントは、装飾やイメージ画像などシンボリックなデザインとストーリー性のある導線設計をすることで、視覚的に特徴を伝わりやすくし、またコンバージョンポイントへ誘導するため、ボタン等は目立たせるなど、適切に情報を伝え、行動を促すためのデザインが重要になります。 患者がオンライン診療を行うためのアプリ アプリは患者がオンライン診療をするための「病院検索」→「予約」→「問診」→「診察」→「決済」の機能をシームレスに繋げるためストレスのかからないユーザー体験を提供することが重要です。 そもそもオンライン診療のメリットとして、待ち時間の軽減や、落ち着いた環境で診察ができるなどが挙げられるため、そこに至るまでのユーザー体験を台無しにしてしまう UI では元も子もなくなってしまいます。 アプリでは「伝えるデザイン」よりも「 機能的なデザイン 」が必要になりますが、ユーザーの行動を途切れさせないよう、不必要な要素や導線を極力排除して、非常にシンプルな UI 設計をおこなっており、機能自体を主張しないデザインを心がけています。前回このブログでもとりあげた DLS も、そういった設計思想のもと開発を進めていたからこそ実現できたと思っています。 医療機関向けの遠隔診療システム 医療機関側に提供しているシステムは、オンライン診療を行うためのツールです。 Web サイトのように「伝えるデザイン」やコンバージョン重視ではなく、「 より機能的に使いやすいデザイン 」が重要になります。 このような画面を Bootstrap のような UI テンプレートそのままの見た目で構築してしまうと、技術的に素晴らしいものができたとしても、使い勝手が悪く貧弱な機能と見られかねないため、 デザイナーが管理画面の UI 設計に携わることは、ビジネス的にも非常に重要な要素 です。 特に CLINICS の医療機関向けのシステムは、実際にオンラインで患者の診察を行うツールのため、医療機関側が診療行為をつつがなく終えられるような UI 設計が重要です。 MVP 的な手法で、とりあえずリリースして検証を重ねていくというスタンスがとれないため、リリースするまでに機能的に不備がないか、医療従事者が迷わず正しく使える UI 設計になっているかなど、社内や実際の医療機関のテストを繰り返し、試行錯誤を経てリリースするという、プロダクトデザインをしている感覚になり「伝えるデザイン」とは違った思考でデザインに取り組んでいます。 機能重視なサービスこそ、直感的にシンプルな UI が重要 このように CLINICS という 1 つのサービスを構成する要素の中でも、ターゲットユーザーや提供価値の違いによって、デザインアプローチや重要視する視点が異なります。 たとえば、自分も業務でよく利用するプロトタイピングツールの inVision もログイン前は、利用シーンやより魅力的なサービスであるということを伝えるためのデザインをしており、ログイン後は直感的にわかりやすいシンプルな UI 設計で、ログイン前後でサービスの UI が異なります。 inVision も機能は豊富ですが、プロトタイピングを行う上で非常にシンプルな操作性を提供しており、無駄な説明や導線がなくても直感的に使える UI は、継続して利用できる安心感にもつながり、見習うべき UI だなと思っています。 （inVision の画面の違い） CLINICS の医療機関向けシステムも受付管理やスケジュール、オンライン診療を行う機能など複数の機能をひとつのサービスとして提供しているため、UI 的に複雑になりかねません。複雑な機能をまとめ、画面上にシンプルに落とし込めるかどうかというのを吟味し、作っては壊し、作っては壊しを繰り返しします。 これならいける！とおもった UI も、機能面での見落としなどがあったりすると導線に矛盾が生じたり、シンプルに表現したつもりが、逆に使い勝手の悪い UI になってしまったり。UI を考えるというのは、感性に訴えるデザインとは違ったよりロジカルな思考が必要で、デザインしながら四苦八苦して、ぶつぶつ独り言を言うことが多くなります w デザインオリエンテッドなプロダクト開発 Web サービスであればいかに目標としているコンバージョン率を高めるかどうか、分析〜調査〜開発というサイクルをベースとした運用になりますが、特に 医療機関向けのシステムの場合は、ムダな機能や使いづらい UI だとサービス的に不安要素を抱かせる要因にもなり、ビジネスの成功可否に直結します 。 そのため、リリースまでに UI を磨けるだけ磨き、実際に医療機関の現場に出向いてどういうフローで診察を行っているのかなどヒアリングしたり、出来上がった機能を試してもらうなどし、十分に検討した上でリリースしています。こうしたデザインを重視した開発が行える点はメドレーだからこその開発体制かもしれません。 このような デザインオリエンテッドなプロダクト開発を行う上で重要なポイントは、事業理解とエンジニアとの密な連携 です。表面的なデザインではなく、実際に使われる利用シーンを想像しつつも、体験することが難しい医療サービスだからこそ、前提の知識やヒアリング、ユーザーテストなどが重要となりますし、機能的な部分に関してはエンジニアと仕様について議論したり、ユースケースを踏まえてどのような UI に落とし込むべきかを考えながらデザインに落とし込んでいきます。インタラクティブな表現など inVision でも表現しきれない細かい動きや導線などは、実装時にエンジニアに伝わりやすいようフロントエンド部分のコーディングを自ら行うことでコードを通じてエンジニアとコミュニケーションが取りやすくもなるので、フロントエンドも把握しておくことは重要です。 まとめ 個人的には「伝えるデザイン」と「機能的なデザイン」で、明確に思考をわけて考えてデザインしてきたわけではなかったのですが、提供すべき価値の違いによって 左脳と右脳それぞれ使い分けてデザインしている かもしれないということに気付かされました。これは以前デザイナーの小山がブログで書いた システム 1（自動的に直感で動く”早い思考”）とシステム 2（手動で論理的に動く”遅い思考”） が自分の中で振り子のように行き来してるだろうなと感じたので、興味のある方は「思考とデザインスキル」も読んでもらうとわかりやすいです。 思考とデザインスキル 〜メドレー TechLunch〜 | MEDLEY Developer Portal はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、前田に引き続き... developer.medley.jp 最後に ふだんビールばっかり呑んで 適当な人とレッテルを貼られているマエダですが、今回は真面目なことを書いてみましたがいかがでしたでしょうか。このブログを書いてて正直疲れたので、システム 2 が働いてるに違いないと思います。こんな私と一緒に仕事がしたい、呑みたいというデザイナーやエンジニアさん。応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

最近 PS4 のグランツーリスモスポーツをやり始めて、自宅のネット環境の遅さに気づいたデザイナーの マエダ です。前回は DLS について ご紹介させていただきましたが、今回はメドレーに入社して感じた「デザインプロセスの違い」について自分なりにまとめてみました。 あとで読みたい人向けに、エレベーターピッチ風にまとめると、 [ CLINICS ] というサービスは [ 患者と医療機関向け ] それぞれサービスを提供しているが [ 提供価値の違い ] によって [ デザインの役割が異なる ] ことに気づいた 特に [ 医療機関向け ] は [ UI が重要 ] となり [ 伝えることを目的とした Web サイト ] とは違って [ UI デザインの良し悪しがプロダクト全体の品質に関わる ] ため [ 事業や技術を理解 ] した[ デザインオリエンテッド ] が求められる というような内容です。 ユーザーによって異なる提供価値 メドレーに入社してから、オンライン診療アプリ「 CLINICS（クリニクス） 」というサービスのデザインを主に担当しているのですが、患者と医療機関側で提供しているプロダクトの内容が異なります。 オンライン診療の内容を伝え、利用を促すための Web サイト（患者・医療機関双方） 患者がオンラインで通院を行うためのアプリ 医療機関側がオンラインで遠隔診療を行うためのシステム サービスの入り口となる Web サイト Web ページの役割としては、オンライン診療というものがどういったもので、CLINICS を利用するとどういう課題解決につながるのか、というサービスの特徴を患者と医療機関双方に「 伝えるためのデザイン 」が必要となります。 デザインするにあたって注力すべきポイントは、装飾やイメージ画像などシンボリックなデザインとストーリー性のある導線設計をすることで、視覚的に特徴を伝わりやすくし、またコンバージョンポイントへ誘導するため、ボタン等は目立たせるなど、適切に情報を伝え、行動を促すためのデザインが重要になります。 患者がオンライン診療を行うためのアプリ アプリは患者がオンライン診療をするための「病院検索」→「予約」→「問診」→「診察」→「決済」の機能をシームレスに繋げるためストレスのかからないユーザー体験を提供することが重要です。 そもそもオンライン診療のメリットとして、待ち時間の軽減や、落ち着いた環境で診察ができるなどが挙げられるため、そこに至るまでのユーザー体験を台無しにしてしまう UI では元も子もなくなってしまいます。 アプリでは「伝えるデザイン」よりも「 機能的なデザイン 」が必要になりますが、ユーザーの行動を途切れさせないよう、不必要な要素や導線を極力排除して、非常にシンプルな UI 設計をおこなっており、機能自体を主張しないデザインを心がけています。前回このブログでもとりあげた DLS も、そういった設計思想のもと開発を進めていたからこそ実現できたと思っています。 医療機関向けの遠隔診療システム 医療機関側に提供しているシステムは、オンライン診療を行うためのツールです。 Web サイトのように「伝えるデザイン」やコンバージョン重視ではなく、「 より機能的に使いやすいデザイン 」が重要になります。 このような画面を Bootstrap のような UI テンプレートそのままの見た目で構築してしまうと、技術的に素晴らしいものができたとしても、使い勝手が悪く貧弱な機能と見られかねないため、 デザイナーが管理画面の UI 設計に携わることは、ビジネス的にも非常に重要な要素 です。 特に CLINICS の医療機関向けのシステムは、実際にオンラインで患者の診察を行うツールのため、医療機関側が診療行為をつつがなく終えられるような UI 設計が重要です。 MVP 的な手法で、とりあえずリリースして検証を重ねていくというスタンスがとれないため、リリースするまでに機能的に不備がないか、医療従事者が迷わず正しく使える UI 設計になっているかなど、社内や実際の医療機関のテストを繰り返し、試行錯誤を経てリリースするという、プロダクトデザインをしている感覚になり「伝えるデザイン」とは違った思考でデザインに取り組んでいます。 機能重視なサービスこそ、直感的にシンプルな UI が重要 このように CLINICS という 1 つのサービスを構成する要素の中でも、ターゲットユーザーや提供価値の違いによって、デザインアプローチや重要視する視点が異なります。 たとえば、自分も業務でよく利用するプロトタイピングツールの inVision もログイン前は、利用シーンやより魅力的なサービスであるということを伝えるためのデザインをしており、ログイン後は直感的にわかりやすいシンプルな UI 設計で、ログイン前後でサービスの UI が異なります。 inVision も機能は豊富ですが、プロトタイピングを行う上で非常にシンプルな操作性を提供しており、無駄な説明や導線がなくても直感的に使える UI は、継続して利用できる安心感にもつながり、見習うべき UI だなと思っています。 （inVision の画面の違い） CLINICS の医療機関向けシステムも受付管理やスケジュール、オンライン診療を行う機能など複数の機能をひとつのサービスとして提供しているため、UI 的に複雑になりかねません。複雑な機能をまとめ、画面上にシンプルに落とし込めるかどうかというのを吟味し、作っては壊し、作っては壊しを繰り返しします。 これならいける！とおもった UI も、機能面での見落としなどがあったりすると導線に矛盾が生じたり、シンプルに表現したつもりが、逆に使い勝手の悪い UI になってしまったり。UI を考えるというのは、感性に訴えるデザインとは違ったよりロジカルな思考が必要で、デザインしながら四苦八苦して、ぶつぶつ独り言を言うことが多くなります w デザインオリエンテッドなプロダクト開発 Web サービスであればいかに目標としているコンバージョン率を高めるかどうか、分析〜調査〜開発というサイクルをベースとした運用になりますが、特に 医療機関向けのシステムの場合は、ムダな機能や使いづらい UI だとサービス的に不安要素を抱かせる要因にもなり、ビジネスの成功可否に直結します 。 そのため、リリースまでに UI を磨けるだけ磨き、実際に医療機関の現場に出向いてどういうフローで診察を行っているのかなどヒアリングしたり、出来上がった機能を試してもらうなどし、十分に検討した上でリリースしています。こうしたデザインを重視した開発が行える点はメドレーだからこその開発体制かもしれません。 このような デザインオリエンテッドなプロダクト開発を行う上で重要なポイントは、事業理解とエンジニアとの密な連携 です。表面的なデザインではなく、実際に使われる利用シーンを想像しつつも、体験することが難しい医療サービスだからこそ、前提の知識やヒアリング、ユーザーテストなどが重要となりますし、機能的な部分に関してはエンジニアと仕様について議論したり、ユースケースを踏まえてどのような UI に落とし込むべきかを考えながらデザインに落とし込んでいきます。インタラクティブな表現など inVision でも表現しきれない細かい動きや導線などは、実装時にエンジニアに伝わりやすいようフロントエンド部分のコーディングを自ら行うことでコードを通じてエンジニアとコミュニケーションが取りやすくもなるので、フロントエンドも把握しておくことは重要です。 まとめ 個人的には「伝えるデザイン」と「機能的なデザイン」で、明確に思考をわけて考えてデザインしてきたわけではなかったのですが、提供すべき価値の違いによって 左脳と右脳それぞれ使い分けてデザインしている かもしれないということに気付かされました。これは以前デザイナーの小山がブログで書いた システム 1（自動的に直感で動く”早い思考”）とシステム 2（手動で論理的に動く”遅い思考”） が自分の中で振り子のように行き来してるだろうなと感じたので、興味のある方は「思考とデザインスキル」も読んでもらうとわかりやすいです。 思考とデザインスキル 〜メドレー TechLunch〜 | MEDLEY Developer Portal はじめまして！最近みるみる太りだしてはいるものの、まだ機は熟していないとダイエットの時期をぐっと堪えている開発本部イケメン担当のデザイナー・小山です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、前田に引き続き... developer.medley.jp 最後に ふだんビールばっかり呑んで 適当な人とレッテルを貼られているマエダですが、今回は真面目なことを書いてみましたがいかがでしたでしょうか。このブログを書いてて正直疲れたので、システム 2 が働いてるに違いないと思います。こんな私と一緒に仕事がしたい、呑みたいというデザイナーやエンジニアさん。応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

こんにちは。開発本部の 宍戸 です。 メドレーでは定期的に、テーマに沿って組織の技術的な底上げを行うための機会（ タスクフォース と呼んでいます）を行っています。そのタスクフォースの１つとして先日、フロントエンド開発力のベースアップを目的としたタスクフォースを行いました。本記事では、その取組みについてご紹介したいと思います。 背景 メドレーには現在 20 人弱のエンジニアが在籍しており、その約半数がサーバーサイド出身者です。また普段の開発においては、一つの機能をフロントからサーバーサイドまで一貫して一人が担当するケースが多くあります。サーバーサイド出身者のフロントエンド開発のスキルセットには多少ばらつきはあるものの、普段の開発業務ではレビュー等でそれぞれサポートしつつ開発を行っています。 しかし、フロントエンドの基礎的な部分や最新の流れまで聞かれると不安なメンバーも少なくありません。フロントエンド出身のメンバーが主導し、改めて基礎や最新情報に関して整理・フォローを行うことで、組織全体のフロントエンドの開発力を高めていきたいと考えました。 タスクフォースの目的 今回のタスクフォースは『フロントエンドの基本や最近のトレンドに関して学ぶ』ことで『（フロントエンド開発における）技術選定、設計、実装ができる基礎を身につける』、そしてこれらをもとに『新規のプロジェクトで設計段階から自走できるようになる』ことを目的としました。 その中でも特にここ数年、変化の流れが早かった JavaScript を中心にトピックを選定しました。 参加者は、これまでサーバーサイド開発を中心に行ってきたメンバー数名です。背景でも触れたとおり、業務経験はそれぞれある前提でのスタートであったため、基礎をみっちりというよりは、基礎的な話から最近の話題までを一通り確認しながら、各自の持っている知識の整理と土台を固めることで、今後の設計や技術選定を行う際の指針を得ることを目的としました。 進め方 今回のタスクフォースは期間を 3 ヶ月と定め、毎週 1 時間程度集まって行いました。 毎週、事前に講師陣が選んだ資料を読んでおき、当日は講師陣が参加者の不明点、疑問点に対してフォローアップするという形式で進めました。その他には、社内のプロダクトでの利用事例なども交えながらテーマに関する質問会のような形で進むことが多かったです。 また毎回のタスクフォースの時間のあとに、参加者がその日の内容をまとめた議事録形式の資料を作成し、参加者全員と共有することで、その日に話された内容や、それぞれの理解度を再度確認するようにしました。 内容 およその流れは上記の通りですが、約 3 ヶ月でどのようなテーマに触れてきたのか、一部をご紹介します。 フロントエンドの基礎 序盤はこちらの資料を利用させていただきながら進めました。 ブラウザの仕組み: 最新ウェブブラウザの内部構造 Asg Boot Camp 　 HTML/CSS An Introduction to JavaScript ブラウザの仕組み、HTML/CSS の基本的な話のおさらい、JavaScript の話に関連して、これまでに出てきた AltJS についてもいくつか特徴や何故流行ったのかなどについて読み込みました。 この中でも、 ブラウザの仕組み: 最新ウェブブラウザの内部構造 で DOM の解析、レンダリング、レイアウトといったブラウザ内部で具体的に何が行われているのかといった話はここで確認できてよかったという声が多くありました。 JavaScript（基礎〜ES2015 以降） JavaScript の話題への導入編としてこちらを資料として読み込みました。 You Don’t Know JS: Up & Going JavaScript Garden このパートでは JavaScript の基礎は、あえて ES3〜5 をベースにすることで JavaScript と他言語との違い・特徴を再確認していきました。上記の内容を踏まえ、今では使わない書き方などについてはその理由も確認しながら進めていきました。 その後は Learn ES2015 · Babel を参照しながら、Promise, Class などは普段の開発でも当たり前のように利用しているものの、ES2015 以降での書き方は ES5 だとどのようになっていたかもここで同時に学習していきました。（ Playground ・ TypeScript で、その雰囲気を見ることが出来ます） モダン JavaScript これまでの知識を踏まえ、モダンな JavaScript の利用(実装)例として、 jser.github.io と preact-www のソースを読んでいきました。 これまでの JavaScript の言語自体に関する内容から、ライブラリを利用したコンポーネント間でのデータフローや、コンポーネントのライフサイクルに関する部分まで確認していきました。また初見のプロジェクトであればどのあたりから目を通していくか、などコード全体の読み方についても講師陣からアドバイスがありました。また時折出てくる DOM API に「なんだっけこれ・・・？」などとなりつつもコードを紐解いていくことで改めてフロントエンド JavaScript の特徴的な部分を垣間見ることができたように思います。 また最後に、現在開発に利用されているツール群について、 Qiita:JavaScript フレームワーク選定の議論 を参考に確認しました。それぞれのツールがどのような背景で使われている（あるいはいない）のかなども合わせて確認をしました。 ここまでのテーマを振り返りつつ、JavaScript が言語としてどのように変化してきたかを考えた時、webpack や TypeScript がなぜ使われるのか、ようやく腹に落ちたように思います。また上記資料も、どのようなケースで何を選択するのかや、アプリケーションの寿命とライブラリやツールの寿命といった運用フェーズで理解していく必要のある事項にも触れられており、非常に参考になりました。 実際にやってみて 今回のタスクフォースでは、3 ヶ月という期間の中で、1 ヶ月半の時点と、全体終了後に振り返りを実施しました。 その中で、参加メンバーからは 業務においては必要な部分に絞った調査で終わってしまったり、周りのコードを参考にしたりすることでなんとなくできた気になってしまっていたが、今回改めて基礎的な知識を学習する、復習する時間としてできてよかった。 断片的でまばらな知識しか持っていなかった部分が資料を読み込むことで理解が深まった 数年前にバズってあとで読まない「あとで読む」ブクマ記事をきちんと読めてよかった フロントエンド経験の長い講師陣の生きた知見（ツラミなども含めて）を聞くことができたのはありがたかった などの感想が出ました。 私自身も参加していましたが、個人的には基礎部分を改めて固めることができた機会だったように感じています。 また、普段は新しいツールなどの情報のキャッチアップへの意識が向きがちですが、今回のタスクフォースで言語・ツールの変遷を一度通して見ることができたことで、新しく現れる技術がどういった課題を解決するものなのか、これまでに似たツールがあったのかどうかなどを調べる指針が得られたことはよかったのかなと思っています。 一方で、今回のタスクフォースの中では「コードを書く」時間は作りませんでした。これについては振り返りの中でも話題となりましたが、それについては TodoMVC などを参考に、自分で手を動かしてみることが必要だろうと今後の課題として挙げられました。このあたりは実務以外での個々の頑張りが必要になってくる部分かと思います。 まとめ 「サーバーサイドエンジニアのフロントエンド開発力の底上げ」をテーマとしたタスクフォースについてご紹介しました。こういった形で、同じようなスキルセットのメンバーが集まり、お互いにわからない部分について話をしたり、経験豊富なメンバーから、個人の経験を含めて話を聞くというのは、改めて非常に貴重な機会だったように思います。 こういった取り組みを繰り返していくことで、個々で尖った部分はもちろん伸ばしつつ、全体の底上げを行いながら、よりよいプロダクト開発に繋げられればと考えています。

こんにちは。開発本部の 宍戸 です。 メドレーでは定期的に、テーマに沿って組織の技術的な底上げを行うための機会（ タスクフォース と呼んでいます）を行っています。そのタスクフォースの１つとして先日、フロントエンド開発力のベースアップを目的としたタスクフォースを行いました。本記事では、その取組みについてご紹介したいと思います。 背景 メドレーには現在 20 人弱のエンジニアが在籍しており、その約半数がサーバーサイド出身者です。また普段の開発においては、一つの機能をフロントからサーバーサイドまで一貫して一人が担当するケースが多くあります。サーバーサイド出身者のフロントエンド開発のスキルセットには多少ばらつきはあるものの、普段の開発業務ではレビュー等でそれぞれサポートしつつ開発を行っています。 しかし、フロントエンドの基礎的な部分や最新の流れまで聞かれると不安なメンバーも少なくありません。フロントエンド出身のメンバーが主導し、改めて基礎や最新情報に関して整理・フォローを行うことで、組織全体のフロントエンドの開発力を高めていきたいと考えました。 タスクフォースの目的 今回のタスクフォースは『フロントエンドの基本や最近のトレンドに関して学ぶ』ことで『（フロントエンド開発における）技術選定、設計、実装ができる基礎を身につける』、そしてこれらをもとに『新規のプロジェクトで設計段階から自走できるようになる』ことを目的としました。 その中でも特にここ数年、変化の流れが早かった JavaScript を中心にトピックを選定しました。 参加者は、これまでサーバーサイド開発を中心に行ってきたメンバー数名です。背景でも触れたとおり、業務経験はそれぞれある前提でのスタートであったため、基礎をみっちりというよりは、基礎的な話から最近の話題までを一通り確認しながら、各自の持っている知識の整理と土台を固めることで、今後の設計や技術選定を行う際の指針を得ることを目的としました。 進め方 今回のタスクフォースは期間を 3 ヶ月と定め、毎週 1 時間程度集まって行いました。 毎週、事前に講師陣が選んだ資料を読んでおき、当日は講師陣が参加者の不明点、疑問点に対してフォローアップするという形式で進めました。その他には、社内のプロダクトでの利用事例なども交えながらテーマに関する質問会のような形で進むことが多かったです。 また毎回のタスクフォースの時間のあとに、参加者がその日の内容をまとめた議事録形式の資料を作成し、参加者全員と共有することで、その日に話された内容や、それぞれの理解度を再度確認するようにしました。 内容 およその流れは上記の通りですが、約 3 ヶ月でどのようなテーマに触れてきたのか、一部をご紹介します。 フロントエンドの基礎 序盤はこちらの資料を利用させていただきながら進めました。 ブラウザの仕組み: 最新ウェブブラウザの内部構造 Asg Boot Camp 　 HTML/CSS An Introduction to JavaScript ブラウザの仕組み、HTML/CSS の基本的な話のおさらい、JavaScript の話に関連して、これまでに出てきた AltJS についてもいくつか特徴や何故流行ったのかなどについて読み込みました。 この中でも、 ブラウザの仕組み: 最新ウェブブラウザの内部構造 で DOM の解析、レンダリング、レイアウトといったブラウザ内部で具体的に何が行われているのかといった話はここで確認できてよかったという声が多くありました。 JavaScript（基礎〜ES2015 以降） JavaScript の話題への導入編としてこちらを資料として読み込みました。 You Don’t Know JS: Up & Going JavaScript Garden このパートでは JavaScript の基礎は、あえて ES3〜5 をベースにすることで JavaScript と他言語との違い・特徴を再確認していきました。上記の内容を踏まえ、今では使わない書き方などについてはその理由も確認しながら進めていきました。 その後は Learn ES2015 · Babel を参照しながら、Promise, Class などは普段の開発でも当たり前のように利用しているものの、ES2015 以降での書き方は ES5 だとどのようになっていたかもここで同時に学習していきました。（ Playground ・ TypeScript で、その雰囲気を見ることが出来ます） モダン JavaScript これまでの知識を踏まえ、モダンな JavaScript の利用(実装)例として、 jser.github.io と preact-www のソースを読んでいきました。 これまでの JavaScript の言語自体に関する内容から、ライブラリを利用したコンポーネント間でのデータフローや、コンポーネントのライフサイクルに関する部分まで確認していきました。また初見のプロジェクトであればどのあたりから目を通していくか、などコード全体の読み方についても講師陣からアドバイスがありました。また時折出てくる DOM API に「なんだっけこれ・・・？」などとなりつつもコードを紐解いていくことで改めてフロントエンド JavaScript の特徴的な部分を垣間見ることができたように思います。 また最後に、現在開発に利用されているツール群について、 Qiita:JavaScript フレームワーク選定の議論 を参考に確認しました。それぞれのツールがどのような背景で使われている（あるいはいない）のかなども合わせて確認をしました。 ここまでのテーマを振り返りつつ、JavaScript が言語としてどのように変化してきたかを考えた時、webpack や TypeScript がなぜ使われるのか、ようやく腹に落ちたように思います。また上記資料も、どのようなケースで何を選択するのかや、アプリケーションの寿命とライブラリやツールの寿命といった運用フェーズで理解していく必要のある事項にも触れられており、非常に参考になりました。 実際にやってみて 今回のタスクフォースでは、3 ヶ月という期間の中で、1 ヶ月半の時点と、全体終了後に振り返りを実施しました。 その中で、参加メンバーからは 業務においては必要な部分に絞った調査で終わってしまったり、周りのコードを参考にしたりすることでなんとなくできた気になってしまっていたが、今回改めて基礎的な知識を学習する、復習する時間としてできてよかった。 断片的でまばらな知識しか持っていなかった部分が資料を読み込むことで理解が深まった 数年前にバズってあとで読まない「あとで読む」ブクマ記事をきちんと読めてよかった フロントエンド経験の長い講師陣の生きた知見（ツラミなども含めて）を聞くことができたのはありがたかった などの感想が出ました。 私自身も参加していましたが、個人的には基礎部分を改めて固めることができた機会だったように感じています。 また、普段は新しいツールなどの情報のキャッチアップへの意識が向きがちですが、今回のタスクフォースで言語・ツールの変遷を一度通して見ることができたことで、新しく現れる技術がどういった課題を解決するものなのか、これまでに似たツールがあったのかどうかなどを調べる指針が得られたことはよかったのかなと思っています。 一方で、今回のタスクフォースの中では「コードを書く」時間は作りませんでした。これについては振り返りの中でも話題となりましたが、それについては TodoMVC などを参考に、自分で手を動かしてみることが必要だろうと今後の課題として挙げられました。このあたりは実務以外での個々の頑張りが必要になってくる部分かと思います。 まとめ 「サーバーサイドエンジニアのフロントエンド開発力の底上げ」をテーマとしたタスクフォースについてご紹介しました。こういった形で、同じようなスキルセットのメンバーが集まり、お互いにわからない部分について話をしたり、経験豊富なメンバーから、個人の経験を含めて話を聞くというのは、改めて非常に貴重な機会だったように思います。 こういった取り組みを繰り返していくことで、個々で尖った部分はもちろん伸ばしつつ、全体の底上げを行いながら、よりよいプロダクト開発に繋げられればと考えています。

こんにちは。開発本部の 宍戸 です。 メドレーでは定期的に、テーマに沿って組織の技術的な底上げを行うための機会（ タスクフォース と呼んでいます）を行っています。そのタスクフォースの１つとして先日、フロントエンド開発力のベースアップを目的としたタスクフォースを行いました。本記事では、その取組みについてご紹介したいと思います。 背景 メドレーには現在 20 人弱のエンジニアが在籍しており、その約半数がサーバーサイド出身者です。また普段の開発においては、一つの機能をフロントからサーバーサイドまで一貫して一人が担当するケースが多くあります。サーバーサイド出身者のフロントエンド開発のスキルセットには多少ばらつきはあるものの、普段の開発業務ではレビュー等でそれぞれサポートしつつ開発を行っています。 しかし、フロントエンドの基礎的な部分や最新の流れまで聞かれると不安なメンバーも少なくありません。フロントエンド出身のメンバーが主導し、改めて基礎や最新情報に関して整理・フォローを行うことで、組織全体のフロントエンドの開発力を高めていきたいと考えました。 タスクフォースの目的 今回のタスクフォースは『フロントエンドの基本や最近のトレンドに関して学ぶ』ことで『（フロントエンド開発における）技術選定、設計、実装ができる基礎を身につける』、そしてこれらをもとに『新規のプロジェクトで設計段階から自走できるようになる』ことを目的としました。 その中でも特にここ数年、変化の流れが早かった JavaScript を中心にトピックを選定しました。 参加者は、これまでサーバーサイド開発を中心に行ってきたメンバー数名です。背景でも触れたとおり、業務経験はそれぞれある前提でのスタートであったため、基礎をみっちりというよりは、基礎的な話から最近の話題までを一通り確認しながら、各自の持っている知識の整理と土台を固めることで、今後の設計や技術選定を行う際の指針を得ることを目的としました。 進め方 今回のタスクフォースは期間を 3 ヶ月と定め、毎週 1 時間程度集まって行いました。 毎週、事前に講師陣が選んだ資料を読んでおき、当日は講師陣が参加者の不明点、疑問点に対してフォローアップするという形式で進めました。その他には、社内のプロダクトでの利用事例なども交えながらテーマに関する質問会のような形で進むことが多かったです。 また毎回のタスクフォースの時間のあとに、参加者がその日の内容をまとめた議事録形式の資料を作成し、参加者全員と共有することで、その日に話された内容や、それぞれの理解度を再度確認するようにしました。 内容 およその流れは上記の通りですが、約 3 ヶ月でどのようなテーマに触れてきたのか、一部をご紹介します。 フロントエンドの基礎 序盤はこちらの資料を利用させていただきながら進めました。 ブラウザの仕組み: 最新ウェブブラウザの内部構造 Asg Boot Camp 　 HTML/CSS An Introduction to JavaScript ブラウザの仕組み、HTML/CSS の基本的な話のおさらい、JavaScript の話に関連して、これまでに出てきた AltJS についてもいくつか特徴や何故流行ったのかなどについて読み込みました。 この中でも、 ブラウザの仕組み: 最新ウェブブラウザの内部構造 で DOM の解析、レンダリング、レイアウトといったブラウザ内部で具体的に何が行われているのかといった話はここで確認できてよかったという声が多くありました。 JavaScript（基礎〜ES2015 以降） JavaScript の話題への導入編としてこちらを資料として読み込みました。 You Don’t Know JS: Up & Going JavaScript Garden このパートでは JavaScript の基礎は、あえて ES3〜5 をベースにすることで JavaScript と他言語との違い・特徴を再確認していきました。上記の内容を踏まえ、今では使わない書き方などについてはその理由も確認しながら進めていきました。 その後は Learn ES2015 · Babel を参照しながら、Promise, Class などは普段の開発でも当たり前のように利用しているものの、ES2015 以降での書き方は ES5 だとどのようになっていたかもここで同時に学習していきました。（ Playground ・ TypeScript で、その雰囲気を見ることが出来ます） モダン JavaScript これまでの知識を踏まえ、モダンな JavaScript の利用(実装)例として、 jser.github.io と preact-www のソースを読んでいきました。 これまでの JavaScript の言語自体に関する内容から、ライブラリを利用したコンポーネント間でのデータフローや、コンポーネントのライフサイクルに関する部分まで確認していきました。また初見のプロジェクトであればどのあたりから目を通していくか、などコード全体の読み方についても講師陣からアドバイスがありました。また時折出てくる DOM API に「なんだっけこれ・・・？」などとなりつつもコードを紐解いていくことで改めてフロントエンド JavaScript の特徴的な部分を垣間見ることができたように思います。 また最後に、現在開発に利用されているツール群について、 Qiita:JavaScript フレームワーク選定の議論 を参考に確認しました。それぞれのツールがどのような背景で使われている（あるいはいない）のかなども合わせて確認をしました。 ここまでのテーマを振り返りつつ、JavaScript が言語としてどのように変化してきたかを考えた時、webpack や TypeScript がなぜ使われるのか、ようやく腹に落ちたように思います。また上記資料も、どのようなケースで何を選択するのかや、アプリケーションの寿命とライブラリやツールの寿命といった運用フェーズで理解していく必要のある事項にも触れられており、非常に参考になりました。 実際にやってみて 今回のタスクフォースでは、3 ヶ月という期間の中で、1 ヶ月半の時点と、全体終了後に振り返りを実施しました。 その中で、参加メンバーからは 業務においては必要な部分に絞った調査で終わってしまったり、周りのコードを参考にしたりすることでなんとなくできた気になってしまっていたが、今回改めて基礎的な知識を学習する、復習する時間としてできてよかった。 断片的でまばらな知識しか持っていなかった部分が資料を読み込むことで理解が深まった 数年前にバズってあとで読まない「あとで読む」ブクマ記事をきちんと読めてよかった フロントエンド経験の長い講師陣の生きた知見（ツラミなども含めて）を聞くことができたのはありがたかった などの感想が出ました。 私自身も参加していましたが、個人的には基礎部分を改めて固めることができた機会だったように感じています。 また、普段は新しいツールなどの情報のキャッチアップへの意識が向きがちですが、今回のタスクフォースで言語・ツールの変遷を一度通して見ることができたことで、新しく現れる技術がどういった課題を解決するものなのか、これまでに似たツールがあったのかどうかなどを調べる指針が得られたことはよかったのかなと思っています。 一方で、今回のタスクフォースの中では「コードを書く」時間は作りませんでした。これについては振り返りの中でも話題となりましたが、それについては TodoMVC などを参考に、自分で手を動かしてみることが必要だろうと今後の課題として挙げられました。このあたりは実務以外での個々の頑張りが必要になってくる部分かと思います。 まとめ 「サーバーサイドエンジニアのフロントエンド開発力の底上げ」をテーマとしたタスクフォースについてご紹介しました。こういった形で、同じようなスキルセットのメンバーが集まり、お互いにわからない部分について話をしたり、経験豊富なメンバーから、個人の経験を含めて話を聞くというのは、改めて非常に貴重な機会だったように思います。 こういった取り組みを繰り返していくことで、個々で尖った部分はもちろん伸ばしつつ、全体の底上げを行いながら、よりよいプロダクト開発に繋げられればと考えています。

こんにちは。開発本部の 宍戸 です。 メドレーでは定期的に、テーマに沿って組織の技術的な底上げを行うための機会（ タスクフォース と呼んでいます）を行っています。そのタスクフォースの１つとして先日、フロントエンド開発力のベースアップを目的としたタスクフォースを行いました。本記事では、その取組みについてご紹介したいと思います。 背景 メドレーには現在 20 人弱のエンジニアが在籍しており、その約半数がサーバーサイド出身者です。また普段の開発においては、一つの機能をフロントからサーバーサイドまで一貫して一人が担当するケースが多くあります。サーバーサイド出身者のフロントエンド開発のスキルセットには多少ばらつきはあるものの、普段の開発業務ではレビュー等でそれぞれサポートしつつ開発を行っています。 しかし、フロントエンドの基礎的な部分や最新の流れまで聞かれると不安なメンバーも少なくありません。フロントエンド出身のメンバーが主導し、改めて基礎や最新情報に関して整理・フォローを行うことで、組織全体のフロントエンドの開発力を高めていきたいと考えました。 タスクフォースの目的 今回のタスクフォースは『フロントエンドの基本や最近のトレンドに関して学ぶ』ことで『（フロントエンド開発における）技術選定、設計、実装ができる基礎を身につける』、そしてこれらをもとに『新規のプロジェクトで設計段階から自走できるようになる』ことを目的としました。 その中でも特にここ数年、変化の流れが早かった JavaScript を中心にトピックを選定しました。 参加者は、これまでサーバーサイド開発を中心に行ってきたメンバー数名です。背景でも触れたとおり、業務経験はそれぞれある前提でのスタートであったため、基礎をみっちりというよりは、基礎的な話から最近の話題までを一通り確認しながら、各自の持っている知識の整理と土台を固めることで、今後の設計や技術選定を行う際の指針を得ることを目的としました。 進め方 今回のタスクフォースは期間を 3 ヶ月と定め、毎週 1 時間程度集まって行いました。 毎週、事前に講師陣が選んだ資料を読んでおき、当日は講師陣が参加者の不明点、疑問点に対してフォローアップするという形式で進めました。その他には、社内のプロダクトでの利用事例なども交えながらテーマに関する質問会のような形で進むことが多かったです。 また毎回のタスクフォースの時間のあとに、参加者がその日の内容をまとめた議事録形式の資料を作成し、参加者全員と共有することで、その日に話された内容や、それぞれの理解度を再度確認するようにしました。 内容 およその流れは上記の通りですが、約 3 ヶ月でどのようなテーマに触れてきたのか、一部をご紹介します。 フロントエンドの基礎 序盤はこちらの資料を利用させていただきながら進めました。 ブラウザの仕組み: 最新ウェブブラウザの内部構造 Asg Boot Camp 　 HTML/CSS An Introduction to JavaScript ブラウザの仕組み、HTML/CSS の基本的な話のおさらい、JavaScript の話に関連して、これまでに出てきた AltJS についてもいくつか特徴や何故流行ったのかなどについて読み込みました。 この中でも、 ブラウザの仕組み: 最新ウェブブラウザの内部構造 で DOM の解析、レンダリング、レイアウトといったブラウザ内部で具体的に何が行われているのかといった話はここで確認できてよかったという声が多くありました。 JavaScript（基礎〜ES2015 以降） JavaScript の話題への導入編としてこちらを資料として読み込みました。 You Don’t Know JS: Up & Going JavaScript Garden このパートでは JavaScript の基礎は、あえて ES3〜5 をベースにすることで JavaScript と他言語との違い・特徴を再確認していきました。上記の内容を踏まえ、今では使わない書き方などについてはその理由も確認しながら進めていきました。 その後は Learn ES2015 · Babel を参照しながら、Promise, Class などは普段の開発でも当たり前のように利用しているものの、ES2015 以降での書き方は ES5 だとどのようになっていたかもここで同時に学習していきました。（ Playground ・ TypeScript で、その雰囲気を見ることが出来ます） モダン JavaScript これまでの知識を踏まえ、モダンな JavaScript の利用(実装)例として、 jser.github.io と preact-www のソースを読んでいきました。 これまでの JavaScript の言語自体に関する内容から、ライブラリを利用したコンポーネント間でのデータフローや、コンポーネントのライフサイクルに関する部分まで確認していきました。また初見のプロジェクトであればどのあたりから目を通していくか、などコード全体の読み方についても講師陣からアドバイスがありました。また時折出てくる DOM API に「なんだっけこれ・・・？」などとなりつつもコードを紐解いていくことで改めてフロントエンド JavaScript の特徴的な部分を垣間見ることができたように思います。 また最後に、現在開発に利用されているツール群について、 Qiita:JavaScript フレームワーク選定の議論 を参考に確認しました。それぞれのツールがどのような背景で使われている（あるいはいない）のかなども合わせて確認をしました。 ここまでのテーマを振り返りつつ、JavaScript が言語としてどのように変化してきたかを考えた時、webpack や TypeScript がなぜ使われるのか、ようやく腹に落ちたように思います。また上記資料も、どのようなケースで何を選択するのかや、アプリケーションの寿命とライブラリやツールの寿命といった運用フェーズで理解していく必要のある事項にも触れられており、非常に参考になりました。 実際にやってみて 今回のタスクフォースでは、3 ヶ月という期間の中で、1 ヶ月半の時点と、全体終了後に振り返りを実施しました。 その中で、参加メンバーからは 業務においては必要な部分に絞った調査で終わってしまったり、周りのコードを参考にしたりすることでなんとなくできた気になってしまっていたが、今回改めて基礎的な知識を学習する、復習する時間としてできてよかった。 断片的でまばらな知識しか持っていなかった部分が資料を読み込むことで理解が深まった 数年前にバズってあとで読まない「あとで読む」ブクマ記事をきちんと読めてよかった フロントエンド経験の長い講師陣の生きた知見（ツラミなども含めて）を聞くことができたのはありがたかった などの感想が出ました。 私自身も参加していましたが、個人的には基礎部分を改めて固めることができた機会だったように感じています。 また、普段は新しいツールなどの情報のキャッチアップへの意識が向きがちですが、今回のタスクフォースで言語・ツールの変遷を一度通して見ることができたことで、新しく現れる技術がどういった課題を解決するものなのか、これまでに似たツールがあったのかどうかなどを調べる指針が得られたことはよかったのかなと思っています。 一方で、今回のタスクフォースの中では「コードを書く」時間は作りませんでした。これについては振り返りの中でも話題となりましたが、それについては TodoMVC などを参考に、自分で手を動かしてみることが必要だろうと今後の課題として挙げられました。このあたりは実務以外での個々の頑張りが必要になってくる部分かと思います。 まとめ 「サーバーサイドエンジニアのフロントエンド開発力の底上げ」をテーマとしたタスクフォースについてご紹介しました。こういった形で、同じようなスキルセットのメンバーが集まり、お互いにわからない部分について話をしたり、経験豊富なメンバーから、個人の経験を含めて話を聞くというのは、改めて非常に貴重な機会だったように思います。 こういった取り組みを繰り返していくことで、個々で尖った部分はもちろん伸ばしつつ、全体の底上げを行いながら、よりよいプロダクト開発に繋げられればと考えています。

こんにちは。開発本部の 宍戸 です。 メドレーでは定期的に、テーマに沿って組織の技術的な底上げを行うための機会（ タスクフォース と呼んでいます）を行っています。そのタスクフォースの１つとして先日、フロントエンド開発力のベースアップを目的としたタスクフォースを行いました。本記事では、その取組みについてご紹介したいと思います。 背景 メドレーには現在 20 人弱のエンジニアが在籍しており、その約半数がサーバーサイド出身者です。また普段の開発においては、一つの機能をフロントからサーバーサイドまで一貫して一人が担当するケースが多くあります。サーバーサイド出身者のフロントエンド開発のスキルセットには多少ばらつきはあるものの、普段の開発業務ではレビュー等でそれぞれサポートしつつ開発を行っています。 しかし、フロントエンドの基礎的な部分や最新の流れまで聞かれると不安なメンバーも少なくありません。フロントエンド出身のメンバーが主導し、改めて基礎や最新情報に関して整理・フォローを行うことで、組織全体のフロントエンドの開発力を高めていきたいと考えました。 タスクフォースの目的 今回のタスクフォースは『フロントエンドの基本や最近のトレンドに関して学ぶ』ことで『（フロントエンド開発における）技術選定、設計、実装ができる基礎を身につける』、そしてこれらをもとに『新規のプロジェクトで設計段階から自走できるようになる』ことを目的としました。 その中でも特にここ数年、変化の流れが早かった JavaScript を中心にトピックを選定しました。 参加者は、これまでサーバーサイド開発を中心に行ってきたメンバー数名です。背景でも触れたとおり、業務経験はそれぞれある前提でのスタートであったため、基礎をみっちりというよりは、基礎的な話から最近の話題までを一通り確認しながら、各自の持っている知識の整理と土台を固めることで、今後の設計や技術選定を行う際の指針を得ることを目的としました。 進め方 今回のタスクフォースは期間を 3 ヶ月と定め、毎週 1 時間程度集まって行いました。 毎週、事前に講師陣が選んだ資料を読んでおき、当日は講師陣が参加者の不明点、疑問点に対してフォローアップするという形式で進めました。その他には、社内のプロダクトでの利用事例なども交えながらテーマに関する質問会のような形で進むことが多かったです。 また毎回のタスクフォースの時間のあとに、参加者がその日の内容をまとめた議事録形式の資料を作成し、参加者全員と共有することで、その日に話された内容や、それぞれの理解度を再度確認するようにしました。 内容 およその流れは上記の通りですが、約 3 ヶ月でどのようなテーマに触れてきたのか、一部をご紹介します。 フロントエンドの基礎 序盤はこちらの資料を利用させていただきながら進めました。 ブラウザの仕組み: 最新ウェブブラウザの内部構造 Asg Boot Camp 　 HTML/CSS An Introduction to JavaScript ブラウザの仕組み、HTML/CSS の基本的な話のおさらい、JavaScript の話に関連して、これまでに出てきた AltJS についてもいくつか特徴や何故流行ったのかなどについて読み込みました。 この中でも、 ブラウザの仕組み: 最新ウェブブラウザの内部構造 で DOM の解析、レンダリング、レイアウトといったブラウザ内部で具体的に何が行われているのかといった話はここで確認できてよかったという声が多くありました。 JavaScript（基礎〜ES2015 以降） JavaScript の話題への導入編としてこちらを資料として読み込みました。 You Don’t Know JS: Up & Going JavaScript Garden このパートでは JavaScript の基礎は、あえて ES3〜5 をベースにすることで JavaScript と他言語との違い・特徴を再確認していきました。上記の内容を踏まえ、今では使わない書き方などについてはその理由も確認しながら進めていきました。 その後は Learn ES2015 · Babel を参照しながら、Promise, Class などは普段の開発でも当たり前のように利用しているものの、ES2015 以降での書き方は ES5 だとどのようになっていたかもここで同時に学習していきました。（ Playground ・ TypeScript で、その雰囲気を見ることが出来ます） モダン JavaScript これまでの知識を踏まえ、モダンな JavaScript の利用(実装)例として、 jser.github.io と preact-www のソースを読んでいきました。 これまでの JavaScript の言語自体に関する内容から、ライブラリを利用したコンポーネント間でのデータフローや、コンポーネントのライフサイクルに関する部分まで確認していきました。また初見のプロジェクトであればどのあたりから目を通していくか、などコード全体の読み方についても講師陣からアドバイスがありました。また時折出てくる DOM API に「なんだっけこれ・・・？」などとなりつつもコードを紐解いていくことで改めてフロントエンド JavaScript の特徴的な部分を垣間見ることができたように思います。 また最後に、現在開発に利用されているツール群について、 Qiita:JavaScript フレームワーク選定の議論 を参考に確認しました。それぞれのツールがどのような背景で使われている（あるいはいない）のかなども合わせて確認をしました。 ここまでのテーマを振り返りつつ、JavaScript が言語としてどのように変化してきたかを考えた時、webpack や TypeScript がなぜ使われるのか、ようやく腹に落ちたように思います。また上記資料も、どのようなケースで何を選択するのかや、アプリケーションの寿命とライブラリやツールの寿命といった運用フェーズで理解していく必要のある事項にも触れられており、非常に参考になりました。 実際にやってみて 今回のタスクフォースでは、3 ヶ月という期間の中で、1 ヶ月半の時点と、全体終了後に振り返りを実施しました。 その中で、参加メンバーからは 業務においては必要な部分に絞った調査で終わってしまったり、周りのコードを参考にしたりすることでなんとなくできた気になってしまっていたが、今回改めて基礎的な知識を学習する、復習する時間としてできてよかった。 断片的でまばらな知識しか持っていなかった部分が資料を読み込むことで理解が深まった 数年前にバズってあとで読まない「あとで読む」ブクマ記事をきちんと読めてよかった フロントエンド経験の長い講師陣の生きた知見（ツラミなども含めて）を聞くことができたのはありがたかった などの感想が出ました。 私自身も参加していましたが、個人的には基礎部分を改めて固めることができた機会だったように感じています。 また、普段は新しいツールなどの情報のキャッチアップへの意識が向きがちですが、今回のタスクフォースで言語・ツールの変遷を一度通して見ることができたことで、新しく現れる技術がどういった課題を解決するものなのか、これまでに似たツールがあったのかどうかなどを調べる指針が得られたことはよかったのかなと思っています。 一方で、今回のタスクフォースの中では「コードを書く」時間は作りませんでした。これについては振り返りの中でも話題となりましたが、それについては TodoMVC などを参考に、自分で手を動かしてみることが必要だろうと今後の課題として挙げられました。このあたりは実務以外での個々の頑張りが必要になってくる部分かと思います。 まとめ 「サーバーサイドエンジニアのフロントエンド開発力の底上げ」をテーマとしたタスクフォースについてご紹介しました。こういった形で、同じようなスキルセットのメンバーが集まり、お互いにわからない部分について話をしたり、経験豊富なメンバーから、個人の経験を含めて話を聞くというのは、改めて非常に貴重な機会だったように思います。 こういった取り組みを繰り返していくことで、個々で尖った部分はもちろん伸ばしつつ、全体の底上げを行いながら、よりよいプロダクト開発に繋げられればと考えています。

こんにちは。開発本部の 宍戸 です。 メドレーでは定期的に、テーマに沿って組織の技術的な底上げを行うための機会（ タスクフォース と呼んでいます）を行っています。そのタスクフォースの１つとして先日、フロントエンド開発力のベースアップを目的としたタスクフォースを行いました。本記事では、その取組みについてご紹介したいと思います。 背景 メドレーには現在 20 人弱のエンジニアが在籍しており、その約半数がサーバーサイド出身者です。また普段の開発においては、一つの機能をフロントからサーバーサイドまで一貫して一人が担当するケースが多くあります。サーバーサイド出身者のフロントエンド開発のスキルセットには多少ばらつきはあるものの、普段の開発業務ではレビュー等でそれぞれサポートしつつ開発を行っています。 しかし、フロントエンドの基礎的な部分や最新の流れまで聞かれると不安なメンバーも少なくありません。フロントエンド出身のメンバーが主導し、改めて基礎や最新情報に関して整理・フォローを行うことで、組織全体のフロントエンドの開発力を高めていきたいと考えました。 タスクフォースの目的 今回のタスクフォースは『フロントエンドの基本や最近のトレンドに関して学ぶ』ことで『（フロントエンド開発における）技術選定、設計、実装ができる基礎を身につける』、そしてこれらをもとに『新規のプロジェクトで設計段階から自走できるようになる』ことを目的としました。 その中でも特にここ数年、変化の流れが早かった JavaScript を中心にトピックを選定しました。 参加者は、これまでサーバーサイド開発を中心に行ってきたメンバー数名です。背景でも触れたとおり、業務経験はそれぞれある前提でのスタートであったため、基礎をみっちりというよりは、基礎的な話から最近の話題までを一通り確認しながら、各自の持っている知識の整理と土台を固めることで、今後の設計や技術選定を行う際の指針を得ることを目的としました。 進め方 今回のタスクフォースは期間を 3 ヶ月と定め、毎週 1 時間程度集まって行いました。 毎週、事前に講師陣が選んだ資料を読んでおき、当日は講師陣が参加者の不明点、疑問点に対してフォローアップするという形式で進めました。その他には、社内のプロダクトでの利用事例なども交えながらテーマに関する質問会のような形で進むことが多かったです。 また毎回のタスクフォースの時間のあとに、参加者がその日の内容をまとめた議事録形式の資料を作成し、参加者全員と共有することで、その日に話された内容や、それぞれの理解度を再度確認するようにしました。 内容 およその流れは上記の通りですが、約 3 ヶ月でどのようなテーマに触れてきたのか、一部をご紹介します。 フロントエンドの基礎 序盤はこちらの資料を利用させていただきながら進めました。 ブラウザの仕組み: 最新ウェブブラウザの内部構造 Asg Boot Camp 　 HTML/CSS An Introduction to JavaScript ブラウザの仕組み、HTML/CSS の基本的な話のおさらい、JavaScript の話に関連して、これまでに出てきた AltJS についてもいくつか特徴や何故流行ったのかなどについて読み込みました。 この中でも、 ブラウザの仕組み: 最新ウェブブラウザの内部構造 で DOM の解析、レンダリング、レイアウトといったブラウザ内部で具体的に何が行われているのかといった話はここで確認できてよかったという声が多くありました。 JavaScript（基礎〜ES2015 以降） JavaScript の話題への導入編としてこちらを資料として読み込みました。 You Don’t Know JS: Up & Going JavaScript Garden このパートでは JavaScript の基礎は、あえて ES3〜5 をベースにすることで JavaScript と他言語との違い・特徴を再確認していきました。上記の内容を踏まえ、今では使わない書き方などについてはその理由も確認しながら進めていきました。 その後は Learn ES2015 · Babel を参照しながら、Promise, Class などは普段の開発でも当たり前のように利用しているものの、ES2015 以降での書き方は ES5 だとどのようになっていたかもここで同時に学習していきました。（ Playground ・ TypeScript で、その雰囲気を見ることが出来ます） モダン JavaScript これまでの知識を踏まえ、モダンな JavaScript の利用(実装)例として、 jser.github.io と preact-www のソースを読んでいきました。 これまでの JavaScript の言語自体に関する内容から、ライブラリを利用したコンポーネント間でのデータフローや、コンポーネントのライフサイクルに関する部分まで確認していきました。また初見のプロジェクトであればどのあたりから目を通していくか、などコード全体の読み方についても講師陣からアドバイスがありました。また時折出てくる DOM API に「なんだっけこれ・・・？」などとなりつつもコードを紐解いていくことで改めてフロントエンド JavaScript の特徴的な部分を垣間見ることができたように思います。 また最後に、現在開発に利用されているツール群について、 Qiita:JavaScript フレームワーク選定の議論 を参考に確認しました。それぞれのツールがどのような背景で使われている（あるいはいない）のかなども合わせて確認をしました。 ここまでのテーマを振り返りつつ、JavaScript が言語としてどのように変化してきたかを考えた時、webpack や TypeScript がなぜ使われるのか、ようやく腹に落ちたように思います。また上記資料も、どのようなケースで何を選択するのかや、アプリケーションの寿命とライブラリやツールの寿命といった運用フェーズで理解していく必要のある事項にも触れられており、非常に参考になりました。 実際にやってみて 今回のタスクフォースでは、3 ヶ月という期間の中で、1 ヶ月半の時点と、全体終了後に振り返りを実施しました。 その中で、参加メンバーからは 業務においては必要な部分に絞った調査で終わってしまったり、周りのコードを参考にしたりすることでなんとなくできた気になってしまっていたが、今回改めて基礎的な知識を学習する、復習する時間としてできてよかった。 断片的でまばらな知識しか持っていなかった部分が資料を読み込むことで理解が深まった 数年前にバズってあとで読まない「あとで読む」ブクマ記事をきちんと読めてよかった フロントエンド経験の長い講師陣の生きた知見（ツラミなども含めて）を聞くことができたのはありがたかった などの感想が出ました。 私自身も参加していましたが、個人的には基礎部分を改めて固めることができた機会だったように感じています。 また、普段は新しいツールなどの情報のキャッチアップへの意識が向きがちですが、今回のタスクフォースで言語・ツールの変遷を一度通して見ることができたことで、新しく現れる技術がどういった課題を解決するものなのか、これまでに似たツールがあったのかどうかなどを調べる指針が得られたことはよかったのかなと思っています。 一方で、今回のタスクフォースの中では「コードを書く」時間は作りませんでした。これについては振り返りの中でも話題となりましたが、それについては TodoMVC などを参考に、自分で手を動かしてみることが必要だろうと今後の課題として挙げられました。このあたりは実務以外での個々の頑張りが必要になってくる部分かと思います。 まとめ 「サーバーサイドエンジニアのフロントエンド開発力の底上げ」をテーマとしたタスクフォースについてご紹介しました。こういった形で、同じようなスキルセットのメンバーが集まり、お互いにわからない部分について話をしたり、経験豊富なメンバーから、個人の経験を含めて話を聞くというのは、改めて非常に貴重な機会だったように思います。 こういった取り組みを繰り返していくことで、個々で尖った部分はもちろん伸ばしつつ、全体の底上げを行いながら、よりよいプロダクト開発に繋げられればと考えています。

こんにちは。開発本部の 宍戸 です。 メドレーでは定期的に、テーマに沿って組織の技術的な底上げを行うための機会（ タスクフォース と呼んでいます）を行っています。そのタスクフォースの１つとして先日、フロントエンド開発力のベースアップを目的としたタスクフォースを行いました。本記事では、その取組みについてご紹介したいと思います。 背景 メドレーには現在 20 人弱のエンジニアが在籍しており、その約半数がサーバーサイド出身者です。また普段の開発においては、一つの機能をフロントからサーバーサイドまで一貫して一人が担当するケースが多くあります。サーバーサイド出身者のフロントエンド開発のスキルセットには多少ばらつきはあるものの、普段の開発業務ではレビュー等でそれぞれサポートしつつ開発を行っています。 しかし、フロントエンドの基礎的な部分や最新の流れまで聞かれると不安なメンバーも少なくありません。フロントエンド出身のメンバーが主導し、改めて基礎や最新情報に関して整理・フォローを行うことで、組織全体のフロントエンドの開発力を高めていきたいと考えました。 タスクフォースの目的 今回のタスクフォースは『フロントエンドの基本や最近のトレンドに関して学ぶ』ことで『（フロントエンド開発における）技術選定、設計、実装ができる基礎を身につける』、そしてこれらをもとに『新規のプロジェクトで設計段階から自走できるようになる』ことを目的としました。 その中でも特にここ数年、変化の流れが早かった JavaScript を中心にトピックを選定しました。 参加者は、これまでサーバーサイド開発を中心に行ってきたメンバー数名です。背景でも触れたとおり、業務経験はそれぞれある前提でのスタートであったため、基礎をみっちりというよりは、基礎的な話から最近の話題までを一通り確認しながら、各自の持っている知識の整理と土台を固めることで、今後の設計や技術選定を行う際の指針を得ることを目的としました。 進め方 今回のタスクフォースは期間を 3 ヶ月と定め、毎週 1 時間程度集まって行いました。 毎週、事前に講師陣が選んだ資料を読んでおき、当日は講師陣が参加者の不明点、疑問点に対してフォローアップするという形式で進めました。その他には、社内のプロダクトでの利用事例なども交えながらテーマに関する質問会のような形で進むことが多かったです。 また毎回のタスクフォースの時間のあとに、参加者がその日の内容をまとめた議事録形式の資料を作成し、参加者全員と共有することで、その日に話された内容や、それぞれの理解度を再度確認するようにしました。 内容 およその流れは上記の通りですが、約 3 ヶ月でどのようなテーマに触れてきたのか、一部をご紹介します。 フロントエンドの基礎 序盤はこちらの資料を利用させていただきながら進めました。 ブラウザの仕組み: 最新ウェブブラウザの内部構造 Asg Boot Camp 　 HTML/CSS An Introduction to JavaScript ブラウザの仕組み、HTML/CSS の基本的な話のおさらい、JavaScript の話に関連して、これまでに出てきた AltJS についてもいくつか特徴や何故流行ったのかなどについて読み込みました。 この中でも、 ブラウザの仕組み: 最新ウェブブラウザの内部構造 で DOM の解析、レンダリング、レイアウトといったブラウザ内部で具体的に何が行われているのかといった話はここで確認できてよかったという声が多くありました。 JavaScript（基礎〜ES2015 以降） JavaScript の話題への導入編としてこちらを資料として読み込みました。 You Don’t Know JS: Up & Going JavaScript Garden このパートでは JavaScript の基礎は、あえて ES3〜5 をベースにすることで JavaScript と他言語との違い・特徴を再確認していきました。上記の内容を踏まえ、今では使わない書き方などについてはその理由も確認しながら進めていきました。 その後は Learn ES2015 · Babel を参照しながら、Promise, Class などは普段の開発でも当たり前のように利用しているものの、ES2015 以降での書き方は ES5 だとどのようになっていたかもここで同時に学習していきました。（ Playground ・ TypeScript で、その雰囲気を見ることが出来ます） モダン JavaScript これまでの知識を踏まえ、モダンな JavaScript の利用(実装)例として、 jser.github.io と preact-www のソースを読んでいきました。 これまでの JavaScript の言語自体に関する内容から、ライブラリを利用したコンポーネント間でのデータフローや、コンポーネントのライフサイクルに関する部分まで確認していきました。また初見のプロジェクトであればどのあたりから目を通していくか、などコード全体の読み方についても講師陣からアドバイスがありました。また時折出てくる DOM API に「なんだっけこれ・・・？」などとなりつつもコードを紐解いていくことで改めてフロントエンド JavaScript の特徴的な部分を垣間見ることができたように思います。 また最後に、現在開発に利用されているツール群について、 Qiita:JavaScript フレームワーク選定の議論 を参考に確認しました。それぞれのツールがどのような背景で使われている（あるいはいない）のかなども合わせて確認をしました。 ここまでのテーマを振り返りつつ、JavaScript が言語としてどのように変化してきたかを考えた時、webpack や TypeScript がなぜ使われるのか、ようやく腹に落ちたように思います。また上記資料も、どのようなケースで何を選択するのかや、アプリケーションの寿命とライブラリやツールの寿命といった運用フェーズで理解していく必要のある事項にも触れられており、非常に参考になりました。 実際にやってみて 今回のタスクフォースでは、3 ヶ月という期間の中で、1 ヶ月半の時点と、全体終了後に振り返りを実施しました。 その中で、参加メンバーからは 業務においては必要な部分に絞った調査で終わってしまったり、周りのコードを参考にしたりすることでなんとなくできた気になってしまっていたが、今回改めて基礎的な知識を学習する、復習する時間としてできてよかった。 断片的でまばらな知識しか持っていなかった部分が資料を読み込むことで理解が深まった 数年前にバズってあとで読まない「あとで読む」ブクマ記事をきちんと読めてよかった フロントエンド経験の長い講師陣の生きた知見（ツラミなども含めて）を聞くことができたのはありがたかった などの感想が出ました。 私自身も参加していましたが、個人的には基礎部分を改めて固めることができた機会だったように感じています。 また、普段は新しいツールなどの情報のキャッチアップへの意識が向きがちですが、今回のタスクフォースで言語・ツールの変遷を一度通して見ることができたことで、新しく現れる技術がどういった課題を解決するものなのか、これまでに似たツールがあったのかどうかなどを調べる指針が得られたことはよかったのかなと思っています。 一方で、今回のタスクフォースの中では「コードを書く」時間は作りませんでした。これについては振り返りの中でも話題となりましたが、それについては TodoMVC などを参考に、自分で手を動かしてみることが必要だろうと今後の課題として挙げられました。このあたりは実務以外での個々の頑張りが必要になってくる部分かと思います。 まとめ 「サーバーサイドエンジニアのフロントエンド開発力の底上げ」をテーマとしたタスクフォースについてご紹介しました。こういった形で、同じようなスキルセットのメンバーが集まり、お互いにわからない部分について話をしたり、経験豊富なメンバーから、個人の経験を含めて話を聞くというのは、改めて非常に貴重な機会だったように思います。 こういった取り組みを繰り返していくことで、個々で尖った部分はもちろん伸ばしつつ、全体の底上げを行いながら、よりよいプロダクト開発に繋げられればと考えています。

こんにちは。開発本部の 宍戸 です。 メドレーでは定期的に、テーマに沿って組織の技術的な底上げを行うための機会（ タスクフォース と呼んでいます）を行っています。そのタスクフォースの１つとして先日、フロントエンド開発力のベースアップを目的としたタスクフォースを行いました。本記事では、その取組みについてご紹介したいと思います。 背景 メドレーには現在 20 人弱のエンジニアが在籍しており、その約半数がサーバーサイド出身者です。また普段の開発においては、一つの機能をフロントからサーバーサイドまで一貫して一人が担当するケースが多くあります。サーバーサイド出身者のフロントエンド開発のスキルセットには多少ばらつきはあるものの、普段の開発業務ではレビュー等でそれぞれサポートしつつ開発を行っています。 しかし、フロントエンドの基礎的な部分や最新の流れまで聞かれると不安なメンバーも少なくありません。フロントエンド出身のメンバーが主導し、改めて基礎や最新情報に関して整理・フォローを行うことで、組織全体のフロントエンドの開発力を高めていきたいと考えました。 タスクフォースの目的 今回のタスクフォースは『フロントエンドの基本や最近のトレンドに関して学ぶ』ことで『（フロントエンド開発における）技術選定、設計、実装ができる基礎を身につける』、そしてこれらをもとに『新規のプロジェクトで設計段階から自走できるようになる』ことを目的としました。 その中でも特にここ数年、変化の流れが早かった JavaScript を中心にトピックを選定しました。 参加者は、これまでサーバーサイド開発を中心に行ってきたメンバー数名です。背景でも触れたとおり、業務経験はそれぞれある前提でのスタートであったため、基礎をみっちりというよりは、基礎的な話から最近の話題までを一通り確認しながら、各自の持っている知識の整理と土台を固めることで、今後の設計や技術選定を行う際の指針を得ることを目的としました。 進め方 今回のタスクフォースは期間を 3 ヶ月と定め、毎週 1 時間程度集まって行いました。 毎週、事前に講師陣が選んだ資料を読んでおき、当日は講師陣が参加者の不明点、疑問点に対してフォローアップするという形式で進めました。その他には、社内のプロダクトでの利用事例なども交えながらテーマに関する質問会のような形で進むことが多かったです。 また毎回のタスクフォースの時間のあとに、参加者がその日の内容をまとめた議事録形式の資料を作成し、参加者全員と共有することで、その日に話された内容や、それぞれの理解度を再度確認するようにしました。 内容 およその流れは上記の通りですが、約 3 ヶ月でどのようなテーマに触れてきたのか、一部をご紹介します。 フロントエンドの基礎 序盤はこちらの資料を利用させていただきながら進めました。 ブラウザの仕組み: 最新ウェブブラウザの内部構造 Asg Boot Camp 　 HTML/CSS An Introduction to JavaScript ブラウザの仕組み、HTML/CSS の基本的な話のおさらい、JavaScript の話に関連して、これまでに出てきた AltJS についてもいくつか特徴や何故流行ったのかなどについて読み込みました。 この中でも、 ブラウザの仕組み: 最新ウェブブラウザの内部構造 で DOM の解析、レンダリング、レイアウトといったブラウザ内部で具体的に何が行われているのかといった話はここで確認できてよかったという声が多くありました。 JavaScript（基礎〜ES2015 以降） JavaScript の話題への導入編としてこちらを資料として読み込みました。 You Don’t Know JS: Up & Going JavaScript Garden このパートでは JavaScript の基礎は、あえて ES3〜5 をベースにすることで JavaScript と他言語との違い・特徴を再確認していきました。上記の内容を踏まえ、今では使わない書き方などについてはその理由も確認しながら進めていきました。 その後は Learn ES2015 · Babel を参照しながら、Promise, Class などは普段の開発でも当たり前のように利用しているものの、ES2015 以降での書き方は ES5 だとどのようになっていたかもここで同時に学習していきました。（ Playground ・ TypeScript で、その雰囲気を見ることが出来ます） モダン JavaScript これまでの知識を踏まえ、モダンな JavaScript の利用(実装)例として、 jser.github.io と preact-www のソースを読んでいきました。 これまでの JavaScript の言語自体に関する内容から、ライブラリを利用したコンポーネント間でのデータフローや、コンポーネントのライフサイクルに関する部分まで確認していきました。また初見のプロジェクトであればどのあたりから目を通していくか、などコード全体の読み方についても講師陣からアドバイスがありました。また時折出てくる DOM API に「なんだっけこれ・・・？」などとなりつつもコードを紐解いていくことで改めてフロントエンド JavaScript の特徴的な部分を垣間見ることができたように思います。 また最後に、現在開発に利用されているツール群について、 Qiita:JavaScript フレームワーク選定の議論 を参考に確認しました。それぞれのツールがどのような背景で使われている（あるいはいない）のかなども合わせて確認をしました。 ここまでのテーマを振り返りつつ、JavaScript が言語としてどのように変化してきたかを考えた時、webpack や TypeScript がなぜ使われるのか、ようやく腹に落ちたように思います。また上記資料も、どのようなケースで何を選択するのかや、アプリケーションの寿命とライブラリやツールの寿命といった運用フェーズで理解していく必要のある事項にも触れられており、非常に参考になりました。 実際にやってみて 今回のタスクフォースでは、3 ヶ月という期間の中で、1 ヶ月半の時点と、全体終了後に振り返りを実施しました。 その中で、参加メンバーからは 業務においては必要な部分に絞った調査で終わってしまったり、周りのコードを参考にしたりすることでなんとなくできた気になってしまっていたが、今回改めて基礎的な知識を学習する、復習する時間としてできてよかった。 断片的でまばらな知識しか持っていなかった部分が資料を読み込むことで理解が深まった 数年前にバズってあとで読まない「あとで読む」ブクマ記事をきちんと読めてよかった フロントエンド経験の長い講師陣の生きた知見（ツラミなども含めて）を聞くことができたのはありがたかった などの感想が出ました。 私自身も参加していましたが、個人的には基礎部分を改めて固めることができた機会だったように感じています。 また、普段は新しいツールなどの情報のキャッチアップへの意識が向きがちですが、今回のタスクフォースで言語・ツールの変遷を一度通して見ることができたことで、新しく現れる技術がどういった課題を解決するものなのか、これまでに似たツールがあったのかどうかなどを調べる指針が得られたことはよかったのかなと思っています。 一方で、今回のタスクフォースの中では「コードを書く」時間は作りませんでした。これについては振り返りの中でも話題となりましたが、それについては TodoMVC などを参考に、自分で手を動かしてみることが必要だろうと今後の課題として挙げられました。このあたりは実務以外での個々の頑張りが必要になってくる部分かと思います。 まとめ 「サーバーサイドエンジニアのフロントエンド開発力の底上げ」をテーマとしたタスクフォースについてご紹介しました。こういった形で、同じようなスキルセットのメンバーが集まり、お互いにわからない部分について話をしたり、経験豊富なメンバーから、個人の経験を含めて話を聞くというのは、改めて非常に貴重な機会だったように思います。 こういった取り組みを繰り返していくことで、個々で尖った部分はもちろん伸ばしつつ、全体の底上げを行いながら、よりよいプロダクト開発に繋げられればと考えています。