Medley Developer Blog

株式会社メドレーのエンジニア・デザイナーによるブログです

2018年の開発本部キックオフ合宿を行いました!@河口湖

こんにちは、開発本部の日下です。インターンを経て新卒としてメドレーに入り、現在は1年生エンジニアとしてオンライン診療アプリCLINICSの開発を担当しています。先日開発本部でキックオフ合宿を河口湖で行ってきましたので、詳細をレポートします。

年始のキックオフを合宿で行う意図

メドレーの開発本部では、チームビルディングを目的としてバーベキューなど全体でリフレッシュをする機会を年に数回設けています。

そのリフレッシュの一環として行っているメドレーの「年始のキックオフ合宿」は、昨年から行われています。昨年のレポートはこちらにあります。

メドレー開発本部全体のキックオフを合宿で行う意図は主に二つあります。

親睦を深める

一つ目の理由は親睦を深めることにあります。

リフレッシュを兼ねた一体感の醸成、連携・親密感を深める場を定期的に用意するようにしています。実際に合宿を終えて振り返ってみても、合宿は日常より密な交流をする場として最高だったなと思います。

方向性の共有

二つ目の理由は方向性の共有のためです。

昨年の合宿では、今後どういった方向を会社として、また各プロダクトとして目指して行くのかといった話をCTO・平山から共有しました。普段の業務から離れた場所でこうした話に向き合えるという意味で、共通の軸をより強く持つためには合宿が適切だと実感し、今年も合宿を行うことになりました

合宿先・アクティビティの選定

いわゆる開発合宿ではなかったため、選定には次の項目を重視しました。

  • 二十数名を収容できるキャパシティがあること
  • プライベートでも行きたい、思い出になるような場所であること
  • アクティビティが近くにあること
  • +αでバーベキューなどができること

上記の条件をすべて満たした場所を調査しましたが、「宿はあるがアクティビティがない」「アクティビティはあるが宿がない」のようになかなかマッチするところがなく苦労しました。

最終的にはこれら全てにマッチした先として、宿泊先を河口湖カントリーコテージさんに、アクティビティはカントリーレイクシステムズさんにお世話になることにしました。

また、アクティビティに関しては、カヌー体験やほうとうづくりなど様々なものが用意されていましたが、次の観点から洞窟探検を選択しました。

  • 普段座りっぱなしなので、運動が行えること
  • 新しい刺激を受けられるように、非日常感が体験できること
  • メンバーの普段見れない様子がでてきそうな、高揚感の高まる場所であること

    非日常な体験ができる洞窟探検

当日、河口湖駅に集合した後はまずアクティビティに挑みました。

みんなで非日常を体験し、リフレッシュしてもらおうと選択したものでしたが、私も含め洞窟探検をした人はおらず、どういったものだろうとワクワクしながら富士の樹海を散策しました。

今回体験した洞窟は富士の青木ヶ原樹海にある富士風穴、初めて本格的な洞窟を見た我々は息を呑むような風景に圧倒されました。

f:id:medley_inc:20180208175850j:plain 先日の週刊メドレーで掲載された写真はまさに洞窟に入ろうとするメンバーでした。 思った以上に洞窟感のある洞窟が姿を表しおおーっとなりました。

天井に頭をぶつけたり、手をついて怪我をしたりする可能性がありましたが、ヘルメット・手袋・真っ赤なつなぎといったグッズがレンタルできたので、すべて装着して洞窟に挑みました。

洞窟の中は手すりや階段のない、自然そのままの洞窟らしく、岩がむき出しで天井が低かったりしたので思った以上に装備が役に立ちました。

f:id:medley_inc:20180208175926j:plain 氷柱がある中、奥の方まで進むメンバー

洞窟といえば氷柱!と思っていたのですが、ちょうど数日前に雨が降った影響で、普段より足元や天井から氷柱がたくさん生えていたので触ってみたり、初めての経験ばかりでした。

氷が多い影響で滑りかけることもありましたが、ガイドさんと先行しているメンバーからの助言に助けられつつ進むことができました。

f:id:medley_inc:20180208180641j:plain 無事に生還しました!

普段は一緒に仕事をしている仲間と会社ではなく洞窟という空間で一緒にいるという不思議な状況と、適度な運動のせいか気分は高揚し、普段は見られないような同僚の一面を見ることができた良い経験になったと思います。

2018年の開発本部キックオフ!

アクティビティで適度に運動をした後はコテージに移り、少しずつお酒を飲んでくつろぎ始めたタイミングで、2018年のキックオフとしてCTO・平山によるプレゼンを行いました。

f:id:medley_inc:20180208180054p:plain

昨年2017年は四つのプロダクトのうちジョブメドレー・MEDLEY・CLINICSの大規模リニューアルがあり、大きな変化の年となりました。

また、今後どういった会社にしていきたいか?医療業界にどういった形で我々が貢献していくのか?そしてそのために事業として、またプロダクトとして2018年はどういった体制で推進していくのかといった事柄が共有されました。

なぜやるのか?どうやってやるのか?といった根本的な指針を背景を元に共有してもらうことで、今後の仕事における一つの軸ができたキックオフになったかと思います。

私自身一年間CLINICSに関わってきたため、肌身で感じてきた変化や苦労を思い出しつつ、プロダクト・事業が着実に成長していることを感じることができ、次の指針を確認する良い機会となりました。

平山のプロダクト・事業・会社に対する熱い思いはメドレー平山の中央突破にも書かれていますので、ぜひご覧ください。

バーベキュー&飲み

キックオフ後はバーベキュー!そして飲み!

火に強いメンバーは肉を焼いたり、料理が得意なメンバーは焼きそばやパスタを作っては食べて飲んで談笑し、思い思いに合宿を楽しんでいました。

