Medley Developer Blog

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

フロントエンドエンジニアがUI設計〜実装で考えていること

おはこんばんちは、開発本部エンジニアの大岡です。

先日、TechLunchという社内勉強会で「フロントエンジニアがUI設計〜実装で考えていること」という内容で発表しました。UI設計から実装の細かい話ではなくどういう気持ちで望んでるかという話で、基本的なことしか書いていませんが紹介させていただければと思います。

UI設計

UI設計をデザイナーがして、それをエンジニアが実装する場合とエンジニアが単独でUI設計から実装までする場合があります。今回はそれぞれのケースで、フロントエンドエンジニアがどういうことを考えてるかを紹介します。

とその前に、他人とUIについて話すときに気をつけてる言葉で分かりやすくまとまっているツイートがあったので紹介します。

  • 普通はそうする
  • 直感的にわかる
  • 使いやすい
  • わかりやすい

これらの言葉は誰にとってなのか?やそれまでの経験によって意味合いが変わってきてしまうので対象を明確にしないと相手と話が噛み合わなくなることもあるので気をつけています。今回何ヶ所か使っていますが実際UIについて話すときは使わないように心がけています

デザイナーから画面仕様をもらう場合

デザイナーが優秀であればあるほど、もらった画面仕様を元に早く手を動かしたくなります。ですがここはグッと堪えます。落ち着いて以下のようなことを考えてます。

  • なぜこの課題がうまれたのか
  • 解決したい課題の本質はなんなのか
  • 他の解決策はないのか
  • この機能を追加してしまうことにより他に影響がでてしまわないか
  • 追加ではなく他の機能を落とすことにより解決できないのか
  • そもそも必要なのか

など、この段階で理解できないことはチームで話したりして解決しておきます。次に画面仕様に目を向けまた考えます。

  • 似たようなコンポーネントがあったら統一できないか
  • より使いやすくできないのか
  • 操作感が他と明らかに違わないか
  • 操作に対して予想した動きになっているか
  • 表示されている情報に意味があるのか

など、画面仕様からは理解できないことや疑問点などはデザイナーとコミュニケーションをとり齟齬がでないようにします。

手を動かす前にある程度ユーザが解決したい課題を精度高く汲み取り落としこめるように努力してます。

自分でUI設計をする場合

「デザイナーから画面仕様をもらう場合」に書いたことをまずは考えています。

それらを踏まえ、すでに実装済みのUIで似たようなものがあれば似たように作ります。理由としては既にユーザが学習済みのUIのため新たに追加した機能だとしても比較的学習コストが低くなるのではないかと考えるからです。

似たようなUIがなく新たに作らなければならないときは以下を意識しています。

  • 表示する情報の精査
  • 表示する情報はリストなのか詳細表示なのか
  • 表示する情報に対しての操作はどんなものがあるのか
  • 操作に対してのレスポンス・納得感はどうすれば得られるのか
  • エラー表示をどうするのか
  • 表示する情報が多すぎて収まり切らない場合どうするのか
  • 表示する情報がない場合どうするのか
  • 画面サイズ毎に適切に表示できるか
  • 状態(クリックやホバーなど)を表現できてるか
  • リストの場合デフォルトの順番は適切なのか

などをざっくりノートなどに書き出し詳細を詰めていっています。行き詰まったら迷わずデザイナーに相談しにいきます笑

実装

細かい実装部分というよりはもっと大枠の基本的なことですが紹介します。

  • 何も考えずにコピペしない
    • 修正が大変になるので一箇所になるべくまとめる
  • 用途にあったコンポーネントを使う
    • 似てるからと使い回すとコンポーネント修正時に思わぬ変更が加わる可能性があるかも
  • コンポーネント間の関係が疎になるようにする
    • 密接な関係だと気を使い合わなくてはならず修正が大変
  • コンポーネントを作成する際に無理に汎用性をもたせない
    • 修正が困難になり逆に汎用性がなくなる場合が多い
  • Reduxに管理させるステートの粒度は適切か
  • なんでもかんでもReduxに状態を管理させてしまっていないか
  • 無駄な再レンダリングをしていないか
  • 無駄な通信をしていないか
  • 非同期通信のレスポンスが遅い場合にサーバー側の処理に問題がないか
  • 関数や変数は適切な命名で適切な場所に書かれているか
  • マジックナンバーを使ってしまっていないか
    • 使ってると修正大変
  • なるべく簡単に書けないか
  • エラー・例外時の動きは適切か

など細かいことを言い出したらキリがないですが、こんなこと意識してます。

よりよいものを届けるために

いろいろと書きましたがUI設計から実装完了まではなるべく早く終わらせようと意識しています。1サイクルを

  1. UI設計
  2. 実装
  3. 触る
  4. フィードバック

とした場合に、このサイクルをリリースまでに多く回すことによってより多くの気づきが得られるからです。基本的には一回作ってうまくいくことは希かと思っているからです。

ただ、フィードバックの段階で本当に色々な意見がでてきます。心が折れかけることやイライラすることもあるかもしれません。ですが、プロダクトとして必要なのか、今必要なのか、対象とする利用者としてなのか、ただの愚痴なのか等を見極め軸をぶらさないことが大切です。

フロントエンドのUIやパフォーマンス系は事業的に見ると優先度が低い場合が多い印象を受けます。優先度が上がるときは強い競合、数字的な上昇が見られなくなった時など危機感がでてきたときかなと。。。足りない機能を追加しないといけないし、そもそも人的リソースが足りないなどしょうがないことなのかなとも思っています。

初回リリース時に時間が足りなくても精度の高いものを作りたいという気持ちがあるため先ほどのサイクルを多く回し一人でも多くの人に触ってもらい気付ける回数を増やすことは大事なことだと思っています。

さいごに

あくまで私個人が考えてることなのでフロントエンジニア全てにあてはまるわけではありません。出来てないこと抜けてしまう時や本質的に理解していないことも多々あると思いますが、自分はこんなことを考えているという紹介でした。最後までお読みいただきありがとうございました。

 

▼メドレーで働くクリエイターたちのストーリーはこちら

www.medley.jp

改めてBigQueryのPartitioned tablesと戯れた話

こんにちは、開発本部の宍戸です。先日のメドレー社内勉強会「TechLunch」で、BigQueryのPartitioned tableについて発表しましたので、その話について書きたいと思います。

