Medley Developer Blog

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

2020年、プロダクト開発合宿に行ってきました!@伊東

こんにちは、インキュベーション本部の加藤です。 2019年に新卒でメドレーに入社し、間もなく1年が経とうとしています。

少し時間が経ってしまったのですが、今回は1月に行われたプロダクト開発合宿の様子をお届けします。

プロダクト開発合宿の目的

メドレーでは「1年間の方針を共有すること」「メンバー間の親睦を深めること」を目的とした開発合宿を、毎年年始に行っています。

合宿の恒例行事となっている「1年間のプロダクト開発の指針」をCTO平山がプレゼンし、全員で共有する大切な機会です。 また、親睦を深める観点で、集中して一気に何かを開発するような合宿ではなく、普段あまり体験しないであろうアクティビティが中心です。

アクティビティの紹介

そば打ち体験

今年の合宿のアクティビティは、そば打ち体験でした。 「チームでひとつの作業に臨むことで、普段の業務以外でのメンバー間の絆を深めてもらいたい」という理由から、そば打ちがアクティビティに選ばれました。

今回お世話になった観音亭さんは、他ではなかなか経験のできない「石臼挽き」から体験できるおそば屋さんです。

f:id:medley_inc:20200327183356j:plain

石臼挽きを終えたら、挽いたそば粉をこねて伸ばしていきます。 職人さんの説明をよく聞きながら、普段食べている蕎麦の太さになるように薄く生地を伸ばしていきます。

f:id:medley_inc:20200327183437j:plain

生地が薄くなりすぎると破れてしまうことも......!

f:id:medley_inc:20200327183459j:plain

伸ばした生地を大きな包丁で切れば、見慣れた蕎麦の形になっていきます。

f:id:medley_inc:20200327183538j:plain

自分たちで打ったそばは、少し太さにばらつきはあるものの、その場で茹でていただきとても美味しくいただくことができました。 他のメンバーもそば打ちを楽しむことができたようで、満足した様子でした。

f:id:medley_inc:20200327183616j:plain

城ヶ崎海岸を散策

そば打ち体験の後は、サスペンスドラマの撮影で使われることでも有名な城ヶ崎海岸に移動し、周辺を散策しました。 門脇吊り橋という大きな吊り橋を渡って少しスリルを味わいつつ、城ヶ崎海岸の絶景を楽しむことができました。

f:id:medley_inc:20200327183707j:plain

f:id:medley_inc:20200327183729j:plain

バーベキュー

夕方には宿泊先に到着し、バーベキューを開始! お酒を飲んだり、雑談したり…時にはプロダクトや組織について熱く語りあったりと楽しい時間を過ごすことができました。

f:id:medley_inc:20200327183804j:plain

f:id:medley_inc:20200327183823j:plain

2020年キックオフ!

バーベキューの後は CTO 平山から2020年に向けてのキックオフです。

f:id:medley_inc:20200327183849j:plain

まず、2019年の振り返りから。

昨年はメドレーにとってもプロダクトにとっても大きな変化のある1年でした。

会社としては創業10周年を迎え、東証マザーズへ上場を果たしました。
ジョブメドレーの大幅なデザインリニューアルや CLINICS のグッドデザイン・ベスト100の受賞など様々なことがあった1年でした。

続いて2020年について。
詳細は記載できず残念なのですが、なにを目指すのか、それをどう実現していくのか…CTOからのメッセージを全員で確認する良い機会となりました。

普段の業務では目の前のタスクばかりに目が向き、つい視野が狭くなってしまうため、日常や業務を離れて少し引いた目でプロダクトや開発組織のこれからについて考える時間も必要なのだと感じることができました。

まとめ

今回はメドレーのプロダクト開発合宿の様子をお届けしました。

私自身、今回初めての合宿参加でしたが、メンバーと同じ時間を過ごすことで、普段見ることのできない一面を知ることができました。 また、これからの1年について考える時間ともなり、2020年、より良い1年にしていきたいです。

最後に、今回の合宿の企画運営をしてくださった前田さん・新居さん、本当にありがとうございました!

f:id:medley_inc:20200327183919j:plain

2019年度エンジニア新卒の研修について

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

メドレーでは今年度より新卒採用活動を本格化しており、今年はエンジニア4名が新卒社員として入社しました。

現在、新卒メンバーは6ヶ月の開発研修が無事終了し、各部署で業務に勤しんでいますが、このエントリでは、初めての新卒研修をどのような視点で計画・実行していったか?を書いていきたいと思います。

f:id:dev-medley:20191216115245j:plain
2019年度新卒入社メンバー

新卒研修を決めるまでやったこと

研修の大枠決定

カリキュラムの大枠を決めるため、まずCTOの平山が「こんなことをやろう」という大枠の方向性を出し、施策レベルに筆者が落としこんでいきました。

決めたことは、以下3点です。

  • 入社後の導入部分
    • 社会人としてのビジネスマナーや考え方の基礎を学ぶ
    • プロダクト開発をする上で必要になる基礎を学ぶ
    • 会社の事業内容を理解する
  • OJTをメインとした各チームへの仮配属
  • 新卒社員へのフォローアップ
    • メンターや部長との定期報告会
    • 半年後に役員陣への成果報告会

エンジニアとして価値を出していくため必要な「社会の課題を解決するために、日々自身の腕を磨き、純粋に取り組む、ただそれだけ」という、メドレーが求めるエンジニアとしての姿勢をきちんと体得してもらうことが目標です。

こちらについては平山のブログに詳しく書かれているので、ぜひご参照ください。

情報収集

社内エンジニアへのヒアリング

前職で新卒研修を受けたことがある社内の20代~30代のエンジニア4人を対象に、研修内容についてヒアリングしました。

ヒアリングしたポイントは

  • 研修の期間
  • 研修全体の流れ
  • 各研修メニューの内容
  • OJTはどういった形で受けたか
  • 研修を受けての感想

など。各社・各年代で個性が出るなという印象を持ちました。

やはり、エンジニアということで座学よりも手を動かすハンズオン形式の方が印象に残ることや、印象的な研修メニューは時間が経っても覚えているという傾向が分かりました。

ネットでの情報収集

ご存知の通り、近年では新卒研修のブログや、学習プログラムに関しては多くの企業様が書かれています。