f:id:medley_inc:20180208180114j:plain まずは肉を焼く火に強いメンバー

f:id:medley_inc:20180208180137j:plain 談笑するメンバー(酔いが回りピントがボケ気味)

f:id:medley_inc:20180208180200j:plain 思い思いにくつろぐメンバー

余談ですが、上の画像で全員が着ている灰色のパーカーはキックオフ直前に配られたメドレーオフィシャルグッズの一つ、デザイン部長・マエダがデザインしたメドレーパーカーです。

実はメドレーではパーカー以外にもうちわやTシャツ、絆創膏などグッズが増えています。

気がついたら増えているので収集は大変ですが、今年はどういったグッズが作られるのか今から楽しみです。

メンバー同士で飲んで食べてくつろぎながら、プロダクトへの思いやプライベートの話などを語り合う宴会が夜遅くまで続きました。

まとめ

いかがだったでしょうか?メドレー開発本部のキックオフ合宿の様子が少しでも伝われば幸いです。

アクティビティやバーベキューを通じてより親密に、プレゼンを通じて認識の共有ができた良い合宿になったと思います。

なお、今回の宿泊先は大人数でも対応可能なコテージが用意され、またWi-Fiなどの通信設備も整い、受付の方の対応も丁寧で、プライベートでも利用したくなる素敵な宿でした。

開発合宿等の大人数での宿を探している方にご参考になれば幸いです。

最後に

最後になりましたが、今回の合宿の企画運営をリードしてくれた新居さんありがとうございました!

f:id:medley_inc:20180208180347j:plain 来年またキックオフ合宿したいですね!(CTOが撮影してくれたので、CTO不在の集合写真)

メドレーでは、チームで新しい医療体験を提供するプロダクトを一緒に創るディレクターやエンジニア、デザイナーを募集しています。

ご興味ある方は、まずはお気軽に話を聞きにお越しください!

www.medley.jp

”自分たちにも優しい”デザインとは?

こんにちは。最近白髪が目立つようになりました。最初は蛍光灯の反射かな?とおもっていましたが実はそうじゃないらしいイケメン担当デザイナーの小山です。

私が担当しているジョブメドレーではサービスの改善をいくつも重ねますがその結果、全体の統一感が薄くなりデザインの改善をすることがあります。

こういった場合、もちろんユーザーの使いやすさを前提にリニューアルを考えますが、自分たち(開発者)にも使いやすいデザインはどういう姿か追いながら取り組むように心がけるようにしてみることにしました。

この試みの背景にはサービスのプロダクト基本理念が関係しています。このエントリでは、先般行ったモバイル向けの求職者画面のデザインリニューアルを通して、プロダクト基本理念に基づいた「自分たちにも使いやすいデザイン」を実現した話をご紹介いたします。

開発工数を増大させるデザイン

まず始めにジョブメドレーの求職者画面についてです。これは医療従事者向けの求人を探しているユーザー『求職者』のための画面で、求人の絞り込む検索、求人の詳細情報、職種の情報を発信するブログ、サービスのコンセプト紹介など多彩な情報で構成されています。

メドレーが運営しているサービスの中で最も歴史があり、求職者の希望に見合った求人をスマートに探すことができるように、リニューアルや機能拡充を繰り返しおこなってきました。おかげさまで毎年安定的な成長をとげています。

f:id:medley_inc:20180130202329p:plain 求職者画面の一部

ただその一方で、リニューアルに対応しきれなかったページも数多くあります。未対応のページは時期を改めて対応するはずでしたが、開発リソースの事情で全て対応できている状態ではありません。

そうした未対応がリニューアルごとに積み重なり、数世代分のデザインパーツが並行運用され、開発の作業効率がなかなか向上できない状況でした。

たとえばボタンやアイコンが同じであったとしても挙動や意味付けにズレが生じていたり、使われているはずがないデザインパーツが全く別の使われ方で存在していたり、全体の把握が追いついていない状況が所々ありました。

これは求職者にとって使い勝手が複雑になる上に、似たようなデザインパーツが増殖されたり誤った使い方をすることで、デザインのルールが曖昧になりエンジニアの作業工数が肥大化していきます。もちろんデザイナーの工数もです。

今回のデザインリニューアルの発端は、ユーザーのために更に使いやすさの改善と、用途が曖昧なデザインパーツの並行運用がもたらす開発上の問題を解決したいということもありました。

プロダクト基本理念に立ち返る

問題を解決するためにどういう方向性が良いか検討するため、まずプロダクト理念まで立ち返ってみました。

ジョブメドレーのプロダクト理念は、各部署が業務を行うための行動指針のようなものです。 プロダクトを一定の品質を保つため、求職者の求職活動を支えるキャリアサポート、事業所の効果的な求人掲載を提案するカスタマーサクセスやクリエイションチーム、これから求人を掲載したい事業所をサポートするセールスチーム、そして開発チームがこのプロダクト理念をもとに動いています。

f:id:medley_inc:20180130202400j:plain

求人を探すユーザー『求職者』と求人を出すユーザー『事業者』の双方が満足のいく意思決定をするためのこれら3つの理念を核としています。また、その理念を通して実現するサービスのミッションの達成に向かってメンバーは業務を行なっています。デザインパーツもこの理念をもとに制作されています。

ただ前述の通り、求職者画面が理念を守れる万全な状況にあるかというと、そうではありませんでした。必ずしも完璧なデザインが世の中にないように、ジョブメドレーももっと良くしていけるポイントはデザイン面で数多くあり、今回のリニューアルでは、そうした課題解決を目指しました。

さらに進めるにあたり、長期的にプロダクト理念に基づいた開発・デザインが行えるよう「求職者と開発の両方に働きかけられる環境」の整備を行うことにしました。

