RubyKaigi 2018 レポ

SHOWROOMエンジニアのシミズです。

RubyKaigi 2018 @仙台 行ってきました!

rubykaigi.org

f:id:otto13:20180604201434j:plain 仙台城跡から見下ろした会場

f:id:otto13:20180604201617j:plain 近くから見るとこんな感じ

ぶっちゃけ、SHOWROOMではRubyを本格的には使っていませんが、旅費、参加費もろもろ会社に負担いただきました。 (ちょっとしたツールならRubyでさくっと書いちゃうことはありますけど)

RubyKaigiは初めての参加で、100%理解できたとは言い難いですが、また参加したいと思いました。

言語仕様や、コンパイラに関する話が多く、普段はあまり考えない部分に3日間肌で感じれたことだけでも学びが多かったと思います。

難しそうな改善内容も、Ruby 2.6にあげさえすればその恩恵を受けらるというはとてもワクワクします。

今からクリスマスが楽しみです(Rubyは例年クリスマスにアップデートがあります)

特に印象に残ったセッション

RubyGems 3 & 4

RubyGems 3 & 4 - RubyKaigi 2018

www.slideshare.net

セッション中に話されていた、デフォルトオプションの考え方はとても感銘をうけました。

不自然な挙動にならないようにすることと、初心者がはまらないようにしているという話は、だからRubyはとっつきやすいのかという理解が深まりました。

My way with Ruby

My way with Ruby - RubyKaigi 2018

slide.rabbit-shocker.org

いつもお世話になっているライブラリが紹介されていて、うらばなしに触れられて新鮮でした。 Rubyで顔認識するライブラリ(CV::CascadeClassifier)は実はちょっとした業務で使いました。(そのうち紹介するかもしれません)

Ruby Committers vs the World

Ruby Committers vs the World - RubyKaigi 2018 f:id:otto13:20180604180706j:plain

developers meeting風な会議のセッションでRubyがどうやって進化して行くのか、新機能がどうやって生まれるのかに触れられてとても刺激的でした。 中央にMatzさんがいる構図も面白かったです。

yield_selfの名前が結局どうなるのか、とても気になってます。

The Method JIT Compiler for Ruby 2.6

The Method JIT Compiler for Ruby 2.6 - RubyKaigi 2018

speakerdeck.com

「C langage is dead」の破壊力はすごかったです。

実際にベンチマークでも圧倒してるのがすごいです。驚きしかないです。

まだJITコンパイラを本番に投入するには課題があるとのことですが、「C langage is dead」な未来にワクワクします。

その他旅の思い出

f:id:otto13:20180604203500j:plain

店舗案内 | 仙台牛タン発祥の店 味太助

「味太郎」に行きました。

近くにある「あじたろう」は居酒屋であり別物という学びを得ました。

f:id:otto13:20180604203735j:plain

googleマップを開いたら、会場の近くに伊達政宗の銅像があるということで足を伸ばしてみたら、、、

地図上では近い距離だったのですが、まさかの山登りでした。

政宗パフェというのを昔ネット番組(SRでも配信)で見たので、それを食べようと思って頑張ったのに、それは違う史跡で残念。

f:id:otto13:20180604204357j:plain

近くに神社があり、伊達政宗パワーといいますか、勝負運に溢れてそうだったので、あのイベントの必勝祈願をしてきました!

以上、3日間にわたるRubyKaigi 2018 レポでした!

仙台、次は9月1日くらいに行きたい!!!

SHOWROOMのUIをカイゼンしてみた

こんにちわ、エンジニアのきむらです。現在は主にフロントエンドを担当しています。

今回は、IBPでSHOWROOMの既存UI改修のプロトタイプ制作をしてみたのでその報告です。

※ IBPに関してはこちら tech.showroom.co.jp

はじめに

入社前からずっと気になっていて、直したかったUIがありました。

それが、こちら

f:id:hkmn:20180423011759g:plain:w256

こちらは、SHOWROOMのPC版のグローバルナビゲーションです。 ナビにカーソルがホバーすると、自動でナビがでてきます。

実際の動きはこちら(SHOWROOMの実際のサイト)

いかがでしたか?

ずっと触っていると私はこんな気分になります(あくまで個人の感想です)。

f:id:hkmn:20180423122827p:plain:w256

SHOWROOMはサービスの特性上、配信に関する改修やイベントの改修が優先されるため、どうしてもこのようなUIの改修は後手後手になってしまうところが正直あると思っています。