なぜ今Partitioned table?

ある案件でユーザーの操作ログを扱う必要があり、データ保管先にBigQueryを利用しようと考えていました。その際に、「以前はβ版だった分割テーブル、そういえば今使えるよね」という話になり色々調べてみた、というのが今回このテーマを選んだ背景です。

なぜ分割テーブルを使おうと思ったのか

ユーザーの行動/操作ログの確認についてはAPIサーバーのアクセスログで、ある程度その目的を果たすことができていました。

しかし、APIアクセスログですと今回対象にしたい”ユーザーの操作”以外にも多くの操作ログ(通知の取得ログなどをはじめとする各種データ参照など)を抱えてしまっているため、必要な情報を抽出するためには無駄が発生してしまう状態でした。無駄なスキャンで無駄なコストが発生するのは嫌ですよね。

ということで目的に即したデータに限定して保存/閲覧できるように、行動/操作ログは新しくPartitioned tableに保存することにしました。

また、新しいテーブルに保存する対象となる操作に関しては、これまで保存していた過去分のアクセスログのデータも新しいテーブルへ移行したいというニーズもあり、既存のデータを取得し加工をしたうえでデータを移行するというタスクも行いました。

分割テーブルの各種方法について

まずひとくちに「分割テーブル(Partitioned table)」と言っても、BigQueryではいくつかの実現方法があります。

  • 「取り込み時間で分割」されたテーブル
  • 「特定のカラムに基づいて分割」されたテーブル
  • 「時間ベースの命名方法を使用して分割」したテーブル

前述のとおり今回は過去データの移行なども同時に行いたい背景があったため「取り込み時間で分割」されたテーブルではなく、「特定のカラムに基づいて分割」されたテーブルを利用するようにしました。こちらのテーブルは分割するための列としてDATE型またはTIMESTAMP型を指定することで利用することができます。

こうして作られた分割テーブルは、パーティションと呼ばれるセグメントに内部的にさらに分割されており、参照するパーティションを限定することで、効率の良いアクセス(スキャン対象データ量の限定、高速化)が可能になります。

注意点として公式ドキュメントにもありますが、クエリの記述方法によっては期待したパーティションの絞り込みがされないことがあります。また分割テーブルへのクエリにはレガシーSQLを利用することができないため、標準SQLを利用する必要があります。

クエリキャッシュ

分割テーブルを使うときに気になるコストについてですが、クエリキャッシュの仕組みを利用することでコスト削減が見込めます。そこで今回利用する分割テーブルで、過去のパーティションに対するアクセスはクエリキャッシュが効くのかどうか確認してみました。

そもそも、クエリキャッシュの仕組み上「対象のテーブルがストリーミングバッファを添付されている状態ではクエリの結果はキャッシュに保存されない」という制約(例外)があります。

今回の私達の用途ですと断続的に書き込みが発生する状況になるため、テーブルがストリーミングバッファを持たなくなる状況というのは発生しづらいです。この状態ではフェッチしたいデータ(パーティション)がいかに過去のものであってもテーブルは一つであるため、前述の制約が残り続けてしまいます。

そのため残念ながらクエリキャッシュが有効になるケースは稀そうだなという結論に至りました。(ストリーミングバッファが付いているかどうかは、WebUIのテーブル情報の詳細タブから確認できます)

f:id:medley_inc:20190315130255p:plain

データ移行

前述の要件の中に「過去のアクセスログから一部データを新しいテーブルに移行したい」という話がありました。こちらの作業内容としては以下のようなものになります。

  • access_yyyymm」的なテーブルから、移行用のデータを取得
  • 必要なデータを付与
  • 移行先のテーブルにデータをinsert

とてもシンプルですね。データが少なければ適当なスクリプトで簡単に移行できそうです。

やってみた

まずは試しに google-cloud-ruby を使って、ストリーミングインサートを利用した移行プログラムを作って、実行してみたところ...

「You can only stream to date range within 7 days in the past and 3 days in the future relative to the current date.」

と、怒られてしまいました。

分割テーブルの制限としてストリーミングインサートは、過去7日までしか書き込むことができないようでした。・・・と!発表当時は公式ドキュメントにも書いてあったと思ったのですが、改めて公式ドキュメント(パーティショニング オプションの比較)見てみると、過去1年まで扱えるようになっている!?ようです。この辺りは定期的にアップデートされているようなので、実際に作業する前にきちんと公式情報を確認しておく必要がありそうです。

最終的に

前述のようなストリーミングに関する話もあり、また移行対象データの量もかなり多かった為、ストリーミングの方式は諦めて、GCSにインポート用のファイルを用意してそちらからインポートする形にし、無事移行することができました。

作業当初はデータ移行を行う手段としてEmbulkを利用することも検討していました。Embulkさまざまなストレージ、データベース、NoSQL、クラウドサービス間のデータ転送を支援してくれる並列バルクデータローダーです。しかし今回は簡易的な方法で移行できそう、との思惑から利用を見送っていました。

あとから気になったので、Embulkのプラグインであるembulk-output-bigqueryを調べてみると、やはりストリーミングインサートは実装しておらず、またGCS経由でのデータインポートができるなど、結果的には独自手法でやったことはまさにこのプラグインが提供してくれる機能そのものでした。こちらを最初から利用していればよかったかも...という気持ちで今はいっぱいです ( ꒪⌓꒪)

まとめ

今更ながらBigQueryのPartitioned table周りについて調べてみたこと、やってみたことを発表しました。なんとなく知ってるような気がする、という感じだったコスト周り、分割テーブル、クエリキャッシュなどの項目に対する理解を私自身少し深めることができたと思います。また、弊社では色々な場面でBigQueryを利用しているため、このネタが他チームでの今後の活用に何か役に立てば嬉しいなと思います。

今回のデータ移行を行った後あたりにClustered Table(beta)のことを知りましたが、こちらも対応することでさらにスキャン量の削減、高速化が期待できそうです。

また、TechLunchでの発表後、今回のような用途に対して、先日公開された Amazon QLDB あたりも使えるのでは?と同僚から教えてもらいました。監査機能などを目的としたログデータについては、QLDBはより適した用途のように思いますので、こちらも今後検証していきたいと思います。