しかし、内容としてはアプリ開発をこのような形式で行ないました」という情報が多く、研修全体や社内情勢も踏まえた背景などが書かれているものは意外に少ないなという印象を持ちました。

そんな中、各社の新卒研修エントリがGistにまとめられているのを発見しました。 こちらは大変参考になりました。作者の方にはこの場をお借りして感謝させていただきます。

研修資料まとめ.md · GitHub

研修メニュー決定

研修の詳細メニュー

ここまでの過程を踏まえ研修メニューを筆者が考え、CTOや開発部部長の田中・副部長の稲本と刷り合わせをしていきました。

結果として、以下のメニュー構成でいくことになりました。

  • オリエンテーション
    • [座学]社会人研修や会社全般の知識の習得を目的にする
  • 開発基礎研修
    • [座学]Webアプリケーション開発の基本や、エンジニアとしての心得、会社の展開するサービスの基本知識を習得することを目的にする
  • 開発実践研修
    • [OJT]社内向けにWebアプリケーションを開発し、チーム開発を実践することを目的にする
  • 開発部OJT
    • [OJT]稼動しているサービスの開発を通して、業務としての開発を実践することを目的にする
  • 事業部OJT
    • [OJT]ビジネスサイドの業務を体験し、開発以外の会社の業務の全体像を理解することを目的にする

特に事業部OJTは新卒メンバーには必ず理解してもらいたい、と決まった研修項目です。

メドレーではプロダクトファーストで開発しますが、プロダクトの機能や要望は実際のビジネスの流れと密接に関わっています。

新卒メンバーもこういった流れを把握出来ていないと、要点を押さえた開発ができません。実際にどのような流れで顧客と関わっていき、自分達が開発するプロダクトにどう影響していくかを体験してもらうために、この事業部OJTをメニューに組み込みました。

研修期間

研修の期間についても様々な意見が出ましたが、最終的には配属後の業務にスムーズに入ってもらえるように、基礎を重視して長めに研修時間を取ったほうがよいと決め、以下の通り全6ヶ月という研修期間を定めました。

  • オリエンテーション・開発基礎研修・開発実践研修
    • 2ヶ月
    • 期間中、午前:開発基礎、午後:開発実践
  • 開発部OJT・事業部OJT
    • 4ヶ月
    • 事業部OJTは期間中に2週間 x 2つの事業部で実施

メンター

研修全体の統括は筆者になりますが、新卒メンバーがいつでも相談できるように1人につき1人のメンターを付けています。社会人経験が3年以上ある社員をメンターとしました。

最初の2週は毎日1on1を15分程度行ない、以降は毎週金曜日に1時間の1on1を実施。 また、メンター同士の交流として、2週に1度メンターの共有会を開き、相談や近況報告を行いました。

メンター制自体も初めての試みだったためメンター同士の対応内容や新卒全員の様子が共有される場作りは、実施してよかったです。

研修メニュー内容

各研修内容のご紹介です。

オリエンテーション

オリエンテーション

  • 外部ビジネス研修
  • コンプライアンス研修
  • セキュリティ研修
  • 開発環境の整備
  • 開発ツールの解説

がメインです。

Macを渡されて、「勝手に開発環境作ってね」というのは新卒エンジニアにはハードルが高いので、筆者が付きっきりで時間をかけてフォローしました。

オリエンテーションは約1週間程度ですが、ここで「メドレー社員の一人になった」という実感を持ってもらうことができました。

開発基礎研修

大きく2部構成です。最初の部では、メドレーでエンジニアに期待していることや、既存サービスなどのシステム構成・ビジネスの流れなどを座学で実施しました。

もう一つの部では書籍の輪読をしました。この輪読は、Webサービスの基本の仕組みと、Webサーバ自体を支えるOSであるLinuxの基本を覚えてもらいたいという趣旨で開催しました。

メドレーについて

こちらの部ではCTO平山から「メドレーのエンジニアとして求めること」と題して、求められるエンジニアリングとは何なのか?自分達のキャリアパスなどをディスカッションしました。

その後は、ジョブメドレーCLINICS介護のほんね などメドレーが提供しているプロダクトについて、システムの概要やビジネスモデルとシステムの対応について講義。

メドレーでのエンジニアは各々専門性がある技術領域を持ちつつ、その領域に限定せずに広い分野で開発をしていますし、プロダクトを第一に考え開発しますが、そのために技術を武器としていくバランス感覚が必要になります。

この段階でまずこうしたメドレーでエンジニアとして働くとはどういうことなのかという知識や考え方を新卒メンバーに勉強してもらいました。 エンジニアとは何か エンジニアの価値は何か プロエンジニアとは何か エンジニアではない職種との違いは何か といった基本的な話から、 2030年のみんなはどうなっているのか、どうなっていたいのか 先輩エンジニアはどのようなことに悩み、どのようにアプローチをして、力をつけてきたのか、それを超えるためのヒントはどこにあるか メドレーのエンジニアとして求めたいことは何か といった踏み込んだ話も含め、個人ワークやグループワークも交えながら伝えていきました。

導入があることで、これからのカリキュラムを実施していく上での心構えができる期間だったのではないかと思います。

輪読会

座学でプログラミングのことを勉強させるのではなく、主体性を持ち、基礎知識を習得してほしいと考えていたので、プランを作っている初期段階から輪読会をすることを決めていました。 参考にさせていただいたのはドワンゴさんの2016年の研修の記事です。

輪読で使用する本の選定は悩んだのですが、弊社で使っているRubyRuby on Railsのことや、JavaScriptなどの技術より、基本となるWeb自体についての知識や、Webサーバで使うLinuxの事などを習得してもらいたいということを考えて以下の2冊で輪読を行いました。

「Webを支える技術」の輪読の形式は毎回決まった章を筆者が講義しつつ、時折質問などをメンバーに投げかけたりしながら理解を深めました。

議事録も新卒メンバー全員で順番を決めてもらうという、自主性に基づくスタイルにしました。まず輪読の雰囲気になれてもらうこと、それから議事録を取りつつドキュメンテーションの練習をすることを狙いとしています。