ユーザさんも気になっているはずですが、ありがたいことにそこまで重大な問題になっていません。

が、日々のカイゼンの積み重ねはとても大事なわけでして、IBPでまとまった時間が取れるようになったため、ここで一気にやってしまおうと思ったのでした。

改修の方針を考える

いままでの私の開発経験上、以下の2点は特に気をつけなければいけないと思っています。

* 開発者が良かれと思ってつけた機能は、案外ユーザには不要なケースが多い

* ユーザが想定しない動きをするUIは使いづらい

これを踏まえると上記のUIは、

  • ナビが、ホバー時に自動で意図せず出てきて、コンテンツが見えづらくなる

  • アニメーションはユーザの目を引くので、意図せず出てくるとコンテンツから意識がそがれる

が課題だと思っています。 更にこのUIではもう1つ課題があり、

  • アニメーションがなんか遅い

点が気になります。 Googleが提唱するマテリアルデザインのガイドラインによると、デスクトップでのアニメーションの速度は150〜200msがよいとの記述がありました。

現状のナビゲーションは、delay 100ms と アニメーション 300ms に設定されていたため、だいぶ遅いようです。

以上を主な改修箇所とし、UIを改修することにしました。

改修内容

前項の内容を踏まえて、改修した内容がこちら

ホバーしたら勝手に出てくるのをやめる

ユーザのアクションでナビの開閉をします。今回はよくあるハンバーガーメニューを採用しました。

これは「ボタンを押した」 -> 「画面が反応した」という、ユーザが想定しやすいUIです。

アニメーションの速度を速くする

ガイドラインをもとに200msに設定し、自動で出てこないので delay をなくしました。

おまけ

ブラウザのウィンドウ幅が十分に広い場合、ナビを閉じておく必要がないため開いた状態にし、ウィンドウ幅が狭い場合のみ現状の閉じたデザインに変更しました。

ユーザの視認性の向上を目的としています。

改修後の画面

できあがったものがこちら

ウィンドウ幅が広いときは、ナビが最初から開いている

f:id:hkmn:20180423021208p:plain:w512

ハンバーガーメニュー

f:id:hkmn:20180423022109g:plain:w256

ウィンドウ幅を変えると、ナビの開閉状態が変わる

f:id:hkmn:20180423022201g:plain:w512

細かい問題はまだまだあるでしょうが、多少「よくあるサイト」「見慣れたサイト」になったのではないでしょうか。

まとめ

UIに正解はないと思っていますが、「根拠のある」「納得感のある」ものである必要はあり、またノウハウをまとめている記事はインターネット上にたくさんあります。

また、書籍もあります。

このあたりはデザインセンスとかは関係なく、学習すれば身につく領域で、いろいろな情報を日々アンテナをはって得たり、他社のサービスを良く見てみることがとても大事だと思いました。

そして、自分が作っているサービスは、たとえ使いにくいと思っていてもずっと触っていると慣れてしまいます。

慣れてしまう前に、気になる部分はどんどんあげだし、改修していくスピード感もまた必要だと感じました。

いっしょに働きませんか!

SHOWROOMでは、一緒にプロダクトを作り上げていく仲間を絶賛大募集中です。

職能や役割にかかわらず、自分たちが楽しく働ける仕組み、ユーザさんに良いと思ってもらえる機能をボトムアップでどんどん作り上げていける会社ですが、まだまだ人が足りません!

後手後手になっている改修をスピード感もって行うためにも、エンジニア、そしてデザイナーがもっと必要です。

興味が湧いた方は一度ぜひ遊びに来てください! www.wantedly.com

ルームフォロー情報を活用したターゲティングpush通知をトライしました

こんにちわ。

SHOWROOMエンジニアのシミズです。

僕です。

今回はこちらの取り組みについて紹介したいと思います。

きっかけ

こちらの機能を作ったきっかけはIBPの取り組みによるものです。 IBPについてはこちらの記事を参照下さい。

tech.showroom.co.jp

IBPで何を作ろうかなーと考えていた時に、

せっかくなら楽しみにしている配信をより盛り上げたい!

というテーマに絞って考えたときに思いつきました。

思いついてから実装するために出社する足取りは、いつの間にか少し早歩きになりました。

何を作ったのか

push通知を送信する仕組みを作りました。

f:id:otto13:20180326181812p:plain

すみません、また、技術的な話は少なくなりそうです。

何がすごいのか