JAWS DAYS 2019にメドレーがランチサポーターとして協賛しました

こんにちは。開発本部エンジニアの平木です。

去る2019/02/23(土)に開催されたJAWS-UG(AWS User Group – Japan)主催の全国規模での交流イベントであるJAWS DAYS 2019にメドレーが‌ランチサポーターとして協賛させていただきましたので、当日の様子などをお伝えしていきます。

f:id:medley_inc:20190228122657j:plain

会場の様子

自分はこちらのイベントに初参加だったのですが、来場者数がかなり多い!ということに圧倒されました。会場のTOC五反田メッセはイベント会場としては大分広い方でしたが、セッションの合間などでは移動するのも中々大変な位でした。日本全国からAWSユーザが集まるイベントの規模の大きさが伺えました。

f:id:medley_inc:20190228122724j:plain

公式発表で1,900人の来場だったということで、歴史があるユーザグループの凄さを実感しました。このため、大体のセッションも満席か立ち見が出ているのが印象的でした。

f:id:medley_inc:20190228122752j:plain

セッションもバラエティに富んだラインナップで見たいものが若干カブってしまっていた位で、大変有意義なものでした。

またこちらは、アマゾンウェブサービスジャパン株式会社さんが後援しているイベントということで、JAWS-UG公式Twitterに負けず劣らず、アマゾンウェブサービス公式Twitterでイベントの様子をTweetしていたのは、さすがだなと思わされました。

メドレーのスポンサー活動

さて、そんな活気に包まれていたJAWS DAYS 2019での弊社のスポンサーとしての取り組みについてですが、今回は‌ランチサポーターとして協賛させていただきました

企業サポーターブース

まずは企業サポーターブースで弊社のエンジニア・デザイナー採用パンフレットと、ノベルティとしてロゴ入りの絆創膏を設置させてもらいました!この絆創膏ですが、十分な数かと思っていたのですが、おかげさまで朝にセッティングしたところお昼までには無くなってしまいました。もっと持っていけば良かったと反省しています。

f:id:medley_inc:20190228122821j:plain

パンフレットを置かせていただいていたのは、会場内で2番目くらいに大きい場所でしたがこちらも各サポーター企業さんのブースや同人誌即売コーナーなどで人が溢れんばかりでした。

f:id:medley_inc:20190228122855j:plain

f:id:medley_inc:20190228122904j:plain

ランチセッション

そして、ランチサポーターとしてランチセッションで弊社の田中がAWSマネージドサービスをフル活用して医療系システムを構築・運用するためのノウハウと題したセッションでお話させていただきました。

f:id:medley_inc:20190228123004j:plain

メドレーで運営しているサービスであるCLINICSカルテをAWSを使って、国で定められたガイドラインにきちんと準拠しながら構築・運用するために今まで行なったことを中心に、AWSの各サービスをどのように使っているか?というお話をさせていただきました。

f:id:medley_inc:20190228123035j:plain

詳細としては

  • 医療情報システムを構成する際に準拠しなければならない3省3ガイドラインの抜粋
  • CLINICSカルテでガイドラインがシステム構成に影響を与えた部分
    • 日本国内法の適用が及ぶ場所へのシステムの設置
    • ユーザである医療機関の使用するアプリ側でTLSクライアント認証を実施
    • ユーザアカウント毎の権限管理と各種操作ログの管理
  • AWS東京リージョンへの移行や、システム構成をAWSの各サービス(ECSfargateNLBなど)を使いながらTLSクライアントに対応していった話 セキュリティを強固にするためにAWSサービス群をどのように使用しているかの話

といった内容の発表でした。 来場していただいた方々の関心も高いようで、写真を撮りながら聞いていただいて大変ありがたかったです。セッションが終了したあとも参加していただいた方々に個別に話を聞きに来ていただいたりと、情報交換という意味でも大変有意義なセッションとなりました。

f:id:medley_inc:20190228123114j:plain
セッションが終わって一安心した田中

最後に

イベントを運営していただいたスタッフの方々、そして参加者の皆さまありがとうございました!

メドレーではこの他にもエンジニア・デザイナー向けのイベントのスポンサーを積極的にしております。スポンサーを募集しているイベント主催者の方などいらっしゃいましたら、お気軽にお問い合わせいただければと思います。

デザイナーがブラックボックスを作らないためにできること

 

f:id:medley_inc:20190221150235p:plain

 こんにちは。昨年末にクリエイターズストーリーが公開され顔面が白日のもとにさらされ『イケメンじゃなくね?イケメンつーか犯罪者顔じゃん!』と影口たたかれてないか不安な日々をおくる開発本部のガラスのハートことイケメン担当デザイナーの小山です。
 
さて今回は先月末におこなった社内の勉強会の内容をご紹介させていただきます。
 

 
デザインのプロセスは、時代とともに明らかになりつつあり、個人主導より参加型のデザインワークが主流になりつつあります。例えばサービスデザインはステークホルダーと課題を協議しながら解決策を見出していきます。視点は異なりますが、デザインスプリントも各参加者の視点や思考を総動員して短期でプロダクト(解決策)を作り出す手法です。
 
関係者が参加したデザインプロセスにより出来たデザインを製品レベルへ品質を高めるため、デザイナーの手によってブラッシュアップされていきます。この段階から本格的にデザイナーの感覚由来の思考が組み込まれ、プロダクトが洗練されていきます。
 
ですが、思考が組み込まれると、周囲とは別世界の領域として扱われている感覚になることがあります。どういう思考プロセスを経て、デザインされたのか周囲は触れることができません。それゆえに、周囲はデザインにおいての思考プロセスはデザイナー頼みになりやすく、作業依頼の最後の決まり文句として『いい感じに!』という言葉を掛けがちです
 
こうした周囲が踏み込みづらい距離感が生まれてしまうのは仕方のないことだと思っています。
原因は、デザイナーの感覚由来の思考プロセスが共有されない状態=ブラックボックス化にあります。またデザイナーが自発的にブラックボックスをオープンにして、周囲の目に留まる環境を用意できていない点も原因としてあります。
目に留まる環境ではないため、周囲はアウトプットだけしか注目できず『いい感じに!』以外の言葉を掛けようがありません。
 