求職活動だけに集中できる環境

満足のいく意思決定を行う環境は、情報を読むことに悩むよう環境ではなくて、読んだ情報をじっくり考えられる環境だと私は考えています。

これまでのリニューアルで生まれた数世代ぶんの負債のために、字が読みにくいだとか、ボタン押したらどうなるかわからないだとか、そういった本質的ではない部分でつまづかない環境を作りました。

デザイナーがいなくても開発できる環境

いくら見栄えがよくユーザーにとって使い勝手が良かったとしても、それを運用するために開発のコストがかかるのであれば良いUIとは言えません。

使い勝手を維持するために開発を逼迫させ本来コストをかけるべきところに注力できずに別の部分の使い勝手を落とし、結果的にユーザーの不利益や不信感に繋がるかもしれないからです。これは極端な考えかもしれませんが、起こる可能性としては低くはないはずです。

それを解決する方法の1つとしてプロジェクトの関係者が把握できる内容にまでデザインを単純化させることなのではと私は考えています。デザイナーしか把握できないものではなく、むしろデザイナーが関わらなくても把握できるものを目指しました。

エンジニアだけで作れるデザイン

扱いやすいデザインとその意図

今回できたデザインは「普通」です。なるべく特殊はことは避け、デザイナー以外でもわかるデザインを目指しました。またデザインの意図もできる限りシンプルにまとめることに注力しました。

理路整然とした意図でも、それが複雑だとつくった本人しか扱えないものになります。なので聞きなれないワードや表現は控え、真に守らなくてはいけないことを抽出しました。またコンポーネントも限界まで削ぎ落とし最適化しました。

f:id:medley_inc:20180130202419j:plain デザインの意図を明文化

f:id:medley_inc:20180130202442j:plain 把握しやすい数に色を減らす 左がリニューアル前:右がリニューアル後

この過程でプロジェクトでうれしい場面がありました。それはエンジニアさんから新しいデザインがあがったこと。

デザインパーツが足りず追加制作していたところ、既にエンジニアさんがデザイントーンを参考に足りないパーツを製作してくれていました。しかも私のデザインよりも良いもので。。。複雑な心境になりましたが、それぐらいデザインが扱いやすくなっているということでもあるのかなと自分に言い聞かせましたポジティブに考えるようにしました。

f:id:medley_inc:20180130202502j:plain 左:私のデザイン 右:エンジニアのデザイン どう見ても左より右が周囲と喧嘩してない。左はしゃしゃり出る

今回のプロジェクトはUIを綺麗にすることだけじゃなく、それ自体を関係者が扱いやすいものに改善する目的でもあったので、この出来事は当初考えていたこと以上の結果で良かったと思っています。

この要因は単純にルールが簡単で覚えやすかったことなのかもしれません。そうした覚えやすいデザインは学習コストが軽く、まわりめぐってユーザーにも扱いやすいものなると考えています。

デザインを維持できるコンポーネントの運用

昨今ではデザインシステムやスタイルガイドの普及により、デザインパーツ、コンポーネントなどを運用することはさほど特別なことではないと思います。

今回のリニューアルでは整備した環境を維持するためにスタンダードな運用にも着手します。こうした取り組みは以前にも行なっていたものの開発チームに明文化されていなかったので、改善を繰りかえし動かしていきたいと思います。

まとめ

今回のリニューアルはバラバラだったデザイントーンに統一感を持たせることでユーザーに使いやすさを担保する、その過程で自分たちにも使いやすいデザインを目指しました。

一般的にはリニューアルではユーザーを中心したものが多いかもしれません。今回はその中に自分たち(開発者)も加味して考え、サービスのミッションの達成のためのプロダクト基本理念を支えられる環境作りを目指しました。

デザインの役割は物事を綺麗にするだけではなく、理念のような根っこの部分に立ち返れる機会や根っこそのものを具現化させる役割を担っていると考えています。とはいえ今回はその第一歩。今後は更に運用方法やコンテンツ設計や導線設計に磨きをかける必要があります。

また進捗があり次第ご報告できればと思います。ここまで読んでいただきありがとうございました。

最後に

メドレーでは、医療介護の求人サイト「ジョブメドレー」、医師たちがつくるオンライン医療事典「MEDLEY」、口コミで探せる介護施設の検索サイト「介護のほんね」、オンライン診療アプリ「CLINICS」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。

www.medley.jp

オンライン診療アプリ「CLINICS」の開発で重視している3つの習慣

こんにちは、開発本部の横尾です。

これまで介護施設の口コミサイト「介護のほんね」の立ち上げや医療介護の人材採用システム「ジョブメドレー」のディレクター・コンテンツ編集などを経験し、現在はオンライン診療アプリ「CLINICS(クリニクス)」のディレクターをしています。 

 CLINICSでは、慎重さとスピード感を両立して開発できるよう、3つの習慣を取り入れています。半年ほど実施してみて手法としてまとまってきましたので、ブログでも紹介させていただきます。 

背景

CLINICSは、スマートフォンやPCからビデオチャットでかかりつけ医の診察を受けられるオンライン診療アプリです。医療機関向けにはブラウザで予約管理や問診、診察、会計を行うことができる機能も提供しています。CLINICSを開発する際は、医療に関するプロダクトゆえに特に意識しなければいけない点がいくつかあります。

一つは人の命に関わるということ。オンライン診療は症状の落ち着いている方が対象となりますが、少しの使いにくさやミスも誰かの生命・生活に何らか影響するかもしれない緊張感が常にあります。

もう一つは、老若男女幅広く使われていること。病院にかかったことのない人はほとんどいないように、さまざまな人がCLINICSを利用しているので、どんな人でも不安なくスムーズに使えることが重要になってきます。

