こんにちは。スマートキャンプの郷田です。 本記事は スマートキャンプ Advent Calendar 2019 - Qiita の24日目の記事です。 私は普段から趣味で楽器演奏や曲作りをしているので、前から少し気になってたSoundPiを使ったサウンドプログラミングで簡単なループ音源を作ってみようと思います！ SonicPiとは？ 作成したものはこちら 曲 コード SonicPiを使ってみた感想 最後に SonicPiとは？ コードベースで音楽制作のできる無料ツールです。 sonic-pi.net Windows、macOS、Raspberry Piで実行することができます。 利用時の画面はこちら 作成したものはこちら 今回は3時間でできるところまでを目指して作成してみました。 最初の1時間でチュートリアル、ヘルプを読み、残りの2時間でコーディングをしました。 チュートリアルはダウンロードしたアプリケーション内で閲覧でき、日本語に翻訳されているため始めるには十分な情報量です。 曲の題材として、この記事はクリスマスイブの公開のため、ジングルベルを選曲しました。 作成した時の気分でEDM風？なアレンジにしてみました。 曲 ※10秒程度の音源が再生されます soundcloud.com コード SonicPi # Sonic Pi v3.1 ## setting use_bpm 132 ## main live_loop :ch_lead do with_fx :octaver do lead_s :E4 , 0.5 lead_s :E4 , 0.5 lead_s :E4 , 1 lead_s :E4 , 0.5 lead_s :E4 , 0.5 lead_s :E4 , 1 lead_s :E4 , 0.5 lead_s :G4 , 0.5 lead_s :C4 , 0.75 lead_s :D4 , 0.25 lead_s :E4 , 2 lead_s :F4 , 0.5 lead_s :F4 , 0.5 lead_s :F4 , 0.75 lead_s :F4 , 0.25 lead_s :F4 , 0.5 lead_s :E4 , 0.5 lead_s :E4 , 0.5 lead_s :E4 , 0.25 lead_s :E4 , 0.25 lead_s :G4 , 0.5 lead_s :G4 , 0.5 lead_s :F4 , 0.5 lead_s :D4 , 0.5 lead_s :C4 , 2 end end live_loop :ch_bass do 2 .times do bass_s :C1 , 0.5 end sleep 3 3 .times do bass_s :C1 , 1 end sleep 1 2 .times do bass_s :F1 , 0.5 end sleep 3 2 .times do bass_s :G1 , 1 end bass_s :C1 , 2 end live_loop :ch_beat do with_fx :reverb , mix : 0.5 do 2 .times do sample :bd_haus sample :bd_klub sleep 0.5 end sleep 1 sample :drum_snare_soft , amp : 5 , rate : 1.7 sleep 2 2 .times do sample :bd_haus sample :bd_klub sleep 1 end sample :drum_snare_soft , amp : 5 , rate : 1.7 sample :bd_haus sample :bd_klub sleep 2 end end live_loop :ch_hh do 2 .times do sample :drum_cymbal_closed , rate : 2.4 sleep 0.5 end sample :drum_cymbal_open , rate : 1.4 , amp : 0.5 , start : 0.2 , finish : 0.7 , release : 1 sleep 1 8 .times do sample :drum_cymbal_closed , rate : 2.4 sleep 0.25 end end ## sounds define :bass_s do | n , crotchet | use_synth :dsaw play n, amp : 2 sleep crotchet end define :lead_s do | n , crotchet | use_synth :saw play n, amp : 0.7 , sustain : 0.2 , release : 1.2 * crotchet use_synth :noise play n, amp : 0.5 , sustain : 0.2 , release : crotchet sleep crotchet end コードはSonicPiにコピペすれば、そのまま再生できるはずです！ SonicPiを使ってみた感想 DTMのUIで行える音楽と比べて、SonicPiでできることがプログラミングであるため「抽象化も具体化もとても高い音楽を作ることができそう！」という可能性を感じました！ 波形の選択、ADSRを数値での設定、Fxの設定といったシンセサイザー機能や、サンプリング音源の再生速度や逆再生といったサンプラー機能等がとても楽しいです！ 逆に DTMやシンセサイザーといった音楽の知識が全くない人だと、楽しみ方がわからないかと思います。 今回のコードはかなり煩雑になってしまっているのですが、先人が沢山いらっしゃるので、学んで趣味の一つとして楽しんで行きたいと思います！ 今の所、仕事では使えなさそうです。 最後に 私の作った曲はいかがだったでしょうか？ SonicPiの詳細ついてはググれば色々と記事がでてくるので、ご自身でお調べください！ そして、プログラミングと音楽制作（DTM）が好きな方であれば、直感的にコードで音楽を表現できるので、是非1度は触って見ることをおすすめします！

こんにちは。スマートキャンプエンジニアの今川( @ug23_ )です。 23 という数字は私の大好きな数字です。 本記事は スマートキャンプ Advent Calendar 2019 - Qiita の23日目の記事です。 監視当番: 年末年始の恒例行事 開発に加えて運用・保守を担うプロダクト開発チームにとって、年末年始といえばアレを決めないといけない時期です。 クリスマスパーティの場所？忘年会の日程？大掃除の分担？ …そうですね！ 監視当番 です！ 帰省する人、海外で過ごす人、ひとりで過ごす人さまざまでしょうが、 監視当番 をきめてその人は一次対応できるようにしておく、というのを他社でもやっていると思います。 この記事では監視担当になったときに大切な心構えをまとめてみました。よければ参考にしてください。これも必要だよ！というのがあればぜひTwitterやブックマークのコメントで書いていただければ私の参考にさせていただきます。 障害対応自体は以下の記事がとても素晴らしいなと思いました。 qiita.com 全体感としては、そちらを見ていただくことにしてこの記事でははじめて担当する人や経験の浅い人向けに書いています。 一次対応の心構え 休み前に: 本番環境を確認する方法をおさらいしておこう 休みに入る前に、会社以外の場所から本番環境にアクセスするときの手順を確認しておきましょう。 いろんなインフラ構成があるかと思いますが、 社外のアクセス時にVPNが必要 とか、 クラウドコンソールにちゃんとログインできるか？ とか 普段と違うPCでログインするなら、 秘密鍵やssh-configなど必要なリソースは揃っているか とか 監視用ダッシュボードがちゃんと見れるか？ とか 予め確認しておくほうがよい項目があるかと思います。 リハーサルのように、休みに入る前に社外からのアクセス方法を確認したり、設定しておいたりしましょう。 AWSだとClient VPNという機能でかんたんにVPNを利用できます。 tech.smartcamp.co.jp ログインできたとしても、どこをみたらいいかわからない！だと困るので、先輩社員にログやメトリクスの見方についてレクチャーしてもらう場を作りましょう。 休み前に: 通知・アラートにすぐに気付けるようにしよう 監視当番とはいえダッシュボードに張り付いているわけにもいかないので、監視アラートが頼りになるわけですが、 アラートが検知されたときにあなたがすぐ気付けるようにしておく ことが必要です。 メールでくるならそのメールがスマホなどでプッシュ通知されてくること Slackの通知チャンネルに飛ぶならそのチャンネルをスマホアプリで Slackの通知の設定方法はこちら: slack.com え、それだと通知がうるさいって？ 通常時にうるさければそれは通知しすぎなので、本当にやばいラインで通知されるようにアラートの閾値や条件を調節しましょう。 通知がオオカミ少年化してるとほんとにやばいときに気付くのが遅れるので過去の経験などからうまいところを見つけましょう。 （という提案をあげられるといいですね） 当日になったら: まずは普段どおり過ごす 特に前日なにもなく、平穏な日々が続いているなら担当のあなたは普段どおり過ごしましょう。 普段どおりコードを書いたり読書したりゲームしたりすればよいです。たいてい一人だけが担当になるときついので二人組で監視することになるかと思いますが、1,2時間見れなくなるタイミングができたらバディに連絡を取るなど、ノーガードの状態を作らないようにしましょう。 要はすぐに見れるような状態にあれば常に気を張っていなければならない必要はないです。 スマホの通知や電池残量には気をつけておきましょう。 年末年始だと地元に帰る方も多いですが、 うっかり地元の友達と飲みにいく約束をしないように…。 なにか起きたら: とにかく報告しよう！声をあげよう なにかアラートがあがり、それに気づいたらアラートに気づいたことを報告しましょう！ もし作業をするなら作業をすることもしっかり報告しましょう。 もしかして誰も見ていないのではないか？ というのが周りで見ていると一番怖いです。 逆に今何をやっているんだろう？ というのも不安になります。 コマンド打つのも共有しつつやりましょう。 それが確実に対処法として正しいことがわかっている場合以外は他のメンバーからのOKをもらってから実行しましょう。 チャットで発言しておけばタイムスタンプが残ります。タイムスタンプを残しておくと障害報告書をかくときに楽です。それを書くのがあなたの仕事でなくても、書く人にとってはありがたいものです。作業前に発言、作業後に発言。記録を残す意味でも、情報共有をするべきだと心に留めておいてください。 障害対応は何が書かれるんだろう？というかたにはこの記事がよさそうです。 qiita.com 作業中: わからなくてもわからないことを報告するのが仕事です 前項にも書きましたが、なにをするにも報告するのが大事です。 一方で 何をしたらいいんだろう どこから見たら良いんだろう と迷って手が止まるタイミングもあるかもしれません。 その時は わからないです！ ということをしっかりアピールしましょう。 それが先輩にとって既知のものであれば助け舟を出してくれるかもしれないし、先輩にとってもわからなければ一緒に悩めばよいのです。 離れている場所にいてかつスピード感が求められる状況なので 自分がいまなにをしているのか を正直に出しましょう。 なにをしたらいいかわからない ことも情報のひとつです。 作業中: 二次災害に注意 もしその場でなにかのオペレーションをやることになったら、しつこいぐらいに確認をするようにしましょう。 例えば DBに直接クエリを実行する ことになったり、 サーバを再起動 しないといけなくなったり様々かと思います。 そんななかで、緊張してテンパっていたりすると、1レコードだけを消すようにクエリを打つつもりで全レコード消したり、再起動しないといけないサーバとは別の健康なサーバを再起動してしまったり…、うっかりですまないミスを誘発することになります。 こうした暫定対応中のうっかりミスを二次災害と呼ぶことが多いと思います。二次災害のほうがひどかったり。 実際に打つコマンドをSlackで見てもらったり、ZoomとかWherebyとかでバディを付けて確認しながら作業をするのが望ましいです。 複数人の目でチェックして二次災害を起こさないようにしましょう。 監視後: 何もなかったらそれはそれでHappy なにもなかったら、まずは無事を喜びましょう。 その上で 今日一日なにもなかったなぁ あれだけ気を張っていたのに と思うかもしれませんが、あなたがやったことには意味があります。 あなたは取り越し苦労をしたのではなく、あなたが警戒態勢をとっていてくれたおかげで他のみんなが休みを満喫できたのです。 その一日に備えて学んだり準備したりしたことはまた役に立つので無駄にはなっていないはずです！ 最後に 障害の一次対応はエンジニア知識の抜き打ち試験のような緊張感がありますが、同時に成長の場でもあります。 落ち着きつつ、着実にとるべき方法を見つけたりコミュニケーションをとったりして乗り越えましょう。 みなさまのシステムにも年末年始の平和がありますように…。

スマートキャンプでボクシルのエンジニアをしている井上です。 本記事は スマートキャンプ Advent Calendar 2019 - Qiita の20日目の記事です。 個人的に遊んでいるAuth0について書いてきます。 前回はAuth0でのよくある認証をAuth0 Nuxtで実装しましたが、 今回は前回の作成したものを使って、Auth0でJWT認証をやってみたいと思います。 前回の記事はこちら tech.smartcamp.co.jp JWTとは Auth0を設定する Rails側のJWTサンプルをダウンロードしよう ダウンロードしたRails sampleを起動する Rails側が何やってるのか一応触れる PrivateController Secured module JsonWebToken Class Nuxt側にJWTの設定を追加しよう JWTで認証を試してみる ログインする JWTリクエストする まとめ JWTとは webbibouroku.com Auth0を設定する 前回作成したAuth0の設定に加えてAPIを追加していきます。 Auth0にログインしたら下記のようにAPIに移動します。 移動後にAPI Createを押下すると、下記のような画面が表示されますので それぞれ、Nameなどを下記のように設定していきます。 Name： test-api Identifier: https:/ test-api Signing Algorithm: RS256 作成ボタンを押すとAPIが作られます！ Rails側のJWTサンプルをダウンロードしよう Auth0ではsampleの実装を公開していますので、それを使用して行います。 また、事前にプロジェクトを作ったことで.envに必要な設定が記載された状態で作成できます。 auth0.com ダウンロードしたRails sampleを起動する プロジェクト直下に移動してdocker環境を起動してみましょう！ docker build -t auth0-rubyonrails-api-rs256 . docker run --env-file .env -p 3010:3010 -it auth0-rubyonrails-api-rs256 これでRailsアプリが立ち上がります！ アクセスしてみると、下記のおなじみのRails画面が表示されるかと思います。 Rails側が何やってるのか一応触れる PrivateController 今回、JWTリクエストを送るのは自動生成されたPrivateControllerのprivateアクションです。 ここにリクエストを送って、 Hello from a private endpoint! のメッセージが帰ってくればJWT認証が成功となります。 # frozen_string_literal: true class PrivateController < ActionController :: API include Secured def private render json : { message : ' Hello from a private endpoint! You need to be authenticated to see this. ' } end def private_scoped render json : { message : ' Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this. ' } end end Secured module JWTを受け取って、認証されているかどうか返す部分をSecuredというmoduleで作成しています。 これをcontroller側でincludeすることで、before_actionでJWT認証をおこなうようになっています。 # frozen_string_literal: true module Secured extend ActiveSupport :: Concern SCOPES = { ' /api/private ' => nil , ' /api/private-scoped ' => [ ' read:messages ' ] } included do before_action :authenticate_request! end private def authenticate_request! @auth_payload , @auth_header = auth_token render json : { errors : [ ' Insufficient scope ' ] }, status : :forbidden unless scope_included rescue JWT :: VerificationError , JWT :: DecodeError render json : { errors : [ ' Not Authenticated ' ] }, status : :unauthorized end def http_token if request.headers[ ' Authorization ' ].present? request.headers[ ' Authorization ' ].split( ' ' ).last end end def auth_token JsonWebToken .verify(http_token) end def scope_included # The intersection of the scopes included in the given JWT and the ones in the SCOPES hash needed to access # the PATH_INFO, should contain at least one element if SCOPES [request.env[ ' PATH_INFO ' ]] == nil true else (String( @auth_payload [ ' scope ' ]).split( ' ' ) & ( SCOPES [request.env[ ' PATH_INFO ' ]])).any? end end end JsonWebToken Class そして、実際にJWTの認証をしてるのは下記のJsonWebTokenです。 ここで、decodeする際にAuth0のdomainなどを使用してます # frozen_string_literal: true require ' net/http ' require ' uri ' class JsonWebToken def self . verify (token) JWT .decode(token, nil , true , # Verify the signature of this token algorithm : ' RS256 ' , iss : " https:// #{ Rails .application.secrets.auth0_domain } / " , verify_iss : true , aud : Rails .application.secrets.auth0_api_audience, verify_aud : true ) do | header | jwks_hash[header[ ' kid ' ]] end end def self . jwks_hash jwks_raw = Net :: HTTP .get URI( " https:// #{ Rails .application.secrets.auth0_domain } /.well-known/jwks.json " ) jwks_keys = Array( JSON .parse(jwks_raw)[ ' keys ' ]) Hash [ jwks_keys .map do | k | [ k[ ' kid ' ], OpenSSL :: X509 :: Certificate .new( Base64 .decode64(k[ ' x5c ' ].first) ).public_key ] end ] end end Nuxt側にJWTの設定を追加しよう 続いてNuxt側に設定を追加していきます。 設定は先ほどnuxt.config.jsに追加した, auth部分に下記のように追加するのみです。 //nuxt.config.js auth: { strategies: { auth0: { domain: 'Domain' , client_id: 'Client ID' , scope: [ 'openid' , 'profile' ] , // 今回追加, response_type: 'id_token token' , // 今回追加, token_key: 'id_token' // 今回追加, } } , redirect: { login: '/login' , logout: '/logout' , callback: '/callback' , home: '/mypage' , } , } , JWT認証をやるためaxiosのheaderにtokenを設定します。 また、ここは新規でplugins/axios.jsを作成します。 //plugins/axios.js export default function ( { $axios, store } ) { $axios.interceptors.request.use(config => { config.headers.common [ 'access-token' ] = store.$auth.$storage._state [ '_token.auth0' ] config.headers.common [ 'Access-Control-Allow-Origin' ] = '*' config.headers.common [ 'access-token' ] = store.$auth.$storage._state [ '_token.auth0' ] return config } ) $axios.onError(error => { console.log(error) console.log( 'opps' ) } ) } また、nuxt.configのpluginsにも設定を追加します //nuxt.config.js plugins: [ '@/plugins/element-ui' , '@/plugins/axios' , // 今回追加 ] , mypage.vueをまるっと下記に書き換えます。 もはや, mypageとは？という状態ですが遊びなので許してください //mypage.vue <template> <el-container> <el-form> <el-button type= "primary" @click= "jwtRequest" >JWTを試す </el-button> </el-form> </el-container> </template> <script> export default { methods: { jwtRequest: function () { this .$axios .get( 'http://dockerのip:3010/api/private' ) .then(response => { confirm (response.data.message) } ) } } } </script> JWTで認証を試してみる ログインする ログインボタンを押下して、下記の画面が表示されるかと思いますので、 Google認証でログインしましょう！ JWTリクエストする /mypageに移動しJWTを試すボタンを押下 認証に成功すると、Rails側からJWT認証が通ったとメッセージが帰ってきます まとめ Auth0でJWTはサンプルもあることで、かなりか簡単に試せるようになってますね！ auth0ようのmoduleもあったりなど、今後より使いやすくなっていくのが楽しみですね