デザイナーは、色や形を論理的な思考と感情的な思考の掛け合わせでアウトプットします。目では見えにくいプロセスに突入するので、周囲からは抽象的で曖昧な領域と思われがちです。
今回は、これまでの経験の中で最もその『曖昧な領域と思われがち』だと感じている余白について、デザイナーの視点でご紹介*し、ブラックボックスの中身を少しお見せしたいと思います。
 
*個人的見解なので世のデザイナー全員に当てはまる訳ではないことをご理解いただければ幸いです。
 

 
余白について
 
みなさん、余白の言葉の意味はご存知ですか? 辞書では  “文字などに書いた紙面の何も記されないままで残っている部分”と記されています。字面としては言い得ているのですが、デザイナー視点ではこれがてではありません

f:id:keisukekoyama:20190221220602p:plain


もちろん”何も記されていない”が余白の前提なのですが、なぜそれが必要か?が重要です。

まずは余白の機能から説明します。余白には最も伝えたいメッセージを視覚的に浮き彫らせ、理解を促す効果があります。多種多様で氾濫した情報から希望したものを抜き出すプロセスを、見ている人に強いるのではなく、デザインが肩代わりします。
 
昨今の日本のデザインは、見ている人の情報に対しての許容量が増え、膨大な量を詰め込んでも理解してもらえる場面が多々あります。
ただスタミナが必要です。スポーツをするのと同じように情報に触れるだけで人はスタミナを消費します。そして、人間であればスタミナには限りがあります。
 
デザインは、その限りあるスタミナを情報の探索に使うのではなく、本来の目的に沿った行動に運用できるような仕組みに整備します。その手段の1つとして余白があります。
 
f:id:keisukekoyama:20190221220641p:plain
 
余白は目的ではなく情報を届けるための1つ手段です。
届けたい情報がどういう文脈であるべきなのか、そことセットで考えなくては余白や目的が破綻します。このプロセスが抜けおちた状態でプロジェクトが成功してしまうとブラックボックス化が進みます。
そうすると周囲の参加が難しい状況になり、『なんだかわからないけど良いだろう…』という状況に陥ります。いつまで経ってもデザインの思考プロセスは理解されないままの状態が続くでしょう。そのために余白を意味あるものとして文脈が必要となります。
 

f:id:keisukekoyama:20190221220659p:plainApple Store 表参道店 店内 Photo by wongwt

 
f:id:keisukekoyama:20190221220716p:plain
ヨドバシカメラの店内   Photo by chesterbr
 
文脈は明快であるべきです。その例としてAppleStoreとヨドバシカメラがあります。AppleStoreは電化製品を扱う店舗の部類としては、延べ床面積に対しての商品数が極端に少ないお店。電化製品としてではなく、利用者の人生に大きな影響を与える重要なプロダクトになり得るものを提供しているプライドが伺えます。高級ブランドに近い売りかたですね。
 
ヨドバシカメラは様々なメーカーの商品を一度にそして大量に伝達するために、より多くの商品を陳列します。世の中には商品が多くありその全てをありのままに伝達しスタッフのアドバイスを受けながら最適解を導き出す戦略です。
この2つの店舗の場合、それぞれ余白はどうあるべきなのかその機能や意味が見出せます。
 
AppleStoreは通路を広くとり、商品を最も強調させるために机以外のノイズを限りなく削ぎ落とし、空間デザインにおいても余白を有効活用しています。物理的な余白を意図的に作ることで、商品に人の視線や意識が集まりやすくなり、より魅力が伝わる設計がなされています。
 
一方、ヨドバシカメラは様々なメーカーの商品を多く陳列することで横断して比較でき、自分にあった商品を見つけられる購入体験を実現します。そのために狭いスペースの中に如何に商品を詰め込められるかを念頭に設計しているように見えます。そこに余白はどこにもなく情報の洪水が押し寄せているように感じられます。
 
ですが、余白はしっかりあります。それは人の頭の中です。
ヨドバシカメラは種別ごとに商品をしっかりまとめ、近しい情報であれば同じ見栄えのポップで整理し、遠くからでもどこにあるか商品がわかりやすいように陳列の技術を駆使し、来店する人のスタミナの消費量を軽減しています。
 
情報の整理をすることで、探す労力を利用者に強いることなく、無意識のうちに理解できるスイッチが入るように設計しています。ヨドバシカメラの場合は物理的な余白をとるのではなく、意識下に余白を作り出している高度な設計をしています。
 
文脈を設計し伝えるべき情報を効率良く届けるために、余白は様々な手段があります。2つの事例をあげましたが、ここには物理的な余白、そして意識的な余白があります。
 
主にUIデザインする個人的な意見ですが、余白の真の意味は、利用する側の頭の中の情報を整理し、スタミナ消費を軽減し意思決定のアクションを促せる『余地』を作ることにあると思っています。
 

 
と、自分なりの余白の考えをお話しました。普段の業務の中でデザイナーの立場として、こうした話をする機会はなかなかありませんしかし考え話すことでデザインに周囲が参加できる素地を作らなければ、いつまで経っても、「いい感じにつくって」の状態から逃れられません。
 
デザイナーの役目として作ることは大前提。しかし、単に手を動かして作るだけでは意図を理解されにくいため、対話を通して思考プロセスを共有しないとその後の改善はその場限りになります。これはデザインに限りません。
事業編成による人事異動や事業規模の拡大など大きな変化のなかでも作り続けれるようにするために、余すところなく言語化し共有することが大事だと思います
 
メドレーには凡事徹底9箇条という仕事の質を高める指標があり、全社員がそれを意識しています。その指標の1つに『ドキュメントドリブン』というものがあります。全てを記録し共有できる状態にし無駄な取り組みをしないというものです。またドキュメントドリブンやドキュメントそのものの意味は、次の人にバトンを渡すことでもあると思っています。
 
言語化されたデザインの思考プロセスは、デザイナー以外にバトンとして次に繋ぐことで、本当にプロダクトが良いものになるのか、検証と改善を継続できるようにする道しるべにもなります。
 
幸運にもブラックボックスを開けて周囲を巻き込むはたくさんあります。冒頭の手法以外にもライブデザイニングという手法があります。これはデザイナーのデザイン業務や思考プロセスを公開しながら進めていくものです。詳しくはこちら
 