今回、ルームのフォロワー以外のユーザーにも通知を送信させていただきました。

一部のユーザーにはびっくりさせてしまったかもしれません。

ですが、この通知は闇雲に送信したわけではありません。

今回の取り組みでは、個人の配信ルームをもつ演者さんが別の配信ルームの配信に出演するものでした。

SHOWROOMの配信ルームは主に個人単位で取得いただいており、ユーザーはグループよりも個人をフォローする傾向が強いです。

いわゆる推しメンです。

SHOWROOMのフォロー情報は、ユーザーの推しメン情報です。

今回はその情報を利用して、その推しメンが出演した時に、その推しメンのフォロワーに通知を送信させていただきました。

手前味噌ですが、かなりコンバージョン率の高いターゲティングができているなと思います。

公式のtwitterでも何名かにお礼させていただきましたが、この機能に激励のコメントを頂きとても嬉しかったです。

トライに至るまで

この機能は、誰かや他部署に作って欲しいと依頼されていた機能ではありません。

なので、

「こんな機能を作ったよ!」

「こんな感じで使ったら良さそうだと思うんです!」

と軽く営業メンバーに売り込んだら、早速やってみることになりました。

このスピード感が素敵です。

通常の告知などの宣伝業務であれば、営業メンバーが担当しますが、

今回は作ったばかりの機能だったので、当然、利用マニュアルもなく、自分の手で送信作業を行いました。

いきなり大規模配信に投入

通常であれば、小規模、中規模の配信でトライしてから大規模な配信に投入しますが今回は、いきなり大規模な配信に投入しました。

もちろん、配信内容がとてもよかったことが主要因ですが、この取り組みの配信がSHOWROOM史上最高の閲覧者数になりました。

今思うと、そんな配信に、新機能がいきなり投入していたことはとても恐ろしいですが、

やらせてもらえるとなったときはとてもワクワクしました。

出てきた課題

大規模配信でトライできたこともあり、課題点もたくさん出てきました。

ちょっとだけ技術の話します。

queueの処理が追いつかない

今回の取り組みに出演された演者さんたちは多くのフォロワーを抱えており、その全てのフォロワーに通知を送信したところ、queueが捌ききれず大量にスタックする事件が起きました。

原因

分散処理ができていなかった。

SHOWROOMではpush通知をQ4Mを利用した非同期処理にて実現しています。

また、そのQ4Mのサーバーは複数台構成となっており、キューイング先を散らすことで分散処理を行っています。

f:id:otto13:20180327020344p:plain

キューイング先はMyDNSのラウンドロビンで切り替えながら、まんべんなく散らすように作っているのですが、それがうまくできませんでした。

通知のqueueはN件毎に分割してキューイングしているのですが、全てが1箇所のサーバーに集中してしまったのです。

その原因は、一度接続したサーバーにそのまま繋ぎっぱなしになっていたことでした。

N件毎に分割してキューイングした際に、都度MyDNSを参照してサーバーの接続をし直すように修正しました。

問題解決に協力いただいたDeNAのインフラチームに感謝です

通知がユーザー毎に大きく異る

こちらは未解決ですが、送信対象ユーザー数が多いことが主な要因です。

送信を実行するワーカー数を増やすことでもある程度解決はできそうですが、どうしてもユーザー毎に早い、遅いが出てきてしまいます。

なので、遅延を解決することと同時に、送信順番を決める新ロジックを作ったり、そもそも通知を希望するかユーザーに選ぶ機能を作って送信対象を減らすことも検討しています。

総括

またまた手前味噌ですが、この機能を本番に投入できたことで少なからず配信の盛り上げに寄与できたのではないかと思います。

それができたことが何よりも喜びです。

我々のSHOWROOM Tech Studioチームではユーザーにサービスを提供することに重きをおいて仕事をしていますが、

今回の記事では、そのサービスがどのように生まれていくのかを簡単に紹介させていただきました。

最後に

今回の取り組みの配信で、一時映像が正常に配信できない時間が発生してしまい、大変申し訳ありませんでした。

このようなことが繰り返されないように、我々も成長していきたいと思います。

これからも引き続きSHOWROOMをよろしくおねがいします。

YAPC OKINAWA 2018に行ってきました

おはようございます。サーバサイドエンジニアむっくです。

この度、会社のお金で沖縄旅行YAPC OKINAWA 2018に行ってきました。 その感想をまとめたいと思います。

yapcjapan.org

会場までの道のり