最初はぎこちなかった部分もありましたが、回を重ねるにつれて、自分の経験や知識も含めたディスカッションにも発展するようになり、全員自主性を持ちながら実施できました。

対して「Goならわかるシステムプログラミング」については新卒メンバーに章を割り当てて、各自講師をしてもらいました。

元々レポートを3回発表することを予定していたので、本の内容を読んできちんと理解した上で、他人へ伝える力を養うことをサブ目標にしています。

さらなる自主性も必要になる上、本の性質上ほとんどのメンバーが触っていないGo言語を使ってプログラムを書いてシステムのことを理解しないといけない為、プログラムの本質的な部分に触れることもできたのではないかと思います。

開発実践

開発実践は上記の開発基礎と並行して午後から実施しました。 1日の午前が開発基礎、午後が開発実践というスケジュールです。

実践は新卒メンバーで社内ツールを実際の業務形式で開発してもらいました。

題材は「メドレーの使い方に合ったビルの予約システムを作る」というものです(以前SmartHRさんが同じビルだったので少しアプローチが違いますがブログに書いてました)。

メドレーでの業務開発と同じ形式で

  • ユーザーからの要望をヒアリング
  • 要件定義
  • 開発計画の策定
  • システム設計
  • チームで分担してながらの開発
  • ベータ版としてリリースしたものをブラッシュアップ
  • 実稼働するための環境整備をしながらリリースする

という一連のプロセスで開発しました。

「開発自体どうやって進めるか」「仕様をどうするか」など基本的な所から、全行程を新卒メンバー主体で考えて実行してもらい、メンター陣は所々MTGやPRをレビューしながら、アドバイスをするという形式で行いました。

新卒メンバー全員が同じスキルセットを持っているわけでもないですし、得意・不得意も違う為、まず最初に彼ら自身にリーダーを決めてもらい、リーダーがオーナーシップを持って開発を進めてもらいました。

チームでの開発というのはほとんど全員が初めてだったため、かなり困惑しているところもありましたが、研修の過程で理解した互いのスペシャリティを活かして、役割分担をしつつ、決まった納期にきちんとリリースすることができました。メンターとしてそばで見ていましたが、新卒メンバー全員の成長を実感しましたし、純粋に凄いと感じました。

途中で納期に間に合わせるための要件の取捨選択をしなければならなかったり、自分達が考えた仕様が必ずしもベストというわけではなく、さらに色々と考える要素が必要だったりという開発のリアルを経験できたのは次のOJTに活きたと思います。

余談ですが、こちらの元々のシステムを調査する上で「Webを支える技術」の知識が早速役に立つという場面が多く、やはり基本は大事だな、と思った次第です。

開発部OJT

基礎研修が終わってから、既存サービスにジョインしてのOJT実施となりました。

ここまでの研修で、ある程度の知識や業務の進め方などは習得していたので、何をすればよいか分からないということはありませんでした。

メンバーによってはここで時間を取ってRuby on Railsについて習得をしてもらいました。 大きい失敗なども特にはなく粛々と進められたのは良かったのではないかと思います。

事業部OJT

開発部OJTの途中で2週間ずつ時間を取って、人材プラットフォーム事業と医療メディア事業での事業部OJTを行いました。

どこで顧客とコンタクトし、お金をいただき、どのような形で自分達が作ったシステムに関わっていくのか?というのをこの時期に体験してもらうことが目的です。

研修はビジネスの流れに沿って行ないました。研修メニューは、事業部の主要メンバーにコンセプトの共有をし、メニューを考えて実施してもらいました。(ありがとうございます!)

実際に電話でアポイントを取ったり、顧客のサポートを電話やビデオチャットでしたり、営業をどうやっているのかを体験したり…などを2週間かけて新卒メンバーに体験してもらいました。

この後に実際「このシステムの機能はこういうときに使うのかと実感した」とか「やっていてこのような仕様のほうが良いと思った」などの感想をそれぞれのメンバーが持っていて、やはり実施して良かったなと強く感じました。

レポート発表

それぞれの研修の終わりにはレポート発表の時間を設け、一人一人振り返りを書いてもらいます。その為に週報の提出も義務付けました。また研修期間の終了時には弊社役員陣にプレゼンする最終レポート発表の時間を取りました。

ひたすら研修内容をこなしていくという形になりがちなので、振り返りの期間を設けて記録を付けていき、自分の成長や反省などを可視化したいという目的です。

また、メドレーではドキュメントドリブンで開発に限らず全社員がConfluenceでドキュメントを書いていく文化なので、文書を誰にでも分かるように論理的に書く技術が求められます。こういったレポートの記述やそのフィードバックから文書技術を高めてほしいという目的もありました。

レポートに関してはメンター陣やマネージャ陣に発表してもらうという形にしていたので、発表自体やレポートのまとめ方などに都度フィードバックをするようにしました。

最初はレポートが読みづらいなどもありましたが、回を重ねるごとに段々洗練されたレポートや発表になってきたのが印象的です。

最終レポートは代表を始めとした経営陣に向けてレポートを発表してもらいました。今まで自分達がやってきた全ての業務を、前提の知識がない聴衆に向けて発表するということで、各自が趣向を凝らしての発表になり、経営陣からも高評価をもらっていました。

まとめ

メドレーで初の新卒研修は以上のような形で終わることができました。

かなりのハードスケジュールだったとか、開発部OJTをもう少し現場と色々と話しあったほうが効果的だったかもなど反省点もありますが、現在新卒メンバーが10月から実際の業務で活躍しているところを見ているので、ある程度の成功を収めることができたのではないかと思います。

来年度のメニューはまた違ったものになる可能性がありますが、今年の研修でも重視した「メドレーでエンジニアとして働くことに対する意義を感じながら業務をしてもらう」という部分はズラさずに実施していければと思います。

長々とお付き合いいただきありがとうございました。

社内勉強会TechLunchで Badging API について発表しました

みなさん、こんにちは。開発本部のエンジニアの舘野です。先日、社内勉強会「TechLunch」で Badging API について発表したので、その内容を紹介させていただきます。

Badging API とは

Badging API とは、ネイティブアプリのアプリアイコン上に表示されるバッジと同様に、ウェブアプリのアイコン上にバッジを表示することができる Web API です。

 