弊社のデザイナーはプロダクト毎に、一人専任でデザインを任されています。それだけに重要な仕事を任される面白さはあるものの、デザイナーの感覚由来の思考プロセスで解決策が生まれやすい状況とも言えます。
 
デザインはデザイナーだけのものではないので、チームならチームに組織なら組織に思考のプロセスを明らかにすることで、新しい発見や解決策が生み出せるかもしれません。その機会をデザイナーから作り出し、より良い事業推進に貢献できたらと思います。
 
最後まで読んでいただきありがとうございます。
 
メドレーではデザインで医療課題を解決するプロダクトを一緒に創るデザイナー、エンジニアやディレクターを募集しています。ご希望の方はこちらまでー。
 

2019年、今年も開発本部キックオフ合宿に行ってきました!@河口湖

こんにちは、開発本部の日下です。
インターンを経て新卒としてメドレーに入り、エンジニアとしては2年目となりました。
現在は医療介護の求人サイト「ジョブメドレー」の開発をしております。
 
先日、恒例となった年始の開発本部キックオフ合宿を河口湖で行ってきましたので、詳細をレポートします。 

キックオフを年始に行う意義

メドレーの開発本部では毎年年始に開発本部全体でキックオフ合宿を行っています。
合宿を年始に実施する意義昨年もまとめましたが、再掲すると次の二つになります。

親睦を深める

一つ目はチームビルディングにあります。
 
合宿ではアクティビティやバーベキュー、キックオフプレゼンなど、みんなで一つの場所で同じ時間を共有するイベントを行っています。
同じ時間を共有することで、より一体感をもち、連携の取りやすい関係性を醸成することを目的としています。
 
実際、より長い時間を共有することで、普段知ることのできない仲間の一面を見ることができるなど、よりお互いの理解を深める事ができる時間が過ごせます。

f:id:medley_inc:20190208133854j:plain

今年の方向性を共有する

二つ目は今年一年の開発本部としての方向性の共有にあります。
 
普段開発していると、全体のことを考える時間はなかなか取りづらいかと思います。
そこでメドレーでは普段の業務から一旦離れた場所で、開発部全体としてどういった動き方をしていくのかという認識を作る機会を作っています
 
これが合宿を年始に行う理由にもなっています。

合宿先・アクティビティの紹介

合宿先の紹介

合宿先は昨年と同じ河口湖カントリーコテージbanさんにお世話になることにしました。
昨年よりメンバーが増えたため、昨年より少し大きなコテージを借りての実施となりました。
 
コテージも夜景も美しく、とても満足のいく環境でした。

f:id:medley_inc:20190208133927j:plain

ワカサギ釣り

合宿ではリフレッシュを兼ねたアクティビティを行っており、今年はワカサギ釣りでした
 
ワカサギ釣りと言われると氷に穴を開けて糸を垂らすイメージが強く、極寒の中で行うのではと思われる方もいるかもしれません。
今回お世話になっマリンハウスmomoさんのプランでは、提供されたドーム型の船の中で釣ることができたため非常に快適でした。
(先日の週間メドレーで着ていたライフジャケットは、このドーム型の船に乗るためのアイテムでした。)

f:id:medley_inc:20190208134010j:plain

 
ワカサギは群れで移動する魚らしく、ちょうど群れが来たときはまさにフィーバータイム。釣り糸を垂れるとすぐにかかるので、とても楽しめました。

f:id:medley_inc:20190208134024j:plain

5匹一気に釣り上げ喜ぶCTO

釣りが得意なメンバーはバケツ満杯に釣れるなど、釣果は上々。当初釣れた数を数える予定でしたが、あまりにも多すぎたため途中で数えるのをやめてしましました。

f:id:medley_inc:20190208134051j:plain

袋いっぱいのワカサギ。多すぎて2袋に分けたうちの一つです。

釣れた魚は合宿先に持ち帰り、唐揚げにしたり串焼きにしたと、食事でも楽しめるとても良いアクティビティでした。

f:id:medley_inc:20190208134120j:plain

一気に焼くために串に刺されるワカサギ
くさみもなく、とても美味しかったです。

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

アクティビティのあとはコテージに移り、お風呂やバーベキューの準備をしながらお酒を少し入れたタイミングで、2019年キックオフプレゼンをCTO・平山が行いました。

f:id:medley_inc:20190208134432j:plain

 
まずは昨年の振り返りから。昨年も各プロダクト大きな変化がありました。
 
JobMedleyはユーザ数が順調に伸び、テレビでCMをするほどの規模に成長CLINICSカルテのリリース、介護のほんねのリニューアル、MEDLEYは医師向け機能の強化をするなど、プロダクトを大きく成長させました。
 
また会社としては、医療ヘルスケア分野における技術のオープン化、および情報活用を推進すること目的としたMEDLEY DRIVEという大型プロジェクトを開始しました。
他にもセキュリティ強化を目的としてISMSとISMSクラウドを取得するなど、攻める一方で守りの面も強化された一年でした。
 
次に開発本部の2019年について。
 
目指すべき未来を示しつつ、なぜ?どうやって?といった基本的な考え方を共有することで、メンバーの中に納得感ができたキックオフになりました。

f:id:medley_inc:20190208134505j:plain

 
個人的には昨年から関わるプロダクトが増えたため、これまで感じてきたプロダクトの成長を振り返ることができました。
また今年はどういったことができるか考える良い時間になりました。
 
平山のプロダクト・事業・会社に対する熱い思いはメドレー平山の中央突破にも詳細に書かれていますので、ぜひご覧ください。

バーベキュー

恒例のキックオフ後のバーベキューもみんなでワイワイしながらの実施となりました。
 
今年は人数が昨年同月比1.5倍ほどになったのもあり、昨年より賑やかな会となりました。

f:id:medley_inc:20190208134558j:plain

f:id:medley_inc:20190208134604j:plain

今年は自前の燻製器を運び込んだ猛者も

f:id:medley_inc:20190208134610j:plain

恒例となっているバーベキュー

食べて飲んで寛いで、プロダクトや組織への思いなどお酒を交えつつ談笑し、夜遅くまで楽しい時間を過ごしました。

まとめと感想

メドレー開発本部合宿の様子はいかがだっだでしょうか?少しでもその様子が伝わっていれば幸いです。
 