前夜祭は参加できなかったのですが、当日は朝も早いため前乗りで沖縄に向かいました。
京急運転見合わせがありましたが、品川から浜松町に移動し東京モノレールに乗り換え無事羽田空港に着けました。

※飛行機移動では、余裕を持って行動しましょう💁
※運転見合わせのリスクを考え、複数経路を把握しておきましょう💁

当日は、あいにくの雨でした。 那覇市内から沖縄科学技術大学院大学 OISTまではレンタカーで移動したのですが、公式サイトのアクセスマップにあるように1時間ほどで到着しました。

オープニングまで

豪華ノベルティの数々🎉

f:id:mukkua:20180306003437j:plainf:id:mukkua:20180306003448j:plainf:id:mukkua:20180306003451j:plainf:id:mukkua:20180306003455j:plainf:id:mukkua:20180306003458j:plain

印象に残ったセッション 前編

Webサービスを監視するときに僕達が考えたこと papixさん

初心者向けという言葉通り、とても丁寧で聞きやすいセッションでした。 "監視とは"と”Mackerelで監視できるメトリクスとその説明”をされていました。 mackerelで監視出来るプラグインにnasneやスマートリモコンのNeture-REMOもあるのは驚きました。

mackerel-plugin-nature-remo https://github.com/papix/mackerel-plugin-nature-remo

yapc豆ハックとして、"僕達が考えたこと〜"というタイトルにすると通りやすい…らしいです。

HTTP/2で早くなるとき、ならないとき Kazuho Okuさん

毎度ながらとてもわかりやすい説明と話し方でした。ちなみに、今回のネタは同僚の方のものだったらしいです。

「一番早いのは、"HTTP/1"、"HTTP/2"、"場合による"のどれか?」のような質問から始まりました。 答えは、"場合による"なのですが、現状利用しているサーバ、クライアントの組み合わせでベンチマークの結果も変わるようです。 (正常なリクエストはHTTP/2圧勝なのですが、パケットロスの発生するケースだと場合によってはHTTP/1の方が早いケースもあるとのことです。)

セッションの意図としては、実際のユーザが利用してる環境でベンチマークを取りましょうということでした。

閑話休憩

パールスポンサーということで、弊社のエンジニアもランチセッションでお話させていただきました。

f:id:mukkua:20180306004745j:plain

超豪華なお弁当🎉

f:id:mukkua:20180306004738j:plain

印象に残ったセッション 後編

2018年春のPerl karupaneruraさん

@charsbarさんが毎年発表されていたシリーズを引き継がれたようです。まさに今回のテーマの架け橋を体現するセッションでした。

perl5やperl6のバージョンアップ情報、バグフィックスから機能改善などとても良くまとめられていました。

※perl6のatom演算子は今年一番の驚きでした😲

High (Availability|Performance) WebSocket for Perl Real-Time Application macopyさん

趣味で作っていたプロダクト(HTTP/1.1とWebsocketの相互変換プロキシサーバ)を社内利用しリリースするまでの話。 設計思想や課題、戦略などがまとめられた素晴らしい内容で、個人的にはこのセッションがベストスピーカー賞でした!!

speakerdeck.com

その後のセッションも

ゲストスペシャルセッションやLT大会でも(ネタを含め)perl愛に溢れたセッションが続きました。 (語り始めるとキリがないほどです。)

最後に

今回のカンファレンスに参加し、perlに限らず様々な分野の話を聞いて自身の見識が広がりました。 また、プロダクトに対する熱い想いに感化され自分ももっとコードを書きたくなりました。

運営スタッフの方、スポンサーの方、登壇者、参加者の方、本当にお疲れ様でした。 次回、YAPC TOKYOでお会いしましょう。

f:id:mukkua:20180306010526j:plainf:id:mukkua:20180306010455j:plainf:id:mukkua:20180306010413j:plainf:id:mukkua:20180306010341j:plain

第一回IBP最終発表会を行いました〜〜!

第一回IBP最終発表会を行いましたので、報告のブログです。

サーバーサイドエンジニアの さかい です。2017年4月入社のひよっこ(?)のエンジニアです。

弊社では業務の20%の時間を使ったIBPという取り組みを行なっております。

IBPに関することや前回の発表内容に関しては、前回記事をご覧ください。

tech.showroom.co.jp

最終発表会の様子

f:id:e_r_k:20180305165104j:plain

大きなテレビを使ってスライドやデモを行います。

f:id:e_r_k:20180305165731j:plain