ネイティブアプリで可能なこと全てをウェブアプリでも可能にすることを目指す、Fugu というプロジェクトで実現に向けて動いている API の1つで、Chrome 73 から Origin Trials として利用可能になっています。Origin Trials とは、試験的に特定の開発者に限定してAPIを利用できるようにする仕組みのことで、正式リリース前にAPIに対する有用なフィードバックを受け取ることができるものです。

 

このAPIの最新の概要や仕様については、 WICGGithubBadging APIのリポジトリを用意しているので、そこで確認することができます。

WICG(The Web Incubator Community Group)は、先進的なウェブ技術について検討するコミュニティグループで、W3Cのグループの1つです。

提案されている API のインターフェースは、現時点(2019/08/14)では以下のようになっています。

 

https://github.com/WICG/badging/blob/master/explainer.md#the-api

 

  • Badgewindowオブジェクトのメンバとして持つ
  • Badgeには2つのメソッドが存在する
    • Badge.set()
    • Badge.clear()
  • Badge.set(5)のようにset()に整数を渡してバッジ上に数字を表示する
  • 単にBadge.set()で呼び出すとフラグとしてバッジを表示する
  • Badge.set(5, { scope:  ‘/baz’ })のようにオプションを渡して特定のスコープ配下で表示されるように指定できる
    • オプションでスコープが指定されてない場合、スコープは/になる

ローカル環境で試す

 

実際にどのような形でバッジを表示できるかを確認するために、今回はローカル環境(macOS 10.14、Chrome76)で試してみました。

API自体は非常にシンプルなので、PWAのアプリを用意してインストールするだけで簡単に試すことができます。

インストールされていないウェブアプリでも、タブのfavicon上やブックマークアイコン上にバッジを表示することも議論されているようですが、今のところインストール済みのウェブアプリでしかバッジは表示されません。

 

最初にAPIを利用可能な状態にする必要がありますが、上述の通りAPI自体が現在Origin Trials の段階なので、Origin Trialsの利用申請を行うかローカル環境であればchrome://flagsで実験的な機能を有効にする(#enable-experimental-web-platform-features)かのいずれかを行う必要があります。

 f:id:medley_inc:20190827173844p:plain

今回はローカル環境で試すだけなので、chrome://flagsから enable-experimental-web-platform-features を有効にしておきます。

実験的な機能を利用可能にしたことでBadging API自体は利用可能になりますが、window.Badgeとして利用可能になっているのではなく、Origin Trials の段階ではBadgeではなくExperimentalBadgeとして提供されています。

 

次に、サンプルのプロジェクトを用意してwebpack-dev-serverでローカルサーバを用意します。

 

$ yarn init

$ yarn add --dev webpack webpack-cli webpack-dev-server html-webpack-plugin copy-webpack-plugin

 

webpack-dev-serverでローカルサーバが見れる状態になるようにwebpack.config.jsに設定を記述します。

const path = require('path')

const HtmlWwebpackPlugin = require('html-webpack-plugin')

 

module.exports = {

  mode: 'development',

  devServer: {

    https: true,

  },

  entry: {

    app: ['./src/js/app.js'],

  },

  output: {

    path: path.resolve(__dirname, './dist'),

  },

  plugins: [

    new HtmlWwebpackPlugin({

      template: 'src/index.html',

    }),

  ],

}

 

次にmanifest.jsonを用意します。manifest.jsonは、そのアプリがどういったものか、また、インストールした時にどのように振る舞うかをブラウザに伝えるための設定ファイルになります。

https://app-manifest.firebaseapp.com/ のようなサービスでmanifest.jsonとアイコンを各種サイズ自動生成できるので、今回はこのサービスで生成します。

 

{

  "name": "badging-api-playground",

  "short_name": "badge",

  "theme_color": "#5B5CFD",

  "background_color": "#5B5CFD",

  "display": "standalone",

  "orientation": "portrait",

  "prefer_related_applications": false,

  "Scope": "/",

  "start_url": "/",

  "icons": [

    {

      "src": "images/icons/icon-72x72.png",

      "sizes": "72x72",

      "type": "image/png"

    },

    {

      "src": "images/icons/icon-96x96.png",

      "sizes": "96x96",

      "type": "image/png"

    },

    {

      "src": "images/icons/icon-128x128.png",

      "sizes": "128x128",

      "type": "image/png"

    },

    {

      "src": "images/icons/icon-144x144.png",

      "sizes": "144x144",

      "type": "image/png"

    },

    ….

  ],

  "splash_pages": null

}

 

webpack.config.jsの方にmanifest.jsonをローカルサーバで配信されるように設定を追加しておきます。

 

const path = require('path')

const HtmlWwebpackPlugin = require('html-webpack-plugin')

+ const CopyPlugin = require('copy-webpack-plugin')

 

module.exports = {

  ….

  plugins: [

    ….

+     new CopyPlugin([

+       {

+         from: 'src/manifest.json',

+         to: '',

+       },

+       {

+         from: 'src/images/icons',

+         to: 'images/icons/'

+       },

+     ]),

  ],

}

 

ここまででChromeのApplicationタブからmanifest.jsonが認識されいてることが確認できますが、インストール可能な状態にはなっていません。

f:id:medley_inc:20190826185511p:plain

アプリをインストール可能な状態にするには いくつかの基準 があり、service workerが必要になります。今回はWorkbox のwebpackプラグインで対応します。

 

yarn add --dev workbox-webpack-plugin

workboxにはGenerateSWとinjectManifestの2つのモードがあり、今回はどちらでも問題ないかと思いますがinjectManifestモードを利用します。

 

const path = require('path')

const HtmlWwebpackPlugin = require('html-webpack-plugin')

const CopyPlugin = require('copy-webpack-plugin')

+ const { InjectManifest } = require('workbox-webpack-plugin')

 

module.exports = {

  ….

  plugins: [

    ….

+     new InjectManifest({

 

+       swSrc: path.resolve(__dirname, 'src/sw.js'),

+     }),

  ],

}

 

app.jsの方でservice workerの登録がされるように記述しておきます。

if ('serviceWorker' in navigator) {

  window.addEventListener('load', () => {

    navigator.serviceWorker.register('./sw.js').then((res) => {

      console.log(res)

    }).catch((err) => {

      console.error(err)

    })

  })

}

 