このような背景から、CLINICSでは慎重にゴールを設定し、丁寧に検証しながら開発を進める必要があります。一方で、あまりに慎重・丁寧すぎても何もできなかったり迷走したりしてスピード感を失いかねません。そこで、両者のバランスをうまく取り開発を推進するために次の3つを行っています。

CLINICS開発をうまく進める3つの習慣

1. プロダクトプリンシプルを共有する

プロダクトプリンシプルは、サービスとしてのやること・やらないことを簡潔に言語化したものです。

例えばCLINICSのプロダクトプリンシプルには「1UUの重み、活用率100%を目指すこだわり:一人の人の命を預かっているという使命感を持ち、一人でも多くの人が使え、今まで使えていた人が使えなくなることが一人でもないようにする」というフレーズがあります。

前述の通り、CLINICSは人の命に関わるプロダクトであり老若男女幅広く使われています。そのためあえてターゲットを絞らず、すべての人が使えるプロダクトを目指していることをこのフレーズで共有しています。これにより、施策検討段階では一部の人にとってとても使いやすいが使いこなせない人がいるUIと、ほぼすべての人がそこそこ使えるUIがあった時、私たちは迷わず後者を選択でき、すぐに実装に取り掛かることができます。

プロダクトプリンシプルの作成にあたっては、日頃寄せられる患者の声・医療機関の声をよく聞き、医療の成り立ちや医療業界の構造なども深いところまで学習するようにしました。患者にとって、医療機関にとって、そして社会にとってのあるべきプロダクト像を理念として映し出すようにしています。

2. 年間・四半期ごとのロードマップを策定する

ロードマップは、いつ頃どんな課題に取り組むのかを概ね年間・四半期ごとに定めたものです。こちらは比較的多くの開発現場で取り入れられている方法ではないでしょうか。

ロードマップをチームで意識するようにすると、先々に開発・リリースする機能を一人ひとりが理解でき、先回りして技術調査を進めたり関連する施策の効果分析の優先度を上げたりといったことができます。また、営業チームなど社内のほかの部署から開発提案があった際にはロードマップを見ながら今後の見通しを案内できるようになり、 他チームのメンバーからの信頼を得ながら開発に専念することができます。

ロードマップを策定する際は、プロダクトプリンシプルを開発内容として落とし込みつつ、事業として伸ばすべき数値や直近で解決すべきお問い合わせなども考慮するようにしています。また、四半期ごとにKPT法を使ってロードマップを振り返り、開発の期間や体制を見直すようにしています。

3. 週次で計画し、日次で進捗を追う

週次の計画と日次の進捗確認には、スタンディングミーティングを行っています。

CLINICSではGitHubのプロジェクト機能を使ってカンバンを作成しています。任意のタイミングでロードマップで挙げた課題をだいたい1週間程度で区切りのつくサイズのissueに落とし込み、カンバンのbacklogにセットします。毎週月曜日の午前中に週次定例を行い、その週に着手するissueをbacklogからin progressに移します。火曜以降は毎日issueごとに進捗を確認し、終わったものをdoneに移していきます。

このように週次・日次で計画と進捗確認を細かく繰り返すことで、一つひとつのissueをスピーディに進めるリズムができます。ミーティング時点で一つのissueも進んでいないということがないようにしようという意識が働き、個々人のパフォーマンスもアップします。

まとめ

今回は、開発推進のためにCLINICSで取り入れている習慣をご紹介しました。 

この3つの習慣は、どれか1つのみを行うのでもだめで、3つセットで実施することが今のCLINICS開発のカギになっています。プロダクトプリンシプルだけでは理想論のように思えたことも、ロードマップや計画になるとより具体的になって着手しやすくなり、また、計画で示しきれない改善の方向性はプロダクトプリンシプルに立ち返ることでお互いの認識をそろえやすくなります。

そうすれば不必要なルールの制定や社内コミュニケーションから解放され、日々やるべきことに集中でき、結果的により早くより優れたプロダクトをユーザーに届けることができると考えています。

メドレーでは、こうした様々な手法を取り入れながら新しい医療体験を提供するプロダクトを、一緒に創るディレクターやエンジニア、デザイナーを募集しています。

ご興味ある方は、まずはお気軽に話を聞きにお越しください!

www.wantedly.com

www.medley.jp

SkyWay UG Tokyo #1 に参加してきました

こんにちは、開発本部 平木です。2017/12/04(月)に SkyWay UG Tokyo #1 という勉強会がありました。弊社から開発本部の宍戸がセッション枠で発表させていただきましたので、イベントレポートをお送りします。

はじめに

弊社の運営サービスの1つである オンライン診察アプリ「CLINICS」 では運用初期の頃から医療機関と患者さんとの診察にSkyWayを使ったビデオチャットを導入しており、現在もWeb / iOS / Androidの各プラットフォームでSkyWayが稼動しています。 そのようなご縁もあり今回の勉強会では、CLINICSでSkyWayをどのように利用しているかをお話させていただきました。

f:id:dev-medley:20171221191518j:plain

セッション

それでは、各セッションの流れなどをご紹介していきたいと思います。

はじめに

勉強会の冒頭、UGのキックオフと参加者の自己紹介タイムがありました。

UGキックオフ

NTTコミュニケーションズの仲さんから、SkyWay UGをなぜ作るのか?というキックオフから会がスタートしました。

SkyWayの大きなミッションとして リアルタイムコミュニケーションを身近にする というものがあり、そのためには 開発者にサービス自体がフレンドリーであるべき であるという理念があるそうです。

開発者フレンドリーであるための一環として 開発者コミュニティの運用をしていく ということになりこの SkyWay UG Tokyoが発足されたという経緯が説明されました。