今年の合宿も、メンバー同士が物理的に近い状態で同じ体験をする時間を通じ、相互理解を深めたり共通認識を持つことのできる良い機会となりました。
 
昨年よりいろいろな人が増えたおかげで、バラエティの富んだ時間を過ごすことができたのは良い発見でした。
また人が増えたものの雰囲気としては昨年と変わらず進められたことは、組織としてのメドレーらしさのようなものが醸成されている証ではないかと感じています
 
個人的にもプロダクト的にも昨年は一昨年に比べて変化の激しく楽しい年だったように思います。
今年はより変化のある一年になりそうということもわかり、今から期待に胸を膨らませています。
 
改めてこういった時間を開発本部としてとるタイミングがあるのは良いことだと、再度認識することのできた時間となりました。
 

最後に

最後に、今回の合宿の企画運営を行って頂いた新居さん、忙しい中本当にありがとうございました!

f:id:medley_inc:20190208134755j:plain

また来年も合宿しましょう!
メドレーでは、このようなチームで新しい医療体験を提供するプロダクトを一緒に創るディレクターやエンジニア、デザイナーを募集しています。
 
ご興味ある方は、お気軽に話を聞きにお越しください!!
メドレーで働くクリエイターたちのストーリーはこちら
 

全社で本気になってリーンにISMSの仕組みをつくった話

 こんにちは、コーポレートエンジニアの兼松です。

今回は、メドレーがリーンな仕組みでISMS認証を取得したので、その過程について、弊社ならではの工夫したポイントを交えてご紹介します。

はじめに

以下のニュースリリースのとおり、情報セキュリティ管理の仕組みであるISMSを構築し、オンライン診療システム「CLINICS」、クラウド電子カルテ「CLINICSカルテ」の事業において「ISMS認証」と「ISMSクラウドセキュリティ認証」という2つの第三者認証を同時取得しました。

www.medley.jp

特に「ISMSクラウドセキュリティ認証」は、国内でも取得している企業はまだ少なく、現時点で私の知る限り、オンライン診療システムとしては弊社のCLINICS(SaaS)が日本初だと思います。

 

ISMSとは

ISMSとは、Information Security Management Systemの略で、組織における情報セキュリティを管理するための枠組みのことです。具体的には、国際規格であるISO/IEC 27001に定められた様々な要求事項を満たし、組織内に情報セキュリティ水準向上のための体制を整備してプロセスを実行し続ける仕組みのことです。

 

ISMS認証」と「ISMSクラウドセキュリティ認証」とは

ISMS認証」とは、ISMSが適切に構築されていることを第三者機関が認証する仕組みです。また、「ISMSクラウドセキュリティ認証」は、ISMS認証の取得を前提としてISO/IEC27017に定められたクラウドサービス固有の情報セキュリティ管理要件を満たしている組織を第三者機関が認証する仕組みです。

f:id:medley_inc:20190201170325p:plain(「ISMSクラウドセキュリティ認証」は「ISMS認証」の取得を前提とした、クラウドセキュリティ分野に特化した追加認証という位置付け)


クラウドサービスを利用する組織(CSC)とクラウドサービスを提供する組織(CSP)の両方の組織を対象としており、メドレーはSaaS提供企業としてCSCとCSPの両方に該当します。

f:id:medley_inc:20190201170346p:plain