service workerの対応が済むとインストール可能なアプリの基準を満たすので、Chrome76ではアドレスバーにオムニボックスが表示され、そこからインストールが可能になっています。

f:id:medley_inc:20190826185538p:plain

f:id:medley_inc:20190826185554p:plain

インストールするとLaunchpadにアプリアイコンが表示されたので、実際にBadge APIを試してみます。

window.ExperimentalBadge.set()を呼び出すと、フラグとしてバッジがつきます。

f:id:medley_inc:20190826185622p:plain

window.ExperimentalBadge.set(1)のように引数に数値を入れて呼び出すと、バッジは数字が入った状態で表示されます。

f:id:medley_inc:20190826185641p:plain

window.ExperimentalBadge.clear()でバッジがクリアされ、元のアプリアイコンだけの状態に戻ります。

f:id:medley_inc:20190826185653p:plain

非常に簡単ではありますが、このようにしてウェブアプリのアイコンにバッジをつけられることが確認できました。

なお、このサンプルプロジェクトは https://github.com/makotot/badging-api-playground にあげてあります。

 

まとめ

近い将来正式リリースされる可能性が高いAPIを試すことで、今後ウェブアプリでどのようなことが実現可能になっていくかの一端を垣間見ることができました。

 

API自体がOrigin Trialの段階で、ブラウザのタブのfavicon上やブックマークアイコン上に表示したいケースであったり、バッジはどこまでの範囲で適用するべきかのスコープの問題であったり、最終的にどのような形に仕様が整理されるかまだ明確ではない部分もあります。

 

最終的にどのように課題が解決されていくか注目したいと思います。

Google Cloud Next '19 in Tokyo にて、App Maker の活用事例を紹介しました

はじめに

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

普段はいわゆる社内SE的な領域を担当していますが、その名の通りエンジニアの視点も持ったコーポレート機能という立ち位置で、社員の働く基盤や事業の発展を支えています。 過去のコーポレートエンジニアの取り組みや、マインドについては以下が参考になるかと思います。

今回もその取り組みの一環で、先日開催された Google Cloud Next '19 in Tokyo に、カスタマースピーカーという形で弊社執行役員の兼松と共に登壇させて頂きました。

今回は、登壇させて頂いたセッション Google Apps Script / AppMaker 最新アップデートと活用のヒント について、セッションでお伝えした内容を含めたレポートを書きたいと思います。

Google Cloud Next '19 in Tokyo について

Google Cloud Next は、年一度 Google 主催で催されるGoogle テクノロジーに関するカンファレンスです(今年は、サンフランシスコ、東京、ロンドンの世界3会場開催)

メドレー社内でも、G Suite を中心に Google Cloud の活用事例が増えてきていることもあり、社内の新しいアプリケーションプラットフォームとして採用している App Maker の話でスピーカー応募してみようということになりました。

なお、登壇させて頂いたセッションですが、一般申込受付が始まってすぐに満席になってしまい、私がSNSでアナウンスしても既に満席で申し込めないような状態になっておりました・・・

会場の雰囲気

f:id:medley_inc:20190821171227j:plain
東京タワーとの一枚

f:id:medley_inc:20190821171259j:plain
登壇の様子(背景と同色なのは偶然です)

セッション内容について

Google Apps Script / AppMaker 最新アップデートと活用のヒント

今回は、Google の深堀さん、嘉穂無線の太田さんとの合同セッションという形で登壇させて頂きました。

まずGoogleの深掘さんが、「G Suite を拡張開発するテクノロジーの全体概要と活用事例」というテーマで、Google Apps Script / App Maker を含む G Suite 周辺の開発プラットフォームについて、位置付けの整理とグローバルでの活用事例、今後のアップデートについてお話されました。次に、嘉穂無線の太田さんが、「Google Apps Script の活用事例」というテーマで、Google Apps Script を活用して開発した社内システムについて、デモを交えて紹介されました。

それを受けて、メドレーでは「Google App Maker 活用事例と開発Tips」というテーマで、Google App Maker を活用して開発した社内システムを、デモを交えて紹介させて頂きました。

App Maker はGAされてからまだ一年強ということもあって、Apps Script と比較してもオンラインに蓄積されているナレッジが非常に少なく(あってもほぼ英語)、現時点において日本で活用できている企業は本当に限られていると思っています。

しかし実際に触っていく中でも非常に可能性を秘めたプラットフォームだと感じているので、日本でも活用する会社が増えてくれれば嬉しいという思いを込めて、今回プレゼンさせて頂きました。

ここからは、実際にメドレーのパートでお話した内容を、振り返りも兼ねて書かせて頂ければと思います。

Google App Maker とは

一言で言うと...

G Suite Business / Enterprise プランに含まれるローコードアプリケーション開発ツール

です!

f:id:medley_inc:20190821171328p:plain

主に以下のような特徴があります。

  • バックエンドのデータストアとして、RDB(Cloud SQL)が利用される
  • 開発言語は JavaScript をベースとしたスクリプト言語である Google Apps Scriptである
  • G Suite のサービス(ユーザーディレクトリ、メール、ドライブ等)と容易に連携が可能である
  • UIのカスタマイズの容易さと高い自由度がある

メドレーでの社内活用事例

メドレーでは、Google App Maker を活用して複数のアプリケーションを実装しています。

今回は、そのうちの一つである社内稟議システムについての概要を紹介させて頂きました。(当日はデモも実施しているので、デモの内容を見たい方はセッション動画をご覧下さい) f:id:medley_inc:20190822102114p:plain

App Maker を使ったアプリケーション開発の流れと開発Tips

App Maker はアプリケーション開発プラットフォームなので、開発の流れを以下の 3step に分割した上で、Tipsを紹介させて頂きます。

  1. データモデルの定義
  2. UI作成
  3. ビジネスロジック記述

1. データモデルの定義

はじめに、GUIベースでRDBメタデータを定義していきます。

モデル(テーブル)の主な設定項目

  • FIELDS:モデルのフィールド情報を定義
  • DATASOURCES:データベースでいうところのビューに近い概念の設定
  • RELATIONS:モデル間のリレーションを定義
  • EVENTS:クライアントのデータベース操作に対するイベントスクリプトを定義
  • SECURITY:モデルに対する権限を制御