確かにこのような形で使っているサービスのUGが開催されると、サービスの開発者の方々や参加している他のユーザさん達と気軽に交流できるなというのを今回参加して実感しました。

SkyWay UGは東京だけではなく 関西福岡 でも続々と発足するとのことで、他の開発者サービスと同じように盛り上がっていくのではないでしょうか。

参加者自己紹介

キックオフが終わったところで、参加者の自己紹介タイムとなりました。

30人近くの参加者が順々に自己紹介していくという形だったのですが、個人的には珍しいなと思うのと同時に、懇親会で何をやっている方なのか?というのが分かりつつ話をすることができたという良さがありました。(参加者として自己紹介する勉強会は初めてでした!)

参加者の感想としては

  • 自分達と同じWeb業界の方がメイン…というわけでもなく、組み込みなどを仕事にしている方なども1/3くらいの割合でいたのが印象的だった
  • 実際にサービスやプロダクトにSkyWayを使っているという参加者の方が多かった
    • とはいえ使ってないが、興味があって参加したという方も
  • 中には弊社のCLINICSに興味があると言っていただけたりもした

という感じでした。ハードウェアにSkyWayを組み込んで使うということをやっている方も多く、改めて幅広い開発者に受け入れられてるプラットフォームだと感じました。

SkypeからSkyWayへ

最初のセッションは会場を提供されていた レアジョブ のInoueさんからの発表でした。

Inoueさんは現在は主にフロントエンド開発をされているそうで、このセッションもJavaScript SDKの知見がいろいろされた有意義なものでした。

レアジョブさんでは創業時からSkypeを使ってサービスを運用していたそうなのですが、サードパーティに依存しすぎるとビジネスとして危ういということで、SkyWayへの切り換えをしていっているそうです。

SkyWayは9月からトライアル版から正式版を提供されていますが、まだなかなか情報が少ないということで、新JavaScript SDKで開発していくなかで得たTipsが発表されました。

実サービスを運用してる方ならではの、 ビデオ・マイクのミュートビデオチャット中のページ離脱防止策 などの対応などは実用的で役立つものでした。

Inoueさんもこの後のLTで発表された仲さんもおっしゃっていましたが、SkyWayというかWebRTCのデバッグには chrome://webrtc-internls が重要だと改めて思った次第です。

オンライン診察アプリの作り方

speakerdeck.com

弊社の宍戸の発表です。

まずはメドレーと運営しているプロダクト紹介から始まり、そもそもCLINICSで実現したかったビデオチャットはどのような条件があったか?SkyWayを選んだ理由、SkyWayとFirebase Realtime Databaseを併用したオンライン診察の実装内容などをご紹介しました。

駆け足でのご紹介にはなりましたが、実際に商用サービスでの事例ということもあり、おかげさまで好評でした。

スライド中でも紹介したSkyWayとFirebaseを使った通話制御は他のプロダクトでも使ってることが多いらしく、相性的にもお勧めなのではないでしょうか。

LT

セッション枠が終わりLTとなったのですが、このLTがSkyWayの中の方達が担当するという豪華なものでした。

WebRTCで統計情報を収集する

qiita.com

NTTコミュニケーションズ仲さんのLTです。 chrome://webrtc-internls で表示されるような統計情報をJavaScript SDKを使って表示することができるという解説とデモでした。

WebRTCのデバッグや、ユーザからの問い合わせなどにすぐに使えそうな実践的な内容でした。が、現バージョンでは残念ながら、Android / iOSではこの統計情報が取れない…とのことだったので、将来的には取れるようになると弊社でもデバックが捗るので首を長くして待ちたいと思います。

紹介されているcallstats.ioは知らなかったので、参考になりました。行く行くは使ってみたいですね。

reCAPTCHAとAPI認証で手軽に利用できて不正利用に強いアプリを作ろう

www.slideshare.net

NTTコミュニケーションズ大津谷さんのLTです。SkyWayでは2018/9月にAPI認証機能がリリースされたため、この機能とreCAPTCHAを使いAPIキーの不正利用を防ぎながらログインが不要なサービスを作れるというものでした。

reCAPTCHAはこういう風に使えるんだ!という驚きと同時にプロトタイプなどをサッと作ったりするの大変よさそうな機能だと感じました。

まとめ

以上、SkyWay UG Tokyo #1 のレポートでした。SkyWayを現在使っている・使いたいというような開発者には気軽に情報交換もでき大変よいイベントでした。また、SkyWay開発陣がユーザからの意見などをすぐに吸い上げてくれるのが改めて分かりました。

次回の東京での開催はまだ未定なようですが、ご興味ある方はぜひいかがでしょうか。

弊社では、SkyWay(WebRTC)を使った開発に興味があるエンジニアさん、ビデオチャットのUIを良くしたい!と思っているデザイナーさんの募集をしています。ご応募お待ちしています。

www.medley.jp

www.wantedly.com

www.wantedly.com

PrometheusでRailsアプリケーションのパフォーマンスが簡単に見れますという発表をしました

こんにちは。エンジニアの宍戸です。先日、社内勉強会「TechLunch」にてPrometheusを使ったアプリケーションのモニタリングについて発表する機会がありましたので、その内容を少しご紹介できればと思います。

Prometheus

先日2.0がリリースされたばかりの統合監視ツールです。監視対象からメトリクスを取得し、その情報をGrafanaと連携してグラフィカルに表示したり、アラートマネージャ機能を利用してメトリクスの状況に応じて通知を作成することなどが可能です。また、PrometheusはPull型のメトリクス収集形式をとっていますが、サービスディスカバリ用の設定を入れることで、対象のサーバ群の増減の度に作業すること無く、監視対象を管理することができるなど、現在のアプリケーション稼働環境にあった運用が可能なものとなっています。(Prometheus自体に関する情報はかなり多くの方が記事を書かれているので、詳細はそちらにお任せしたいと思います🙏)