.........と、前回とかわり映えがないですね。 (かわっているのは服くらい)

前回からの進捗

それでは今回の進捗を報告しようと思います。

前回の発表会から2ヶ月弱の期間があきました!

どのような進捗があったのでしょうか〜〜!

と書き出したいところなのですが、圧倒的に進捗が〜〜不足です。。はい。

原因なんですが、

よっしゃ今日は1日IBPやるぞ〜〜〜〜!

って意気込んでも

「〇〇お願いしてもいいですか??」

「これってどうなってます???」

□_ヾ(・_・ )カタカタ

□_ヾ(・_・ )カタカタカタカタ

-----------退勤時間-------------

IBPなんも今日やってない〜〜〜〜😇

となってしまう現象。

通常業務 80% IBP 20%

通常業務 100% IBP 20%

😇😇😇😇😇😇😇😇😇😇😇

こんな状態になってしまいましたね。。

「勉強にはなるからいいんだけど、まとまった時間がとれない」

という声もちらほら。

私自身はチームでIBPに取り組んでいて、 普段クライアント側がどうなっているか見る機会が少なかったのですが、 チームのiOSエンジニアにいっぱい質問させてもらって勉強になりました:) がしかし、私自身も時間をとるのがなかなか難しかったです、、、

ということで次回はまとまった時間をとってのハッカソン形式にすることにしました!!!

またブログで報告しますね〜〜!

いっしょに働きませんか!

SHOWROOMでは現在採用に力を入れており、

一緒にプロダクトを作り上げていく仲間を絶賛大募集中です〜〜!

IBP以外にも自分たちが楽しく働ける仕組みを自分たちでどんどん作り上げていける風通しの良い会社です!

興味が湧いた方は一度遊びに来てくださいね〜〜! www.wantedly.com

Streaming Conference #1 にて登壇しました

こんにちわ。

SHOWROOMエンジニアのシミズです。

主にサーバーサイドの業務を担当しております。

更新が遅くなりましたが、先日「Streaming Conference #1」に参加し登壇しましたのでその報告です

streaming-lab.connpass.com

当日の様子はニコニコ生放送でも放送されました。

live.nicovideo.jp



自分は「SHOWROOMの泥臭い負荷対策」というテーマでSHOWROOMの負荷対策についてお話させていただきました。

speakerdeck.com

今振り返ると、技術的な話のセッションが多い中、全然技術の話をしなかったなーという印象です。 技術的な話を期待していた方には申し訳ないです。興味あればお話いつでも受けつけてます!

今回、私が届けたかったメッセージは「泥臭くっちゃだめですか?」ということです。

エンジニアとしては仕組みを全てシステム化してスマートに解決したいものですが、正直我々はまだそれができていません。 そんな現状でも、我々はどんなにかっこ悪い運用でも利用者に安定して動画を届けることを死守したいと考えております。

いつの日にか再びの登壇では、「システム化してスマートになりました!」っていう報告をしたいものです。 でも、きっとその時はその時で別のことを泥臭く取り組んでいると思います笑



その他の登壇で気になったのは、やっぱりHLSのチューニングまわりですね。
皆さん、あの手この手で低遅延化に取り組んでいて、とても参考になりました。 SHWOROOMでも低遅延化の調査や取り組みは行っており、 あの手、この手で低遅延化はできるんだけど、安定運用を考えると。。。っていうところに課題が残っちゃうのがとても共感できました。

今回、このカンファレンスを開催してくれた みゆっき さん、会場、懇親会の場を提供してくださった 株式会社ドワンゴ さんありがとうございました。

予定は未定ですが、#2 も引き続き参加させていただこうと思います。

IBP中間発表を行いました!

あけましておめでとうございます(大遅刻ですね)。サーバーサイドエンジニアの加藤です。

弊社では業務の20%の時間を使ったIBPという取り組みを行っており、今回は先月に社内で行ったIBP中間発表会の様子を紹介したいと思います。

f:id:hiropon_sr:20180105173522j:plain

IBPとは?

通常業務の他に週1日の時間をエンジニアが自由に使いボトムアップによる新たな価値の創出を目指す取り組みです。 (要は20%ルール) 新規プロダクト、既存プロダクトへの機能追加のプロトタイプ制作をアイディアソン、ハッカソンを通して実施します。

月1~2でアイディアソン&ハッカソンを回して発表会を実施しビジネスモデル、プロダクトのUXの完成度が高いモノに関しては 正式にリリースを目指しての開発の許可及び本格的な予算、工数の割当が行われるという形になっています。