f:id:medley_inc:20190821171355p:plain

データモデルの定義における開発Tips

  • EVENTSの挙動

    MODELの設定項目なので一見データベーストリガーと思いがちですが、このイベントは、サーバーサイドスクリプトや外部からのデータベースレコード操作では、トリガーされません。(クライアントサイドからの操作限定) サーバーサイドスクリプトや外部からの操作には、別途関数呼び出しを組み込む等の配慮が必要になります。

  • データベースへの更新反映タイミング

    既定の設定ではクライアントでデータソースの情報が変更された場合に、サーバーに即時反映される動き(Auto Save Mode)になります。この動きを止めたければ Manual Save Mode に切り替えることも可能ですが、コード記述量が大きく増えることになります。Auto Save Mode のままでも UI/UX の工夫で回避できたりするので、まずそこを検討するのが重要かなと思います。

  • 細かな権限制御

    GUI からできる権限制御設定は限られています。アプリケーション内での動的な権限制御や、フィールドの値に基づく細かな権限制御が必要な場合は、Query BuilderQuery Script による読み込み制御が必要になりますが開発コストが結構増加するので、他の回避策がないか事前に検討することをお勧めします。

2. UI作成

次に、ウィジェット(画面を構成する部品)をドラッグ&ドロップで配置して画面を作成していきます。

一般的に必要となるボタンやドロップダウンに加えて、G Suite ならではの User PickerDrive Picker 、更にはリッチなポップアップ、ダイアログ等も利用可能です。

スタイルに関しては、バリアントを利用することで、統一感のあるスタイル適用が容易に可能になっています

f:id:medley_inc:20190821171425p:plain

UI作成における開発Tips

3. ビジネスロジック記述

最後に、2種類のスクリプト(Client Script, Server Script)を利用して、ビジネスロジックを記述していきます。(アイテム生成とか、読み込みとかは基本的に記述不要)

Client Script からServer Script を呼び出したい場合は、 Google Apps Script 同様、以下のような形で実行が可能になっています。

google.script.run.ServerSideFunction();

f:id:medley_inc:20190821171501p:plain

ビジネスロジック記述における開発Tips

  • 外部公開できない

    Google Apps Script で言うところの、doGet/doPost 関数のような Web API は、App Maker のスクリプト内に作ることができないようになっています。外部システムとの連携が必要な場合、Cloud Function 等を介して、Cloud SQL を直接操作する必要があります。(トランザクション処理等は複雑化します)

  • ローカルの開発環境と上手く連携できない

    Google Apps Script で利用可能な clasp は、現時点で App Maker には対応していません。バージョン管理、デプロイ管理機能は開発コンソールに実装されていますが、コードレベルでの差分レビュー等を実施したい場合は、現時点では少しめんどくさいです。

  • 定期実行トリガーをGUIで設定できない

    Google Apps Script ではGUIから設定が可能な、「時間ベース」のトリガーがGUIで簡単に設定できません。設定が必要な場合は、以下のようなスクリプトベースで設定する必要があります。

ScriptApp.newTrigger('functionName').timeBased().at(date);

App Maker をこれから始める人向けの情報

なお、今回紹介させて頂いた内容は App Maker を全く触ったことがない人には少し難しい内容だと思っています。

知識がゼロからの方は、以下のナレッジを元に是非一度チュートリアルなどで簡単に触ってから、改めて読んで頂けると理解が深まるかと思います。

まとめ

今回紹介させて頂いた Google App Maker は、G Suite をディープに利用している企業であれば、Google Apps Script に匹敵する強力な社内アプリケーションプラットフォームになると感じています。

App Maker のようなローコード/ノーコード開発プラットフォームは既に市場にいくつか出ており、Google App Maker はその中でも比較的コーディング・技術力が求められるプラットフォームだと思います。しかし、その分既存社内システムと親和性の高い高度な自動化が実現しやすいプラットフォームでもあると思うので、臆せずにチャレンジする価値は十分にあると思います。

なお、セッション中に紹介させて頂いた稟議アプリケーションは、App Maker に対する知識が0の状態から1~2ヶ月程でSlackとの連携も含めて1人で実装できました。(RDBやGASに対する知識は、ある程度習得済みの状態が前提にはなっています)

GA直後ということもあってインターネット上のナレッジが少ない中、探り探りに得られた活用のヒントを今回の場でお話しさせて頂きましたが、引き続き App Maker というプラットフォームを上手く利用していくには、ユーザーコミュニティの盛り上がりが欠かせないと思っていますので、引き続き情報発信等を通じて盛り上げていければと考えております。

最後になりますが、メドレーではこのような市場に出て間もないテクノロジーでもチャレンジしていける風土があります。こういったチャレンジを求めている方は、ぜひご応募下さい。

www.medley.jp

www.medley.jp

Developers Summit 2019 Summerで弊社田中がエンジニアのキャリアについてお話させていただきました

みなさん、こんにちは。開発部エンジニア平木です。

少しレポートまで間が空いてしまいましたが、去る7/2(月)にソラシティカンファレンスセンターで開催されたDevelopers Summit 2019 Summerにメドレーが協賛させていただきました。

また、弊社の開発部長である田中がSI × Webの総合力で切り拓く新しいエンジニアのキャリアパスというタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。

会場の雰囲気

f:id:medley_inc:20190719173752j:plain
会場入口の立て看板がステキでした

会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。

f:id:medley_inc:20190719172816j:plain
次のセッション待ちで長蛇の列が
f:id:medley_inc:20190719172807j:plain
ブースも人が切れませんでした
しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。

印象に残ったセッション

f:id:medley_inc:20190719174247j:plain

色々とセッションを見ましたが、個人的にはやはり、@t-wadaさんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。

f:id:medley_inc:20190719173721j:plain

今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。

f:id:medley_inc:20190719173729j:plain

エンジニアのキャリアパス

f:id:medley_inc:20190719173659j:plain

いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。

f:id:medley_inc:20190719174601j:plain

内容としては、少し前まではいわゆるSIerとWeb系という2つの領域で結構明確に壁を感じることもあったと思います。しかし、近年X-Techなどの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすいUIへの落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Webサービスとして高速にPDCAを回しサービスを改善していくという能力も他方で必要になります。