Prometheusは前職時代にもお世話になっており、そのときにはGoで書かれたサーバのモニタリングに利用していました。当時から便利に利用していたこともあり、弊社のプロダクトはRailsを利用しているため、今回はPrometheusを利用して、Railsアプリケーション自体のパフォーマンスに関するメトリクスを取得してみました。

アプリケーションパフォーマンスのモニタリング

アプリケーション自身のパフォーマンスの情報を定常的にモニタリングしておく事は、潜在的ボトルネックの発見や、アクセス状況の変化、リリース単位でのパフォーマンスの変化(改善/悪化)を早期に発見することに繋がると考えています。

アプリケーションのモニタリングは有料ツールを含めてかなり多くの選択肢があります。NewRelicのAPMは代表的なツールの一つで、実は現時点ではこちらを利用してモニタリングを行っています。またその他様々なツールでも同じようなインサイトを得ることができます。アプリケーションパフォーマンスのモニタリング(マネジメント)ツールについてはこちらに良くまとまっていましたので、合わせて見ていただくと良いかもしれません。

メトリクスについて

Prometheusも様々な機能がありますが、監視対象となるサーバはExporterと表現されます。このExporterに対して、Prometheus Serverがデータを取りに来る格好です。

https://github.com/prometheus/client_rubyというライブラリが公式に提供されています。こちらにあるPrometheus::Middleware::CollectorPrometheus::Middleware::Exporter という2つのRack middlewareを利用することで設定に数行追加するだけで以下に記載した情報をPrometheus Serverから利用する準備が整います。

key 意味
http_server_requests_total アプリケーションの処理したリクエスト総数
http_server_request_duration_seconds_bucket あるエンドポイントの要求処理時間のヒストグラム
http_server_request_duration_seconds_sum 上記の合計値
http_server_request_duration_seconds_count あるエンドポイントへのリクエストの総数
http_server_exceptions_total アプリケーションで発生した例外の合計数

ここで出て来るバケットというのは特定の範囲のデータを格納する領域のようなものです。 ヒストグラムの計算などの際に利用します。

これらを用いて、

  • 直近10分のエンドポイント毎のレイテンシ
    • rate(http_server_request_duration_seconds_sum{path=~"/api.*"}[5m]) / rate(http_server_request_duration_seconds_count{path=~"/api.*"}[5m])
  • APIのエンドポイント毎のステータスコードが200以外となったレスポンスの数
    • sum(http_server_requests_total{job="rack-example", code!~"^2..$", path=~"/api.*"} offset 10m ) by (path)

などをPromQLというPrometheusの独自クエリ言語を用いて集計することができます。デフォルトで提供されるダッシュボードで即座に確認できるのでとても便利です。

実際に発表した際のスライドはこちら。 speakerdeck.com

まとめ

今回はPrometheusを利用したRailsアプリケーションのモニタリングについてご紹介しました。

Prometheusがどうという話はあまりできませんでしたが、ここまで手軽に準備できるもんかというのは正直びっくりしました。他のツールを利用していない状態でアプリケーションの運用をしている場合には、特にRails等であれば簡単に監視を始められるので、導入を検討する価値はあるのではないかと思いました。

現在は比較的安定してサーバを稼働させることが出来ていると思いますが、日頃からこういったメトリクスを見つつ、今後の安定運用につなげていきたいと思います。

フロントエンドエンジニアがIonicを触ってみた〜メドレーTechLunch〜

こんにちは。開発本部の大岡です。オンライン診療アプリ「CLINICS」の開発を担当しているエンジニアです。2017年6月にメドレーに転職してきて初めて気づきましたが、僕は人見知りでした。

メドレーでは、定期的にTechLunchという社内勉強会を実施しています。今回僕が担当になりましたので、その時の内容をご紹介させていただければと思います。テーマは「フロントエンドエンジニアがIonicを触ってみた」です。

色々な事情を考えずに好き放題言っています。個人的にウェブアプリが好きということもありウェブアプリよりの偏ったことを書いていると思います。ご了承ください。

なぜIonicを触ろうと思ったか

ウェブアプリ・ネイティブアプリ(このエントリーではiOS/Android各プラットフォーム固有の言語を使って開発したものを指しています)それぞれにメリットデメリットはあると思いますが、ゲームのようなグラフィックごりごりのものでなければウェブアプリで十分に感じています。

最近では、両方に展開しているもののネイティブアプリにコストを割いてしまっているのか、モバイルのウェブアプリのUIが本当にひどかったり最適化されていないと感じる例があります。最適化もしてないし、導線はネイティブアプリに向けてるのにネイティブアプリの方が使われてるじゃん!って言われてもウェブアプリの気持ちになると「そりゃそうでしょ。。。」って感じです笑

とはいえ、いくらウェブアプリが好きでもネイティブアプリを作らざるをえないとなった場合にiOS/Androidそれぞれ作ることが適切なのかなと思ってしまいます。そこでクロスプラットフォーム開発できるものを探していると、自分のスキルセットに合いそうなものがいくつかありました。その中で今回は、Ionicを触ってみることにしました。

今回TechLunchで発表したスライドは以下です。

speakerdeck.com

スライドと重複してる箇所もありますが、テキストでも解説してみます。ご興味がありましたら以下もどうぞ。

ウェブアプリとネイティブアプリ

ウェブアプリとネイティブアプリはよく比較されますが、その違いは以下のような感じかなと思います。