(https://www.bsigroup.com/ja-JP/ISO27017/ より引用)

 

なぜISMS認証を取得することにしたのか

メドレーでは、これまでも個人情報保護認証の「TRUSTe」マークの取得や、CLINICS事業においては医療情報を取り扱う際の安全管理に関するガイドラインである「3省3ガイドライン」への対応など、情報セキュリティ体制の強化に努めてきました。

しかし、機密性の高い情報を取り扱うサービスをクラウドで提供する企業として、顧客からのより高度なセキュリティ、コンプライアンス要求にお応えできる体制を作っていく、という経営陣の強い意思決定がキッカケとなり、上記の取り組みに加えてISMS認証を活用しての組織的な仕組みづくりをすることに決まりました。

そしてさらにCLINICS事業では、医療情報という機密性の非常に高い情報を取り扱うサービスをクラウドで提供するため、導入医療機関様や患者の皆様により安心して利用してもらえるよう、今回取得した2つの第三者認証を取得することに決定しました。


脱「ISMSあるある」

ISMSについてご存知の方は、ISMS認証取得について少々ネガティブなイメージを持たれている方も少なくないかもしれません。

例えば、「分厚い規程類がたくさん出来上がる」、「ガチガチのルール作りを強いられる」、「やたらと手間のかかる台帳を使わないといけない」といったような、「はぁ、昔はラクで良かった…。」というイメージです。

私自身も、過去にISMS活動の一環として、勤務先が決めた面倒なルール遵守をたくさん強いられてきた記憶がありましたし、後述しますが今回一緒に取り組んだメンバーの多くも、同じような経験をしてきていました。

そこで、堅牢なセキュリティにしつつも、このような面倒な作業をできるだけせずに、自分自身が働きたい環境となるよう、脱「ISMSあるある」のために意識したポイントや工夫の一部を3点ほどご紹介したいと思います。


ポイント1:ゼロベースで考える

今回のISMS取得プロジェクトにおいて初志貫徹したコンセプトがあります。それは、「ムダを削ぎ落としたリーンな仕組みを作る」ということです。

多くの組織は、認証取得支援コンサル会社などから入手した雛型をバコッとはめて、結果として大量の社内文書ができあがったりしてしまいがちですが、今回は本来要求されているISO規格の要求事項を本質的に実現するにはどうすればよいかという事に注力しました。

例えば、プロジェクトミーティングで、情報セキュリティ委員会(ISMS取得企業では設置するのが一般的)の設置について、私が「そもそも、これって必要ありますか?」と発言した際には、他社でISMS取得経験があるメンバーに唖然とされました。あとで「あの時は、この調子で進んで本当に認証取得できるのか不安でしたよ(笑)」と言われたほどです。

このように、当初からこのポイントをいちばん大切にしており、形式だけの仕組みができる位なら、むしろやらない方が良いというくらいに考えて取り組んでいました。


ポイント2:各部門の責任者と共創する

ムダがなくサスティナブルな仕組みづくりのためには、各部門の視点からしっかりと考えていく必要があります。そこで、責任者クラスでの組織横断のISMS取得プロジェクトを発足させました。

例えば、管理部門サイドの視点だけで仕組みを作ってしまうと、どうしても事業の実態に沿わないムダの多い仕組みとなりがちです。また、エンジニアサイドの視点だけで作ってしまうと、ムダの少ないオペレーションとなる一方で既存規程との不整合などがおこってしまうことも考えられます。

そこで、メドレーでは、コーポレートIT責任者が全体統括を担当しつつも、開発業務とプロダクトに精通する開発部長と、事業プロセスに精通する事業責任者およびマネージャを中心メンバーとしてプロジェクトを作りました。また、他社での取得経験者や社内弁護士ともコラボレーションして規程群を作成しました。

この体制により、最も難しいタスクの一つであるリスク対策の決定や、各部門での実オペレーションへの組込みにおいて、実用的な管理策を「即断・即決・即実行」できました。

この取り組みの成果として例えば、ISMS管理策の事例として重複管理や更新漏れなどがよく発生しがちな「管理台帳」を、極力作らずに運用できるようになりました。また、情報の重要度を識別するためのISMS要件である「情報資産に対するラベリング」も、リスク発生のケースを具体的に想定することで特定のケースのみラベルを付けることとしました。

各部門の責任者と共にこのような細かな工夫の積み重ねることによって、全従業員にとって手間の少ないシンプルな設計にすることができました。

f:id:medley_inc:20190201170507j:plain

(開発部長、事業責任者、他社におけるISMS認証取得経験者と共に記念撮影。左から2人目が筆者。)


ポイント3:情報を集約する

最後に特徴的なポイントとして、セキュアなクラウド環境に情報を集約したことです。元々メドレーの社内にはサーバを置いていません。もちろん管理するデータセンターなどもなく、全員クラウドベースで業務しています。

そして、そのクラウド上の厳選したセキュアなツールに、機密度や用途に応じて情報を集約して保管することで、重複や探す手間を極力少なくしています。例えば、規程群・業務フロー/マニュアル・営業資料・企画書などのストックとフロー情報は基本的に全てConfluence(社内Wiki)に構造化して保管されています。さらにオープンを原則としているため社内のコラボレーションもとてもスムーズになっています。

このように、どこに何があるかが誰にとっても明確になっているので、リスクも把握しやすく対策も立てやすくなります。結果としてセキュリティレベルも向上します。

また、認証審査の際には、審査員から求められた情報を瞬時に提示することができました。結果、あまりにも審査の進捗が速く進んだため、審査員の方々にとても驚かれました。

f:id:medley_inc:20190201170529p:plain

(情報を集約している弊社のConfluenceの一例)


審査機関の反応

認証審査の第三者機関からは、以下のような点でメドレーの取り組みに対して非常に高い評価を受けることができました。

・オープンな社内コミュニケーション環境による情報共有や意思疎通

・開発部門と事業部門との協業関係

・役割責任の明確化と専門家(医師、弁護士)のアサイ

・組織における機微情報であるカスタマーデータに対する高いセキュリティ管理運用

 など

f:id:medley_inc:20190201170557p:plain
(取得した「ISMSクラウドセキュリティ認証」マーク)

f:id:medley_inc:20190201170613p:plain

(取得した「ISMS認証」マーク)


さいごに

今回の活動を通して改めて感じたことがあります。それは、こういった活動をやり遂げるために最も大切なのは、社長やCTOを始めとする「経営陣の情報セキュリティに対する意識の高さとコミット」だということです。

今回、メドレーでは経営陣が社内メッセージを発信し続けたからこそ、部門横断でコラボレーションし、このような工夫を生むことができたのだと思います。

これからも弊社では、ISMSをさらに磨きあげ、事業運営の効率化にまで寄与するISMSとして運用することで、良質なサービスの提供を通じた"納得できる医療"の実現を目指していきたいと思います。

最後まで拙文を読んでいただき、ありがとうございました。


メドレーでは、提供サービスの拡大を受けて、その成長を支えるクリエイター(エンジニア・デザイナー)を募集しています。

また、組織も急成長しているため、組織の抱える課題や社内IT環境について、様々な効率化や改革を進めるコーポレートエンジニアを募集しています。

 

クリエイター(エンジニア・デザイナー)

www.medley.jp


コーポレートエンジニア

www.wantedly.com

ISMSの情報交換とかでも結構です。

少しでも興味を持っていただいた方、ぜひお気軽にご連絡ください!

Classi / メドレー合同でAWS勉強会を開催しました!

みなさん、こんにちは。開発本部エンジニアの新居です。
 
先日12/7(金)、AWSのre:Inventの余韻冷めやらぬ中、メドレーと教育現場支援のICTプラットフォームを展開しているClassiさんとの合同でAWS勉強会を開催しました。 
サブタイトルに「AWSを最大限活用して教育/医療業界の課題をスマートに解決していく」とある通り、教育/医療業界ならではの課題を両社がどのようにAWSを使って解決しているのかといったことを中心に、各社3名ずつ発表を行いました。
 
当日はSNS禁止で外部公開できないディープな話などもありましたが、この記事では簡単に当日の発表内容を紹介したいと思います。

f:id:medley_inc:20181213125501j:plain場所はサポーターズさんのレンタルスペースをお借りしました 

発表内容の紹介

1. ガイドライン対応のためのAWSセキュリティ系マネージドサービスの活用(メドレー 中畑)

一人目はメドレー中畑から、「CLINICSカルテ」と「3省3ガイドライン」(開発当初は3省4ガイドラインでしたが、2018年7月から3省3ガイドラインに変更されました。以下3省3ガイドライン、「CLINICSカルテで利用しているAWSのセキュリティ系マネージドサービス」について発表しました。 

発表内容の要約

先日のre:Inventで発表されたCloudWatch Logs Insightsを早速導入していたりと、新しい技術に対して高いアンテナを持ち、日々改善を続けています。
 
また、プロダクトの特性を踏まえて様々なマネージドサービスを活用することで、自前で仕組みを用意することなくセキュアにシステムを構築でき、プロダクト開発に集中できる環境作りを心掛けていることが伝わる発表でした。

2. システムをEC2からFargateへ安全にリプレイス(Classi 高田さん)

f:id:medley_inc:20181213125515j:plainClassi 高田さんの発表

二人目はClassi高田さんで、現在EC2上で動いている既存システムをECSのFargateに安全に移行する方法についての発表でした。

発表内容の要約

  • ECSの起動タイプには「EC2」と「Fargate」の2種類があり、マイクロサービスアーキテクチャでアプリケーションの種類が多いケースなどではEC2インスタンスの管理が不要なFargateが便利
  • Fargateへの移行の際は「既存の環境のシステムと相互に切り替えが可能なこと」と「切り替えが容易であること」などを考慮
  • 新環境と既存環境の振り分けにはOpenRestyを採用
Fargateへのリプレイス時などには参考になる事例ではないでしょうか!

3. クライアント認証対応のためのAWS構成の変遷(メドレー 田中)

f:id:medley_inc:20181213125521j:plainメドレー 田中の発表

 【発表資料は非公開】
 
三人目はメドレー田中で、一人目の中畑に引き続き、3省3ガイドラインへの対応について発表しました。
 
3省3ガイドラインの中でもシステム構成に特に影響が大きい内容として
  • サービス提供に用いるシステム、アプリケーションを日本国内法の適用が及ぶ場所に設置すること
  • クライアント証明書を利用したTLSクライアント認証を実施すること
があり、これらをAWSを利用してどのように対応したかという内容でした。
 
発表資料は非公開なので詳細には触れませんが、この辺の話についてはこちらの記事にもありますので、興味がある方は御覧いただければと思います。
 

4. ClassiでのAmazon Elasticsearh Serviceの活用(Classi 中村さん)

f:id:medley_inc:20181213125527j:plainClassi 中村さんの発表

https://speakerdeck.com/nakaearth/classidefalseelasticsearchfalseli-yong-nituite

四人目はClassi中村さんで、ClassiでElasticsearchをどのように利用しているかについての発表でした。 

発表内容の要約

  • Classiの「コンテンツボックス」と「校内グループ」の機能でAmazon Elasticsearch Serviceを利用
  • 「コンテンツボックス」では、レスポンスが10秒以上掛かっていたものが1~2秒まで短縮できたが、Elasticsearchのバージョンアップに追随するためにどのように対応したかの紹介
  • 「校内グループ」では、当初学校毎にindexを作成していたが、サービスの成長に伴い学校数が多くなりindexの数は数千以上に。ここから安定稼働にためにどのような対応したかの紹介
Elasticsearchは弊社でも利用しており、自分が担当している別のサービスでは1 or 2系から5系以上へのバージョンアップ(ちなみに3系4系はありません)も過去に経験しており、この辺の泥臭さは個人的には共感値が高かったです!

5. クラウドと院内システムをつなぐためのAWS IoTの活用(メドレー 有馬)​​

f:id:medley_inc:20181213125536j:plainメドレー 有馬の発表

【発表資料は非公開】
 
五人目はメドレー有馬で、クラウドと院内システムをつなぐためのAWS IoTの活用について発表しました。
 
CLINICSカルテを始めとした電子カルテでは、医療機関内の院内機器などの外部機器やサービスと連携する必要があります。
 
こうした外部機器やサービスと、CLINICSカルテをどのように連携させていくのか?また可用性を担保しつつ、AWSをどう活用して実現していくのかという内容でした。
 
こちらはSNS禁止で外部公開できないディープな話でしたので、また別の機会でお話できるときがあればという感じですね。 

6. ソシャゲ業界出身者が驚いた、学校教育支援システムの裏側(Classi 本間さん)

f:id:medley_inc:20181213125547j:plainClassi 本間さんの発表

最後六人目はClassi本間さん。Classiさんもメドレーも、前職でソーシャルゲーム業界だったメンバーが多数在籍しており、ソーシャルゲームの開発との違いなども絡めてClassiでのAWS活用事例の発表をいただきました。

発表内容の要約

  • 教育業界特有のガイドラインについて
  • 本番環境への接続制限
  • ECS化とCloudWatch Logsの利用
  • データベースの監査ログ取得
  • CloudWatchLogsの費用感
  • ManagementConsole操作権限
最後のまとめのところで
  • 学校向けのサービス提供は、セキュリティへの理解が重要
  • セキュリティを保ちつつ、運用負荷を軽減する機能がAWSにはたくさんある
  • とはいえ、もっともっとAWSを活用できる筈。なので…
とありましたが、この辺は医療業界ともリンクする部分だよなあと改めて実感することができました。本番環境への接続制限など結構シビアにされているところも垣間見え、興味深いお話を聞くことができました。
 

懇親会

発表終了後は、お酒とフードを交えてざっくばらんに交流しました。

f:id:medley_inc:20181213125552j:plain懇親会の様子

f:id:medley_inc:20181213125602j:plain本間さんのre:Invent参加レポート

本間さんからはre:Inventの参加レポートもあり、現地で体験した人の生のレポートが聞け、その興奮を少し感じることができたのは良かったです!

まとめ

教育業界と医療業界はもちろん別業界ではありますが、それぞれの業界で特有のセキュリティ要件があり、それらをAWSでどのように解決していくかなど、リンクする部分も多々あることを実感することができました。
 
そして両社共、AWSに詳しいメンバーが多数在籍しており、AWSをフル活用して効率良く柔軟性を持たせたシステムを構築していることが垣間見えた会となりました。
 
教育/医療業界というとWeb系のエンジニアにとってはまだまだ未知でよくわからないイメージなのかなあと思います。実際この業界でエンジニアとして働いていると、レガシーなシステムや業界特有の慣習がサービス開発の障壁となることもあります。
 
しかしそういった障壁や課題を、新しい技術を適切に用いてうまく解決していくことがやりがいのひとつですし、そのような課題解決のひとつひとつがエンジニアとしての成長の糧にもなるのではないでしょうか。
 
両社の歩み教育業界と医療業界のそれぞれの発展になればとても素晴らしいことですし、その担い手となる仲間が一人でも多く増えることを切に願っています。

f:id:medley_inc:20181213125557j:plain

最後に両社のメンバーで記念撮影 
 
「新しい医療体験を創造する」
メドレーで働くクリエイターたちのストーリーを公開中。ぜひご覧ください。