tech.showroom.co.jp

中間発表会の様子

前回はピザを頬張りながらワイワイとアイデアソンを行いましたが、
今回は中間発表ということでちょっと真剣な雰囲気で現在の進捗状況などを
各自が自由な形式で発表をするスタイルで行いました。

f:id:hiropon_sr:20180105174914j:plain

大きなテレビを使ってスライドやデモを行います。

f:id:hiropon_sr:20180105173539j:plain

それぞれ個性のある発表で非常に面白かったです(盛り上がった!!)

f:id:hiropon_sr:20180105174544j:plain

盛り上がりすぎて時間オーバーしてしまった為、一旦休憩を挟んで全員の発表が終わりました。

特に評価の高かった取り組み

hls.jsのチューニングによる動画の低遅延化

SHOWROOMはユーザーが生配信することのできるサービスで、PC、iOS、Androidに対応しています。
PC版の視聴にはこれまでRTMPを使っていましたが、RTMPはブラウザで直接再生出来ないためプラグインのFlashのプレーヤーが必要です。 脱Flashの流れの中で昨年SHOWROOMでもHLS版の視聴プレーヤーを追加しました。 f:id:hiropon_sr:20180119123000p:plain
RTMP (Real Time Messaging Protocol )は、Adobe Systems社が開発したメディアストリーミングプロトコルで、低レイテンシーが特徴です。
対してHLS ( HTTP Live Streaming )はApple社が開発したHTTPベースのメディアストリーミングプロトコルで、安定した再生ができますが一般的にはRTMPより遅延が発生します。
現在のSHOWROOMのHLSプレイヤーもRTMPより遅延しているために、これをできるだけ低遅延化させよう!というのが今回の取り組みです。

※再生にはDailymotion社が開発したhls.jsを利用しています github.com

実際に取り組んでいるのはプレイヤー側(hls.js)のパラメータチューニングです。試行錯誤を繰り返し、ストリーミングサーバ側の設定も同時に調整することで5秒程度まで遅延を縮められそうだということが分かったため、今後は本格的に案件化する予定となりました!

※チューニングの詳細はブログで公開するかもしれません!

ライブ機能追加 スタンプを投稿

SHOWROOMはライブ時にで配信者と視聴者が、コメントやギフトでコミュニケーションを取っています。
しかし、始めたばかりのユーザにとってコメントを送るというのは少々敷居が高く、もっとカジュアルに配信者とユーザがコミュニケーションを取れないかとの発想からチャットアプリにあるようなスタンプを送れたら気軽にコミュニケーションを取れるのではという仮説を立て、実際にテストしました。

技術的にはpub/sub+png画像の表示+css3のanimationを利用した動く
画像+動き(出現モーション)のあるスタンプです。
今後はsvg形式を利用しさらにライブ性の高い動きにしてリリースに向けて完成度を高めていきます。

人気配信者になる ??

こちらは弊社のiOSエンジニアが実際にこっそり配信を行ったという面白い取り組みです!
SHOWROOM Tech Studioはサービスに寄り添っていく集団です。SHOWROOMのサービスを実際に使っているエンジニアが多数ですが、やはり配信をするというのは敷居が高く、配信をしたとしても継続的に続けられたエンジニアはこれまでいませんでした。
実際に1ヶ月継続して配信してみて思った以上に初心者には厳しい、継続が大事などの生の知見が得られたりしたようです。

※こちらもとても面白い取り組みだと思いますので、ブログで紹介できたらと思います



やってみて

初めての試みでしたので課題もありつつも、概ね成功だったのかなという所感です。
普段、業務で絡まないメンバー同士でもチームを組んでいたりするので相乗効果も期待できそうです。

(私自身は、きちんと20%の時間確保というところが一番難しかったです。日々のスケジューリング、段取り力が問われますね!)

また、発表に慣れてないメンバーもいるので全員にこういった機会が定期的にあることはとても良い環境なのかも、と思いました。
(プレゼンて難しいですよね...!!)

いっしょに働きませんか!

SHOWROOMでは現在採用に力を入れており、
一緒にプロダクトを作り上げていく仲間を大募集しています!
IBP以外にも自分たちが楽しく働ける仕組みを自分たちでどんどん作り上げていける風通しの良い会社です。
興味が湧いた方は一度遊びに来てください! www.wantedly.com