項目 ウェブアプリ ネイティブアプリ
動作速度 遅め 早め
バイスの機能 使えるものもある 利用可
開発コスト 普通 多め
審査 無し 有り
インストール 不要 必要

動作速度は遅めとはいえ、ゲームではなくECサイトのようなものであれば、そこまで気にするほどではない思います(作りにもよると思いますが)。デバイスの機能に関してはChromeなら割と使えます。開発コストはワンソースでいけるのでネイティブアプリよりは優れているかなと思います。

あとは何と言っても、ブラウザとURLさえあればどこからでも使えるっていうのがメリットです。最近ですとウェブアプリをネイティブアプリっぽく動かすProgressive Web Application(以下PWA)というワードもよく目にするようになりました。PWAは動作速度の面やプッシュ通知・オフラインでも利用できたりとウェブアプリの弱点を補ってくれるのですが、PWAに必要な技術であるService Workerの実装がされていなかったりと環境により十分に恩恵を受けることができない場合があります。

個人的に以下のようなパターンの場合

  • ネイティブの実装が必要
  • 重要だけど機能に更新がはいることがほぼない
  • アプリを使う上で毎回必要なわけではない

アプリによっては、この部分だけアプリに切り出して、ウェブアプリで必要になったら呼び出すとかでもいいのかなと思います。

上記のようなことをネイティブアプリとして実現できるものにApach Cordova(以下Cordova)があります。ウェブアプリはWebView(ネイティブアプリ内でウェブページを表示する部品みたいなもの)に表示し、ネイティブ機能はプラグインとして提供されているのでそれをJavaScriptから呼び出すことが可能です。

Ionicとは

ウェブの技術を用いてネイティブアプリの開発を可能にするフレームワークです。 主な特徴は以下です。

実際に触ってみた

公式の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テンプレートを使用しました。

f:id:medley_inc:20171122191851g:plain

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部分に戻ってきます。実際触ってみた感じフルネイティブアプリと違和感なく感じます。

f:id:medley_inc:20171122192030g:plain

※アニメーションGIFの容量が重くなったので相手側でのコード入力中の空白時間を削ったり編集した影響で左下の緑と赤の画面が飛んだりしてますが、実際は滑らかです

まとめ

今回触ってみたというより指先が触れた程度ですが、全然Ionicでもいけそうな雰囲気を感じました。普通に触ってる分にはネイティブ部分なのかウェブ部分なのかわからなかったです。ただし、銀の弾丸ではないので、実際に開発に導入する場合はメリット・デメリットをちゃんと把握する必要があります。 ウェブアプリ寄りのことを言ってはきたものの、結局はウェブだろうがネイティブだろうがどんなツールを使おうが、使ってくれる人が求めるものを提供できればいいと思います。今後も何かあったときの引き出しのために色々なツールなど触っていこうと思います。

お知らせ

12/6(水)、こんなイベント(というか飲み会)をやります。 今回のブログの話が詳しく聞きたい、医療ヘルスケア領域の開発ってどんな感じだろう、社会貢献性の高いプロダクトに関わりたい、など思っているエンジニア・デザイナーの方、ビール片手に開発の話で盛り上がりませんか?

www.wantedly.com

その日は予定が入っているんだけど話を聞きたいという方は、こちらの「話を聞きたい」ボタンからどうぞ。

www.wantedly.com

提供価値によって異なるデザインプロセス

最近PS4グランツーリスモスポーツをやり始めて、自宅のネット環境の遅さに気づいたデザイナーのマエダです。前回はDLSについてご紹介させていただきましたが、今回はメドレーに入社して感じた「デザインプロセスの違い」について自分なりにまとめてみました。

あとで読みたい人向けに、エレベーターピッチ風にまとめると、

[ CLINICS ] というサービスは
[ 患者と医療機関向け ] それぞれサービスを提供しているが
[ 提供価値の違い ] によって
[ デザインの役割が異なる ] ことに気づいた

特に [ 医療機関向け ] は
[ UIが重要 ] となり
[ 伝えることを目的としたWebサイト ] とは違って
[ UIデザインの良し悪しがプロダクト全体の品質に関わる ] ため
[ 事業や技術を理解 ] した[ デザインオリエンテッド ] が求められる

というような内容です。

ユーザーによって異なる提供価値

メドレーに入社してから、オンライン診療アプリ「CLINICS(クリニクス)」というサービスのデザインを主に担当しているのですが、患者と医療機関側で提供しているプロダクトの内容が異なります。

f:id:medley_inc:20171116131612p:plain

  • オンライン診療の内容を伝え、利用を促すためのWebサイト(患者・医療機関双方)
  • 患者がオンラインで通院を行うためのアプリ
  • 医療機関側がオンラインで遠隔診療を行うためのシステム

サービスの入り口となるWebサイト

Webページの役割としては、オンライン診療というものがどういったもので、CLINICSを利用するとどういう課題解決につながるのか、というサービスの特徴を患者と医療機関双方に「伝えるためのデザイン」が必要となります。

デザインするにあたって注力すべきポイントは、装飾やイメージ画像などシンボリックなデザインとストーリー性のある導線設計をすることで、視覚的に特徴を伝わりやすくし、またコンバージョンポイントへ誘導するため、ボタン等は目立たせるなど、適切に情報を伝え、行動を促すためのデザインが重要になります。

患者がオンライン診療を行うためのアプリ

アプリは患者がオンライン診療をするための「病院検索」→「予約」→「問診」→「診察」→「決済」の機能をシームレスに繋げるためストレスのかからないユーザー体験を提供することが重要です。

そもそもオンライン診療のメリットとして、待ち時間の軽減や、落ち着いた環境で診察ができるなどが挙げられるため、そこに至るまでのユーザー体験を台無しにしてしまうUIでは元も子もなくなってしまいます。