スマートキャンプでBiscuetのエンジニアをしている中川です。 本記事は スマートキャンプ Advent Calendar 2019 - Qiita の19日目の記事です。 現在弊社のプロダクトであるBOXILとBiscuetは、そのどちらの開発チームもVue.jsを使用して開発しています。 Vue.jsの学習コストの低さやコンポーネント指向は少人数のチームでユーザーに素早く価値を届けていきたい弊社の開発においても重宝しています。 さてそんなVue.jsですが、2020年のQ1にバージョン3.0が正式リリースされることが予告されており、正式リリースに先駆けて目玉機能のひとつであるComposition APIが公開されました。 Composition API RFC | Vue Composition API ドキュメントやAPIリファレンスのみならず、バージョン2系でプラグインとして利用できるコードも公開されていたので、本記事では実際に使ってみた上で従来のSFCのコードと比較することでComposition APIの特徴を掴んでいこうと思います！ Vue.js 3.0について Composotion APIについて 導入 試してみる setup, reactive function ref computed, watch lifecycle hooks まとめ Pros Cons Vue.js 3.0について Vue.jsの次バージョンである3.0のリリース時期は前述の通り2020年のQ1を予定しており、その開発自体は今年のQ1からスタートしています。 アップデート内容は作者であるEvan You氏のこちらの記事（ Plans for the Next Iteration of Vue.js - The Vue Point - Medium ）にまとまっています。 本記事ですべてを紹介することはしませんが、個人的には以下の機能や変更が気になっています。 Composition API（本記事で触れる機能です） TypeScriptサポートの強化 Reactivity APIのパブリック化 デバッグ能力の向上 ソースコードの軽量化 処理の高速化 slotsメカニズムの向上 IE11サポート 盛りだくさんですね。 Vue.js自体のロードマップは以下にカンバン形式で公開されているため、バージョン3.0に限らず今後Vue.jsがどういった方向に進んでいくのかの概観を掴むことが出来るようになっています。 Roadmap · GitHub また、バージョン3.0自体はvue-nextとしてリポジトリ管理されています。 github.com Composotion APIについて これまでVue.jsは小〜中規模のアプリケーションにとって最適といわれてきましたが、月日の経過とともにアプリケーションは大きくなり、それに伴い不便を感じることが増えてきました。 なかでも、「複数の開発者が１つのSFCを長期間メンテや機能追加することによりリーダビリティが低下しコードジャンプを重ねないとどこに何があるのか分からない」や、「複数のSFCで繰り返し使っているが共通化されていない関数がある」といった事態はもはやあるあるとして語られるようになってきつつあるのかなと思います。 その問題を解決する切り口として提案されているのがComposition APIで、ドキュメントの Motivation の項目にも Logic Reuse & Code Organization として掲げられています。 Composition API RFC | Vue Composition API また、同ドキュメント内の以下イメージが分かりやすかったです。 左が従来のScriptタグ内で１つのObjectをexportする形、右が同一の内容をComposition APIで書き直した形で、各色はそれぞれに関連するコードを表しています。 Composition API RFC( https://vue-composition-api-rfc.netlify.com/ )より抜粋 従来の書き方では散らばっていた関連するコードがComposition APIではまとまっていることが見て取れますね！ 導入 導入方法は以下の手順の通りです。 vue-cliで vue create した直後に以下コマンドでComposition APIプラグインをインストールします。 $ npm install @vue/composition-api --save インストールしたプラグインを Vue.use します。 import Vue from 'vue' import App from './App.vue' import VueCompositionApi from '@vue/composition-api' Vue.use(VueCompositionApi) Vue.config.productionTip = false new Vue({ render: h => h(App), }).$mount('#app') 以上で導入は終了です！ yarnやCDNでのインストールにも対応しているようなので、詳しい導入方法は以下のリポジトリのREADMEを参考にしてください。 github.com 試してみる さて、それでは実際にCompositionAPIを使ってみましょう！ サンプルとしてボタンをクリックすることでカウントアップする簡単なコンポーネントを作ってみます。 setup, reactive まずは count という変数名の data を初期値0でセットして template タグ内で表示してみます。 これを従来のOptions APIで書いてみるとこのようになります。 Options API <template> <div> <p>count: {{ count }} </p> </div> </template> <script> export default { data() { return { count: 0 } } } </script> なんの変哲もない見慣れた形ですね。 特に説明することはなさそうです！ 次にこの内容をComposition APIを使って書いてみます。 Composition API <template> <div> <p>count: {{ state.count }} </p> </div> </template> <script> import { reactive } from '@vue/composition-api' export default { setup() { const state = reactive( { count: 0 } ) return { state } } } </script> いきなり雰囲気がガラッと変わりましたね。 まずは setup 関数なるものが登場しました。 これは従来の data や、 computed 、 methods などの種類に関わらず、 template タグ内で使用したりリアクティブな値として保持しておきたいものを定義し、returnするObjectに含めます。 次に reactive 関数ですが、この関数に引数としてObjectを渡すことでそれぞれの値がリアクティブ化されます。 従来の data の役割に近そうです。 また、templateで参照するにあたって count から state.count と state を挟むようになっています。 これは後述する ref という関数で別の書き方が出来るので、その場合は従来通りの count として参照することができます。 function 次にボタンをクリックするごとに count の値を1ずつ増加させる処理を実装します。 Options API <template> <div> <p>count: {{ count }} </p> <button @click= "increment" >Count Up</button> </div> </template> <script> export default { data() { return { count: 0 } } , methods: { increment() { this .count++ } } } </script> Options APIではdata関数と並んでmethodsオブジェクトが登場しました。 Composition APIでは以下の形になります。 Composition API <template> <div> <p>count: {{ state.count }} </p> <button @click= "increment" >Count Up</button> </div> </template> <script> import { reactive } from '@vue/composition-api' export default { setup() { const state = reactive( { count: 0 } ) function increment() { state.count++ } return { state, increment } } } </script> methodsのような関数をまとめるオブジェクトはなくなり、前述の setup 関数のなかでfunctionとして宣言してそれをreturn文に含めるという形に変化しています。 この書き方であればまとめておきたい一連の変数や関数の宣言を並べることが出来るため可読性が向上する効果が期待できます。 また、この形であればimportした関数をreturn文にそのまま含めることも出来ますね。 ref refはrefferenceの略で、その名の通り引数として渡した値の参照をreturnする関数です。 <template> <div> <p>count: {{ count }} </p> <button @click= "increment" >Count Up</button> </div> </template> <script> import { ref } from '@vue/composition-api' export default { setup() { let count = ref(0) function increment() { count.value++ } return { count, increment } } } </script> この書き方には以下の特徴があります。 プリミティブな値であっても state のようにオブジェクトにまとめる必要がなくなり、ソースコード上の利用する関数等と近しい位置に書くことができるようになる template タグ内で従来通り count として参照することが出来る 値を更新する場合は count.value など、 .value をつける必要がある 特に1.の理由で使用することが多そうな気配がします！ computed, watch 次にcomputedとwatchを使ってみます。 count の値を2倍にするcomputedである double と count をwatchして3の倍数のときにalertを出すwatcherを実装します。 Options API <template> <div> <p>count: {{ count }} </p> <button @click= "increment" >Count Up</button> <p> double count: {{ double }} </p> </div> </template> <script> export default { data() { return { count: 0 } } , computed: { double () { return this .count * 2 } } , watch: { count(v) { if (v % 3 === 0) alert ( 'Multiple of 3' ) } } , methods: { increment() { this .count++ } } } </script> Options APIではdata, methodsに加えてcomputedとwatchが登場しました。 対してComposition APIでは以下の形になります。 Composition API <template> <div> <p>count: {{ state.count }} </p> <button @click= "increment" >Count Up</button> <p> double count: {{ state. double }} </p> </div> </template> <script> import { reactive, computed, watch } from '@vue/composition-api' export default { setup() { const state = reactive( { count: 0, double : computed(() => state.count * 2) } ) function increment() { state.count++ } watch(() => { if (state.count % 3 === 0) alert ( 'Multiple of 3' ) } ) return { state, increment } } } </script> computed、watchどちらもsetupの中に収まる形になっていますね。 もちろん関数の宣言順の決まりはなく、見通しのよいと判断した位置に記述できます。 lifecycle hooks 最後にlifecycle hooksについて見てみましょう！ mounted のタイミングでconsoleを出してみます。 Options API <template> <div> <p>count: {{ count }} </p> <button @click= "increment" >Count Up</button> <p> double count: {{ double }} </p> </div> </template> <script> export default { data() { return { count: 0 } } , computed: { double () { return this .count * 2 } } , watch: { count(v) { if (v % 3 === 0) alert ( 'Multiple of 3' ) } } , mounted() { console.log( 'mounted!' ) } , methods: { increment() { this .count++ } } } </script> 対してComposition APIでは以下の形になります。 Composition API <template> <div> <p>count: {{ state.count }} </p> <button @click= "increment" >Count Up</button> <p> double count: {{ state. double }} </p> </div> </template> <script> import { reactive, computed, watch, onMounted } from '@vue/composition-api' export default { setup() { const state = reactive( { count: 0, double : computed(() => state.count * 2) } ) function increment() { state.count++ } watch(() => { if (state.count % 3 === 0) alert ( 'Multiple of 3' ) } ) onMounted(() => { console.log( 'mounted!' ) } ) return { state, increment } } } </script> onMounted など onXXX の形で各lifecycleの関数が提供されているので使うものを都度importして setup 内に記述する形になりました。 また、従来の created や beforeCreated については対応する onXXX はなく、 setup に置き換わっているので注意が必要そうです。 その他の onXXX についてなど詳細は以下のAPIリファレンスをご覧ください。 API Reference | Vue Composition API まとめ 駆け足でComposition APIにおける主要なシンタックスを見てみました。 雑感としては以下です。 Pros 従来の data や computed 等に散らばっていた関連するロジックを setup 関数のなかで自由に宣言出来るのは思った以上に自由度が高くなる 関連するロジックをまとめるなど、リファクタリングとしてもComposition APIに移行する価値はありそう あるコンポーネントにひとつの機能を追加するときなど、「これをdataに定義してこれをcomputedに定義して〜」といったコードジャンプがなくなるのは可読性の面でもよさそうだし実装スピードも上がりそう setup 関数のreturn文を見るだけで何がtemplateタグから使用できるのか一目瞭然 今回は紹介できなかったがTSXサポートもあるので3.0のTypeScriptサポート強化と併せてTypeScriptがさらに負担少なく導入出来るようになりそう TypeScriptとTSXを使ったサンプルレポジトリが公開されている（ GitHub - liximomo/vue-composition-api-tsx-example ）のですぐに試せそう Cons 従来のシンタックスから大きく離れることになるので既存プロジェクトからの移行はある程度の手間を覚悟しないといけなそう Composition API自体あくまでオプショナルなので3.0以降でも従来通りのOptions APIで書くことはもちろん可能 setup 関数内の自由度があまりに高いので一定のルールが無いとカオスになりそう これに関してはeslint-plugin-vueのように全プロジェクトで統一されたルールを適用することは難しいのでプロジェクト内であらかじめルール決めが必要そう 既存プロジェクトでいますぐ導入することはなかなか難しそうですが強力なシンタックスである片鱗は存分に感じたので、新規プロジェクトや個人開発などでガンガン使っていきたいと思います！ Vue.js 3.0、たのしみですね！

スマートキャンプでボクシルのプロダクトマネージャーをしている笹原です。 本記事は スマートキャンプ Advent Calendar 2019 - Qiita の18日目の記事です。 もうアドベントカレンダーも残すところ1週間ですね。書く人も2週目に入ってきており、そろそろネタの引き出しに困りだすところですが頑張って走り抜けます！ 話は変わりますが、ブログを書くにせよ何にせよ、目標を持つことは大事ですよね。 しかし、エンジニアやデザイナは目標設定に悩む人も多いんじゃないでしょうか。 僕はいつもめちゃくちゃ悩んでます笑 今日は、ボクシルのProductチームがどのように目標を設定し、それをどのように振り返っているのかまとめていきたいと思います。 長期的な事業Visionと中期の事業目標 半期 目標設定: Productチームの目標設定 四半期 振り返り: チーム振り返りDay 月次 振り返り: 360°フィードバック 隔週 目標設定＆振り返り: チームの目標達成推進 週次 目標設定: Sprint Planning 振り返り: Sprint Review（ボクシル全体ミーティング） 振り返り: Sprint Retrospective 日次 目標設定: 朝会（ Daily Scrum ） 振り返り: モブプロ振り返り 随時 振り返り: 振り返り専用チャンネル まとめ 長期的な事業Visionと中期の事業目標 ボクシルは長期的な事業Visionとして以下を掲げています。 この事業Visionを実現していくための中期の目標として事業全体のマイルストーンが設定されており、Productチームはこのマイルストーンを達成することを目的として、目標を設定していくことになります。 半期 目標設定: Productチームの目標設定 弊社では半期ごとに目標設定をしています。 Productチームでは目標を落とす最小単位を個人ではなくチームとしているため、チームメンバー全員の認識をすり合わせながら、半期のチーム目標を考えていっています。 チーム目標を考えていく際には以下の流れで進めていきます。 目標設定の目的についてチームで目線合わせ 前提条件として事業全体の状況の洗い出し、認識統一 設定すべき目標をブレスト 付箋に書き出し 目標となる単位にカテゴライズ カテゴライズされた目標群を優先順位付け 取り組む目標の決定 目標が実現されたことを計測するための指標を策定 目標は考えるときはOKRのエッセンスを多分に入れています。 特に以下のような点を取り入れることで、チームが最大限以上のパフォーマンスを発揮できるようにと考えています。 目標はワクワクするようなものにする 定性的な目標とそれが達成されたことを図るための定量的な指標をセットで考える 目標の達成度合いは給与に関する評価には影響させない 四半期 振り返り: チーム振り返りDay 四半期に一度丸一日かけて、チーム全体の振り返りをしています。 丸一日とることで、普段ではできないようなフィードバックできたり、ちょっとしたもやもやを全員で話せたりします。 毎回している以下の2項目に加えて、都度アジェンダをチーム内で募集して開催しています。 4半期のタイムライン確認 メンバーの相互フィードバック 直近では昨日行ったのですが、その時のアジェンダは以下のような感じになってました。 月次 振り返り: 360°フィードバック 個人の成長にフォーカスした取り組みとして、360°フィードバックを実施しています。 フィードバックを受ける側の成長、モチベUPのために、普段の業務や振返りで伝えきれてない事を率直に伝える場です。 以前は半期ごとに実施していたんですが、重い＆遅いので軽く＆早いフィードバックを、ということで月次での実施になりました。 スクラムの5つの価値基準ベースでフィードバックをします。 コミットメント(Commitment) 集中(Focus) 公開(Openness) 尊敬(Respect) 勇気(Courage) フィードバックの内容はマネージャーと、フィードバックを受ける人だけが見れるようになっています。 隔週 目標設定＆振り返り: チームの目標達成推進 実際にチームの半期目標に対してどういうアクションを取るのかを確認・軌道修正をしているのは隔週のこの場になります。 以下のようなアジェンダでVisionを達成するためのマイルストーンにどの程度近づいているのか、次に取るべきアクションは何なのかを確認しています。 その場で次の振り返りまでの宿題を作り、その宿題の確認から次のMTGは始まります。 アジェンダは以下のような流れになっています。 前回の宿題確認 目標の再確認 指標の集計 現状の確認 ネクストアクションの設定 週次 週次より小さい単位から、実際の開発に内容が落ちてきています。 ボクシルもBiscuetと同じく、開発プロセスのフレームワークとしてScrumを採用しています。 イテレーションを1週間で回しているため、Scrumのセレモニーが週単位での目標設定や振り返りの役割を担っています。 tech.smartcamp.co.jp 目標設定: Sprint Planning その週に何を開発するかをSprint Planningで決めています。 スプリントゴールをプロダクトマネージャーが決めた上で、開発チームがバックログの上からその週で開発するアイテムを選択してスプリントバックログを作成していきます。 振り返り: Sprint Review（ボクシル全体ミーティング） ボクシル全体ミーティングというボクシル事業に関わる全員が参加する場で、アウトプットの共有をしています。 この場ではセールスやマーケから事業数字の共有や、事業部長から中長期の施策の共有があり、そういった事業にまつわる情報をインプットする場にもなっています。 振り返り: Sprint Retrospective スプリントの振り返りはKPTでやっています。 KPTは以下の流れで1時間に収まるようにしています。 メトリクスの収集（ミーティングの前に行っておく） メトリクス及び前回のトライの確認 KPを書き出す KPの中から議論したいものをVoteで決める Voteされた順に議論を進めTryを決めていく 始めた当初は1時間でTryを決めきれることのほうが珍しかったのですが、今では余裕を持ってTryを決めることができています。 振り返り自体は、ホワイトボードを用いてアナログに見える形で行っていますが、実施内容をストックしていくためにスプレッドシートにまとめています。 日次 目標設定: 朝会（ Daily Scrum ） 目標設定というと大げさかもしれないですが、一日でやることを決める場ということで朝会をここで挙げさせてもらいます。 アジェンダとしては以下のような簡潔な感じになってます。 昨日の進捗の確認 今日やることの確認 写真を見ていただくとわかりますが、朝会の司会は毎日ルーレットを回してわいわいしながら決めてます。 また、弊社ならではの確認にはなりますが、どの時間でモブプロをするのかこの場でスケジュールを決めてます。 モブプロをどのように取り入れているか気になる方は以下の記事を読んでみて下さい。 tech.smartcamp.co.jp 振り返り: モブプロ振り返り 日次でも振り返りを行っています。 その日の良かったこと課題に感じたことをまとめて、翌日以降に取り組むアクションを決めています。 随時 振り返り: 振り返り専用チャンネル 良かったこと課題に感じたことを随時共有できるチャンネルをSlackに設けて、リアルタイムにも振り返りをしています。 ここまでくると、どんだけ振り返ってるんだって感じですね。 まとめ こうして改めて可視化すると、目標設定を適切なスパンで行いながら、振り返りを回数こなして軌道修正しているなーと感慨深いです。 ちょっと前までは無かったものや、逆にちょっと前はあったけど今はもう行っていない取り組みも思い起こされました。 どちらもチームが最大限に力を発揮するために必要な取り組みだと思うので、目標設定や振り返り自体も改善を続けながら強くなっていきたいですね！

スマートキャンプエンジニアの瀧川です！ 本記事は スマートキャンプ Advent Calendar 2019 - Qiita の17日目の記事です。 私は前々からログ転送基盤構築やらログ分析を生業としてきたのですが、新規プロダクトを作る際などではインフラコストもかかるし、開発者が必要とするデバッグのための情報、プロダクトオーナーが必要とする定量的な情報など多彩な要望に答えるコストも高いなと感じていました。 そこで課題を解決する方法を探す中で出会った、 ユーザの行動ログを収集し、様々な機能を提供するSaaS である、LogRocketとFullStoryについて調べたことを紹介しようと思います！ ※ 本記事は比較記事ではないので、LogRocketとFullStory両者でできること、どちらかでしかできないことをあまり区別せずにざっくばらんに書かせていただきます。 LogRocket, FullStoryってどんなSaaS？ どんな使い方がある？ カスタマーサポート・サクセスが円滑になる 開発者のエラー・バグ調査が円滑になる UI/UX改善のための分析ができる ファネル分析 ヒートマップ その他 個人情報など隠せる 料金 まとめ LogRocket, FullStoryってどんなSaaS？ ※ FullStoryのリプレイ画面 海外のサイトでは以下のようにカテゴライズされていました。 Conversion Rate Optimization Software > Session Replay Software Webアプリケーションに組み込むことで、アプリケーションのログを収集し、 ユーザーのアクセスしたセッションでの操作(カーソルの動きや入力、ページ遷移)を再現(リプレイ) できるのが主な特徴となります。 それに付随して以下のような機能があるようです。 アプリケーションのカスタムイベント(コンバージョン)の記録 ブラウザのDeveloperConsole(ネットワークとコンソール)を再現 ユーザ識別情報の記録(id, email, name, custom…) ユーザのユーザエージェントや表示サイズなどの情報を自動で記録 ユーザセグメントや行動でフィルタリング 行動ファネル分析などのアナリティクス etc... 【以下公式】 logrocket.com www.fullstory.com ※ 私が試したのは上記2つですが、海外では Hotjar や Smartlook といったサービスのシェアが多いようです。 どんな使い方がある？ カスタマーサポート・サクセスが円滑になる Webサービスを運営していると多くのお問い合わせを受けることとなります。 その際に多くはカスタマーサポート・サクセス担当者が、内容を確認し、バグ報告などで必要であればより詳細な発生状況をヒアリングするなど各社されているかと思います。 多くのセッションリプレイSaaSで、 IntercomやZendeskといったカスタマーサポートサービスとも連携することができるようになっており、「このお問い合わせが来たときのセッション」を紐付けること ができます。 またBugsnagやSentryといったエラートラッキングサービスとの連携も備えており、 エラーをキャッチした際にエラー内容とセッション情報にもとづいてカスタマーにメッセージを送るなど迅速なフォローもできるようになる と考えています。 ※ BugsnagとLogRocket連携イメージ 開発者のエラー・バグ調査が円滑になる 前述した通り、BugsnagやSentryといったエラートラッキングサービスとの連携によって、エラーが発生した際の行動を 見る ことができるので調査コストが下がります。 また、セッションの再現動画とともに、 ブラウザのデベロッパーコンソールのような機能も利用できるようになっており、コンソールログ、ネットワーク通信も見ること ができます。 本番環境ではコンソールログを出さないようにされていると思いますが、 カスタムログを送れる機能 もあったりするのでデバッグ情報などはそちらを利用するといいかもしれません。 UI/UX改善のための分析ができる これらのサービスには、 大量のセッション情報から、ユーザー属性や行動によってフィルタをかける機能 があります。 そのフィルタをかけたセグメントに対して様々な分析を行うことで、UI/UXの改善につなげていくことができます。 フィルタに利用できる要素は、「ユーザー識別情報」「訪問ページ」「要素クリック」「カスタムイベントの発火」etc...があり、複雑なフィルタも作ることができます(以下は例) 「/app/homeを訪問」かつ「button#transition-analytics-pageをクリック」かつ「RunDailyAnalyticsカスタムイベント発火」 「GoogleChrome」かつ「ログイン状態」かつ「エラー発生」 用意されている分析として代表的なものに「ファネル分析」と「ヒートマップ」があります。 ファネル分析 ファネル分析とは、目的のアクションを取るまでにユーザーがどれだけ離脱したかを可視化する手法です。 これにより、「ユーザー登録プロセスの離脱率」や「意図順序でページ遷移をしているか」などをユーザーセグメントによって比較するなどして改善していくことができます。 ユーザー識別情報やカスタムイベントなど、自由度が高いため、ファネル分析はできることが多そうに感じました。 ※ FullStoryのファネル分析機能 ヒートマップ ヒートマップとはユーザーのカーソルの動きやクリック数などを、Webページの上に色の強弱で表現したものです。 Web分析では定番のヒートマップですが、セッションリプレイと組み合わせることで、 「もしかすると押し間違えてるかもしれない」というヒートマップから出た仮説を、セッションリプレイをサンプリングすることで確証を得る ような使い方もできるかなと感じています。 その他 個人情報など隠せる お客様や契約によっては当然セッションを記録することが問題になる場合もあるかなと思います。 一部情報(個人情報やコンフィデンシャルな内容)をサービス側で記録しないようにできるため、状況に応じてそちらを対応し導入することも検討するとよさそうです。 (特定のclassがついているDOM要素は記録せず、マスキングするなどの機能がある) 料金 最大Session数によるプラン選択が多いですが、$100~$500/月 程度のようです。 Webサービスの定性面を評価したい場合は、少ないSession数でも価値があるのでサンプリングして導入するのもありかなと思っています。 (アナリティクス機能がメインであれば別のサービスのほうが適しているかなと感じています) まとめ ユーザーの行動ログを収集し、アクセスしたセッションでの操作を再現するSaaSについて紹介させていただきました。 なかなか導入事例は聞かないですが、これらサービスで提供するデータでカスタマーサポートや開発の効率が飛躍的に上がると感じています。 カスタムイベントやユーザー属性付与など拡張性もあるので、ABテストの効果測定などでも利用できるかなと思っています。 また、アナリティクスはUI/UXに基づいた分析が容易にできる印象があり、そういった改善でも効果を発揮しそうです。 このようなサービスを利用してよりよいアプリケーション、顧客体験を提供していきましょう！ (再三となりますが、今回どのサービスにどの機能があるかは明言していないので、導入検討する際は公式ドキュメントなど参考に改めて調査をお願いします)

こんにちは。スマートキャンプでエンジニアリングマネージャーをしている米元です。 本記事は スマートキャンプ Advent Calendar 2019 - Qiita の16日目の記事です。 皆さんの会社ではモブプログラミング、通称「モブプロ」をやっていますか？ 興味を持っている方は多いものの、 なんだか楽しそうだけど実際どんな効果があるのかわからない 効率悪くなりそうなので上司から許可が出ない などの理由でなかなか導入に踏み切れないケースが多いのではないでしょうか。 スマートキャンプでは数ヶ月前からスクラムを用いたアジャイルな開発プロセスを取り入れていますが、その一環としてモブプログラミングも導入しています。 tech.smartcamp.co.jp この記事では実際に数ヶ月間モブプロを実践してきたメンバー達にモブプログラミングのメリット・デメリットについてのアンケートを行い、その結果を赤裸々に書いていこうと思います。 なおモブ「プログラミング」だけでなくレビューや調査などの他の作業でも複数人で作業をすることがあるため、以下の文章では単に「 モブ 」もしくは「 モブワーク 」と記載している場合があります。 今までの会社やプロジェクトで、業務でのモブ経験はありましたか モブプロのメリット 情報共有、共通認識の形成 レビュー フロー効率 その他 モブプロのデメリット 複数人でやることによる集中力や意思決定の問題 作業内容によって時間効率が落ちる問題 スケジュールやモブへの出入りの問題 その他 印象的なエピソードがあれば教えてください（良いこと悪いこと両方） 良かったこと 悪かったこと モブプロをこれからも続けたいですか？ 改善したい点があれば教えてください 集中力について パフォーマンスについて モブと個人作業使い分けについて その他、改善のために必要なこと モブプロに対する感想をどうぞ！ 結果から分かった事 モブに適した作業はモブで行い、個人に適した作業は個人で行う（なんでもかんでもモブではやろうとしない） 環境を整える 何のためにモブをするのか、チームで認識を合わせる まとめ 今までの会社やプロジェクトで、業務でのモブ経験はありましたか ほとんどのメンバーが経験が無く、今回が始めてだったようです。 モブプロのメリット 情報共有、共通認識の形成 技術・知識の情報共有とそれによる作業効率の向上、チームで共通認識を作れる事に対する効果が多くあがっていました。 朝会の時間が短くなった 実際に手を動かす姿を見ることで新入りメンバーが作業する上での勘所を効率よく吸収できる。オンボーディングにもよい 知識共有、規約の共通認識 進捗も常に全体で共有できている 開発ラインが1つになるので、全体を通して何が動いているか？を全体で認識しやすくなる 集合知が取れること リスクがある部分を並行して検証できること チームの課題をすぐに発見・取り組めること レビュー レビューに関するメリットを上げている人も多かったです。 知らないプルリクが存在しなくなった レビューがないことでPRの放置がなくなる 口頭で共有しながら進められる、レビューがその場で即完了する レビュー工数が少なくなる、手戻りが少なくなる フロー効率 フロー効率についてあげているメンバーもいました ・フロー効率を意識できること。 後の「印象的なエピソードがあれば」とかぶりますが、モブでタスク消化しているものに関してはコーディングの後に軽く全員でレビューしてマージが即座に行われていきます。 そのため、レビューによって一つのタスクに対する作業者が変更になることがなく、それに伴う待ちも発生しません。割とレビューのやり取りによるストレスは結構あるので、それがないだけでメリットだと感じます。 その他 また、チームで作業することにより精神的な負担が和らぐケースもあるようです。 辛いタスクが少しだけ辛くなくなる(バグ調査とかは最適) モブプロのデメリット メリットだけでなくデメリットも多く感じているようです。 複数人でやることによる集中力や意思決定の問題 ナビゲーターはかんたんにオブザーバーになれるし、他のこともできるし、モブに参加しようという意思が参加者に必要。 人数が増えてくると発言する機会が少なくなり、集中力散漫になる 3人以上になると開発スピード落ちやすい(個々の集中力、発言機会、やることが低下する) いろんな解釈・意見があるようなタスクだと「船頭多くして船山に登る」といった状態になりかねない。 案外ミスを見逃す(誰かが見てくれてるだろうとか、細かい作業でみんなに見られてると思うと焦ってとかかな...) 作業内容によって時間効率が落ちる問題 参加者全員の時間を消費するので、簡単なタスクほど時間効率が落ちる 細かいリファクタリングなどは言葉でドライバーに伝えるのが難しく、もどかしさがある 個人でできるタスクをやるのは向いてないし、むしろ遅くなる スケジュールやモブへの出入りの問題 予定を合わせるのが難しい&一人になったときに作業が不明確になる メンバーが揃わず、入れ替わりになると、作業効率悪い 抜け時や入り時がわからない その他 個々人の達成感が削がれることがある（自分が書いたコードにアイデンティティを感じる場合など アウトプット量が減っていると感じることがある（プロセス指標を取っていないのでなんとも モブプロの業務ノウハウを持っていないため、何がよくて何が悪いか、それを判断するのが難しい 後に残らない情報が増えがち 普通に仕事するよりかはとても疲れる。 デメリットというよりまだまだベストプラクティスが見つかっていないというのが現状のようです。 印象的なエピソードがあれば教えてください（良いこと悪いこと両方） 良かったこと 開発チームだけでなく他部署とのモブワークのエピソードもありました。 マーケティングを担当しているメンバーとデザイナーとエンジニアチームで全員集まって技術検証をやったことがあった。お互いの知識を全部出しあい、検証ができて気持ちよかった。全員で集まることで情報の齟齬や「調整」「交渉」などが発生せずスムーズに進んだ。 他にも複数人でやることのメリットが感じられたエピソードとして以下のようなものがありました。 大きい変更作業をみんなで検討・実装することで認識共通化できて、作業やりやすいね！ってなった 難しい仕様を考えるとき、全員が考えるので軌道修正を細かく可能だった 面倒なドキュメント作成のタスクをモブで共同編集することで心理的な障壁を下げつつ効率よく完遂できた 悪かったこと 以下のように悪い面でのエピソードもありました。 全員でレビュー項目を漏らしたことがある デメリットにもあげられていた、人数が増えて注意力が散漫になってしまった時に発生したのかもしれませんね。 モブプロをこれからも続けたいですか？ 半分のメンバーは「どちらとも言えない」との意見でした。 これはメリット・デメリット両方感じていることと、今のモブプロのやり方が最適という訳ではないと感じている事からこのような結果になっているのだと思います。 改善したい点があれば教えてください 集中力について 全員がモブに集中できるような環境、作業を全員の脳で並列でやれている感覚を持てるような方法を見つけたい。 全員が集中して短時間で効率的・高成果なモブにしたい 長時間やると意識が分散しがちなところ パフォーマンスについて パフォーマンスを高めるために モブ自体のやり方改善(ドライバー以外の立ち振舞いなど) ペアプロや個人作業時間の確保 チームの人数が増えても開発速度が上がらない、3~4人いると持て余しがち モブと個人作業使い分けについて モブの使用すべき箇所の定義をしっかりして、個人作業でできるものを分離していきたい その他、改善のために必要なこと モブによるメリット・デメリットを定量的に図れるようにしていきたい。その上で改善策を練れるようにしたい。 正直なところ、チームで改善することに限界を感じてます。こういう方向に向かうと明確に示してあげられる人がいないとモブプロの改善はこれ以上進んでいかないだろうなと。そういった点で、経験・知見のある方を招聘した上で、実業務で一緒にモブプロをしてもらい、こういう形だとめっちゃアウトプット出てるよね！って言えるようにしたいです。 モブプロに対する感想をどうぞ！ 良さを感じている人、楽しい人、難しさを感じている人など様々でした！ モブが当たり前になってきたここからがスタートですね。 純粋にワイワイ開発するのは楽しいのでモブは好きです 月・火・水を個人 or ペアで進めて、木・金をモブはパフォーマンスよい。重めのタスクは月・火・水でもモブを柔軟にまぜる 思ったよりもパフォーマンスは落ちない(レビュー工数やバグ率)けど、ちゃんとやらないとそこそこパフォーマンス落ちる。基本的には楽しい チームを選ぶプラクティスだなと感じてます。結構取り入れてから時間経ってみんなの中でフロー効率に対する意識が体に染み付いているような気もするので、ちょっとずつモブでやる範囲を減らしても良いのかなとは思います。 やり辛さも多々あるが、メリットも多い！慣れやベストなやり方にたどり着くのがとても難しい。 必要ならやればいいし、必要なければやらなくていいものだと思う 基本的には好印象です！手段の1つとしてうまく使い分けができるのが良いと思うので、メリデメを明確にした上で、使い分けられる用になるべきかな？と考えてます。 結果から分かった事 数ヶ月間、実際にチームで実践してみて様々なメリット・デメリットがあることが分かりました。 私が実際にメンバーから意見を聞いたり、このアンケート結果を読んでモブを円滑に進めるために必要だと感じたポイントは以下の3つです。 モブに適した作業はモブで行い、個人に適した作業は個人で行う（なんでもかんでもモブではやろうとしない） モブプロには前述したように 情報・知識・技術の共有 フロー効率が上がる などのメリットがありますが、作業内容や進め方によってはデメリットがあることも分かりました。 そもそもモブに向いてない作業（誰がやっても同じ結果になるもの、定型化した作業など）は個人でやるなど、作業内容によって使い分けるのが良さそうです。 環境を整える 弊社の場合、メンバーが開発とは別の会議（他部署との会議、エンジニアのMeetupの運営会議、ブログ運営の会議など）に参加してモブを抜けたり、そもそも最初からいなかったりする場合があり、モブの実施自体がうまく出来ない事が何度かありました。 メンバーが同じ時間に作業が出来るようにメンバーや他部署の人にも協力してもらって会議のスケジュールを調整するなどの工夫が必要だと感じました。 実際に定例系の会議についてはメンバーが被らないようにしたうえで同じ時間帯に実施するように調整中です。 また、現在はモブがしやすいように大型のディスプレイやドライバーの変更時にPC切替えがスムーズに出来るように購入したりするなどハード面での環境の整備をしていますが、これらによってモブワーク時のストレスを取り除く事も重要な要素であると感じました。 何のためにモブをするのか、チームで認識を合わせる 1とも被りますが、作業内容やプロジェクトの状況・メンバーの志向性・チームの状況などによっても、モブでやるべきではない事もあるでしょう。 モブをすることに拘って作業効率が下がったり、メンバーの不満が溜まっては本末転倒です。 最初はまずやってみるところから始めるのが良いと思いますが、ある程度やってみてからは改めてチームで振り返りを行い、そもそもモブワークに何を求めるのか、何の目的で行うのかを認識を合わせたうえで進めていくのが良さそうです。 まとめ 以上、弊社で実践してみて分かった事をまとめてみました。 これから導入を検討している方や導入したもののうまく進められていない方に少しでも参考になれば幸いです。 個人的には、「モブプロ最高！」のような結果ではなく、課題や改善点もしっかり出してくるところがスマートキャンプのエンジニアらしいなと思いました。 今後は社外の知見のある方にも頼りながら、モブワークの練度を上げつつ目的に応じて実施するかどうかを決めていくようなスタイルになっていきそうです。 さらに詳細を聞いてみたい、実際にモブを体験してみたいという方がいればぜひ弊社オフィスまで遊びに来てください！ hrmos.co 次回のAdvent Calendarは瀧川によるfullstoryとlogrocketについての記事です。お楽しみに！ qiita.com

こんにちは、スマートキャンプでエンジニアをやっている徳田( @haze_it_ac )です。 12月14日(土)に開催された 平成Ruby会議 01 にスポンサーとして参加してきたお話です。 heiseirb.github.io ※ 本記事は スマートキャンプ Advent Calendar 2019 - Qiita の15日目の記事です。 平成Ruby会議 01について heiseirb.connpass.com 平成生まれのRubyエンジニアが集まる 平成.rb - connpass のコミュニティが開催する、各世代で交流ができるRubyのカンファレンスです。 今回の内容としてはキーノートが2つ、15分のセッションが2トラック、及びスポンサー企業LTと飛び込みLT、懇親会となっていました。 なぜスマートキャンプが平成Ruby会議のスポンサーをするのか スマートキャンプでは創業当初からRubyやRuby on Railsが使われており、現在でも弊社のエンジニアは全員がRubyを使ってサービス開発を行っています。 そして、そのRubyを盛り上げるコミュニティや開発者に対して感謝をしています。 そのわたしたちがRubyコミュニティに還元する方法のひとつとして、平成Ruby会議へスポンサーをさせていただきました！ スポンサーとしてやったこと スポンサーとしてドリンクを購入し会場に配達依頼をするところまでと、 メインセッション終了後のスポンサー企業 LT タイムで 5分のスポンサーLTをさせていただきました。 ドリンクの購入 普通にカクヤスで購入し、会場のドリコムさん宛に配達しました。 ハイボール、チューハイ、ソフトドリンク、お茶、日本酒(!)を提供させていただきました！ スポンサーLT 2019.12.14 平成Ruby会議 01 スマートキャンプ スポンサーLT資料 - Speaker Deck 普通に会社紹介しても面白くないだろう と思ったので、赤裸々に今やっていること、これからやろうとしていることをお話しさせていただきました。 スポンサーLTとは思えないどよめき(?)と盛り上がりがあり、良かったです。 懇親会でもたくさんの方とこのLTにかかわるお話をさせていただき、とても嬉しかったです！ありがとうございました。 最後に載せているエンジニアのアンケートはこちらの記事からの抜粋です。 tech.smartcamp.co.jp スマートキャンプではRubyが好きなエンジニアを募集しています スライドにも書いてありますが、BOXIL開発チーム、Biscuet開発チームではRubyが好きなエンジニアを募集しています！ hrmos.co 次回のAdvent Calendarはマネージャの米元による "モブプロしてるみんなにインタビューして良いところ悪いところ書く" です、おたのしみに！ qiita.com 最後になりますが、今回の平成Ruby会議の運営をしてくださったスタッフ、スポンサー企業の皆様、そして参加者の方々、とても楽しいカンファレンスを開催していただきありがとうございました！

スマートキャンプのエンジニア入山です。 本記事は スマートキャンプ Advent Calendar 2019 - Qiita の13日目の記事です。 qiita.com スマートキャンプにおける新規プロダクトの基盤としてKubernetes（k8s）を導入してから、早いもので１年が経過しました。 また、Amazon EKSの東京リージョンがリリースされてからも、もう少しで１年になります！ この1年間でk8sやEKSは大幅にアップデートされており、EKSではサーバーレス運用が可能となるFargate for EKSが１２月３日に発表されるなど、k8s運用の選択肢も増えてきています。最近では導入事例や技術ネタを多く目にするようになりましたが、k8s導入のハードルはまだまだ高いイメージがあるのではないでしょうか？ 以前、以下の記事でノンマネージドk8sの環境構築方法を紹介しましたが、マネージド（EKS）ではもっと簡単に環境構築が可能です！（今見直すとノンマネージドのk8s構築って大変です…） tech.smartcamp.co.jp EKSの環境構築にはいくつか方法がありますが、その中でもシンプル＆簡単なeksctlを使ってEKS環境構築をする方法を紹介します！ eksctlとは eksctlで作成されるもの eksctlでのEKS環境構築 事前準備 eksctlのインストール EKSクラスタの作成 作成されたEKSクラスタの確認 EKSクラスタの削除 最後に eksctlとは eksctlは、EKSクラスタを構築するためのCLIツールで、基本的なEKSクラスタを1コマンドで作成することができます。 AWSの各リソースはCloudFormationを使用して作成する仕様となっており、Goで開発されています。 リソースがない状態からの新規構築だけでなく、既存リソース（VPCなど）が存在する場合もそれらを利用して EKS クラスタを作成することができます。 eksctl eksctl の開始方法 - Amazon EKS eksctlで作成されるもの eksctlにおまかせして新規EKSクラスタを作成した場合、 Amazon EKS アーキテクチャ - クイックスタート で紹介されているアーキテクチャ（以下図）に従った構成で各リソースがAWS上に構築されます。 eksctlでのEKS環境構築 事前準備 以下は、事前に準備が必要です。今回は説明を省略します。 AWS CLIのインストール AWS CLIの認証情報設定(IAMユーザー作成とprofile設定) kubectlのインストール eksctlのインストール 最初にeksctlをインストールします。 また、今回の内容は以下のバージョンで実施しています。 $ brew install weaveworks/tap/eksctl $ eksctl version [ℹ] version.Info{BuiltAt:"", GitCommit:"", GitTag:"0.11.1"} EKSクラスタの作成 早速EKSクラスタの作成に入るのですが、基本的に以下のコマンドを1つを実行するだけでCloudFormationのスタックが作成され、EKSの各リソースが作成されます。 $ eksctl create cluster ただ、デフォルトでは、リージョンがus-west-2であったり、インスタンスがm5.largeとなっているため、いくつかのオプションを指定して実行します。（必要に応じてオプション設定値は変更してください） $ eksctl create cluster \ --vpc-cidr 10.0.0.0/16 \ --name eks-sample \ --region ap-northeast-1 \ --version 1.14 \ --nodegroup-name sample-workers \ --node-type t2.small \ --nodes 1 \ --nodes-min 1 \ --nodes-max 3 \ --managed また、既存のサブネットに作成する場合は、以下のオプションで既存サブネットを指定します。 --vpc-private-subnets=subnet-xxxxxxxx,subnet-xxxxxxxx \ --vpc-public-subnets=subnet-xxxxxxxx,subnet-xxxxxxxx ※既存に作成する場合は、private * 2、public * 2のサブネット指定が必要です その他のオプションや詳細は、以下のコマンドで確認できます。 eksctl create cluster --help コマンドを実行すると、EKSクラスタの構築が始まります。 作成されたEKSクラスタの確認 eksctlでは、EKSコントロールプレーンとの通信に必要なKUBECONFIGも自動で生成してくれるため、eksctlの実行後すぐにkubectlによるEKSクラスタの操作が可能です。 $ eksctl get cluster NAME REGION eks-sample ap-northeast-1 $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 172.20.0.1 <none> 443/TCP 10m $ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-10-0-0-130.ap-northeast-1.compute.internal Ready <none> 5m v1.14.7-eks-1861c5 EKSクラスタとオプションで指定した通りにEKSノードが1つ作成されたことが確認できました！ EKSクラスタの削除 作成した全てのリソースを削除する場合は、以下のコマンドを実行します。 $ eksctl delete cluster \ --name eks-sample \ --wait 最後に eksctlを使うことでEKSクラスタを1コマンドで簡単に作成することができます。 今回は省略しましたが、YAML形式のファイルに構成を定義することで構築する環境の詳細な指定や、EKSクラスタの管理もできます。 運用面の課題はありますが、環境構築のハードルが下がるだけでも、EKSが試しやすくなるのではないでしょうか。 また、運用面についてもEKSの機能追加によってハードルが下がってきているので、今後の更なる機能追加が楽しみです！ 明日は弊社エンジニア瀧川の記事です！お楽しみに！

こんにちは！スマートキャンプで20卒の内定者インターンをしている、ジョニーこと高砂です。 本記事は「 スマートキャンプ Advent Calendar 2019 - Qiita 」の11日目の記事です。 私は主に Biscuet という営業効率化ツールの開発に携わっています。 プログラミング初心者としてインターンを始め、週2のペースで10ヶ月程続けてきました。 その中でメンターから学んだことを思い返して、本記事ではその中でも特に印象に残った10個を会話形式で紹介していきます！ 開発の進め方について 一行ずつ全て理解しながらコードを読もう 調べる時は3つのソースから 説明する時は専門用語を使って 開発期間の見積もりが甘い プログラミングについて 範囲を区切ってコーディングしよう 関数名・変数名は内容と一致するように 関数一つの役割は一つに 学習方法について まずは実務をやって課題を見つけたら本を読む 「分かった」は気軽に言わない 話せるまで理解しよう まとめ 開発の進め方について 一行ずつ全て理解しながらコードを読もう Biscuet全体のコードの繋がり方を上手く追えず、メンターに相談した時の話です。 私「このコードがデータをどう処理しているのか分かりません…」 メンター「なるほど、この一文はどこを参照してる？」 私「えっと、多分DBのこのテーブルです」 メンター「本当に？何でそう考えたの？」 私「え、関数名的にそこかな、と…」 私「あ、でもいま下のコードをよく読んだら別のテーブルでした！」 メンター「うん、高砂はコードの流れをなんとなくで追ってしまっているね」 私「確かに…一文ずつ丁寧に読むべきですね！」 調べる時は3つのソースから 新しい関数を作ろうとしたものの上手く動かず、メンターに相談した時の話です。 私「ソート機能を実装したくて、調べて出てきた記事を基に書いたんですが…」 メンター「この書き方で合ってるの？」 私「うーん、記事の通りに書けてると思います」 メンター「公式ドキュメントも読んでみようか」 私「はい！…あれ、記法が微妙に異なりますね」 メンター「おそらく環境によって変わるんだろうね」 私「本当だ、こっちなら動きました！」 メンター「記事の内容が必ずしも正しいとは限らないよ」 メンター「基本は公式ドキュメント、本、記事の最低3ソースで確認するくらいが良いね」 説明する時は専門用語を使って 実装内容をメンターに説明する時の話です。 私「この部分は画面の上部に表示させたくて、このような実装にしました」 メンター「うーん、画面の上部ってどこを指してる？」 私「あ、パンくずリストの事です」 メンター「だったらそういう風に専門用語で言ったほうがすぐ伝わるよ」 私「そうか、分かりやすくしようと必要以上に平易な言葉で話していました…」 メンター「専門外の人に対してはその意識は大事」 メンター「でも僕らの会話では的確に専門用語を使おう！」 開発期間の見積もりが甘い メンターにタスクの進捗報告をしている時の話です。 私「今日までに完了する予定でしたが、あと3日かかりそうです…」 メンター「うーん、何で見積もりより遅れたの？」 私「API作成が想定より大変だったのと、風邪で数日休んだからですね…」 メンター「それは全体的に見積もりが甘いかな…」 メンター「前者についてはタスクを細かく分解して工数を予測するのが大事」 メンター「後者はイレギュラーケースも考慮して長めに期間を決めると良いね」 私「なるほど…間に合わないよりは早く完了した方が良いですもんね！」 プログラミングについて 範囲を区切ってコーディングしよう 新しいプログラムを作ろうとしたものの、フロント〜バック〜データベースの流れを追いきれなくなってメンターに相談した時の話です。 私「現時点でどこの機能まで出来たか分からなくなってしまいました…」 メンター「それは一度に作ろうとしている範囲が大きすぎるからだね」 メンター「いきなりシーケンシャルにコーディングするのは難しい」 メンター「まずはフロントだけ、のように区切って開発すると良いよ」 私「確かにそれなら混乱せずに作りきれそうですね！」 関数名・変数名は内容と一致するように 個人開発した社内向けツールをメンターにリファクタリングして貰った時の話です。 メンター「ここの changeUser(user) って関数は名前はユーザーを変更してそうだけど、中身はユーザーの投稿内容の変更だよね」 私「はい、ユーザーに関する変更だからそれで良いかと思ってました！」 メンター「関数名や変数名は、原則それだけで役割が分かるようにしたい」 メンター「今回だと changeContentOnPost(user) のように具体的な方が良いよ」 私「確かにそのほうがわかりやすいですね！」 関数一つの役割は一つに 上記と同様のリファクタリングの時の話です。 メンター「この displayFilteredPosts はユーザーの投稿のうちフィルターに合致するものを表示する関数かな？」 私「そうです！」 メンター「一つの関数に対して役割が多いな…」 メンター「例えばこれは displayPosts と filterPosts に分けた方が良いね」 メンター「一つの関数は一つの役割に限定した方が、読みやすいし再利用性も高まるよ」 私「なるほど！そしたら別の場面でも使えそうです」 学習方法について まずは実務をやって課題を見つけたら本を読む 何の本で勉強した方が良いかについてメンターに相談した時の話です。 私「どの本を読もうか迷ってるんですが、何かオススメはありますか？」 メンター「そうだなぁ、高砂は何で勉強しようと思ってるの？」 私「えっ、それはもちろん開発のスピードを上げたいからです」 メンター「だったらそれを阻害する部分の勉強をすれば良いんじゃない？」 メンター「慣れたら課題になりそうな分野を先読みして学習する事も出来る」 メンター「でも今は素直にいつも分からなくなる分野の本を読めばいいよ」 私「なるほど！ではRubyの文法の本から読んでみます」 「分かった」は気軽に言わない 新しいライブラリを導入するタスクをメンターに任された時の話です。 私「事前に勉強したのでこのライブラリの事は大体分かりました！」 メンター「お、じゃあとりあえず一つ画面を作ってみて」 私「はい！」 私「…あれ、上手く動かない」 メンター「うーん、サンプルも作れないと『分かった』とは言えないよね」 メンター「あと完全に理解するのは不可能だから、どこまでなにが理解できたかを伝えた方が良いよ」 私「了解です…もっと丁寧に勉強してきます！」 話せるまで理解しよう 上記を踏まえて、ライブラリの調査の最中にメンターに疑問点を話しました。 私「ライブラリの調査はどの位までやればいいんですか？」 メンター「そうだなぁ…例えばこの部分はどうやって表示してるの？」 私「ここはさっき調べました！」 私「えっと…あれ、どこのコードが影響してるのか分かってなかったです」 メンター「だとするともう少し調査が必要だね！」 メンター「何度か顧みて他の人に説明できるかどうかを目安にすると良いよ」 まとめ 一行ずつ全て理解しながらコードを読もう 調べる時は3つのソースから 説明する時は専門用語を使って 開発期間の見積もりが甘い 範囲を区切ってコーディングしよう 関数名・変数名は内容と一致するように 関数一つの役割は一つに まずは実務をやって課題を見つけたら本を読む 「分かった」は気軽に言えない 話せるまで理解しよう 以上10個が、本記事で紹介した愛のムチです。 私は情報学部出身ではなく、しばらく独学で開発を行っていました。 その為「どう書くと他の人に分かりやすいか」や「どうすれば効率的に開発できるか」を考えた経験が無く、チーム開発に参加した当初はそのような考え方を知るところから始めなければなりませんでした…。 そんな中、インターンを通じて指摘されたたくさんの内容（全てノートにメモっています）を出来る限り意識し開発を行うことで、今はだいぶ一人前のエンジニアに近付けたかなと自信を持てています！ 明日は弊社デザイナー高松の記事です！お楽しみに！ qiita.com

スマートキャンプエンジニアの今川です。 この記事は スマートキャンプ Advent Calendar 2019 - Qiita 10日目の記事です。 qiita.com 別のネタで書こうと思っていましたが、ちょうど昨日今日で AWS5年やってたのに誤解してた！ という経験をしたのでそれについて忘備録＆人に共有するためにもまとめます。 T2 Unlimitedって何が嬉しいの？ という方には読んでいただきたいです。 t2インスタンス - バースト可能なインスタンスタイプ AWS EC2には t2 という安価なインスタンスタイプ群があります。 aws.amazon.com ベースラインから必要に応じてバースト可能な汎用インスタンスタイプ という見出しがついており、 オンデマンドインスタンスの価格は 1 時間あたり 0.0058 USD から開始され、T2 インスタンスは最も安価な Amazon EC2 インスタンスオプションの 1 つであり、マイクロサービス、低レイテンシーのインタラクティブアプリケーション、中小規模のデータベースなどのさまざまな汎用アプリケーションに最適です。 という説明がついています。 普段t2系インスタンスを利用されている方や初めて知った方はどうイメージしたでしょうか？ 普段は弱いけど、必要なときはパワーアップできる という印象を持ったかと思います。私も 4,5年そう思っていました。だからこそ、 常に高負荷になるアプリケーションには不向き ユーザからのリクエストのピークタイムが決まっているようなWebアプリケーションなどには向いている といった用途に向いている、という理解になるかと思っています これは正解ではありますが、間違っています。 というのも、「一時的にパワーアップできる」という理解をするとT2 Unlimitedを使うべきタイミングやメトリクスをみて状況を正しく理解できなくなると思われます。 CPUクレジットとは何なのか？ ではT2系で動くCPUクレジットなるものは何なのでしょう？ docs.aws.amazon.com 1 個の CPU クレジットは、1 台の vCPU を使用率 100% で 1 分間実行することに相当します。 これに尽きます。パワーアップという概念はなくただ単に「CPUを1分100%で動かすとCPUクレジットを1消費する」というだけです。 その他の vCPU、使用率、時間数の組み合わせを CPU クレジットと同じにすることができます。たとえば、1 個の CPU クレジットは 1 台の vCPU を使用率 50% で 2 分間実行するか、または 2 台の vCPU を使用率 25% で 2 分間実行するのと等しくなります。 上記のページにも書いてありますが、CPUクレジットの会計単位は ミリ秒単位 であるし、CPU複数個にまたがって消費することもできます。 CloudWatchで CPUUtilization のメトリクスを見ると、上限は100%ですが、コア全部が100%のときにMAX100%になる計算であるため、 CPUUtilization * コア数分が実際のCPU使用率になります。 すなわち、CPUクレジットは CPUUtilization [%] * コア数 * 時間 [分] でつねに消費されることになります。 上図はある24時間におけるAWS EC2 t2.largeインスタンス(vCPUが2コア)のCPUUtilizationとCPUCreditUsageをCloudWatchでグラフ化したものです。 CPUUtilization[%]の値域は[0, 75]、CPUCreditUsageの値域を[0, 7.5]にすると波形がほぼ一致します。 CPUCreditUsageの値は5分の和が表示されている（下記リンク参考）ようなので、以下の式が成り立ちます CPUCreditUsage * 2 [コア] * 5[分] = CPUCreditUsage * 10 = CPUUtilization[%] docs.aws.amazon.com これがCPUクレジットの使われ方です。 ではベースラインパフォーマンスとは何なのか？ CPUクレジットは各インスタンスタイプによって決まった速度で付与されていきます。たとえば、t2.largeは1時間にCPUクレジットが36付与されます。1分あたり0.4が付与されることになります。毎月もらえるおこづかいのようなものですね。 上記の通り、CPUクレジット1つで1分1コア100%を維持できます。もらった分より、消費する分が少なければ CPUCreditBalance として貯めることができます。 では、もらった分より、消費する分が多いときはどうなるでしょうか？ もらった分より足りない分は CPUCreditBalance が残っていればそこから捻出することができます。 CPUCreditBalance がないときは、付与された分について使い尽くしてしまいます。足りない分はCPUを動かせなくなります。 たとえば、 CPUCreditBalance がないときはt2.largeにおいては1分あたり0.4しかもらえないので、1分間に1コア40%分だけしか動かすことができません。実はこれが ベースラインパフォーマンス というものです。 ドキュメントを見るとt2.largeにおける ベースラインパフォーマンス は20%となっていますが、2コアフルパワーの20%なので1コア40%分です。この値は上記のCPUCreditBalanceの話と一致します。 ベースラインパフォーマンスというのは付与されるCPUクレジットに全く余裕がない時に起きる下限のCPU使用率のことでした。CPUCreditBalanceを使いまくるほど処理が多い状況だとCPUCreditBalanceが0になった瞬間に出力がおいつかなくなるようになってしまうということでした。 T2 Unlimitedを有効にすると起きること ではCPUクレジットが足りない！今すぐ欲しい！というとき、何ができるのでしょうか。付与は以下のタイミングで行われます。 時間による付与（先述） インスタンス起動時に一定数付与される これ以外でCPUクレジットをより使いたい場合、 T2 Unlimited を有効化するという方法があります。 CPUクレジットという仕組みは貯めたり消費したりすることによって「ピーク時もアイドル時も負荷をベースラインパフォーマンスに均して考えること」を可能にします。他の汎用インスタンスファミリであるM系などでは「常に一定の負荷がかかること」を前提にしているため、ピークが一定で、アイドルタイムが長い用途と勿体なくなってしまいます。 T2 Unlimited はCPUクレジットの 前借り と 追加購入 が可能になります。普通にしていると、ベースラインパフォーマンス以上の性能をあげようとするとCPUCreditBalanceが必要になります。T2 Unlimitedが有効になっているときは「その1日中で得られる合計のCPUクレジット」と「その日中に使ったCPUクレジット」の比較で計算することができ、そのタイミングにCPUCreditBalanceがなくても必要なパフォーマンスを出せるようになります。 docs.aws.amazon.com 上記のドキュメントにある図です。実線で表されているCPU使用率のグラフの面積を均したとき、ベースラインパフォーマンスである点線の30%以下になれば問題ないのですが、実際は点線を超えて紫線の値、1日で40%分になった場合、 差分の10%分のvCPU分については課金されてしまう という仕組みです。 その上で、「その日中に使ったCPUクレジット」で赤字になってしまった分についてのみ、1時間のvCPU100%単位で課金されるという仕組みです。 UnlimitedはEC2コンソールでかんたんに有効化/無効化を切り替えることができます。 T2 Unlimitedでどれだけ前借りしているのか？どれぐらい足りなくなってしまっているか？についてはメトリクスが用意されています。以下の2つのメトリクスはT2 Unlimitedを有効にすると計測されるようになります。 CPUSurplusCreditBalance CPUCreditBalance が0のときに消費したCPUクレジット 上限は1時間あたりに付与されるCPUクレジット☓24の値 CPUSurplusCreditsCharged - CPUCreditBalance が0のときに消費したCPUクレジットで、課金対象になっているもの 前借り という言葉で紹介したとおり「これからはいる収入をあてにして動かすことを可能にしている」部分があるため、やめるタイミングも重要です。 CPUSurplusCreditsCharged が増えるタイミングが3つあります。 24時間分で得られるCPUクレジットに対して、消費したCPUクレジットのほうが多くなったとき（24時間が過ぎたあとに不足分のみ精算） インスタンスのstopやshutdown時は CPUSurplusCreditBalance が CPUSurplusCreditsCharged になる Unlimitedを無効化したときも CPUSurplusCreditBalance が CPUSurplusCreditsCharged になる 前借りしたままT2 Unlimitedを無効にせず、様子をみて前借り分を返済してから無効にしたほうがよさそうです。 こちらは以下の記事で理解できました。(ありがとうございます！) dev.classmethod.jp 一方で常に前借りしたり常に不足分を課金し続けるのはもったいないので、ほかのインスタンスタイプに変更することのを考慮にいれることも選択肢にいれてみましょう。 上で紹介したページに 損益分岐点を求める計算式 があるため、それを参考にしてみてください。 T3系について 最近はT3インスタンスファミリーも登場しました。T2より数字が増えているから なにか新しいからこっちのほうが断然いいんじゃない？ と思う方もいるかと思います。 aws.amazon.com 実際その通りで、パフォーマンス部分での改善がなされていますが、T2との大きな違いとして Unlimitedがデフォルトでオン になっていることがあります。 知らない間に不足分のCPUクレジットについて課金されないよう注意しましょう。 最後に あるときCPU負荷が上がらない割にWebサーバのレイテンシが増大したことがありました。その時、ちょうどこのことを思い出して確認したところ、CPUCreditBalanceが完全に枯渇してしまっていました。そこはUnlimitedを有効にして難を逃れました。 T2系インスタンスの特性を理解することで、非常時には勇気と自信を持ってUnlimitedを有効化できます。T2系を使っているかたはたまにCPUクレジットの存在を思い出してあげてくださいね。 明日は20卒内定者としてインターンをしているジョニーくんが 20卒内定者インターン生が社員から頂いた愛のムチ について書いてくれます。楽しみですね！

スマートキャンプのエンジニア井上です！ 本記事は「 スマートキャンプ Advent Calendar 2019 - Qiita 」の9日目の記事です。 先日、 B2B SaaSエンジニアMeetup - Sharing Issues というイベントを弊社で開催させていただきました。 今回は今年1年でやりきったこと・反省点、来年こそは○○するぞ！というテーマで開催しました！ 忘年会ということもあり、ビールを片手に課題を語り・聞くという不思議で楽しい会でした 笑 参加者も前回に引き続き 40名強 もの方にお越しいただき、とても充実した会でした！ 私も主催者でありながら、ただの１参加者として発表に聞き入ってしまい、途中司会業を忘れかけるようなこともありましたが、無事イベントは盛況のうちに終わりました。 このSharing Issuesというイベントをどのよう意味で作ったかは下記で紹介しています。 tech.smartcamp.co.jp 今回も前回と同様どのような登壇内容だったかイベントレポートを書いてみました！ 前回の内容はこちら tech.smartcamp.co.jp 「2019年のANDPADの開発を振り返る」 株式会社オクト VPoE 下司さん 感想 「Gitでのチャットコミュニケーション」 株式会社マネーフォワード 内西さん 概要 感想 Anyflow株式会社 CEO 坂本さん 概要 感想 「ドキュメントを 組み込んだ 開発プロセス」株式会社スマートキャンプ 徳田 概要 感想 「ミニマムで始める承認フロー設計」A1A株式会社 曽根田さん 概要 感想 「顧客の要望を消化する開発から脱却して本質的な課題を探す開発へ」株式会社ヒューマンキャピタルテクノロジー CTO 鹿島さん 概要 感想 「特別対応をするのか、仕様を守るのか」クレコンリサーチ＆コンサルティング株式会社 三内さん 概要 感想 株式会社ビットジャーニー 代表取締役 井原さん 感想 「SaaS1年生の私達がたどり着いたプロダクト開発の進め方」株式会社オープンエイト 取締役 古山さん 概要 感想 全体通して 「2019年のANDPADの開発を振り返る」 株式会社オクト VPoE 下司さん 感想 開発チームのアウトプットとして登壇を多くしようという試みについて語っていただきました。 うちも、どんどんアウトプットしていきたいと感じた刺激になる内容でした！ 「Gitでのチャットコミュニケーション」 株式会社マネーフォワード 内西さん speakerdeck.com 概要 チャットコミュニケーションがなぜ大切なのか？ みんな褒めあったほうが楽しい 他の人が見る２度手間を省く 実践していること わからないことは聞く 確認したいこと残す　 常に感謝の気持ちは忘れない わからないことは聞く 自分がわからないことは他のレビュワーもわからない　 確認したいことは残す レビュー時間を短縮したい 見るだけでわかりやすいレポートを残す 常に感謝の気持ちは忘れない 時間をさいてレビューしてもらってる レビューしてもらえるのは嬉しい 感謝の気持ちは伝えるべ き 感想 チャットでのコミュニケーションは必要事項を伝えて終わりになりがちですが、感謝や配慮をすることでチャット上でも有意義で楽しいコミュニケーションがとれるという貴重な学びがある発表でした。 Anyflow株式会社 CEO 坂本さん 概要 AnyflowProduct紹介 Anyflowエンジニア紹介 感想 急遽、 CEO 坂本さんに登壇していただきました！ Anyflowというプロダクトがどのようなものを解決するか、エンジニアとしてどんな人が働いているかを紹介していただきました！ 「ドキュメントを 組み込んだ 開発プロセス」株式会社スマートキャンプ 徳田 drive.google.com 概要 ドキュメントを組み込むとは？ ドキュメントをもとに意思決定する仕組みを構築する PRDとは？ DesingDocとは？ ドキュメントの意義 必要なものを正しく作れる PRDをPdMが確認することで仕様漏れをふせぐ 正しい情報を未来に残せる PRDにより仕様の意図を DesingDocにより設計の意図を 感想 PRD、DesignDocがどのようにくみこまれるか、そして、なぜ必要なのかをわかりやすく説明してもらいました。 コミュニケーションコストを減らす手段として有効だなとあらためて感じました！ 「ミニマムで始める承認フロー設計」A1A株式会社 曽根田さん speakerdeck.com 概要 RFQについて -BtoBSaaSのあるある機能 承認ワークフロー機能について BtoCであまり経験しない機能の１つ 承認ワークフローの概念について RFQにおける承認ワークフロー機能について 要求 最初に犯した3つの失敗 最初に犯した間違えた設計 失敗から生じる辛さ 承認ワークフロー機能を満たすための設計 まとめ 感想 承認系の処理はその場は良い実装にみえても、後々を考えると多様な権限が増え、負の遺産ができがちです。 自分も実装するときはすごく考えるところなので、共感しかありませんでした。 「顧客の要望を消化する開発から脱却して本質的な課題を探す開発へ」株式会社ヒューマンキャピタルテクノロジー CTO 鹿島さん 顧客の要望を消化する 開発からの脱却 B2B SaaS Engineer Meetup -sharing issue- #2 from 隆雄 鹿島 www.slideshare.net 概要 大量に寄せられる顧客要望 開発責任者として参画したエンジニアの私 要望溜まってる 対応したら複雑な方にしか機能が進化しない 作ったのに使われていない そこで課題の抽象化 顧客の課題集め KPIベースでの改善が回るように 次なる問題 ステークホルダーの課題が合わない 開発が見てる課題はごく一部 主要メンバーの目線合わせ 課題の目線合わせ合宿 事業で合意した課題がリストアップされるように 感想 ユーザーの課題や言われたとおり作った機能で要求が満たされるかはあるある話でとても共感できる話でした。 その対策として合宿を行ってしっかり目線をあわせに行く行動力が印象的でした。 「特別対応をするのか、仕様を守るのか」クレコンリサーチ＆コンサルティング株式会社 三内さん 概要 顧客からの要望を分類しました 製品の標準機能であってもいいが全社は使わない要望 その顧客限定の機能要望を受けた場合 製品の標準機能であってもいいが全社は使わない要望を受けた 個人的結論 製品の仕様は心を鬼にして守るべき それでも特別対応になる場合はある 感想 様々な要望を受けるエンジニアとして最後の砦となってプロダクトを守るという考え方はとても共感できるものでした！ 株式会社ビットジャーニー 代表取締役 井原さん 感想 つらい経験をしながらも前向きに捉えながら進んでいきサービスを成長させていく話をしていただき、自分も楽しく話を聞きながらとても刺激になりました。 「SaaS1年生の私達がたどり着いたプロダクト開発の進め方」株式会社オープンエイト 取締役 古山さん speakerdeck.com 概要 チーム編成 開発手法 プロダクトロードマップ UI・UX改善 開発フローについて リリースされたプロダクト評価について 感想 現在のフェーズにおけるプロダクトロードマップの考え方や、開発の流れ・それぞれの業種ごとの声をいかに拾うかなど、勉強になる話がとても多い内容でした。 全体通して 今年1年でやりきったこと・反省点、来年こそは○○するぞ！というテーマで開催しましたが、それぞれ、改善したいことや良くしたことなどで似てるけど違う課題や解決方法があり、とても有意義な時間でした！ 次回も多くの課題と解決方法をシェアする場所として続けていきたいと思います。 次は2月開催を目指しています！ 次回のスマートキャンプ Advent Calendarはなうりばこと今川の記事です！お楽しみに！ qiita.com

こんにちは。スマートキャンプでエンジニアリングマネージャーをしている米元です。 本記事は 「 スマートキャンプ Advent Calendar 2019 - Qiita 」 「 Engineering Manager vol.2 Advent Calendar 2019 - Qiita 」 の8日目の記事です。 昨年の10月に私が開発チームのマネージャーになってから1年と1ヶ月が経ちました。 今回はこの約1年間を YWT形式 で振り返っていこうと思います。 Y: やったこと チーム分け チームビルディング 1on1 最近のワイ チーム文化作り PR 育休をとった 開発リーダーの引継ぎ ビジネス職の新卒へのエンジニア研修 採用 エンジニア採用の立て直し、採用活動全体の再構築 新卒採用の開始 技術顧問 EM系のイベントに参加 メンバーがやってくれたこと エンジニアブログ 開発合宿 アジャイルコーチ イベントの開催 W: 分かったこと マネジメントは面白い T: 次にやること 組織 技術 個人 まとめ Y: やったこと チーム分け マネージャーになってから最初にしたことが開発チームのサブチーム化でした。 スマートキャンプではもともと1つの開発チームで主力事業の BOXIL（ボクシル） を開発・運用をしていたのですが、2018年の途中から新規事業の立上げに伴って各エンジニアが複数のプロダクトを持つような体制になり、責任範囲が曖昧になったりタスクのスイッチングコストがかかって非効率な状態になるなど、いくつかの問題が発生していました。 それらの問題を解消するためにプロダクト毎にチームを分け、メンバーはそれぞれのプロダクトにコミットする体制に徐々に移行していきました。 一方でチーム分けすることによりチーム間のコミュニケーションや情報共有が足りなくなる事も予想されたため、採用活動や勉強会などは全体で行うように横軸での連携も意識していました。 全社会議で開発チームを分ける理由の説明をした際のスライド ※余談ですが当時から「One Team」という言葉を先取りして使っていました チームビルディング 1on1 マネージャーになってから毎週全メンバーとの1on1を始めました。 もともと会社の制度として隔週で30分の1on1をすることになっていましたが、 それまでも他のメンバーと仲は良かったものの、改めてメンバーの事を深く知るための時間を取りたかった 課題が小さいうちにキャッチアップするには隔週だと間が長過ぎる ことなどから毎週30分、日によっては1時間以上の時間をかけて話すようにしました。 話す内容は 雑談 心身の調子 困っている事 私がサポート出来ることがあるか などを中心として、私は質問のみを行いなるべくメンバーに話をしてもらうように心がけました。 また、会話の中で課題の発見と解決をメンバー自身が行い、成長を促すための支援をすることを意識していました。 1on1についての社内LT資料 今年の4月以降はチームリーダーになったメンバーに他のメンバーの1on1をお願いし、私自身は主にチームリーダーとの1on1を行っています。 最近のワイ チームを分けたことや新メンバーが入社して人数が増えたこともあり、今年に入ってから「誰が何をやっているのか、何を考えているのかわからない」という声を聞くことが多くなってきました。 情報共有の目的で隔週で開発チーム全体の会議を行っていたので、その中で各自が最近やっていること等をLT形式で発表するようにしました。 当時の議事録 - 各自の最近の業務を話す - 1人3分くらい - フォーマット - 1,2スライドくらいのボリューム - YHWT法 - Y: やったこと（こなしたタスク） - H: ハマったこと、失敗したこと（何かあれば） - W: わかったこと（学んだこと何かあれば） - T: つぎにやること（予定） - 3人ずつくらい - 発表後、esaのこのページにUPする 内容としては上記のようにYWTに H:ハマったこと を追加してYHWTとしましたが、語呂が悪いので「最近のワイ（Y）」と名付けて運用しています。 始める前はうまく回るか分からなかったのですが、いざ始めてみると人によって自分の想いを熱く語ってくれたり悩みや将来やりたいことを話してくれたりと、1人5〜10分程度のかなりエモい内容のLTになりました。 意外とみんな自分が考えていることを話す場が欲しがっているのだなと思いました。自分自身も毎回楽しみにしているコンテンツです。 最近のワイについて社内で共有した時のスライド チーム文化作り 開発チームで大事にする「文化の言語化」を最近始めました。 スマートキャンプの開発チームは基本的には非常に仲が良いものの、この1年で少しずつ人数が増えてきたことでチーム毎に文化や雰囲気の違いが出てきていたり、コミュニケーションや行動の取り方でメンバー同士がぶつかることが何度かありました。 また、弊社ではSOCS（SmartThinking, Ownership, Collaboration, Speed）という行動指針がありますが、前述した課題の部分がカバーしにくい内容であるため、SOCSに加えてもう少し開発寄りの指針が欲しいと思うようになっていました。 特にこれから更に組織が大きくなっていくことを考えるとスマートキャンプのエンジニアとして大事にすることは何かを言語化し、 どんな行動が良くてどんな行動が悪いかの基準 を作りたいと考えました。 いきなりゼロから考えるのも大変な事でしかも浸透しづらいため、現在チームで取組んでいる「スクラム」に定義されている 5つの価値基準 を開発チームの基準とすることにしました。 今後は弊社の行動指針であるSOCSや「Team Geek」で有名な「HRT」などをうまく取り入れながらスマートキャンプの開発チームらしい文化を作っていきたいと思っています。 毎週金曜日にSlack Botが価値基準での振り返りを促します PR 今年に入ってから社外へのアウトプットを増やすことにも力を入れています。 開発チームの社外へのプレゼンスを高めることで会社としては採用活動の際に候補者に訴求しやすくなりますし、各メンバーも個人での登壇を増やしたりブログ記事の執筆をすることでスキルと市場価値を高めることができます。 いくつか取組んでいることがありますが、その中でも後述するエンジニアイベントやエンジニアブログはメンバーのおかげで順調に成果が出ています。 また、最近はイベントのスポンサーを行ったり、島根県主催のRuby biz グランプリに応募し「WEB+DB PRESS」に掲載して頂くなど積極的に社外へのPR活動を行っています。 BOXILとBiscuetが掲載されたWEB+DB PRESS 育休をとった マネージャーになって3ヶ月後、今年の1月に育児休業を取得しました。 育休をとることはマネージャーになる前から決めていたものの、マネージャーに成り立てでチーム作りがこれからというタイミングでの育休取得には正直迷いはありました。 詳しくは以下の記事に書いていますが、生まれた直後の時期に子供と一緒に過ごせた事は本当に貴重な体験で、結果として育休を取ってよかったと思っています。 tech.smartcamp.co.jp 不在の間カバーしていただいたメンバーや会社の方々、改めてありがとうございました。 また、今後育休をとるメンバーには全力でサポートしたいと思います。 開発リーダーの引継ぎ マネージャーになった当時は現在の「Biscuet」の前身となる新規プロダクトの開発リーダーを兼務していました。 しかし新規プロダクトの立上げもマネジメントもどちらも片手間でやるのは難しく、また育休の件や採用活動に力を入れていく事も考えてプロダクトにコミットできるメンバーに開発リーダーを引き継ぎました。 引き継いだメンバーは現在は「Biscuet」のPdMとして活躍してくれています。 私自身はもともとはプロダクト作りをしたいと思ってスマートキャンプに入社したこともあり、個人的には難しい決断でしたが、自分があのままリーダーをしていても組織もプロダクトもうまく回っていなかったと思いますし、引き継いだメンバーが自分よりも上手く回してくれているので、あのタイミングで引き継いだことは正解だったと思っています。 tech.smartcamp.co.jp ビジネス職の新卒へのエンジニア研修 5月の連休明けにHRからの依頼で、札幌オフィスにてビジネス職の新卒メンバーへエンジニア研修をしました。 目的はエンジニアと一緒に働く際に必要な知識をつけてもらうことで、内容としてはエンジニアの業務内容・考え方・働き方などを話したり、プログラミング体験や設計体験でした。 エンジニアの仕事は自分達が思っている以上に他の職種の人からは理解しづらいものですが、一緒に手を動かしてもらうことで仕事内容や一緒に働くイメージがついたのではないかと思います。 tech.smartcamp.co.jp 採用 エンジニア採用の立て直し、採用活動全体の再構築 マネージャーになってから最初にした事の1つとして採用活動の再開があります。 スマートキャンプでは以前からエンジニア採用はエンジニアが中心で行っていたものの、2018年10月当時はエンジニア採用に責任を持って動かせる人間がいない状態だったため、私が中心となって改めて採用活動を再開することになりました。 私自身はそれまで面接官の経験はあったものの採用活動全体の戦略立てやフロー設計などは経験が無く、手探りでのスタートとなりました。 立て直しを図るべく採用系サービスの開拓や既存で運用していた採用サービス担当者の方々との打合せ等を行っていきましたが、最初の半年間は全く結果が出ず、採用の難しさを思い知らされました。 今年の5月あたりから採用にフルコミットして、フローの整備をしたり会社やチームを巻き込んだ採用活動を行えるようになった結果、最近になってようやく成果が出るようになってきました。 B2B領域での採用活動の難しさ、コミットメントについて話した資料 speakerdeck.com 現在の採用フローについて tech.smartcamp.co.jp 新卒採用の開始 21卒を対象に新卒エンジニアの採用も開始しました。 まだ始めたばかりですが 業務経験が少ない学生のポテンシャルを見極める事 学生に対しての知名度が無いところからの訴求 学生にとってイメージしにくいB2B SaaS業界の説明方法 など、中途採用とは違った難しさを既に感じていますが、何名かの優秀な方々にも出会えており今後が非常に楽しみです！ 技術顧問 スマートキャンプでは以前から外部の優秀な方々にアドバイザーとして入って頂いているのですが、11月から新たに 庄司嘉織 さんに技術顧問として就任して頂きました。 まだ着任して頂いてから1ヶ月ほどですが、技術的な部分はもちろん組織文化作りや採用についても良いアドバイスを頂いたり私やメンバーの壁打ち相手にもなって頂いたりと既に非常に助けられています。 www.wantedly.com EM系のイベントに参加 EOF2019 (Engineering Organization Festival 2019) をはじめとしていくつかのEM系のイベントに参加しました。 自分がマネージャーになったタイミングでEM界隈が盛り上がってきて、色んな方々のノウハウが世の中に出てきているのが本当にありがたいです。 この日は風邪をひいて声が出ず、他の参加者との交流がほとんど出来なかった事が悔やまれます。 今後はもっと外部のEMの方とのつながりを増やしていこうと思います。 twadaさんの発表 メンバーがやってくれたこと メンバーが自主的に企画・運営してくれていることも紹介したいと思います。 エンジニアブログ 今年の1月から開始したこのエンジニアブログ。 開始当時で9名と少ない人数であったことや通常業務もかなり忙しい状態だったため、当初は運営が回るかどうかが不安でした。 ただ始めてみるとブログ運営メンバーが率先して記事を書いたり、スケジューリングや他のメンバーの記事を書くことをサポートするなどしてくれたおかげで、毎週途切れることなく記事を出すことができ、いくつかバズる記事も出るようになりました。 最近では以下の記事で数あるTechブログの中で4位（！）にランクインしたりと、想像以上の成果が出ています。 note.com 開発合宿 昨年から年一回の頻度で実施している開発合宿。 今年は熱海で2泊3日の合宿を行い、3チームに分かれて3つのプロダクトを開発しました。 作ったプロダクトや合宿の様子については以下をご覧ください。 tech.smartcamp.co.jp tech.smartcamp.co.jp tech.smartcamp.co.jp 始めて使う技術を利用しての開発は純粋に楽しいですし、普段と違ったメンバーで開発することで技術面でも性格面でも改めてお互いを知る良い機会になりました。 また、開発プロセスがこなれてきたせいか成果物も実際にプロダクトとして価値があるものが多く、昨年に比べて企画からプロダクトを作る力が上がっているように感じました。 アジャイルコーチ メンバーの紹介で7月からアジャイルコーチの 天野さん に参画していただき、スクラムの導入を進めています。 実際のプロセスは以下の記事をご覧頂きたいのですが、それまでの「なんちゃってアジャイル」から本格的なスクラムに移行し、開発における 不確実性 を減らせる状態に徐々になってきています。 tech.smartcamp.co.jp tech.smartcamp.co.jp イベントの開催 B2B SaaS領域のエンジニアリングに関する情報共有やそのコミュニティ形成と、スマートキャンプエンジニアの社外へのPR活動を兼ねて「B2B SaaSエンジニアMeetup - SharingIssues」というイベントを開催しました。 これまで10/29と12/6の2回開催しましたがいずれも盛況に終わり、この領域でのエンジニアリングの課題意識の高さとMeetupの需要の高さを感じました。 第一回のイベントレポート tech.smartcamp.co.jp www.findcareers.jp また、運営のサポートをして頂いた他部署の方々、LT登壇依頼に快く応じて頂いた社外の登壇者の方々、共同開催して頂いた会社様など、多くの方に協力して頂いており、自分たちだけの力ではここまでうまく出来なかったと感じています。本当にありがたいです。 来年以降も継続して開催し、B2B SaaSの課題を共有していくコミュニティとして大きく育てて業界を盛り上げていきたいです。 W: 分かったこと 「Y:やったこと」が、かなり長くなってしまいました。 他にも書きたいことはあるのですが一旦この辺でまとめようと思います。 マネジメントは面白い 振り返ってみて感じたことはチームのメンバーや周囲の方々に助けられた事が多く、自分自身の成果だと思える事はそれほど無いということです。 この1年で改めて学んだ事としては 自分1人で頑張っても大したことは出来ないが、チームが一体となって課題に取り組めた時には想像以上の成果が出せる ということです。 自分自身が精一杯コミットする事はもちろんですが、 自分だけでなくメンバーがいかにモチベーション高く自主的に動ける環境を作れるか マネージャーとしていかにその事にコミット出来るか が最終的な成果の大きさに比例するということを身をもって学びました。 マネジメント自体は成果が出るまでに時間がかかる事が多く、さらに曖昧で不確実性の高い問題に取り組む必要があるため、精神的には辛い時期もありました。 ただチームで取組んだことに対して 自分の想像を超えた成果が出た時に皆で喜べること が自分自身のやりがいにもなり、マネジメントの面白みを感じられた1年でした。 私自身は至らない部分も多くありますが、そこを埋めてくれるOwnershipのある優秀なメンバーと一緒に働けていることに感謝しています。 T: 次にやること 来年以降にかけてはEMとして以下の事に取組んでいくつもりです。 組織 組織文化の言語化と定着 採用とそれに合わせたチーム体制の再構築 自己組織化したチーム作り 技術 インフラ・アプリケーションアーキテクチャの改善 メンバーの技術力の向上 登壇や記事執筆など社外へのプレゼンスを高める取組み 個人 これらを踏まえて、自分自身のチャレンジとしては 組織・技術基盤の両方のスケーラビリティとケイパビリティを高める 上記を達成するために自分自身の技術スキル・マネジメントスキルを高める になりそうです。 まとめ 繰り返しになりますが、記事を書いてみて改めて多くの方々にサポートして頂いた1年だったなと思いました。 来年はチームとしても組織としても更に飛躍の年になると思うので、今からワクワクしています！ 次回のスマートキャンプ Advent Calendarは師匠こと井上の記事です！お楽しみに！ qiita.com Engineering Manager vol.2 Advent Calendar 2019はこちら qiita.com

こんにちは、スマートキャンプでエンジニアをやっている徳田( @haze_it_ac )です。社内ではとってぃと呼ばれています。 今回は弊社のエンジニアチームで行っているオンボーディングの取り組みについてご紹介します。 オンボーディングとは？ オンボーディングで行うこと 仕事に必要な知識を手に入れる チームに馴染んでもらう、仕事に慣れてもらう スマートキャンプのエンジニアチームで行っているオンボーディング 選考前後、選考中 内定承諾後 入社〜1ヶ月 二ヶ月目以降〜 その他 PDCAを回す 最後に オンボーディングとは？ On-boardingとは、新しくチームに加わったメンバーをはやく馴染んでもらい、戦力になってもらうための取り組みを言います。直訳で 新入研修 です。 人事・総務で実施される全社的なものと、配属されるチームで具体的な業務に当たるためのものに大きく分かれますが、今回は後者をメインにお話ししていきます。 仕事に限らず、新しい環境に飛び込み、その中で必要な情報を取り入れ、成果を出すことは簡単ではありません。 ですが、採用活動をがんばって新しい方に入社をしてもらったとしても、入社した方が成果を出しチームに貢献しない限りは採用に成功したとはしたとはいえません。 そのため、採用フローを整備するぶん、オンボーディングにも力を入れていく必要があります。 tech.smartcamp.co.jp オンボーディングで行うこと エンジニアに限らずですが、大きく分けて以下のふたつです。 仕事に必要な知識を手に入れる チームに馴染んでもらう、仕事に慣れてもらう そのまんまだと思うのですが、少し解説します。 仕事に必要な知識を手に入れる 仕事に必要な知識、とは何でしょうか。 エンジニアでいうと、扱っている技術やアーキテクチャ、連携しているサービスといったものが多くを占めますが、それ以外にもサービスの仕様、サービスにかかわるステークホルダ、チームメンバ、競合などの知識も重要です。 技術、アーキテクチャといったスキル面は経験者であれば問題がないことも多いですが、当然 オープンしている情報だけで仕事ができることはほとんどなく、入社する前、した後で手に入れていく ことになります。 チームに馴染んでもらう、仕事に慣れてもらう チームに投げ込んで放置しているだけで良い関係を構築できるほど全員がコミュニケーションが上手なわけはありませんし、 人間関係はそんなに簡単なものではありません 。 チームの中だけでなく関連する別の部署や社外のステークホルダともかかわることは多いでしょう。 仕事のやり方はチームによって様々です。誰がどんな役割を担っているか、どのタイミングでどんな作業をするのかといったことも明示したり説明ができないと理解や慣れに時間がかかります。 スマートキャンプのエンジニアチームで行っているオンボーディング 選考前後、選考中 基本的にオンボーディングは入社が決定してからはじまるものですが、選考をしている中でも、会社や人を理解してもらうための取り組みをしています。 会社紹介資料 を見てもらう、説明する 選考、内定後に弊社エンジニア全員と会ってもらう 要望があれば他部署の方とも会ってもらう、ランチに行く 一日体験入社 などなど... 内定承諾後 入社が決定したら、入社後に必要な情報は可能な限り 事前に共有 していきます。 入社する側の不安を無くす役割も持ちます。 内定承諾後にVISIONやMISSION, VALUEや、組織などの説明をする 他部署とのコミュニケーションを取る 可能であれば、会社に遊びに来てもらう。中の様子を見る 入社より前にSlackに入ってもらって、事前に質疑応答をしたり使用する技術を共有したりする 入社〜1ヶ月 入社したら、社内全体で使っているツールの説明やPCのセットアップなどを人事から行った後に配属されるチームに受け渡されます。 最初の1ヶ月が体験期間として設定されており、以下のようなスケジュールで仕事や会社に慣れていってもらうプロセスになっています。 これら以外にも、 朝会や部活動、月1開催のピザパ等 で部署、事業部を超えたコミュニケーションが積極的に行われており、どんな人がいるのかはとても理解しやすいです。 入社初日〜2週間: 配属予定のチームに在籍。サービス全体の説明、アーキテクチャの共有、チームメンバとのランチ モブプロ、ペアプロでのOJTを兼ねたサービス開発 一週間に一度、メンターと、チームリーダと1on1 3週間〜4週間目 配属予定でないチームに配属。サービスの説明、アーキテクチャの共有、ランチ モブプロ、ペアプロでのOJTを兼ねたサービス開発 一週間に一度、メンターと、チームリーダと1on1 1ヶ月後以降〜 配属、チーム開発 オンボーディングの振り返り、改善 大きな特徴は、弊社エンジニアチームには BOXIL 開発チームと Biscuet 開発チームの2つがあるのですが、どちらに配属になるとしても 両方のチームに2週間ずつ在籍してもらう ようにしていることです。 人数がそこまで多くないこと、サービス開発以外にも何かとかかわることが多いこと、隣のチームが何を作っていてどんなことをしているのかを理解することが目的です。 スクラムの一環でモブプロを活用していることもあり、いきなり一人で放り出されることがないようになっています。 tech.smartcamp.co.jp tech.smartcamp.co.jp 二ヶ月目以降〜 一ヶ月が経ってからも、メンターとは随時1on1を行いなにか問題が起きていないかを確認します。 また、オンボーディング期間内外にかかわらず、リーダやマネージャとは定期的に1on1をすることで仕事上の相談や障壁の取り除き方、体調管理などをコミュニケーションを通じて共有しています。 その他 情報共有には主にSlackとKibelaを活用しており、新しく入った方でもキャッチアップできることを意識してドキュメントを整備しています。 入社したらKibelaに 自己紹介 フォルダに簡単な自己紹介記事を書いてもらう運用を最近はじめ、どんな人が働いているのかを理解できるようにしています。 同時に、新しく入った人が既存の社員が知ったり、コミュニケーションのきっかけとしても活用しています。 テンプレートを用意して、簡単に書けるようにしています。 PDCAを回す オンボーディングの施策は、作って終わりになることはありません。 採用活動が続き、人が入り続けるたびに発生しますし、オンボーディングプロセスを作って一回で完璧なものになることはそうありません。 そのため、オンボーディングで何が足りないか、何が必要かをオンボーディング期間中・期間後に ヒアリングし、改善し続けていくことが大切 です。 高速道路を整備し続けていく感覚で、次に入社する人が更に楽に、早く成果を出せるようにオンボーディングを受ける側も協力しながら良いものを作っていきましょう。 最後に これらは現状のオンボーディングプロセスです。 PDCAを回す にも書いたとおり、今後も改善し続けていく予定です。 一緒にオンボーディングを考え、改善していきつつ成果を出していくメンバーを募集しています。お待ちしています！！！！ hrmos.co 次回のAdvent Calendarは siso9to の マネージャーになってから一年でやったことまとめを書く です！お楽しみに！ qiita.com

スマートキャンプで開発リーダーをしている笹原です。 師走、ということでみなさん、色々な振返りをしているのではないでしょうか。 本日は、私が入社してからボクシルの開発プロセスがどのように変わっていったのか、 そのときどきの課題とともにお話していきたいと思います。 2018年4月〜2018年9月: みんなボクシル 2018年10月〜2018年12月: 新規事業群雄割拠 2019年1月〜2019年3月: 運用とグロースの2チーム化 2019年4月〜2019年6月: ボクシルワンチーム化 2019年7月〜2019年9月: フロー効率をバリバリ上げてこう 2019年10月〜: Visionやロードマップに沿った開発へ まとめ 2018年4月〜2018年9月: みんなボクシル 2018年4月に、スマートキャンプ株式会社に入社しました。 入社前営業日にオンボーディングの話ではなく、あだ名の話をする社員たち このときは、開発しているプロダクトがボクシルのみで開発メンバー全員でボクシルの開発をしていました。 開発プロセスは決まったものはなく、各々が各部署からの要望をそれぞれ受けているような状況でした。 エンジニアが各Divのフロントとなり、それぞれ開発している このときは、開発プロセスを振り返って改善していこうという取り組みは特になかったように思われます。 ただ、システムの改善には積極的に取り組んでいて、特に、アプリケーションの安定性向上などが優先度の高い課題でした。 エラー監視 Bugsnag導入 リソース、ログ監視 Mackerel導入 断捨離 いらない機能削除 DB要らないテーブル削除 ローカル開発環境整備 2018年10月〜2018年12月: 新規事業群雄割拠 2018年10月頃から新規事業の開発をするべく、ボクシルの開発リソースが一気に減ります。 新規事業をやっているメンバーには、ボクシルの障害発生時に手を貸して貰う形でした。 当時の開発リソース概略図 その頃のボクシルは、流入を増やしていくことが一つの目標であり、数ヶ月で2倍3倍と流入が増えていきます。 ページビューの伸び率 その中で、開発ではパフォーマンスの課題が深刻になり、ちゃんとした負荷試験を実施するようになりました。 tech.smartcamp.co.jp tech.smartcamp.co.jp また、エグジットに向けて内部統制を効かせていく必要がでてきたのもこの頃です。 AWSなどの開発で利用するリソースの管理を適切にできるような状況にし始めてました。 tech.smartcamp.co.jp 開発リソースが一気に減ったこと、流入が増えたことでパフォーマンスの改善をしないといけないこと、などから当時はほかチームからの開発要望をだいぶ絞って対応していました。 開発チームと他チームとの関係 2019年1月〜2019年3月: 運用とグロースの2チーム化 2019年1月からは、新規事業Bの仮説検証フェーズが終わり一旦開発リソースを使わずに進めていく判断がされたことから浮いた人員をボクシルの開発に入れていきます。 その際に、以下の理由からもともといた2名を運用チームとした上で、1名のグロースチームを立ち上げることにします。 オウンドメディアへの流入を増やすことに注力したい 運用や内部統制にかかる工数は別途確保しておきたい 運用とグロースの2つのチームに分けて開発 tech.smartcamp.co.jp tech.smartcamp.co.jp 2019年4月〜2019年6月: ボクシルワンチーム化 運用とグロースで2チームに分けていたことでボクシル開発チーム全体でのコミュニケーションが不足していき以下のような弊害が出ていました。 開発リソース全体として、優先度の高いものから取り組めているかわからない 両方のチームで開発内容を確認するためオーバーヘッドがかかる そういった問題が発生していたことと、内部統制を敷くことが一旦の落ち着きを見せたことから、再度、ボクシルを一つのチームで開発していくことにしました。 それに際して、チームビルディングのためにインセプションデッキを作成しました。 インセプションデッキを作成することで、お互いが何を大事にしているのかを知ることができ、その後のコミュニケーションが円滑に行えるようになりました。 当時作成したインセプションデッキ また、このタイミングからチームでの開発プロセスの振返りとして隔週でKPTをはじめました。 自分たちのプロセスを自分たちで改善していく仕組みを徐々に作っていきます。 現存する最古のKPT モブプロを少しずつ取り入れ始めたのもこの頃です。 モブプロの様子を日報に投稿する人 ここから急速に『チームで開発に取り組む』ようになっていきます。 2019年7月〜2019年9月: フロー効率をバリバリ上げてこう チームで開発を取り組むようになったものの、チームで目指す目標が明確に設定されていないため、チームが前に進めているのかわからない状態でした。 そこで、7月にボクシルの開発チームの目標を明確に設定します。（目標をどう設定していっているのか、についてはアドベントカレンダーの中でまた別のエントリを書こうと思っています。 メインの開発目標として掲げたのは、開発のフロー効率の向上でした。 開発チームの目標と工数割合 フロー効率を上げていくために、タスクのフローに注目しやすい開発プロセスとしてKanbanの要素を多く取り入れるようになっていきます。 また、開発のフロー効率を上げていくことを明確な目標としたことで、プロセスの振返りが更に重要になります。 隔週では軌道修正やTryの回数が少ないので、頻度を上げて、毎週振返りとしてKPTをやるようになりました。 目標設定や、振返りの甲斐もあってか、フロー効率の指標の一つとしていたリリース回数が8月に一気に上がります。 月別のリリース回数 2019年10月〜: Visionやロードマップに沿った開発へ 開発チームが変わる中、裏では採用プロセスも改善されていき、2019年10月には1年ぶりの新規エンジニアのチームへの参画がありました！！！ tech.smartcamp.co.jp 新しいエンジニアが入ることで、今まで暗黙知となっていたことを明らかにする必要があり、ドキュメントベースでのやりとりが一気に増えました。 開発タスクは誰でも着手できるような粒度でオンライン上に書き残すようになったり、複雑な仕様についてのドキュメント化が進むことで属人性が下がっていっています。 Asanaの開発タスクテンプレート チームで開発することやそのプロセスが整うなかで直近で課題になっているのが、中長期的なプロダクトの方向性とそれに向かって開発するための見通しです。 チームでは見通しを立てるために、Biscuetチームがすでに回しているScrumの要素を少しずつ取り入れていっています。 tech.smartcamp.co.jp まとめ こうして振り返ると、3ヶ月おきくらいで大きくチームが変化していっているのがわかります。 そのときどきの課題に合わせて、柔軟にチームのあり方を変えながら対処できていっているのは弊社の良さだなと感じています。 次の3ヶ月でまたどんな課題に立ち向かい、どんなチームになっていくのか、楽しみです！！ 明日は弊社エンジニアのタッキーによる「fullstoryとlogrocketの記事」です！おたのしみに！

こんにちは。iTunesでダブった音源をコマンドでいい感じにしようとしてすべての音源をrm -f してしまったエンジニアの今川( @ug23_ ) です。Apple Musicがあるからいいんだ…。 本記事は スマートキャンプアドベントカレンダー2019 3日目の記事です。 今回はスマートキャンプのエンジニアにアンケートを実施し、スマートキャンプのエンジニアってどんな人達がいるんだろう？を知ってもらおうという企画です。 使っているキーボードの配列を教えて下さい キーボードの機種について聞いてみました 使っているポインティングデバイスを教えて下さい エディタを聞いてみました プログラミングを始めた時期を教えて下さい 好きな言語は？ 得意な言語は？ まとめ Googleフォームでエンジニアチーム10人にアンケートをとりました。私も含んでいます。一部、任意項目にしています。 使っているキーボードの配列を教えて下さい JIS/USが半々でした。 dvorakな人はいませんでした キーボードの機種について聞いてみました いまでは全員がバタフライキーボード搭載のMacbook Proを使用しているため、内蔵キーボードを使う人が多いようです。HHKBもちょっとだけいます。私もそうです。 現在スマートキャンプではほとんどの開発をモブプログラミングで行っているため、標準キーボードを使っているのがほとんどな人も多そうです。 tech.smartcamp.co.jp また、自作キーボード温泉街のかたはいらっしゃいませんでした。私はHelixを自作して使おうとしましたが、 R T を右手でタイプするタイプの人間だったので耐えられませんでした。60%ぐらいのやつを作ろうかな。 使っているポインティングデバイスを教えて下さい 圧倒的なTrackPad派。上記と同じ状況もありそうです。 スマートキャンプでは基本的に外部ディスプレイが支給されているので、Macbook Pro本体のキーボード＋Trackpadを利用しながら外部ディスプレイまたはモブ用のディスプレイを見る、というのが基本スタイルと言えるかもしれません。 エディタを聞いてみました Atom / VSCode / Jetbrains系で3つに割れました。 最近は各チームでVSCode Live sharingでリモートペアプロすることも多く、VSCode人口が増えてきています。 プログラミングを始めた時期を教えて下さい 高校以前・大学・社会人以降で3つに割れました。大学で勉強してそのまま…だけでなく、新卒からとか、エンジニアを目指し始めてからというバックグラウンドの人もまんべんなくいます。個人的には開発において多面的な意見が上がりやすい環境だと感じています。 好きな言語は？ Javascript, Rubyが2人ずつでほかはバラバラですね。 得意な言語は？ あれ、本番稼働でScalaを使っているプロダクトはないはずでは…？ まとめ スマートキャンプのエンジニアチームはエンジニア一辺倒な人がいないということがわかりました。Rubyめっちゃ好き！Railsもっと深堀りたい！というより、 サービスを大きくしたい！ プロダクトで価値提供したい！ という指向が強いのがわかりました。 いろんなバックグラウンドを持った人々が「テクノロジーで社会の非効率を無くす」というミッションに向かっている、そんなメンバーが揃っています。 いろんな意味でもエンジニアらしくない人々がいるスマートキャンプに興味を持った方はぜひ遊びにきてくださいね！ hrmos.co

こんにちは、スマートキャンプのエンジニア中川です。 本記事は「 スマートキャンプ Advent Calendar 2019 - Qiita 」の2日目の記事になります。 突然ですがみなさん、Webサイトのパフォーマンス計測はお好きですか？ 好き嫌いはさておき、私は以下のような課題感を前々から持っていました。 顕在化してきたタイミングで問題となる いつパフォーマンスが悪化したのか、継続して悪化し続けているのかなど、情報量がすくない状態から対応をはじめなければならない 調査が長くつらいものになる なぜパフォーマンスが悪いのかわからない ある特定のコミットで著しく悪化したのか？どういう変更をするとスコアが遅くなりがちなのか？など知見が貯まらない どれもあるあるな悩みかと思いますが、タイムラインをチェックしていたところたまたまLighthouse CIの存在を知り、これらの課題を解決出来そうだったので試してみました！ The new Lighthouse CI automates checking web performance & best practices on each commit! https://t.co/WrWUAM0eHk ✅ Free & helps prevent regressions ✅ Offers a new Diff View between reports ✅ Available as a GitHub Action Made with ♥️ from our team @____lighthouse pic.twitter.com/reYXBGUFzC — Addy Osmani (@addyosmani) November 28, 2019 本記事はハンズオン形式で実際にリポジトリを作成するところからReactアプリケーションを作成・プッシュすることでGithub Actionsを経由してLighthouse CIによるパフォーマンス計測を実行してみる、といったものになります。 ※ 本記事ではGithub Actionsを使用していますが、Circle CI, Travis CIなどその他のCIツールも同様に利用出来ます。 詳しくは以下URLの Collect Lighthouse Results の項目を参照してください。 lighthouse-ci/getting-started.md at master · GoogleChrome/lighthouse-ci · GitHub Lighthouse とは まずはLighthouseについて簡単な説明です。 LighthouseとはWebサイトのパフォーマンスや品質を計測するツールで、コマンドラインツールもしくはChromeの拡張機能として提供されています。 WebサイトのURLを指定することで、Performance, Accessibility, Best Practices, SEOの5つの観点からそれぞれ100点満点として採点されたレポートを生成することができます。 以前弊社の井上が点数を上げる方法について書いた記事もありますので、よければ目を通してください！ tech.smartcamp.co.jp Chromeの拡張機能は簡単に試すことが出来ますので、まだ一度も触ったことが無い方は以降の段落に進む前に一度触っておくことをオススメします。 Lighthouse CI とは その名の通り前述のLighthouseをCI実行のタイミングでトリガーさせることが出来るツールです。 Circle CI, Travis CI, Github Actions, GitLab CI, Jenkinsなど、多様なCIに対応しています。 使ってみる まずはリポジトリを用意しましょう。 今回は lighthouse-ci-tutorial としました。 次にローカル環境でreactアプリケーションを作成します。 以下のコマンドはreactアプリケーションの雛形をnpx経由で作成するコマンドです。（本記事の趣旨と異なるため細かな説明は割愛します。） npx create-react-app 実行が完了したら念の為動作確認しておきます。 yarn global add serve serve -s build 動作確認が出来たらリポジトリにプッシュしておきます。 git remote add origin https://github.com/hogehoge/lighthouse-ci-tutorial.git git push -u origin master さて、これでリポジトリにはビルドが出来るreactアプリケーションのソースコードが存在するようになりました。 Github Actionsを導入する 次に、このリポジトリにプッシュするたびにLighthouse CIが実行されるようにGithub Actionsを導入していきます。 導入方法としては、Githubのブラウザ上からGUIで設定ファイルを編集する方法、もしくは手作業で設定ファイルをリポジトリ内の所定の階層に配置する方法があるのですが、今回は手作業で設定ファイルを配置します。 さっそくですが、以下が今回使用する設定のymlです。 name : Build project and Run Lighthouse CI on : [ push ] jobs : lhci : name : Lighthouse CI runs-on : ubuntu-latest steps : - uses : actions/checkout@v1 - name : Use Node.js 10.x uses : actions/setup-node@v1 with : node-version : 10.x - name : npm install, build run : | npm install npm run build - name : run Lighthouse CI run : | npm install -g @lhci/cli@0.3.x lhci autorun --upload.target=temporary-public-storage --staticDistDir=./build || echo "LHCI failed!" このymlを .github/workflows/lighthouse-ci.yml としてリポジトリ配下に配置して、プッシュしてください。 以上で準備は整いました！ Github上の該当リポジトリを見てみましょう！ Actions タブを選択してworkflowの一覧ページに進みます。 一覧から最新のworkflowをクリックし詳細ページに進みます。 （ymlを特に変更していない場合、タイトルは Build project and Run Lighthouse CI となっているかと思います。） 各タスクが順番に実行されていき、 run Lighthouse CI のタスクでLighthouseによるパフォーマンス計測が実行されます。 また、デフォルトの設定では3回実行されるようです。（スコアは毎回変動するため平均値をとるためかと思われます。） キャプチャのログ部分が小さくて見づらいですが、24行目に Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1575204293240-46048.report.html とあります。 どうやら今回の実行結果のレポートがLighthouseプロジェクト共有の一時ストレージに保存されているみたいです。太っ腹ですね。 さっそくURLにアクセスして確認してみます。 問題なくLighthouseの実行結果レポートが表示されましたね！ 実行結果のスコアがめちゃくちゃ優秀なので一瞬腰が浮きますが、雛形プロジェクトだったことを思い出して落ち着きました。 表示は特に問題なさそうですね。 以上で今回のハンズオンは終了です！お疲れ様でした！ 所感 ハンズオンで試してみたことで、Lighthouse CIの一端に触れることが出来ました。 今回紹介しきれなかった機能が多くありますので、気になった方はぜひ一度 公式のGetting Startedページ を読んでみてはいかがでしょうか。 個人的には、以下の部分を作り込むことで実際のプロダクションでも強力な武器になりうると感じました。 Lighthouse CI Serverを自前で用意することで、実行結果のレポートを履歴として溜め込んだり、コミット同士のスコアを比較する機能 The Lighthouse CI Server Github Status Checks 対応による実行結果レポートのGithub上表示 Assertionを定義出来る機能 lighthouse-ci/assertions.md · GitHub たとえばPerformanceが60点以下の場合にerrorを出したり、first-contentful-paintに2000ms以上かかっている場合warnを出すなどできる 前述の Github Status Checks と組み合わせることで、Github上で簡単にLighthouseの主要な項目の変化を確認できるようになり、また、フロントエンドのパフォーマンス悪化をデプロイ前に防ぐことができる Lighthouse CIを使って日頃からフロントエンドのパフォーマンスを計測することで、常にユーザーの使い勝手がよいものを届けていきたいですね！ 以上、「コミット単位でWebサイトのパフォーマンスを計測出来るLighthouse CIを使ってみた」でした！ 明日は弊社エンジニアのナウリバさんによる「スマートキャンプエンジニアの開発環境の話」です！おたのしみに！

久しぶりに記事を書くような気がします。スマートキャンプのエンジニア笹原です。 『Search Inside Yourself』 というマインドフルネス研修に参加してきたので、そこで学んだことを書いていこうと思います。 開催概要 『Search Inside Yourself（SIY）』とは なぜ参加したのか 実際に参加してみてどうだったか 実践的なワークショップ 充実した講師陣 継続が意識されたフォローアップ 研修で発見したこと・学んだこと マインドフルネスに対しての理解 情動の制御の仕方 自己（モチベーション）への理解 その他 これから おしらせ 開催概要 研修内容に関するHP: https://mindful-leadership.jp/siy/ 参加日程: 2019/10/19 - 2019/10/20 『Search Inside Yourself（SIY）』とは 以下、上のHPからの引用となります。 Google社が、最新の脳科学に基づいて開発したリーダーシップ・パフォーマンス向上のプログラムです。 SIYは、マインドフルネスに基づく新しいプログラムで心の知能指数(エモーショナルインテリジェンス)における「５つの要素」（自己認識・自己制御・モチベーション・共感・コミュニケーション）に着目した「心と思考力」を科学的アプローチで強化するプログラムです。 ＊SIYプログラムは米国SIYLI(Search Inside Yourself Leadership Institute)が認める組織と講師によってのみ教えられるプログラムです 簡単に言うと、Googleが開発した心の筋トレプログラムです。 研修では2日間を通して、マインドフルネスをベースに 心の知能指数（以下EI） を構成する5つの要素に順を追って焦点をあてていきます。 自己認識 自己管理 モチベーション 共感 リーダーシップ なぜ参加したのか 業務をしている中で、自身の感情が昂ぶり、それが原因で集中できなかったりといった課題を感じることがありました。 それについて外部アドバイザーの方との1on1で相談したところ、SIYでは情動を制御する方法論が科学的根拠に基づいて示されていると教えてもらいました。 紹介してもらってからSIYに関する本を読んですぐ、マインドフルネスを意識するだけで自らが課題と感じていた情動の制御に効果があると感じはじめました。 サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法 作者: チャディー・メン・タン , ダニエル・ゴールマン(序文) 発売日: 2016/05/17 メディア: 単行本（ソフトカバー） これは素晴らしいと感じていたので、その実践をより高度に行ったり、更には社内に共有したいと考えていたので研修に参加することにしました。 研修費用を経費で出せないかダメ元で相談したところ、『成長して、それが会社のためになるならOKだよ！』って言ってもらえました！感謝です！ 稟議を出すときには、以下のような目的だと伝えました。身につくスキルの部分は上のHPからの引用を含みます。 # 自身が得るもの マインドフルネスの実践を習得します。 マインドフルネスを実践することで以下のようなスキルが身につきます。 - 冷静かつ集中色のある、ハイパフォーマンスなマインド - 高いパフォーマンス、創造力、モチベーションを維持する方法 - 回復力・人間関係・生産性をより高める方法 - 感情を制御する能力を高める - 思いやりと見識を持ってコミュニケーションをする習慣づくり - 生産性の高いチームワークと信頼を作る能力 - ヴィジョンを明確にし、ポジティブな風土を創るためのスキル その中でも特に、以下の項目が個人の課題として強く認識するところです > - 感情を制御する能力を高める > - 生産性の高いチームワークと信頼を作る能力 # 会社に提供できる価値 研修後には以下をしたいと思います。 - 継続的なマインドフルネスの実践 - 研修内容の社内展開 - 参加報告ドキュメントをまとめる - 希望者がいれば講習を行う 実際に参加してみてどうだったか 実践的なワークショップ 座学の内容自体は上で紹介した本に書いてあることと大きく相違があるところはないのですが、それぞれの要素の中で随所でワークショップを行うことになります。 たぶん、2日間を通して20回くらい瞑想したんじゃないかと思います。 そのワークショップが素晴らしいのは、瞑想を一人でするだけでなく、した結果を参加者の方とFBし合うところにあります。 本の中でも複数人でやるワークショップが紹介されていたりしますが、一人で行うワークショップについても他の人と感じたことを共有し合うことで、ワークショップに対する没入度が深まったり、自分の感覚に対しての認知度が上がったりといったことが感じられました。 充実した講師陣 当日参加するまであまり講師陣について知らなかったのですが、うち一人はGoogleのグローバルの元人事部長でSIYを実際に開発した方でした。 1次情報に触れながら学んでいけたことは納得感がとても上がりました。 継続が意識されたフォローアップ こうした研修を受けたときに、継続することが活かすために必要だと思います。 その継続するという部分に関してもプログラムに含まれており、研修後28日間で毎日これをしていきましょう、というフォローアップがあったり、それを一緒に行うためのバディを研修中に組んだりします。 今もマインドフルネスを継続中です！！！ 研修で発見したこと・学んだこと 研修を通して、その後の実践を通して様々なことに気づき、学びました。 マインドフルネスに対しての理解 研修をする前はマインドフルネスの根本は集中力を高めることにあると考えていました。 研修を通して、自らの無意識に気づくのも根本の一つにあるなと気づきました。 - 集中力を高める - 自らの無意識に気づく <= NEW これは僕の解釈であり、どこかに書かれているものではないので、間違ってたりすることもあるかも知れませんが、マインドフルネスを実践したことでそれに対して今までと違った気づきを得られたことが収穫だと思っています。 情動の制御の仕方 一番の目的とした部分ではありますが、情動を制御する方法を学びました。 感情に支配されたと気づいたときに（これが難しかったりしますが）、刺激に対して反応するまでの間に以下のようなステップを踏みます。 S top : 気づく B reathe : 呼吸する N otice : 気づく R eflect : 良く考える R esond : 反応する 自己（モチベーション）への理解 予期していなかったものの一番の収穫となったのが、自分への理解が深まったことです。 2日間で20回近く瞑想する中で自分の思考や、モチベーションについて徐々に理解が深まっていきました。 その他 他にも色々学んだことがあります。 思考の客観視 モチベーションへの回復力の寄与 ネガティブバイアス 共感と同情との違い コンパッション（思いやり） セルフコンパッション 他者へのコンパッション これから これからしていきたいこととして以下の2つがあります 実践を続ける 社内で広める 社内で広めることで人を巻き込んで自分を追い込むことができるので、実は 実践を続ける が目的だったりします。 マインドフルに仕事をしていけるように、継続、実践あるのみです！ おしらせ 12月6日に弊社でLTイベントを開催するのでぜひお越しください！今回のテーマは B2BSaaSエンジニア忘年会 です。 smartcamp.connpass.com

スマートキャンプでPMをしている郷田です！ 10月に毎年恒例の開発合宿に行ってきました！ 私たちチームは4日間で社員同士のコラボレーションを目的とした SPARK（スパーク） というプロダクトを作りました。 合宿記事第3弾として、この記事ではSPARKができるまでに行った課題抽出〜プロダクト立案までのプロセスをご紹介します！ ▼過去の2本はこちら tech.smartcamp.co.jp tech.smartcamp.co.jp チームのメンバー構成 SPARK（スパーク）とは 合宿当日までの流れ スケジュール プロダクトが解決する課題を定める 開発内容の決定 技術選定 Nuxt.js Element UI Ruby on Rails 6 Auth0 プロダクトコンセプト作り コンセプトの不在 作ってよかった3つのもの SPARK - 火花のように質問が飛び交うプロダクト 社内発表後の反響 終わりに チームのメンバー構成 私たちのチームでは、以下の4人で構成されています。 髙松 （デザイナー） 入社時期：2019年1月 普段の業務： ボクシル やスマートキャンプ内のデザイン全般 合宿での担当： チームリーダー・コンセプト作り・デザイン全般 特徴：全体最適化が得意 井上 （エンジニア） 入社時期：2018年1月 普段の業務：社内プロジェクトの推進・ボクシルのプロダクト開発 合宿での担当：技術の選定・開発 特徴：本質志向 郷田 （PdM） 入社時期：2016年10月 普段の業務： Biscuet のプロダクトマネジメント 合宿での担当：プロダクト整理・開発 特徴：情報整理が好き 林 （CMO） 入社時期：2015年11月 普段の業務：経営・ボクシルのプロダクトマネジメント 合宿での担当：課題整理・発表資料作り 特徴：必殺仕事人 チームの特徴は普段の業務からシステム開発を行っている人がエンジニアが1名のみであることでした。 あと謎に、ボードメンバーが所属しています。 SPARK（スパーク）とは 私たちのチームでは、社員数が急激に増えていくスマートキャンプ社内で、社員同士のコラボレーションがしづらくなる問題にフォーカスを当てました。 ひとりが深くコミュニケーションが取れる範囲を最大5人と仮定すると、社員数の少ない時代では5人と話せば会社の全貌をつかめましたが、今だと5人話してもたかだか1チーム分の状況しかつかめません。 SPARKでは 質問・回答・蓄積 により、その人の エモい社内用プロフィール を自動で作ることができます。特に新入社員に対してのオンボーディングを支援できるように考えてプロダクトを作りました！ 合宿当日までの流れ スケジュール 6月 チーム結成 各自自由に合宿のアイデア出しをしていました 7月 チームが活動開始 毎週のMTGを始めてアイデアの絞り込みを行っていました 8月 課題ヒアリング プロダクトイメージを煮詰めつつ、解決したい課題を絞り込んでいました 9月 プロダクト決定 機能の絞り込みや技術の選定を行っていました 10月 コンセプトとデザインの作成 ・合宿本番 発表に向けてのプロダクトの背景を煮詰めました 合宿当日以外は、通常業務の合間で準備やMTGを重ねていきます。話し合いを4ヶ月前から始めているものの、基本的に週に1時間（月に4時間程度）しか集まれませんでした。思うように進捗しない時間を乗り越えながら、当日に向けて準備を進めていきました。 プロダクトが解決する課題を定める メンバーのアイデアベースで社内の課題定義を行いました。 アイデアの多くは、社内での取り組みを支援するものでした。 サービス案の例 社内で図書を借り合える 部活動の活性を支援する 毎朝の朝会を面白くする 日報の効率化 社内の色々なことを依頼しやすくする etc 場に出たアイデアから「私たちはスマートキャンプのどんな課題を解決したいか？」をホワイトボードに書き出していき、課題の定義を行っていきました。 フォーカスする課題を オンボーディング や 社内コミュニケーション といったHRに近い領域に絞ってからは、人事担当を呼んで現状の課題をヒアリングしながら、より具体的な課題を抽出していきました。 議論の末、解決する課題は 新入社員のオンボーディング に決まりました。オンボーディングは社内で型化が進んでいない現状がありました。チームメンバーもオンボーディングで苦労した経験があったことから、取り組むべき課題に選定しました。 開発内容の決定 課題が決まってからは、元のアイデアから機能一覧の洗い出しをし、ユーザーストーリーマッピングを行い、MVPの開発要件を決めていきました。 MVPを定めた上で、Figmaによるプロトタイピングを行い、それをベースにチーム内での認識合わせと、実開発を進めていきました。 技術選定 今回の合宿で開発するSPARKでは技術的に特別なことをやる必要性はなかったので、開発工数があまりかからないような一番スモールな形にしました。 領域 技術・ツール フロントエンド Nuxt.js フロントコンポーネント Element UI バックエンド Ruby on Rails 6 認証系 Auth0 Nuxt.js Nuxt.jsの選定理由としては、開発スピードの削減とPWA対応が挙げられます。 開発チームである井上とPMの郷田はVue.jsを触れるメンバーであったこともあり、 実際の開発以外の設定周りはすべてNuxt.jsに任せることで開発工数を削減しました。 Element UI 後々のPWA対応のためにモバイル対応しているのと、 単純にシンプルで使いやすくて好きだったのでElement UIにしました。 今回の合宿チームはデザイナーと一緒ということもあり、Element UIをもとに全体のイメージや画面レイアウトを作成してもらいました。 Ruby on Rails 6 今回のプロダクトは技術的には特別やることがないため、Railsで十分だろうという判断をしました。ただ、触ったことのなかったRails6に挑戦することにしました。 Auth0 認証周りは技術的にやったことないことへの挑戦も含めてAuth0でJWT認証で行いました。 設計としてはAuth0のみでユーザー情報を保持し、DBではemailなどの情報は持たない設計にしました。JWTのdecodeはRails側からAuth0のAPIへリクエストを送信し行いました。 プロダクトコンセプト作り コンセプトの不在 合宿の2週間前にはプロダクトの基本機能が決まり、ワイヤーフレーム制作と技術選定が進んでいました。 その中で、デザイナーの高松から プロダクトコンセプトが必要だ という意見が挙がりました。 社内コミュニケーションを促進するための機能を 質問しあえるプロダクトを作る に定めたものの、このプロダクトを触るユーザーはどのようなモチベーションで向き合えばいいのか、 このプロダクトを使うことによって得られる体験や未来を想像させる説得力 が欠けているように感じることがあったからです。 コンセプトがないことによる不具合はデザイナーとしての実作業にも現れていました。ワイヤーフレームからプロトタイピングを行うにあたり、 ここに使うべき色はなんだろう UIでどんな印象を与えよう この機能、本当にこの位置でいいんだっけ...？ といった疑問が生まれては立ち止まることが増えてきていました。 作ってよかった3つのもの コンセプトがない状況のままでは、作業の迷いが増えるうえにデザインや開発の方向がぶれていく可能性がありました。プロダクトのユーザーとなる社員にはこのプロダクトの機能、すなわち できること ではなく 実現したい未来 を認識して使って欲しいという思いもありました。 これから合宿に向かう開発チームのためだけでなく、プロダクトとユーザーのモチベーションも統一するためにも、合宿までに3つのものを作ることにしました。 世界観となる プロダクトコンセプト コンセプトを表す プロダクト名 & ロゴ 世界観を支える テーマカラー SPARK - 火花のように質問が飛び交うプロダクト 合宿後に発表したプロダクトコンセプトがこちらです。 スマートキャンプには CAMPFIRE という社内イベントがあります。 会社の経営陣が何を考えているのか、社員同士が何を考えているのか、業務では関わりを持ちづらい社員同士のコミュニケーションを促進する目的で生まれたイベントです。 私たちのプロダクトも、新メンバーと既存メンバーのコミュニケーションを促進する目的で生まれています。コミュニケーション促進という同じ目的を持った CAMPFIRE から 火 のテーマを抽出することにしました。 テーマを共通にした一方で、私たちのプロダクトでは特定の相手と焚き火を囲んでじっくりと話し合うのではなく、 誰とでも気兼ねなく軽快に質問しあってほしい という思いから、プロダクト名は焚き火の火の粉から SPARK に決まりました。 コンセプトとプロダクト名が決まったあとは、カラーイメージも選びやすくなり、合宿最中にロゴも決定しました。 最短で固めたコンセプトでしたが、プロダクトのイメージがぐっと引き締まり、合宿中のディスカッションにおいても プロダクト名とコンセプトが決まっていることで共通認識をとりやすくなる など、多くのメリットを感じることができました。 （他にもあったプロダクト名の案） 社内発表後の反響 他の2チームも含め、エンジニア合宿で作られた3つのプロダクトは、合宿成果として社内で発表されました。 （発表会の様子） どのチームのプロダクトも反響があり、その日の日報では社員がたくさんの感想を投稿してくれ、合宿に取り組んだエンジニアとしても嬉しい反応が返ってきました。 終わりに 社内の非効率を考えて解決する時間には、通常業務では得られない発見がたくさんありました。来年ももっと良いプロダクトを作り上げたいです。 そんなスマートキャンプでの開催のイベントが近々あります！B2B SaaSに関わる人はぜひ遊びに来てください！ smartcamp.connpass.com

スマートキャンプエンジニアの今川( @ug23_ )です。 10月中旬に、スマートキャンプのエンジニアチームで開発合宿にいってきました。合宿のテーマは、スマートキャンプのミッション テクノロジーで社会の非効率を無くす になぞらえて、 テクノロジーでSMARTCAMPの非効率を無くす でした。合宿を楽しんでいるメンバーの様子は来週のブログでお届けする予定なので、このエントリでは作ったものについて触れます。 解決する課題 できたもの - bony システム構成 オフィスのヒートマップ AWS IoT Coreを使ってみて ふりかえり さいごに 解決する課題 合宿のチーム分けが決まり、合宿のためのプロダクトを検討し始めた頃、我々はちょうどオフィス移転から2ヶ月後ぐらいの真夏の時期でした。チームで社内の課題を出し合ったところ、 オフィス移転してから風邪引いてるひと増えたかも 、 空調が効き過ぎていて寒いって言ってる人多いよね 、という声があがりました。 それらに対してシステムでどうアプローチしようかと考えていましたが、あの言葉が頭をよぎりました。 推測するな、計測せよ。 と。 まずはオフィスの状況を定量的に見れるようにしなければ、と思いました。そこで我々は オフィスの環境が計測できない という課題にフォーカスすることにしました。計測した上でそこから改善案を出せるようにしよう、そこから改善案を出せるようにしよう！という思いで設計をはじめました。 またチーム内で「今まで触れたことのないような技術に触れたい」ということで、チームみんなで実世界のデータを可視化するという分野への興味が湧いてきたというのもありました。 できたもの - bony 開発するシステムは Rasberry Piで取得したセンサデータをへいい感じに出力する 、という形になりました。 そこからプロダクトデザインをして、 bony というプロダクトになりました。 ※ジョニーは オフィスの案内業務を20倍効率化 した高砂の愛称です。 システム構成 ローカルでないと動かない、というよりデプロイ・公開までしたいよね、という理由から最初からAWSでの開発で考えていました。 設計には私自身のサーバレスに取り組んでみたいという気持ちとAWS-SAAを取得して使ったことのないサービスを使ってみたいという気持ちが反映されています。 AWS-SAAを取得したときの話はこちらからどうぞ！ tech.smartcamp.co.jp 結果、システム構成は以下のようになりました。 Raspberry PiのGPIOに 温度・湿度センサ と CO2センサ を接続しオフィス内に複数箇所配置する AWS IoT Core でMQTT経由でセンサデータをトピックとしてpublishする IoT Coreのルールでトピックをそのまま DynamoDB へ格納 DynamoDBに入った各センサからのデータを基に、オフィス上の温度のムラを示した ヒートマップ を生成する ヒートマップ生成のためにクリギングができる pyKriging を使用 Lambdaに載せたいが、一旦EC2に避難中 API Gateway + Lambda でDynamoDBのセンサの値をJSONとしてフロントエンドに提供する Nuxt.js でフロントエンドを開発し、APIとヒートマップを生成 フロントエンドではデータに合わせてbonyからのアドバイス（通称ボニドバ）を表示 Netlify で配信 Raspberry Piはこんな感じ オフィスのヒートマップ オフィスの温度を示すとして、ITエンジニアなら監視ダッシュボードのようなものを想像するかと思いましたが、オフィスの環境をみるには温度変化よりも 今どこが暑い/寒いのか？ という情報が重要と感じました。 複数の地点の温度データから 地点間の温度を補完して ヒートマップを作成し、それを見せることでそれが解決できると考え、追加しました。 地点間の数値補完 は 等高線図 で使われているようで、 クリギング という概念があるようでした。以下のパッケージを利用して画像を生成しています。 pykriging.com 正確性はまだ測れていませんが この辺は温かい/寒い などの情報を見せるにはこれが良いのではないかと考えていれてみました。 AWS IoT Coreを使ってみて aws.amazon.com 当初、Raspberry PiからDynamoDBへのデータの格納はAPI Gateway + Lambdaを使おうかと考えてみましたが、調べてみると AWS IoTってやつが使えそうだ と気付き、採用しました。特にこの部分が私の担当だったのでLambdaもIoT Coreも慣れてなければより専用っぽいものを使ってみよう！という考えでした。 今回始めてIoT Coreを触ってみましたが、RaspberryPiに指定された証明書などを配置し、そのファイルパスをコード中で定義しつつIoT Core SDKを叩けばJSONをDynamoに送れました。サンプルコードでは双方向にpub-subをさせてRaspberryPi上とブラウザ上でトピックをやりとりするのが体験できましたが、この周りはなにかに応用できるかもしれません。MQTTが使われているとのことでしたが、そのあたりはあまり意識せずとも使えるようになっていると感じました。Linuxが入っていれば動くのでラクだと思います。調べてみるとarduinoやintel edisonも対応していそうなので夢が広がりますね！ トピックを受け取ったあとの流し先をいろいろ設定できるのでそのままDynamoDBに格納したり、Lambdaに流したりできるようです。 ただし、複数台に対してデプロイするにはほかのサービス（CloudFormationなど？）を使う必要がありそうです。合宿中ではデモすることを重視してすべてを手作業で乗り切りました。また、権限周りはやはり少し複雑で、各端末にひとつの証明書をつけてそれに全台を統括するポリシーを割り当てるという方法を取りましたが最初はそれが原因でpublishに失敗して気づかなかったりして大きくハマりました。 具体的にどう使ったか？などコードを交えての説明はアドベントカレンダーの記事として出す予定なのでお待ち下さい！ ふりかえり ほとんどの部分を合宿中に開発しましたが、環境周りで転けそうなところを早めに解消した状態で開発したり、1時間に1回顔を合わせて進捗や困りごとを共有してヘルプしたりやる順番を変えたり、落とし所を決めるなど柔軟に開発できた気がします。 一方でSwitch RoleやMFAが必要な環境で開発をしていた事もあり、Serverless Frameworkなどの権限周りやIAM等でハマった事もありました。 このあたりは最初からプロトタイピングと割り切って、権限を気にしなくても良い環境で開発すればよかったかもしれません。 そうした技術的な悩みも多かったですが、チームをまたいで組んだ5人が集まってものづくりをしたのは新鮮な体験で「○○さんといっしょに開発できて楽しかった！」という感想がでました。普段関わりが薄い人同士だとたのしいですね。 さいごに 先日全社の前でプロダクトのプレゼンをしましたが、現在まだRaspberry Piのデプロイ（物理）が済んでいないのと、回路実装がプロトレベルなのでそこを整える必要があり、実稼働には至っていません。また、ヒートマップ生成バッチにまだ不備があるのでそれを直すなど、早くこの辺の細々した課題を解決してリリースしたいですね。年内を目標にしたい…。 これからインフルエンザが流行る時期なので、これをもとにオフィス環境改善ができるといいな！と思います。寒くなってきたのでみなさまもご自愛下さいませ。 最後まで読んでいただきありがとうございました。