f:id:medley_inc:20190719174328j:plain

こういった背景により、きっちりとした要件定義や設計する能力を求められるSIer的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要なWeb的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。

f:id:medley_inc:20190719173302j:plain

途中田中のキャリア変遷や、弊社のCLINICSを例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。

終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。

まとめ

メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早くPDCAを回し、早く確実に実装することを目指しています。Developers Summit 2019 Summerのような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。

f:id:medley_inc:20190719173131j:plain
セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に

▼メドレーってどんな会社?気になった方はこちら www.medley.jp

データウェアハウスとして使うAmazon Redshiftについて

はじめに

こんにちは。開発本部の阪本です。

今回は私が社内勉強会(TechLunch)にてAmazon Redshift(以下Redshift)についてお話した内容を紹介させていただきます。

Redshiftとは

概要

f:id:medley_inc:20190701165024p:plain RedshiftとはAWSサービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。

競合としてはBigQueryHadoop、また同じAWSサービスではAmazon Athenaも同様の位置付けになると思います。

データベースとしての特徴

Redshiftの特徴として、列志向型データベースという点があります。

MySQLのようなリレーショナルデータベースはデータを行(レコード)単位で保持している事に対し、Redshiftは列単位で保持しています。

f:id:medley_inc:20190701165052p:plainf:id:medley_inc:20190701165052p:plain 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスはMySQLPostgreSQLのような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。

またデータにはSQLでアクセスすることができ、構文もPostgreSQLと互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshiftは事前にテーブルを作成する必要のある従来型のRDBMSの形となっており、テーブル作成時はCREATE TABLEといったデータ定義言語(DDL)を使うことになります。

機能面の特徴

f:id:medley_inc:20190701165113p:plain:w350 先にも書きましたが、データアクセス時に使うSQLPostgreSQLの構文と互換性があります。

よってPostgreSQL用ドライバ(JDBC含む)さえ使えれば、後は特別に意識することなくRedshiftに対して接続やクエリ発行が行えるということになります。

この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BIツールのTableauRedashなどもそのままデータソースとして利用することが出来ます。

次に、一般的なRDBMSとの差についてです。 RDBMSにはありRedshiftには無いものとしては - UNIQUE制約 - 外部キー制約 - インデックスが無い

などがあります。

インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体はPostgreSQL互換なのでこれらを作るDDL構文を受け入れてくれるますが、Redshiftでは無視されますのでご注意ください。

逆に、Redshift固有のものとしては - Sort Key - 分散キー - 列圧縮

などがあります。 これらについては以下で少し掘り下げて説明します。

Sort Key

テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、ORDER BYGROUP BY句などの精査速度に影響します。

分散キー

MySQLでいうパーティショニングキーに近いものとなります。

Redshiftのデータ分散方法は - 均等に分散 - キー値による分散 - 全コピー - Auto(負荷状況による自動選択)

の4つで、データ量や特性によって使い分けることが出来ます。

分散キーはRedshiftを上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。

運用面の特徴

AWSコンソール

f:id:medley_inc:20190701165138p:plain RedshiftはAWSコンソール上からも詳細な情報を確認することが出来ます。

f:id:medley_inc:20190701165201p:plain Amazon RDSにあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。

データ取り込み

Redshiftはインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。

取り込み可能な形式

CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIPなど)

読み取り元

Amazon S3/Amazon EMR/Amazon DynamoDBなど

特にデータ配置元としてS3がサポートされているので、各種サービスが出力するログや、Amazon CloudWatch LogsからのS3やAmazon Kinesis Data FirehoseからのS3・・など、組み合わせ次第で可能性がとても広がります。

またS3に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能Amazon Redshift Spectrumがあります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。

ワークロード管理

f:id:medley_inc:20190701165215p:plain 負荷に関する運用についてはWLM(Work Load Management)という機能があります。

これはRedshiftに接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。

制御できる項目としては

並列クエリ実行数

同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。

クエリ実行時間

クエリ実行時間の上限。

メモリ使用量

クエリ実行時に使うメモリ使用量の上限。

などがあります。

可用性について

Redshiftはクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。

AWSも推奨しているように、Redshiftはマルチノード運用を基本としています。

これはRedshiftの個々のデータノードはRAID5のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 (同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します)

将来性について

過去1年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。

  • UNLOADコマンドのCSV対応
  • Concurrency Scaling
  • ALTER文でVARCHARの桁数変更
  • Elastic Resize
  • UNLOADコマンドのヘッダ行出力対応
  • コンソールにてクエリ実行環境追加
  • ネスト化されたデータのサポート
  • 自動バージョンアップ方式の設定/予告確認可能
  • Parquet、ORCからのIMPORTサポート
  • Amazon Redshift Spectrum東京サポート
  • 新ノードタイプDC2
  • Query Editorの追加
  • PL/SQL プロシージャのサポート
  • Vacumコマンドの自動化 New!!(2018/12リリース)
  • WLMワークロード管理の自動化 New!!(2019/06リリース)

実際の使い勝手

では、実際のところRedshiftの使い勝手がどういったものなのかを実例を含めて紹介します。 ここではdc2.large ノード数2のサンプル環境を使用します。

データのロード

クエリを発行するにも、まずは元になるデータが必要です。

ここでは日本語Wikipediaの目次ダンプデータを100セット分用意し、その内容をRedshiftにロードしてみます。

f:id:medley_inc:20190701165252p:plain f:id:medley_inc:20190701165257p:plain まずは目次データをこちらの画像の様に加工し、100セット分のファイルとして分割しS3へとアップロードします。

f:id:medley_inc:20190701165317p:plain 今回のロードするデータ量は235,732,000レコードの11.9GBとなりました。

f:id:medley_inc:20190701165331p:plain S3にファイルが配置出来たら、それを格納するテーブルをRedshiftに作ります。 この際PostgreSQLCREATE TABLEによってテーブルを作成します。

f:id:medley_inc:20190701165355p:plain テーブルの作成が完了したら、次はデータのロードです。 これもSQLクエリのCOPYコマンドによって取り込みが行われます。 今回このロード処理は8分55秒で完了しました。

データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。

Redshiftのロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。

クエリ発行

次に、クエリ発行についてですが、これはそのままPostgreSQLのクエリを実行することになります。

今回は先のステップで取り込んだ目次ページをタイトルごとにDISTINCTする集計クエリを発行してみます。

f:id:medley_inc:20190701165409p:plain すると49秒で結果が帰ってきました。 最低限のスペックで235,732,000レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。

不便に感じたこと

ここでは私がRedshiftを運用していて不便に感じた事をいくつか紹介します。

料金が高い

これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWSの他のサービスと比較して高価な印象があります。

さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。

更新クエリが遅い

列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新するUPDATEDELETEは遅いです。

そもそもRedshiftは頻繁にUPDATE/DELETEする用途には向いておらず(後述)、INSERTのみの積み上げ型や全レコード洗い替えが基本の用途になります。

また、UPDATE/DELETEを繰り返すとパフォーマンスが低下します。

これは内部的に保持しているSortKeyの状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。

解消するためにはSortKeyの再構築(VACUM/OPTIMIZEコマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。

(追記)2018/12のアップデートで自動実行機能が追加されました!

AWSコンソールが機能しないことがある

先に多くの便利な機能を紹介しましたが、なぜかこれらがAWSコンソール上で機能してくれないことが割とあります。

WLMの設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。

メンテナンスが高頻度

新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。

タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から2週間に1度ぐらいの頻度で発生していました。

この時間帯は再起動を伴う場合もあるため、WriteどころかReadすら出来ない状態になることもあります。

そのため日中は社内業務。夜間はバッチでといった24時間ずっと稼働する要件を満たす事は少し厳しいものとなります。

まとめ

まとめととなりますが、Redshiftは特徴をふまえると下記のような場面で利用すれば良いかなと感じています。

BIツール等のデータソースとして

メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。

履歴やマスタデータのような大量の積み上げ型データの集計

UPDATEが発生するなら、全件入れ替えが可能なデータ。

1日の利用頻度がそれなりにあること

頻度が高く無いのであれば、Athenaの方が安い。

どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。

Redshiftについても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

メドレーが協賛予定のイベントをご紹介します。(2019/7~)

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

メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどに、積極的に協賛させていただきたいと考えています。7月以降のイベントも積極的にスポンサードさせていただきますので、ぜひ皆様にもお越しいただきたく、このエントリではメドレーが協賛するイベントの魅力をご紹介します。

Developers Summit 2019 Summer

f:id:medley_inc:20190620190529p:plain

  • 公式サイト
  • 2019/07/02(火) @ソラシティカンファレンスセンター
  • ブロンズスポンサー

一番最初にご紹介するのは、ご存知Developers Summit 2019 Summer(以降デブサミ夏)です。

本家であるDevelopers Summit 2019冬でも協賛させていただきましたが、今回のデブサミ夏ではブロンズスポンサーとして執行役員である田中SI × Webの総合力で切り拓く新しいエンジニアのキャリアパスというタイトルでお話します。

ここ数年でX-TechDXの必要性が一気に叫ばれるようになってきましたが、メドレーでも医療におけるデジタルトランスフォーメーションの推進を目指して日々プロダクトの開発を進めています。X-TechやDXを推進する上で、いわゆる「Web系エンジニア」と「SI系エンジニア」という垣根を越えた、ハイブリッドな新しいエンジニア像が求められるようになってきたと感じます。「課題を解決するために必要とされるようになったハイブリットな能力とは?」「これからのエンジニアはどう成長していくのがよいか?」ということをお話させていただきます。

おかげさまで、現時点でセッションは満員になっていますが、ぜひご覧いただければ幸いです。

CloudNativeDays Tokyo 2019 / OpenStack Days Tokyo 2019

f:id:medley_inc:20190620190716p:plain

今年はイベントの統合もされ、名称も一新された日本最大級のコンテナ技術を始めとしたクラウドネイティブとオープンインフラの祭典である、こちらのイベントにも協賛させていただきます。

当日会場で配られるトートバッグに公式ロゴと共にメドレーのロゴを入れていただきました。実際にどんなデザインになるかは当日にご来場していただくまでのお楽しみとさせていただきますが、とても良いものになっているかと思います。

builderscon tokyo 2019

f:id:medley_inc:20190620190740p:plain

2016年から毎年開催されている、色々な分野のエンジニアの様々なセッションが一気に聞けるイベント「builderscon tokyo」ですが(去年は電子名札バッジがインパクトありましたね)、今年は初めてスポンサーとして参加させていただくことになりました。

会場である東京電機大学千住キャンパスの部屋の一つ、100周年記念ホールでセッションするスピーカーさんの後ろに設置されるバックパネルのなかに、メドレーのロゴが入ることに。

こちらのイベントでは弊社エンジニアもお邪魔する予定ですので、会場でお気軽にお声がけしていただければと思います。

CODE BLUE 2019

f:id:medley_inc:20190620190759p:plain

今年で7回目の開催となる情報セキュリティの国際会議「CODE BLUE 2019」に初めてスポンサーをさせていただいています。

メドレーでも取り扱っている情報の重要性から、会社としての取り組みでISMS認証 / ISMSクラウドセキュリティ認証を取得していますが、このようなセキュリティに関するイベントにも業界の発展に少しでも寄与できればと今年から協賛させていただくことになりました。

DesginShip 2019

f:id:medley_inc:20190620190818p:plain

去年から開催されているデザインカンファレンス「DesignShip 2019」に、去年から続きスポンサーをさせていただきます。

今年は会場も東京国際フォーラムになるということで、メドレーも去年よりもさらにアクティブな形でイベントに参加させていただくことになりそうです。

まとめ

ここまでご紹介させていただいたイベント以外にも現在、スポンサーの打診をさせていただいているイベントがいくつかありますが、こちらも決定次第おしらせできればと考えています。

メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどにこれからも積極的に協賛させていただくスタンスを取っています。

全てのイベントに協賛できるわけではありませんが、スポンサーを探しているイベント運営者の方がいらっしゃいましたら、一度お気軽にお問い合わせいただければと思いますので、よろしくお願いします。

▼メドレーってどんな会社?気になった方はこちら www.medley.jp