アプリでは「伝えるデザイン」よりも「機能的なデザイン」が必要になりますが、ユーザーの行動を途切れさせないよう、不必要な要素や導線を極力排除して、非常にシンプルなUI設計をおこなっており、機能自体を主張しないデザインを心がけています。前回このブログでもとりあげたDLSも、そういった設計思想のもと開発を進めていたからこそ実現できたと思っています。

f:id:dev-medley:20171117113501p:plain

医療機関向けの遠隔診療システム

医療機関側に提供しているシステムは、オンライン診療を行うためのツールです。 Webサイトのように「伝えるデザイン」やコンバージョン重視ではなく、「より機能的に使いやすいデザイン」が重要になります。 このような画面をBootstrapのようなUIテンプレートそのままの見た目で構築してしまうと、技術的に素晴らしいものができたとしても、使い勝手が悪く貧弱な機能と見られかねないため、デザイナーが管理画面のUI設計に携わることは、ビジネス的にも非常に重要な要素です。

特にCLINICSの医療機関向けのシステムは、実際にオンラインで患者の診察を行うツールのため、医療機関側が診療行為をつつがなく終えられるようなUI設計が重要です。

MVP的な手法で、とりあえずリリースして検証を重ねていくというスタンスがとれないため、リリースするまでに機能的に不備がないか、医療従事者が迷わず正しく使えるUI設計になっているかなど、社内や実際の医療機関のテストを繰り返し、試行錯誤を経てリリースするという、プロダクトデザインをしている感覚になり「伝えるデザイン」とは違った思考でデザインに取り組んでいます。

機能重視なサービスこそ、直感的にシンプルなUIが重要

このようにCLINICSという1つのサービスを構成する要素の中でも、ターゲットユーザーや提供価値の違いによって、デザインアプローチや重要視する視点が異なります。

たとえば、自分も業務でよく利用するプロトタイピングツールのinVisionもログイン前は、利用シーンやより魅力的なサービスであるということを伝えるためのデザインをしており、ログイン後は直感的にわかりやすいシンプルなUI設計で、ログイン前後でサービスのUIが異なります。

inVisionも機能は豊富ですが、プロトタイピングを行う上で非常にシンプルな操作性を提供しており、無駄な説明や導線がなくても直感的に使えるUIは、継続して利用できる安心感にもつながり、見習うべきUIだなと思っています。

f:id:medley_inc:20171116131754p:plain

(inVisionの画面の違い)

CLINICSの医療機関向けシステムも受付管理やスケジュール、オンライン診療を行う機能など複数の機能をひとつのサービスとして提供しているため、UI的に複雑になりかねません。複雑な機能をまとめ、画面上にシンプルに落とし込めるかどうかというのを吟味し、作っては壊し、作っては壊しを繰り返しします。

これならいける!とおもったUIも、機能面での見落としなどがあったりすると導線に矛盾が生じたり、シンプルに表現したつもりが、逆に使い勝手の悪いUIになってしまったり。UIを考えるというのは、感性に訴えるデザインとは違ったよりロジカルな思考が必要で、デザインしながら四苦八苦して、ぶつぶつ独り言を言うことが多くなりますw

デザインオリエンテッドなプロダクト開発

Webサービスであればいかに目標としているコンバージョン率を高めるかどうか、分析〜調査〜開発というサイクルをベースとした運用になりますが、特に医療機関向けのシステムの場合は、ムダな機能や使いづらいUIだとサービス的に不安要素を抱かせる要因にもなり、ビジネスの成功可否に直結します

そのため、リリースまでにUIを磨けるだけ磨き、実際に医療機関の現場に出向いてどういうフローで診察を行っているのかなどヒアリングしたり、出来上がった機能を試してもらうなどし、十分に検討した上でリリースしています。こうしたデザインを重視した開発が行える点はメドレーだからこその開発体制かもしれません。

このようなデザインオリエンテッドなプロダクト開発を行う上で重要なポイントは、事業理解とエンジニアとの密な連携です。表面的なデザインではなく、実際に使われる利用シーンを想像しつつも、体験することが難しい医療サービスだからこそ、前提の知識やヒアリング、ユーザーテストなどが重要となりますし、機能的な部分に関してはエンジニアと仕様について議論したり、ユースケースを踏まえてどのようなUIに落とし込むべきかを考えながらデザインに落とし込んでいきます。インタラクティブな表現などinVisionでも表現しきれない細かい動きや導線などは、実装時にエンジニアに伝わりやすいようフロントエンド部分のコーディングを自ら行うことでコードを通じてエンジニアとコミュニケーションが取りやすくもなるので、フロントエンドも把握しておくことは重要です。

まとめ

個人的には「伝えるデザイン」と「機能的なデザイン」で、明確に思考をわけて考えてデザインしてきたわけではなかったのですが、提供すべき価値の違いによって左脳と右脳それぞれ使い分けてデザインしているかもしれないということに気付かされました。これは以前デザイナーの小山がブログで書いたシステム1(自動的に直感で動く”早い思考”)とシステム2(手動で論理的に動く”遅い思考”)が自分の中で振り子のように行き来してるだろうなと感じたので、興味のある方は「思考とデザインスキル」も読んでもらうとわかりやすいです。

developer.medley.jp

最後に

ふだんビールばっかり呑んで適当な人とレッテルを貼られているマエダですが、今回は真面目なことを書いてみましたがいかがでしたでしょうか。このブログを書いてて正直疲れたので、システム2が働いてるに違いないと思います。こんな私と一緒に仕事がしたい、呑みたいというデザイナーやエンジニアさん。応募お待ちしております。

www.wantedly.com

www.wantedly.com