はじめに こんにちは、strongWhiteです。 ラク スでは毎月1回、開発チーム主催の ビアバッシュ を開催しています。 ビアバッシュとはビールや軽食をいただきながら技術内容について楽しく語り合う交流会です。 今回は10月に大阪で開催したビアバッシュの内容を記事にしたいと思います（過去の開催も記事になっていますので、よろしければ下記をご覧ください）。 tech-blog.rakus.co.jp 今回は「行ってきた特集」 大阪のビアバッシュは決められたテーマに沿って発表する「 テーマ枠 」と、自由なテーマで発表する「 自由枠 」の2セッションを設けて発表を進めます。 また、「自由枠」は質疑応答ありで15分間の発表と質疑応答なしで5分間の発表（LT枠）に分かれます。 10月のテーマは「 行ってきた特集 」であり、各々がこれまで参加した勉強会や セミ ナーの様子と、そこで得た学びを共有していただきました。 今回の記事では主に「テーマ枠」の発表の様子をご紹介いたします。 はじめに 今回は「行ってきた特集」 行ってきた特集（テーマ枠） 京都アジャイル勉強会に行ってきた ハッカソンあるある 今回から新オフィスで発表 おわりに 参考 行ってきた特集（テーマ枠） 京都 アジャイル 勉強会に行ってきた 筆者が「 京都アジャイル勉強会 」に赴き、 スクラム について学んだことを発表いたしました。 スクラム とは「ソフトウェアに変更はつきもの」という前提から、要求や仕様変更に柔軟に対応するために生まれたソフトウェア開発手法です。 もともと私の所属するチームでは スクラム による開発を推進しており、私自身の スクラム に対する知識理解の向上を目的に勉強会に出席しました。 この勉強会はディスカッション形式で、会場には スクラム を実践する人たちが集まります。特にタイムボックスはなく、開始時間になると各々が日頃から スクラム について感じている課題や疑問を議論し合います。同じ苦難や困難に立ち向かう者同士、お互いに スクラム に対する理解を深め合うのがこの勉強会の目的です。 筆者は個人的に「スプリント バックログ の作成に時間がかかる問題」を抱えており、問題解決のヒントを得るため勉強会へと足を運びました。現在は、勉強会で得た知見をもとに自身の スクラム に対する姿勢の見直しを行なっています。 ハッカソン あるある ハッカソン に参加しているとこういう場面絶対にある！という「 ハッカソンあるある 」を発表していただきました。 ハッカソン によく行かれる方は、↓と同じようなことを感じられたことがあるのではないでしょうか？ 名刺は切れる 名刺を交換すると世の中は狭いことがわかる ハードウェアがわかるとありがたがられる ネットワークはもっとありがたがられる etc... ハッカソン の場合、（テーマにもよりますが） プログラマー よりハードウェアやネットワーク面に強い方がいると心強いと思います。 突発的なネットワーク障害に遭遇した場合に、すぐに原因を究明して修正してくれると勉強会もスムーズに進行するかと思います。 筆者は ハッカソン に参加した経験はないですが、「名刺を交換すると世の中は狭いことがわかる」はよくわかります。 最近も、プログラミングの外部勉強会に参加したのですが、そこで大学時代の同期に出会いました。以前にエンジニアになったとは聞いていたのですが、世の中は狭いものです...「あるある」は共感するものがあるととても面白いです。 今回から新オフィスで発表 ラク スは9月末に大阪オフィスを毎日インテシオから 梅田ゲートタワー へ移転しました。今回のビアバッシュは引っ越し後初のビアバッシュとなりました。 年々新卒をはじめ、社員の増加に伴ってビアバッシュの参加者も増加してきたため、旧オフィスでは開催スペースの圧迫化が問題だったのですが、新オフィスでは広々とした開催スペースとなり、より新鮮な気持ちでビアバッシュを楽しむことができました。 おわりに いかがでしたでしょうか。今後も定期的にビアバッシュの様子をお伝えしていこうと思います。次回のテーマは「 新機能特集 」を予定しています。 最近の弊社商品のリリース機能を紹介できたらと思います。どのような発表になるか楽しみです。 参考 京都アジャイル勉強会 スクラム ハッカソン

はじめに こんにちは、開発エンジニアのnorth_mkyです。 先日業務にて負荷検証を JMeter で行うことになり、弊社エンジニアが書いた下記の記事を読みつつ複数のシナリオ作成を行いました。 tech-blog.rakus.co.jp ですが最初の1シナリオの作成で全然想定している動作にならず、予想よりも3倍ほど時間がかかってしまいました。。。 シナリオ作成にあたって必要な知識として、もちろんシナリオを作成する対象の画面の仕様理解も必要ですが、 思った以上に小さな設定ミスが多い です。 この記事では原因箇所に気づくまでのプチ・ベストプ ラク ティスをご紹介したいと思います。 はじめに 対象読者 シナリオ作成トラブルシューティングガイド Step0. 準備 Step1. jmeter.logを確認する Step2. リクエストパラメータの値が正しいか確認する Step3. シナリオ実行がどこのリクエストで落ちたか実行順に見て特定する おわりに 対象読者 シナリオを作成している 方には有益な記事になっていると思います。 特に少し複雑なシナリオを作成しようとしている方にはぜひ一度みていただけたらと思います。 JMeter のシナリオ実行はしたことがあるけどシナリオ作成は初めて/始めたばっかりの方 シナリオ開始から終了までの間の画面遷移が多い( サンプラー が多い) 特定のリク エス トパラメータの値を外部ファイル( CSV )から読み込んでセットするようにしている リク エス トパラメータが動的に変わる画面遷移がある CSRF トーク ン シナリオ作成 トラブルシューティング ガイド ミスの原因調査が簡単なものから除々に特定が難しい原因調査へとステップを踏むと効率的 ですのでそのような構成にしました。シナリオ デバッグ をしていると最初は直しても直しても違うエラーがでてくる...と思わせてくるところがあるのですが、多くは簡単な設定ミスなので、気にせず淡々と確認していきましょう！ Step0. 準備 まず最初に デバッグ ができるようにする設定が必要です。 テスト計画 の直下に以下2点の コンポーネント を追加します。設定を適切に行うと 実際に実行したときのリク エス ト・レスポンスの情報がすべて見れるようになります 。注意なのですが、 デバッグ 用に追加するので 実際に負荷検証を流すときには必ず無効にしてください。 正しく計測ができない可能性があります。 リスナー > シンプルデータライタ 実行結果をファイル出力する コンポーネント 。以下のような xml ファイル形式に設定する リスナー > 結果をツリーで表示 1.で出力したファイルを読み込んでリク エス ト・レスポンスをわかりやすい形で表示する コンポーネント 失敗したリク エス トは赤字にしてくれる 1 まちがっていそうなパラメータを赤字にしてくれる URL エンコード されたパラメータをデコードして表示してくれる Step1. jmeter .logを確認する ポイント 外部ファイルが正しく読み込まれているか パスの指定が誤っていないか 外部ファイルの書き方とシナリオで設定したカラムの順番、情報に誤りがないか いざテスト実行してみたものの、本来ならもっと実行に時間がかかるところが一瞬で実行が終わってしまった...という場合はそもそもシナリオを実行するための準備に不足がある可能性が高いです。そのときはまず jmeter .logを確認します。 jmeter .logは実行ログとなっており、外部ファイルの読み込みがうまく行っていない場合はエラーとして記録を残してくれます。 jmeter .logをみて原因箇所が推測できたら、 設定エレメント > CSV Data Set Config の設定内容であったり指定したファイルの形式があっているか確認し適宜修正してください。 Step2. リク エス トパラメータの値が正しいか確認する Step0 で設定した リスナー > 結果をツリーで表示 を見て実際にアクセスしたときのリク エス トパラメータを見ていきます。 このパラメータの設定のミスが割と多いので下記ポイント4つを順番に見ていくと良いと思います。 ポイント 変数名がそのまま出ていないか 適切にURL エンコード をしているか 前画面の値を取得する 後処理 > 正規表現抽出 で設定した変数名をパラメータにセットし忘れていないか 受け渡している変数パラメータの値が前画面から正しく取得されているか 1. 変数名がそのまま出ていないか リク エス トパラメータの値を見ればすぐに見つけられます。( ${hoge} ) 大抵原因は 「 サンプラー に設定した変数名が定義した変数名と違う」 「 後処理 > 正規表現抽出 の 正規表現 が誤っていて抽出結果が空」 の いづれ かになります。 2. 適切にURL エンコード をしているか マルチバイト文字であったりURLでメタ文字や利用できない文字が含まれるパラメータをURL エンコード しないでリク エス トを投げているか、逆にすでにURL エンコード しているところに誤って二重でURL エンコード を行ってしまっている場合があります。「URL Encode?」 チェックボックス を確認してみてください。 HTTPプロキシをたててリク エス トを記録した場合、よしなに JMeter がつけてくれている場合が多いですが、 正規表現 を組んだりしていくうちにチェックが外れてしまった/ついてしまったことがでてくるかもしれません。緻密な作業でミスが起きやすいので自分を責めず、そしてめげずに進めていきましょう...( 経験談 ) 3. 前画面の値を取得する 後処理 > 正規表現抽出 で設定した変数名をパラメータにセットし忘れていないか リク エス トを記録した場合、その記録していた値のままになっているかもしれません。もう一度変数の設定漏れがないか確認してみてください。 4. 受け渡している変数パラメータの値が前画面から正しく取得されているか 1.で書いた原因に似ていますが、 正規表現 抽出で前画面から抽出自体はできていても余計な文字も拾ってきていてエラーになっている可能性があります。 リスナー > 結果をツリーで表示 ではレスポンスのbodyに対して文字列検索ができるため、リク エス トパラメータにセットした値が前画面のレスポンス内で引っかかるか確認してみてください。 Step3. シナリオ実行がどこのリク エス トで落ちたか実行順に見て特定する ポイント リク エス ト/レスポンスごとに想定の挙動になっているか確認する webサーバ/アプリログなど 画面 Step1,2を確認しても解消しない場合はいよいよシナリオをしらみつぶしに確認する作業になります。複数箇所でエラーが出ている場合は、だいたい上のエラーが引き継がれてエラーがでることが多いので焦る気持ちを抑えて上から順番に見ていきます。 レスポンスでエラー画面やエラー文言があれば、そこからコケた原因を考えられるかと思います。 アサーション を適切に設定していないとエラーなのに見た目は成功を表すグリーンのアイコンになるのでより原因特定が難しくなりますよね。後世のために原因がわかったら アサーション を追加して次もし引っかかったときは失敗を表すレッドのアイコンになるようにすると良いと思います。 おわりに いかがでしたでしょうか。長いシナリオだったりパラメータの多い画面の遷移となるとシナリオに小さいミスが起きやすくなる割に原因特定に時間がかかり気味になります。 そんなときにこの記事をみていただいて皆さんのもやもやや苦痛が少しでも和らげば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com 失敗かかどうかはアプリケーションに依存するので サンプラー > アサーション で適宜エラーを定義する必要があります ↩

id:radiocat です。 スクラム は 銀の弾丸 ではないので、いつもうまくいくとは限りません。今回は私たちのチームの失敗事例をご紹介します。 以前の投稿 でも紹介しましたが、私たちのチームは1週間スプリントを採用しています。以下のように木曜に計画を立ててスタートし、翌週木曜にレビューを行う流れです。 ご覧のように開発に注力できる期間は実質4日しかありません。油断するとすぐにレビューの日を迎えるので緊張感があります。そして、その緊張感にさらに拍車をかける要素がスプリント期間中の「休日」です。 連休の狭間の期間は スクラム を進めるべきか？ ご存知の通り、2018年の9月は2週続けて月曜が休日となる期間がありました。このままだと開発が実質3日しかないスプリントが2回続きます。 さらに、この連休期間を利用して2人の主力メンバーが休暇を取ることになりました。5人チームなので開発力は半減します。チームはこの期間をどう過ごすべきでしょうか？ 連休の狭間もスプリントを進める選択 ご察しのとおり、我々はこのままスプリントを進めました。とはいえ、さすがに丸腰でこの状況に立ち向かうほどの度胸はないので、我々なりに対策を立てて取り組もうとしました。まずはその対策をご紹介します。 連休期間の スクラム イベントは中止する 全員揃っていない状態なのでスプリントレビューは1週間スキップすることにしました。ただ、連休前の金曜から着手したスプリントを中断するのはもったいないので以下のように進めることにしました。 個々の開発は進めて良い 中途半端に作業を中断して別の事をやるのも気持ちが悪いので、出社しているメンバーは出来る範囲で開発は進めておくことにしました。ただし主力不在で開発チーム内でのフォローやレビューは手薄になるので、無理せず出来る範囲で作業を進めて、主力メンバーのレビューが必要な作業などは連休明けまで保留するようにしました。 狭間の4日間で1日分の実績を目標にする 主力2人の休暇でチーム全体のパフォーマンスは低下しますが、残りのメンバーだけでも4日あれば普段の1日分ぐらいの実績は充分達成出来るだろうと考えました。そうすることで結果的に2週間の合計が4日分の実績となるので、いつも進めている1週間スプリントと同じぐらいのベロシティを目指すことになり、感覚的にもわかりやすい目標になります。主力不在とはいえ4日で1日分なので、出勤しているメンバーにも負担がかからないはずです。 プランニングと共有をいつも以上にしっかり行う 念のため、休暇の前日に改めて主力メンバーが考えているスプリント中のタスクの進め方をチームのメンバーへしっかり共有して引き継いでもらいました。 下がりきらなかったバーンダウンチャート 結果的にこのスプリントでは、残タスク量を示すバーンダウンチャートの実績が次のようになりました。 微妙な結果です。大負けというほどでもなく、微妙な感じが逆に気持ち悪いくらいです。しかし、このスプリントのふりかえりはチームに疲弊感が漂い、私も含めてみんなモヤっとした状態で改善アクションもうまくまとめられないままスプリントは終了しました。 なぜ計画どおりにスプリントが終わらなかったのか？ いったい何が問題だったのか、後日 スクラム コーチに相談してみると3つの課題が見えてきました。 スプリントを進めるのに十分な体制ではなかった 私たちのチームのメンバー構成を改めて整理すると次のようになっています。 現在進めているプロジェクトの在籍期間が1年以上のメンバーが誰もいない状況で、目に見える人数以上にチームの体制は弱くなっています。さらに実はこのスプリントの前半の主力メンバーが休暇に入る直前まで、チームを助けるべき スクラム マスターは出張先からリモートでチームの活動に参加しており、開発チームの状況を詳細まで把握出来ない状況にありました。いつも以上にしっかり共有してから休暇に入るという事前の対策は開発チーム内の個々のメンバーの感覚に託されており、客観的にみても対策できているといえる状態かどうかは誰もわからない状況になっていました。 バックログ がReadyではなかった さて、上記のバーンダウンチャートは狭間の4日間を1日の実績としてまとめていますが、これをそれぞれの日ごとの実績に分けてみると次のような実績になっていました。 主力メンバーが休暇に入った初日から実績が上がらず、残タスクが全く減っていません。すでに危険な状況に突入していることがわかります。実はこのとき、プランニング時点の想定が覆ってそのままではタスクを進められないことがわかりました。 スクラム マスターはチームの状況を察知し、いったんタスクの終了条件を見直したりスプリントのゴールを見直すなどの調整を行い、一度は残タスクが減りましたが、すぐにまた別の問題が発生して逆に残タスクが増えてしまいました。 結果的にこの時着手していた バックログ は最初からReadyではなかったのです。つまりこのスプリントは前半時点ですでにコールド負けが決まっていました。 しかし、1つ目の原因にあるとおり、チームの体制が不十分で、前半時点ではこの状況を正しく判断できるメンバーがいませんでした。 スクラム マスターはチームの状況を正確に判断出来るだけの情報をキャッチできていなかったため場当たり的な対策を取ってしまい、結果的にはコールド負けしたチームにそのまま試合続行を促すことになってしまいました。 仕掛りがたまっていて手当てが追いつかず チームはそれでもなんとかスプリントのゴールを目指そうと取り組みました。休暇が明けてから、主力メンバーの頑張りによってなんとか持ち直しますが、計画していたゴールには到達できませんでした。 バーンダウンチャートを見るとスプリントの最後で残タスクの消化が少なくなっています。実はこのとき、仕掛中のタスクがたくさ増えすぎて経験のある主力メンバーでも残りの期間で全てを手当することは出来なくなっていました。スプリント前半に発生した問題をなんとかしようとして計画時の想定とは違う進め方をしたり、いったん保留して他のタスクに手を出した結果、想定以上に仕掛り中のタスクが増えてしまったのです。 コールド負けしない鉄則 実はこれらの原因は既に スクラム コーチの吉羽さんが別の場で示されているものでした。 slide.meguro.ryuzee.com この資料の中で アジャイル 開発でコールド負けしないための5つのポイントが挙げられています。 十分条件 で開始する Readyなプロダクト バックログ 項目だけ着手する 同時の仕掛りを少なくする フィードバックサイクルを回し続ける 技術に投資し続ける 我々は5つのポイントのうち3つを犯してしまっていました。コールド負けしてしまっても仕方ないですね。スプリントを進めるにあたり、改めてこれらの3つのポイントが重要であることを痛感しました。 開始するのに十分な条件か？ バックログ はReadyになっているか？ 仕掛りが増えすぎる進め方をしていないか？ それでも、我々はこの1回のスプリントでとても大きな学びを得たとも思っています。今後はこれらをしっかり意識してチームで取り組もうとしています。 REGIONAL SCRUM GATHERING TOKYO 2019 のCfPを出しました！ 2019年1月9日〜11日に大崎ブライトコアホールで1年に1度の スクラム のビックイベント「REGIONAL SCRUM GATHERING TOKYO 2019」が開催されます。 2019.scrumgatheringtokyo.org 私たちの スクラム の取り組みを多くの方に知っていただき、そして私たち自身が学びを得るためにプロポーザルに応募しました。下記のリンクをご確認いただき、ご興味のあるかたは是非likeをお願いします（締切が10月末ですのでご注意ください）。 https://confengine.com/regional-scrum-gathering-tokyo-2019/proposal/7956/- confengine.com REGIONAL SCRUM GATHERING TOKYOでは毎回たくさんの素晴らしいセッションが行われますので、 スクラム に興味のあるかたはぜひチケットを入手してご参加いただければと思います。

初めに こんにちは！エンジニアの id:FM_Harmony です。 前回はgitのfetchコマンドについて、記事を投稿しました。 tech-blog.rakus.co.jp 今回は postgreSQL の対話型ターミナル、 psql のオプションについて紹介したいと思います。 普段の業務でも、 psql コマンドの -f オプションや -c オプションを利用してクエリを発行する機会が多いのですが、 psql には他にも便利なオプションが備わっています。 多くのオプションが存在しますが、今回はその中でも個人的に便利だと思う4つのオプションについて紹介します。 初めに -a：発行したクエリ、コメントも出力する -t：抽出結果のみ出力 -A：位置揃えを行わない -F：区切り文字を指定する 利用例：抽出結果からcsvファイルを作成する 終わりに 参考 -a：発行したクエリ、コメントも出力する psql コマンドを利用して SQL ファイルやクエリの発行を行った場合、実行結果のみ出力されます。 sample.sql --this is comment SELECT columnA, columnB FROM some_table; $ psql -U postgres -d some_db -f sample.sql columnA | columnB ---------+--------- A | B (1行) この時、 psql コマンドに -a オプションを指定することで、発行したクエリや SQL ファイルに記載したコメントも出力することができます。 $ psql -U postgres -d some_db -f sample.sql -a --this is comment SELECT columnA, columnB FROM some_table; columnA | columnB ---------+--------- A | B (1行) このオプションを使うことで、例えば SQL ファイルの実行結果ログをレビューしてもらう際など、レビュー者が SQL ファイルの実行コマンドを把握しやすくなります。 -t：抽出結果のみ出力 通常、 psql コマンドを用いて抽出結果を出力する場合、列名や出力した行を出力結果に含めます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" columnA | columnB ---------+--------- A | B (1行) psql コマンドに -t オプションを指定することで、抽出結果から列名や行数表示を除いて出力することができます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" -t A | B 例えば、 psql で抽出した結果を基にして何らかの繰り返し処理を行う スクリプト を作成する際など、抽出結果に列名や行数表示は必要ない場合があります。 そこで、このオプションを使うことでそれらを除いた出力結果を取得することができます。 -A：位置揃えを行わない psql コマンドを利用した際の抽出結果は、表形式に整形されて出力されます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" columnA | columnB ---------+--------- A | B (1行) この時、 psql コマンドに -A オプションを利用することで、位置揃えなしの区切り文字を | とした形式で抽出結果を出力することができます。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" -A columnA|columnB A|B (1行) 主にこのオプションは、次の -F オプションと組み合わせて抽出結果の出力形式を変更する際に利用します。 -F：区切り文字を指定する 前述の -A オプションと共に利用することで、抽出結果の出力形式を変更することができます。 -F オプションの後に指定した文字を、抽出結果の区切り文字に指定します。 $ psql -U postgres -d some_db -c "SELECT columnA, columnB FROM some_table;" -A -F : columnA:columnB A:B (1行) 利用例：抽出結果から csv ファイルを作成する 今回紹介したオプションの利用例として、データベースの抽出結果から csv ファイルを作成する方法をご紹介します。 この場合、 -A 、 -F オプションが有効です。 2つのオプションを組み合わせて区切り文字を カンマ にすることで、抽出結果を csv ファイルの形式で出力することができます。 $ psql -U some_user -d some_db -c "SELECT columnA, columnB FROM some_table;" -A -F , columnA,columnB A,B (1行) あとは、出力結果に対してリダイレクトなどを用いることで、抽出結果から csv ファイルを作成することができます。 また、列名は CSV ファイルに含めるが、行数は含めたくないという場合、 grep コマンド などと組み合わせて行数表示を出力結果から除くと良いでしょう。 # 行数表示を削除する一例 $ psql -U some_user -d some_db -A -F , -c "SELECT * FROM some_table;" | grep -v "行" columnA,columnB A,B 終わりに psql のオプションをいくつか紹介してみましたが、いかがでしたでしょうか。 今回紹介したオプションは抽出結果に影響を与えるものばかりですが、もちろんデータの追加や更新時に利用できるオプションも存在します。 ただ、 psql コマンドを利用する目的として多いのは、やはりデータ抽出だと思います。 なので、今回紹介したオプションを利用できる機会というのは、ほかのオプションに比べて多いように感じます。 皆さまも psql コマンドを利用される際は、今回紹介したオプションの利用を検討してみてはいかがでしょうか。 参考 psql - PostgreSQL 9.6.5文書 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

大阪オフィスの移転 を機に、生活リズムも絶賛見直し中の @kawanamiyuu です。 今回は昨年度から取り組んでいる、通称「かみせんプロジェクト」の今期の成果（の一部）についてご紹介します。 かみせんプロジェクトとは ミッション 目標 社内システムのマイクロサービス化 社内システムの概要 かみせんプロジェクト開始前 2018 年 9 月現在 マイクロサービスの結果整合性 課題感 検証内容 検証結果（得られた知見） サービスの分割は難しい 結果整合性の担保は難しい 最後に かみせんプロジェクトとは かみせんプロジェクトとは「開発の未来に先手を打つプロジェクト」の略称で、2017 年度に取り組みが始まりました。 ミッション 『継続的に新しいことに取り組み、組織要望に対して迅速にトレンド技術で応えることができるようになる』 目標 具体的には以下の実現のための技術検証や知見獲得を、社内システムのマイクロサービス化を題材に行っています。 ソフトウェア規模に比例した開発効率低下の軽減 無停止デプロイ、不具合発生率低下などの高可用性の実現 現行ソフトウェアからの段階的な移行の実現 社内システムのマイクロサービス化 社内システムの概要 LAMP ( PHP ) で構築されたモノリシックな Web アプリケーション エンジニア、 経理 担当者などが、社内からのみアクセスして利用する プロジェクト管理機能、開発稼働集計機能などを提供する かみせんプロジェクト開始前 すべての機能がモノリシックなアプリケーションとして提供されている 2018 年 9 月現在 モノリシックなアプリケーションから、一部の機能をマイクロサービスとして切り出した マイクロサービスは AWS 上でコンテナとして動作している マイクロサービスの結果整合性 マイクロサービス化を進めるとバックエンドで複数のサービスが協調して動作することになり、これまではデータベースの トランザクション 機能により担保されていたデータの一貫性について別のアプローチが必要になります。 かみせんプロジェクトの今期の取り組みの 1 つとして、マイクロサービスの結果整合性について調査や技術検証を行いました。 課題感 複数に分割されたサービス間のデータの一貫性をどのように保てばよいか データ不整合が生じた場合、どのように リカバリ ーすればよいか 検証内容 ある機能を 2 つのサービス (図中の project-service と function-service ) として切り出す モノリシックなアプリケーションを、複数（社内での利用実績がない、あるいは少ない）の言語や フレームワーク を利用して分割することも技術検証の一環 あるリソースを新規登録する際に、従来 1 トランザクション で行っていた処理 ( SQL ) の一部を、今回切り出したサービスの API 呼び出しに置き換える データの整合性はリトライ処理で担保する 検証結果（得られた知見） サービスの分割は難しい 大前提としてサービスをまたぐ トランザクション が発生しないようにサービスを分割すべき 今回のように同一 トランザクション でデータ更新をしたい処理であれば、サービス同士が 疎結合 ではないということであり、そもそもサービス分割の粒度が正しくない可能性が高い ドメイン の知識が乏しい状態では適切な ドメイン 境界を認識することはきわめて難しい ドメイン の知識が増えた中盤になってから分割し直すことも、別の意味で難易度が高そう 自動テストなど品質担保の仕組みや、作り直しに対する組織の理解の度合いで実現可能性が大きく変わる 結果整合性の担保は難しい 今回のようにリトライ（有限回数）で整合性を担保する場合、すべて失敗する可能性もゼロではなく、最終的にログなどから手動 リカバリ ーできる仕組みを考えておく必要がある 今回は時間の都合で検証していないが、メッセージキューを利用したイベントソーシングな アーキテクチャ も検討したい 分散 トランザクション （二相コミットなど）の手法を使う選択肢もあるが、システムの複雑さや難易度が一気に増加しそうで現実的ではなさそう 最後に マイクロサービスの分割や結果整合性に関する知見は、情報としては世の中にありますが、実際に自分の手を動かして検証することで、改めてその課題感を実感するとともに、現実のサービス開発にマイクロサービス アーキテクチャ を適用する難しさも明らかになりました ラク スでは現在、 HR（人事労務）領域を対象した新サービスの開発 に取り組んでおり、この「かみせんプロジェクト」で得られた知見が現実のプロジェクトで活かされようとしています。例えば ラク スが提供する クラウド サービスとしては初めて全面的に クラウド ネイティブな アーキテクチャ を採用することが決定しました マイクロサービス アーキテクチャ の採用についても検討しましたが、今回経験したサービス分割の難しさから、まずはモノリシックな アーキテクチャ で最速でマーケットに参入するという選択をしました ラク スでは現状に満足せず開発の未来に先手を打っていける仲間、HRTech に興味があるエンジニアを募集しています！ www.wantedly.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに 新卒2年目エンジニアのkasuke18です。 つい先日iOS12がリリースされました。リリースされた内容は数多くありますが、その中でも気になったのが「ショートカット」というアプリです。このアプリをうまく使えば iPhone 単体で API の実行が可能になります。実際に試してみましたので、紹介します。 もくじ はじめに 「ショートカット」アプリについて 作成したショートカット 内容 作成例 実行結果 おわりに 参考文献 付録：今回使用したアクション 「ショートカット」アプリについて リリースノート Shortcuts 2.0 release notes を見ると、「ショートカット」アプリはiOS12の以前に「Workflow」アプリとして公開されていたようです。 「ショートカット」アプリでは、 ビジュアルプログラミング言語 のように アクション と呼ばれる構成要素を組み合わせて1つのショートカットを作成します。アクションには iPhone端末の設定変更 や 他アプリの操作・データの受け渡し といったものが用意されているほか、変数・条件分岐・繰り返し（for, foreach）といった制御を行うものも用意されています。 作成したショートカット 内容 クリップボード に保存されている画像のリンクに対して OCR の API を実行し、画像内の文字をテキストに変換して出力する、ということをやってみました。今回使用した OCR の API は Free OCR API | OCR.space です。POSTパラメータやレスポンスの JSON 構成はリンク先でご確認ください。 作成例 まずはPOSTリク エス トを送信する部分です。 図1. POSTリク エス トの送信 今回POSTパラメータとして必要な情報は APIキー ・ 画像内の文字の言語 ・ base64エンコードされた画像 の３つです。このうち 画像内の文字の言語 は日本語で固定としているので、残り２つを取得する処理はサブルーチンとして別ショートカットに切り出し、それらを呼び出す方式をとっています。ではそれぞれのショートカットを見ていきます。   APIキー の取得処理です。 API キーは 環境変数 に持っておきたいのですが、さすがにそこまではできないようなので、今回は リマインダー アプリに保持・読み出すようにしています。 図2. API キーの取得 内容は API キーを保持している リマインダー を検索し、その中から今回使用する OCR.space というタイトルの項目から API キーを取得しています。 ショートカットの最後では、メインのショートカットに値を渡すため、変数から値を取り出して終了しています。   次に base64エンコードされた画像 の取得処理です。このパラメータに設定する値は data:image/[フォーマット],[base64エンコードされた画像] ですので、実際は 拡張子 と 画像をbase64エンコードしたテキスト の２つが必要になります。 まずは拡張子の取得処理です。 図3. 拡張子の取得 大きな流れとしては、まず クリップボード の内容がURL形式どうか確認し、URL形式ならその内容を取得します。さらにその内容がイメージであれば拡張子を、そうでなければ none というテキストを返却する、という処理を行っています。この none というテキストは、ショートカットを実行する側の処理で none を受け取り、エラーとして処理を終了するために利用します。 次が 画像をbase64エンコードしたテキスト の取得処理です。 図3. 画像を base64 エンコード したテキストの取得 これは 拡張子 の時とほぼ同じ処理の流れをしていて、 拡張子 を取得していたところを 画像をbase64エンコードしたテキスト を取得するように変更しただけです。   最後にメインのショートカットで 他のショートカットを実行する＆その結果を受け取る 処理と、 レスポンスJSONをパースする 処理を行います。 まずは 他のショートカットを実行＆その結果受け取る 処理です。 図4. 別ショートカットの実行 処理の流れは画像の通りです。ショートカットを実行し、その結果が拡張子ではないときは中断されたことを通知しショートカットを終了します。 続いて レスポンスJSONをパースする 処理です。 図5. レスポンス JSON のパース 「ショートカット」アプリ内では JSON は 辞書 という単語で扱われています。アクションとしては 辞書の値を取得 というもので、これは組み合わせればネストされた JSON のパースも可能です。また今回は結果出力のため、最後にメモに書きだすようにしています。 実行結果 以上のサンプルを、前回私が書いた記事の画像に対して実行した結果が以下となります。 図6. OCR で認識する画像 図7. 実行結果 おわりに 今まではちょっと API を試してみたいだけでもPCを用意する必要がありましたが、この「ショートカット」アプリを使用すれば iPhone 単体で簡単にできます。また今回は紹介していませんが、テキストに対して 正規表現 を用いたマッチングもできるので、 スクレイピング も可能です。 iPhone ユーザの方は試してみてはいかがでしょうか。 最後までご覧いただきありがとうございます。 参考文献 Shortcuts 2.0 release notes https://support.apple.com/en-us/HT209087 Free OCR API | OCR .space https://ocr.space/ocrapi 付録：今回使用したアクション アクション名とその使い方を以下にまとめました。 API 実行 URL URLを次のアクションに渡す URLの内容を取得 受け取ったURLをリス エス トし、レスポンスを次のアクションに渡す クリップボード をリク エス ト用に加工 クリップボード を取得 クリップボード の内容を次のアクションに渡す 種類を取得 受け取った値のデータ種類（イメージ・URLなど）のテキストを次のアクションに渡す Base64 エンコード 受け取った値を Base64 形式で エンコード ・デコードした値を次のアクションに渡す ファイルの詳細を取得 受け取った値（ファイル）の詳細（拡張子・サイズなど）を次のアクションに渡す JSON のパース 辞書の値を取得 受け取った JSON から指定したキーの値を次のアクションに渡す 制御 変数を設定 受け取った値を変数に代入する 受け取った値をそのまま次のアクションに渡す 変数に追加 受け取った値を変数に追加する（Listにappendするようなイメージ） 受け取った値をそのまま次のアクションに渡す 変数を取得 変数から値を取り出し、次のアクションに渡す 次の場合（if~else文） 受け取った値と指定した値を比較する（次と等しい・次を含む・より大きい・より小さい） それぞれで繰り返す（foreach文） 受け取ったリスト形式の値に対して１つずつ処理を行う ショートカットを実行 受け取った値を特定のショートカットに渡し、その実行結果を次のアクションに渡す（メソッドのようなイメージ） API キーを取得する リマインダーを検索 条件に合致するリマインダーを検索し、その結果を次のアクションに渡す リマインダーの詳細を取得 受け取った値（リマインダー）の詳細（メモ・タイトルなど）を次のアクションに渡す その他 テキスト 指定したテキストを次のアクションに渡す 通知を表示 タイトル・メッセージを指定し、その内容を通知として表示する メモを作成 受け取った値をメモに新規登録する "ショートカット"を終了 現在のショートカットを終了する 現在のショートカットに含まれる後続のアクションは実行しない エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは。 ラク スエンジニアのstrongWhiteです。今回は8月に 京都アジャイル勉強会 に行ってきましたのでレポートしようと思います。 アジャイル とは、要求仕様の決定や変更に対して、柔軟に対応するためのソフトウェア開発手法のことです。昨今有名になりつつある アジャイル ですが私としても興味がありましたので今回勉強会に参加してみました。 ※この記事では アジャイル に関する詳細な説明は省きます。 アジャイル ・ スクラム を初めて聞く方は馴染みのない用語が出てきますがご了承ください。 京都 アジャイル 勉強会とは アジャイル ・ スクラム を実践しようとしている（もしくは実践中の）人を対象とした勉強会で、自身（あるいは自社）が抱えている アジャイル ・ スクラム に関する疑問、不安などをざっくばらんに議論し、お互いに理解を深め合う会です。ちなみに私が行ってきたのは以下の勉強会です。 connpass.com 私の所属するチームでは アジャイル ・ スクラム を取り入れた開発をしているので、今回は アジャイル ・ スクラム を実践する中で私が抱えている疑問や不安を勉強会に参加されている皆さんにぶつけてみることにしました。 学んだこと ディスカッション形式の勉強会は初めてだったので新鮮でした。また、 アジャイル ・ スクラム に対する理解も少しながら進んだ気がしました。私としては日々 スクラム ・ アジャイル を実践する中で プロダクトバックログからスプリントバックログを出すまでに時間がかかり次のスプリントが始められない という課題を抱えていたのですが、今回の勉強会でとある方から「見切り発進的に次のスプリントを始めるのはよくないので、時間がかかってもいいから全てのスプリント バックログ を出してから次のスプリントをスタートすべき」という助言をいただき、少し勇気をもらえました。 終わりに 今回のようなディスカッション形式の勉強会は講義形式のお堅い感じは全くないので私としてもリラックスして受講できました。機会があればまた アジャイル ・ スクラム 系の勉強会に参加したいと思います。チームとしても私としてもまだまだ アジャイル ・ スクラム を始めたばかりなので、また疑問が出てきたらこういう勉強会の場で解消していこうと思います。 参考 アジャイル開発 京アジャ

こんにちは、MasaKuです。 ビッグデータ という言葉をよく目にしますが、その背後にある技術についてはあまり理解していませんでした。 そこで、 ビッグデータ を支える技術のひとつであるNoSQLについて興味が生まれたので、今回の記事では、NoSQLについて勉強した結果についてまとめようと思います。 （本記事の執筆には以下の書籍を参考にさせていただきました） NOSQLの基礎知識 ビッグデータを活かすデータベース技術 はじめに NoSQLとは RDBとの違い NoSQLに期待すること NoSQLのデータモデル キーバリュー型 カラム指向型 ドキュメント指向型 グラフ型 おわりに 参考文献 はじめに 現在、 Twitter は、１日あたり１０テラバイトを超えるデータを扱っているそうです。 10テラバイトというと、書籍一冊のデータ量（５０万文字）とすると書籍１０００万冊分に相当します。 モバイルデ バイス からも簡単にアクセスして写真や動画コンテンツを発信できる Webサービス が普及してきたことが ビッグデータ の発生の起因のひとつになったと言えるでしょう。 ビッグデータ の対応には3Vという以下のような特徴があります。 Volume（膨大な量） Velocity（速さ） Variery（多種多様） 今後、更にリッチな情報を扱う Webサービス が普及してくると、 ビッグデータ を処理する技術がますます重要になることから、NoSQLの技術発展が期待されます。 NoSQLとは PostgreSQL や MySQL などの RDB では対処しづらいような ビッグデータ に対応すべく生み出された技術で、 SQL を使用しないということが特徴です。 「Not Only SQL 」の略であり、「 SQL だけでなく、新しいデータベースの技術も利用する必要があるというムーブメントのことである」と多くの方に認識されています。 しかし、「NoSQLとはズバリこういうこと！」という定義についてはまだ明確化していないようです。 NoSQLとして代表的なものには、 Google の BigTable 、アマゾンの Amazon DynamoDB などがあります。 RDB との違い NoSQLと RDB との違いについて以下にまとめました。 機能は豊富ではない データの整合性が緩い 結果整合性でよいという考え NoSQLでは、 RDB で当たり前に利用できるJOIN（結合）が通常はサポートされていません。 また、同時実行制御（ 排他制御 ）を成立させる トランザクション の機能が緩められており、データの整合性よりも、大量のデータを素早く処理することを優先しているという特徴があります。 NoSQLと RDB の特性の違いを説明する上で重要な「 CAP定理 」という定理があります。 分散型データベースシステムにおける三大要件として以下が存在します。 Consistency（整合性）…常に同一のデータを参照する Availability（可用性）… 常に読み出しと書き込みができる Partition Tolerance（分断耐性）…ネットワークが分断されても間違った結果を引き起こさない 分散型データベースシステムでは、上記の3つのうち最大２つしか満たすことができない、というのがCAP定理です。 CAP定理 RDB にはACIDという特性が存在し、 トランザクション が信頼性をもって実行されるための必要条件を定義されています。 一方、BASEというものも存在し「アプリケーションは常時稼働し、常に整合性を保つ必要はないが結果的に整合性がとれる状態に至るという特性を備えているべき」という考え方があります。 CAP定理の提唱者であるEricBrewer氏は以下のように説明してます。 システムに整合性（C)と分断耐性（P）が求められる場合には、AICD特性を完備しなければならない。 だが、整合性（C）よりも可用性（A）と分断耐性（P）が求められるのであれば、そのシステムはBASEの特性を持つべきである。 RDB はCA（整合性と可用性）に分類され、ほとんどのNoSQLデータベースがCP（整合性と分断耐性）かAP（可用性と分断耐性）に分類されます。 RDB とNoSQLでは期待している性能が異なることから、NoSQLが RDB を完全に代替するものではないことがわかります。 NoSQLに期待すること NoSQL全般には以下のような要件を満たすことが期待されています。 一台のサーバには収容できないほど膨大なデータを扱う データを複数のサーバに分割して割り当てる 高価なハードウェア等ではなく、安価な汎用ハードウェアの上で稼働する データに紛失がなく、データは安全な状態に格納されている システム全体としては、いつでも使える状態にある 障害が発生しても短時間で復旧できる リアルタイムに近い応答性能を備えている また、データを高速に処理する上で、高度なデータベースチューニングの技術を必要としないことも特徴です。 データのサイズや形式が頻繁に変化するようなアプリケーションを RDB でデータを高速で処理し続けるためには、データベース設計に対する高い技術力を持ったエンジニアが常時対応しなければなりません。 これまでの RDB では十分な性能が得られなかったり、 RDB で実現しようとすると、構造が複雑になり、コストがかかりすぎるという問題を回避するための手段としてNoSQLが選択肢の一つとなりうることが期待されます。 NoSQLのデータモデル NoSQLには様々なデータモデルが存在します。 キーバリュー型 キーバリュー型 RDB のようなテーブルや関係性を定義せず、キーとバリューという組み合わせからなるシンプルなデータモデルです。 データが増えるにつれて表が縦の方向に伸びていくイメージです。 データモデルが単純であることからデータを容易に分割可能なことから、スケールアウトに最適なのが特徴です。 カラム指向型 カラム指向型 上記のキーバリュー型にカラムの概念を持たせたデータモデルです。 行に付与されたキーが複数のカラムを持つことができます。 カラム数は RDB のように固定ではなく、動的に追加していくことができます。 RDB を利用していると異質に思えるかもしれませんが、ほかの行には存在しないカラムを持つ行を作ることができます。 ドキュメント指向型 ドキュメント指向型 JSON や XML 形式で記述されたドキュメントの形でデータを管理することができます 各ドキュメントは階層構造を持たず、相互の関係を横並びに管理します。 RDB のように固定されたデータ設計が不要なことから「 スキーマ レスである」と言われます。 私はドキュメント指向型の説明を読んだ際、上記のカラム指向型との違いを明確に認識することができていませんでしたが、以下のようなものなのだと理解しました。 ドキュメント指向型の例 ブログの投稿履歴とメールの送信履歴をドキュメント指向型データベースに記録したとします。 これらは全く異なる性質のデータですが「投稿日と送信日が2018/9/18のデータ」と指定することで、関係するデータが取得できます。 このようなデータの性質が異なるものや、これまで取得していたデータの形式が唐突に変わってしまうような対象でも、ドキュメントの形式でデータベースに格納し、データを処理できるようにするのが オブジェクト指向 型のデータベースの特徴なのだと思いました。 グラフ型 グラフ型 データとデータ感のつながりを管理できるデータモデルです。 グラフ型のデータベースには以下の構成で表現されます。 ノード リレーションシップ プロパティ 例えば、 FaceBook の友達関係をグラフ型で表現すると以下のようになります。 Aさんというアカウントが存在します（ノード） AさんはBさんと関係があります（リレーションシップ） AさんとBさんは友達同士です（プロパティ） この基本構造を拡張していくと「Aさんの友達であるBさんの友達」や「Aさんと友達になってから3年以上経過したアカウント」といった検索も可能になります。 おわりに いかがでしたでしょうか。 筆者も、MongoDBというドキュメント指向型NoSQLを利用して簡単なWebアプリケーションを作ってみましたが、NoSQLについて調べて見ると様々なデータモデルが存在することがわかりました。 それぞれのデータモデルごとの強みが光るようなWebアプリケーションの特性についても今後調べていきたいと思いました。 参考文献 NOSQLの基礎知識ビッグデータを活かすデータベース技術 NoSQL - Wikipedia ブリュワーのCAP定理～データストレージの選定基準 - 浜村拓夫の世界 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

id:radiocat です。9/13に東京オフィスで開催したMeetupに登壇し「終わらない スクラム 」というタイトルで発表しました。今回のイベントを通じて、私たちが継続して スクラム に取り組んでいくうえでの様々な気づきを得ることができたので、それらを5つの学びとして記事にまとめてみました。ご参加頂いたみなさま、ありがとうございました。 rakus.connpass.com 発表の概要 発表の前半は私たちのチームが取り入れた アジャイル 開発のプ ラク ティスの説明で、今年3月の社内イベントで発表した内容がベースとなっています。それらの概要は以前のブログ記事にまとめていますのでご参照ください。 tech-blog.rakus.co.jp 発表の中盤からは開発を少しずつ アジャイル にし、やがて スクラム にチャレンジしていくために私たちが参考にした書籍やネット上の情報を紹介しました。そして後半部分では、現在のプロジェクトでも引き続き スクラム で開発を進めている中で新たに取り組んでいることを紹介しました。 speakerdeck.com 5つの学び 発表後の懇親会では参加者の方々からたくさんフィードバックを頂いて、それぞれの現場で実践している スクラム の取り組みなども教えていただき、とても有意義なイベントにすることができました。頂いたフィードバックも交えて、5つの学びをご紹介します。 1. 役割に徹することができる体制で スクラム を始める 私たちの スクラム チームではプロダクトオーナー（以下PO）をデザイン部門のメンバーが担っています。 その理由は大きく2つです。 開発チームは大阪、POのデザイン部門と ステークホルダー の事業部門は東京が拠点 BtoBのサービスであるため、デザイン部門はデザインの作り込みよりもUI/UXをしっかり検討することが求められる この話をした時に、「（上記の体制を書いた）スライドを見た時にそうだと思った」というフィードバックを頂きました。 スクラム チームの中で誰がPOや スクラム マスター（以下SM）を担当するかは スクラム に取り組むうえでの最初の難題の1つです。チームの中で誰がその役割を担えばその役割に徹することができるのかをしっかり問いかけて決める必要があります。 役割に徹することができない体制で スクラム を始めていたら恐らく失敗していました。世の中的に複数拠点やリモートワークを絡めたメンバー構成は当たり前となっていますし、それぞれの現場に合わせて最適な体制を考える必要があります。 ちなみに、今回の体制の場合は開発部門におけるリーダーという立場の私がSMを担うことがもう1つの課題になりました。 開発チームが機能するために組織としての役職が邪魔になることもあれば、うまく活用してチームを支援できることもあり、それらをうまく使い分けることも役割に徹するために必要なことです。 2. スプリントの期間は1週間がおすすめ 今回の発表で取り上げた開発プロジェクトでは2週間のスプリントで スクラム を始めましたが、現在はスプリントの期間を1週間にしています。 同様に1週間でスプリントを回している人から「1週間じゃないとスプリントを回すのは無理」というフィードバックをもらいました。大きな理由は以下の2点です。 スプリントの最初に2週間分のタスクを洗い出してプランニングするのが大変 2週間先の見込みを見極めるのが大変 私たちも慣れた今となっては1週間が最もやりやすく感じています。 チームの事情にもよりますが、スプリントの期間をどのくらいの長さにするかもまた スクラム に取り組む上での課題の1つです。私たちが最初にスプリントの期間を決めた当時は他のプロジェクトに稼働を使うメンバーもいたため2週間ぐらいがちょうど良いと判断しました。また、当時は1つのタスクの粒度を小さくする事に慣れておらず、1週間スプリントで大きな粒度のタスクの実行に想定外の時間がかかってしまうとあっという間にスプリントの終わりを迎えてしまう恐れも感じていました。しかし、今となっては1週間スプリントならうまくいかなくても改善して次に活かせば良いという感覚のほうが大きいです。 3. リファインメントと技術的スパイクの大切さと難しさ 次のスプリントに向けて バックログ を準備するリファインメントや技術的スパイクの活動は スクラム イベントとしては定義されていませんが、非常に重要でかつチームでルールを決めるのが難しい活動です。私達のチームではリファインメント会議をイベント化して強制的に時間を取るようにしています。 これについても同様にルールを決めて時間を取っているチームもあるというフィードバックを頂きました。やりかたはチームによっていろいろあるようでしたが、いずれにしてもプランニングまでに バックログ をきちんと準備できていなければ、スプリントはうまく回らないというのが共通の理解です。 ちなみに、現在私たちのチームでは1スプリントに2種類のリファインメント会議を実施しています。 開発チーム内リファインメント会議：技術的スパイクの状況確認や認識合わせが中心 スクラム チーム全体リファインメント会議： バックログ の整理と内容の認識合わせが中心 その理由は主に以下の3点です。 現在取り組んでいるプロジェクトの特性として技術面での不確定要素が多い 開発チームの人数が増えてきたため全体共有や認識合わせの場があったほうが進めやすい POと開発チームの拠点が別れているため時間を決めて実施したほうが進めやすい いずれも私たちのチームの事情によるものですが、これらを踏まえてリファインメントや技術的スパイクはそれぞれのチームでやりかたを考えて取り組む必要がある活動だと感じています。 4. チームの人数が増えるにつれて スクラム は難しくなる 私達のチームはメンバーが10人を超えたためスケールアウトを検討し始めています。 これに関連してチームのメンバーが9人いるという人からもフィードバックをもらいましたが、デイリー スクラム を時間どおりに終わらせるだけでも難しく、人数が増えると スクラム は難しくなると感じています。私たちのチームでも、スライドに書いてあるとおり スクラム ・オブ・ スクラム 、LeSS、 Nexus といった大規模 スクラム の事例を調査して検討をしていますが、事例自体があまり多くないのでまだ具体的な判断は下せていません。 ただ、スライドの下に書いてある「若手メンバーのミニ スクラム 」を試す期間で、一時的にメインのプロジェクトのメンバーを5人にしたところベロシティが上がってスプリントを以前よりうまく回せるようになったので、やはり5人ぐらいがちょうど良いという感覚も得ています。 5. チームの育成と成長は熱意を持って根気強く 上記の「若手メンバーのミニ スクラム 」や、以前このブログでも紹介した「 スクラム クイズ」に関しては良いフィードバックを頂きました。 チームのメンバーひとり一人がきちんと スクラム に向き合わなければ スクラム をうまく回すことが難しくなります。フィードバックの中でその点に課題を持っているチームの話もいくつか聞くことができましたが、チームの中で熱意をもって進められるメンバーがいないと スクラム を続けていくのは難しいと感じました。 我々もまだまだ試行錯誤しながら様々な取り組みを行っているところですが、そのためにも他のチームの事例や課題はとても参考になります。そういう意味で、今回のイベントではたくさんのフィードバックを頂き、私たち自身の新たな学びを得ることができました。 この学びをまたチームに持ち帰ってさらに スクラム を前進させていきたいです。 スクラム の習得はまだまだ終わりそうにありません。 今回のイベントをきっかけに当ブログに「終わらない スクラム 」というカテゴリを作りました。今後も スクラム の取り組みで得たことを随時発信していきたいと考えていますので、引き続きチェックして頂けますと幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは。開発エンジニアのd_ shr ( id:d_shr )です。 これまではNode.jsや PostgreSQL について書いていましたが 今回はIoTを支える 通信プロトコル MQTT についてまとめます。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp はじめに 軽量で省電力 メッセージングとTopic メッセージング Topic MQTTの機能 QoS Retain Will まとめ はじめに MQTT は、Publish/Subscribe モデルのメッセージングにより、非同期に1対多の通信ができる プロトコル です。 シンプルかつ軽量に設計されているため、機械同士が通信を行いやり取りするM2M (Machine-to-Machine) や 家電や自動車など多種多様な「モノ」が通信を行いやり取りするIoT (Internet of Things) を実現するのに適した プロトコル と言われています。 軽量で省電力 HTTPと比較すると、軽量で省電力な プロトコル です。 MQTT のヘッダサイズは２バイト〜とHTTPに比べるとかなり軽量になっており その軽量さからバッテリーが限られているモバイル通信に適しています。 メッセージングとTopic メッセージング MQTT はPub/Subモデルでメッセージングを行います。 Pub/Subモデルではメッセージの送信者をPublisher、メッセージの受信者をSubscriber、メッセージの仲介をするのがBrokerです。 Publisher はメッセージをBrokerへ送るとき、送ったメッセージがどの Subscriber に届くのかなど気にする必要はありません。 Subscriberはメッセージがどの Publisher から送られて来たのか知ることなく欲しいメッセージをBrokerから受け取ります。 Topic MQTT では、Topicと呼ばれるキーを用いてメッセージングを行います。 トピックは「/」で区切られた階層構造になっています。 例：japan/osaka PublisherはTopicを指定してメッセージを送信し、Subscriberは受信したいトピックをfilterとして指定することで、欲しいメッセージだけを手に入れることができます。 MQTTの機能 QoS MQTT ではメッセージごとに到達保証に関する QoS (サービスの品質)を指定します。 QoS0 メッセージは最高 1 回 配信される メッセージが 送信先 に届くかは保証されない QoS1 メッセージは最低 1 回 配信される メッセージが 送信先 に届くことが保証されるが重複して届く可能性がある． QoS2 メッセージは正確に 1 回 配信される メッセージが過不足なく 1 回のみ到着することが保証される． Retain Topicごとに最後にPublishされたメッセージをMQTTサーバが保持しておく機能。 MQTT はPub/Subモデルなので、PublishしたときにSubscribeしていたクライアントにしかメッセージは送信されません。 具体的には、10分ごとに更新される情報を得るために新しくSubscribeしても，最長10分間はなにも情報が得られないことになります。 しかし、Retain機能を使うとその時点での最新の情報が得ることができます。 Will Publisherが切断されてサーバとの通信ができなくなったときに 指定されたTopicとメッセージをSubscriberに送信する機能。 予期せぬ切断などが発生したときに、SubscriberはPublisherが切断されていることを判断できます。 まとめ IoTを支える プロトコル MQTT について簡単にまとめてみました。 世の中にIoTが広がってきているので、それに関連した技術は追っていきたいと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

ラク スは「 IT技術 で中小企業を強くします！」をミッションに掲げ、 メール共有・管理システムのメールディーラーから始まり、経費精算システムの楽楽精算に至るまで、 延べ40,000社を超えるお客様に自社開発した クラウド サービスを提供してきました。 今回（9/13(木)）は、 ラク スで主力 クラウド サービスの開発を牽引するエンジニアによる トーク セッションと交流会を開催します。 クラウド サービス開発のエンジニアとして活躍している方はもちろん、 クラウド サービス開発にご興味をお持ちのエンジニアの方も気軽にご参加頂ければと思います。 自社開発ならではの技術・運用ノウハウや、新しい取り組みの成果や失敗談など ご参考にして頂ける情報を積極発信していきたいと考えております。 このイベントが新しい気づきや成長につながる機会を提供する場になるとともに、 ラク ス社員と参加者の皆さま、また参加者の皆さま同士で新たなつながりが生まれるきっかけになれば幸いです！ 開催概要 【日時】2018/9/13(木) 19:30～21:30(開場は19:00) 【会場】 ラク ス 東京本社 （〒151-0051 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス] ） 【定員】30名 【申込み】 connpass 【参加費】無料 【主催】 ラクス 今回の トーク テーマ 終わらない スクラム 　～楽楽精算のサービス拡大を支える スクラム 開発の取り組み 大塚正道（おおつかまさみち） ラク スでは、まだ多くの開発チームが ウォーターフォール 型の 開発プロセス を採用していますが、 一部のチームで スクラム による アジャイル 開発に取り組んでいます。 今回は楽楽精算チームでの取り組みを紹介します。 実際にやってみると様々な問題が発生しました。問題解決に向けたアクションや取り組みを通じて得た知見、今後の課題等を事例を交えてお話しします。 テッ クリード （自称）としてのやっていき！　～ iOS アプリ開発 チームを率いて 川並裕（かわなみゆう） 若手エースエンジニアが初めての iOS アプリ開発 でテッ クリード として奮闘したお話しです。 iOS アプリ開発 は、自身も初、メンバーも初、しかも短納期（3ヵ月．．．）。 この デスマーチ を予感させる不利な条件下で、テッ クリード としてどのようにチームをリーディングしたのか。 様々な事例を交えてご紹介します。 流行の開発手法ChatOpsとは　～楽楽明細チーム/ChatOpsでルーティン作業をまるごと自動化～ 三田英一（みたえいいち） Jenkinsの導入で自動化が進んだけど、「Jenkinsを毎回開くのは面倒」、「アカウントの作成も面倒」、「非エンジニアに使ってもらうにはちょっとハードルが高い」。 そこで導入したのがChatOps! Slack互換のチャットツール「Mattermost」でルーティン作業を丸ごと自動化しました。 利用した bot ツール、システム構成、Hubot スクリプト の実例など、ノウハウを余すことなくご紹介します。 タイムテーブル 19:00 開場・受付開始 19:30 イベントスタート 21:30 終了予定 トーク が終わり次第、交流会に移ります。 交流会では、フィンガーフード、ドリンクをご用意致します。 お気軽にご参加ください。 エントリー方法 [connpass] よりエントリーをお願いします。 ※当日はお名刺2枚ご持参ください ※提供可能な設備： Wi-Fi 、電源 会場 ラク ス　東京オフィス2F セミ ナールーム 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス]

はじめに こんにちは sts -250rrです。 前回の記事ではARをテーマに記事を投稿いたしました。 今回はテーマをガラリと変えまして「 機械学習 」について簡単にまとめてみようと思います。 昨今、 AWS の Amazon Machine Learningや Microsoft のAzure Machine Learning Studioなどで手軽に 機械学習 を利用できるようになって来たことに加え、 楽楽精算では、 iOS 向けに領収書のアップロードができるアプリをリリースしました。 楽楽精算 株式会社 ラク ス ビジネス 無料 このアプリでは 機械学習 系技術の1つである OCR （Optical character recognition）を用いて領収書データを読み取り、楽楽精算にアップロードしています。 世間的にも話題かつ、 ラク スでも 機械学習 に注目していることもあり、 良いタイミングなので 機械学習 について整理してみようということです。 今回は簡単に 機械学習 とは といった話から、 機械学習 を行うツールを使って 機械学習 を体験してみた内容をまとめていきます。 機械学習 とは？ はじめに、 Wikipedia では 機械学習 についてこう書かれています。 機械学習 （きかいがくしゅう、英: machine learning）とは、 人工知能 における研究課題の一つで、人間が自然に行っている学習能力と同様の機能をコンピュータで実現しようとする技術・手法のことである。 つまり、 人工知能 を実現する手段が 機械学習 という事です。 さらに Wikipedia を読み進めていくと概要にこう記載されています。 センサやデータベースなどから、ある程度の数のサンプルデータ集合を入力して解析を行い、そのデータから有用な規則、ルール、知識表現、判断基準などを抽出し、 アルゴリズム を発展させる。なお、データ集合を解析するので、 統計学 との関連が深い。 とあるように、実は 機械学習 は 統計学 と深い関連を持っています。 統計学 は、大量に得られたデータの性質や規則性、分類を見つけるような学問ですが、この 性質や規則を見つける事 が 機械学習 にとっての学習になるわけです。 機械学習 の種類 機械学習 について少し掘り下げていきます。 単純に 機械学習 といっても、大きく分けて「 教師あり学習 」と「 教師なし学習 」が存在します。 それぞれに学習方法やできることが異なりますので簡単にまとめていきます。 教師あり学習 学習に使用するデー タセット に対して、正解を与えておく学習方法です。 この学習では、大量のデー タセット から正解の情報を学習し、「ある特徴を持つものは、ある事柄に対して正解である」ことを判断できる学習方法です。 簡単な例だと、「赤い色という特徴を持つ果物」が「美味しい」と判断することができます。 しかし、正解として「美味しい」か「美味しくないか」のみを学習させているため、「赤い色という特徴を持つ果物」が「美しい」かは判断することはできません。 教師あり学習 を行う方法には次のようなものがあります。 線形回帰 ロジスティック回帰 ナイーブ ベイズ k近傍法 ニューラルネットワーク 教師なし学習 教師あり学習 とは反対に、学習に使用するデー タセット に対して、正解は与えません。 この学習は、大量のデータの類似度や規則性を学習し、データの分類を行います。 簡単な例だと、ある果物のデータを大量に集めてくると3つに分けられました。 機械自身には分けられたデータが何を示すものであるかはわかりませんが、次にデータが得られた時、3つのうちどこに該当するデータであるかを判断することができるようになります。 教師なし学習 を行う方法には次のようなものがあります。 主成分分析 k平均法 ディープラーニング 強化学習 *1 機械学習 を試してみる 言葉のみでは腑に落ちない部分もあるので実際どのように学習しているのかを試してみたくなりました。 そこでweka *2 というフリーの 機械学習 ツールを使っていきます。 (今回、wekaの使い方については特に説明いたしませんので悪しからず。。。) 今回は 教師あり学習 に「ロジスティック回帰」、 教師なし学習 に「k平均法」による クラスタリング を使っていきます。 これらの手法については下記の記事で詳細が紹介されていました。 qiita.com qiita.com お試し1： 教師あり学習 wekaのサンプルデータであるアヤメの品種分類データiris.arffを使っていきます。データの内容は以下の通りです。 クラス(正解):setosa, versicolor, virginica 特徴量(属性) - sepallength : がくの長さ - sepalwidth : がくの幅 - petallength : 花弁の長さ - petalwidth : 花弁の幅 上記のデータを持った150のデー タセット とロジスティック回帰を使って学習をさせてみました。 しかし、学習をさせるだけでは意味がありません。 学習の成果を見るために、10分割交差検定を用いて判別制度を見ていきます。 wekaならここまでやってくれるのでお手軽です。 検証結果の抜粋です。 === Stratified cross-validation === === Summary === Correctly Classified Instances 144 96 % Incorrectly Classified Instances 6 4 % Kappa statistic 0.94 Mean absolute error 0.0287 Root mean squared error 0.1424 Relative absolute error 6.456 % Root relative squared error 30.2139 % Total Number of Instances 150 === Detailed Accuracy By Class === TP Rate FP Rate Precision Recall F-Measure MCC ROC Area PRC Area Class 1.000 0.000 1.000 1.000 1.000 1.000 1.000 1.000 Iris-setosa 0.920 0.020 0.958 0.920 0.939 0.910 0.970 0.933 Iris-versicolor 0.960 0.040 0.923 0.960 0.941 0.911 0.975 0.933 Iris-virginica Weighted Avg. 0.960 0.020 0.960 0.960 0.960 0.940 0.982 0.955 学習による全体の判別制度96%、 それぞれの正解に正しく判別することができる確率が Iris-setosa : Iris-versicolor : Iris-virginica = 100％ : 95% : 92% という結果が得られました。 テストデータということもありなかなかの好成績ですね。 お試し2： 教師なし学習 教師あり学習 と同じようなデータで試してみます。 ただし、 教師なし学習 では正解データは必要ないため削除しておきます。 今回はk平均法による クラスタリング を行ってみました。 元データが3種に分類されていたので3 クラスタ に分類されるように設定しました。 テストデータとはいえ、綺麗に分類されるわけではなさそうですね。。。 ここで綺麗に分類するような学習ができれば、新たなデータを得た際にどこに分類するかを判別できるようになるわけですね。 かなりざっくりですが、数値や画面をみて少しだけイメージできました。 まとめ 今回は 機械学習 について簡単にまとめてみました。 しかしながら、この記事の内容は 機械学習 の表面をなぞった程度でしかありません。 今回のような内容をしっかり把握しておらずとも、はじめに述べたような Amazon Machine LearningやAzure Machine Learning Studioを利用することで簡単に 機械学習 は利用可能な世の中になりつつあります。 ただし、効率よく 機械学習 を取り入れるためにも、どんな方法が何に適しているのかは知っておくべきでしょう。 次回は今の 機械学習 の流行りをテーマに投稿してみようかと思いますのでお楽しみに。 *1 : 教師あり学習 、 教師なし学習 と同じレイヤーで分けられる場合もあります。 *2 : https://www.cs.waikato.ac.nz/ml/weka/

ラク スは「 IT技術 で中小企業を強くします！」をミッションに掲げ、 メール共有・管理システムのメールディーラーから始まり、経費精算システムの楽楽精算に至るまで、 延べ40,000社を超えるお客様に自社開発した クラウド サービスを提供してきました。 今回（9/13(木)）は、 ラク スで主力 クラウド サービスの開発を牽引するエンジニアによる トーク セッションと交流会を開催します。 クラウド サービス開発のエンジニアとして活躍している方はもちろん、 クラウド サービス開発にご興味をお持ちのエンジニアの方も気軽にご参加頂ければと思います。 自社開発ならではの技術・運用ノウハウや、新しい取り組みの成果や失敗談など ご参考にして頂ける情報を積極発信していきたいと考えております。 このイベントが新しい気づきや成長につながる機会を提供する場になるとともに、 ラク ス社員と参加者の皆さま、また参加者の皆さま同士で新たなつながりが生まれるきっかけになれば幸いです！ 開催概要 【日時】2018/9/13(木) 19:30～21:30(開場は19:00) 【会場】 ラク ス 東京本社 （〒151-0051 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス] ） 【定員】30名 【申込み】 connpass 【参加費】無料 【主催】 ラクス 今回の トーク テーマ 終わらない スクラム 　～楽楽精算のサービス拡大を支える スクラム 開発の取り組み 大塚正道（おおつかまさみち） ラク スでは、まだ多くの開発チームが ウォーターフォール 型の 開発プロセス を採用していますが、 一部のチームで スクラム による アジャイル 開発に取り組んでいます。 今回は楽楽精算チームでの取り組みを紹介します。 実際にやってみると様々な問題が発生しました。問題解決に向けたアクションや取り組みを通じて得た知見、今後の課題等を事例を交えてお話しします。 テッ クリード （自称）としてのやっていき！　～ iOS アプリ開発 チームを率いて 川並裕（かわなみゆう） 若手エースエンジニアが初めての iOS アプリ開発 でテッ クリード として奮闘したお話しです。 iOS アプリ開発 は、自身も初、メンバーも初、しかも短納期（3ヵ月．．．）。 この デスマーチ を予感させる不利な条件下で、テッ クリード としてどのようにチームをリーディングしたのか。 様々な事例を交えてご紹介します。 流行の開発手法ChatOpsとは　～楽楽明細チーム/ChatOpsでルーティン作業をまるごと自動化～ 三田英一（みたえいいち） Jenkinsの導入で自動化が進んだけど、「Jenkinsを毎回開くのは面倒」、「アカウントの作成も面倒」、「非エンジニアに使ってもらうにはちょっとハードルが高い」。 そこで導入したのがChatOps! Slack互換のチャットツール「Mattermost」でルーティン作業を丸ごと自動化しました。 利用した bot ツール、システム構成、Hubot スクリプト の実例など、ノウハウを余すことなくご紹介します。 タイムテーブル 19:00 開場・受付開始 19:30 イベントスタート 21:30 終了予定 トーク が終わり次第、交流会に移ります。 交流会では、フィンガーフード、ドリンクをご用意致します。 お気軽にご参加ください。 エントリー方法 [connpass] よりエントリーをお願いします。 ※当日はお名刺2枚ご持参ください ※提供可能な設備： Wi-Fi 、電源 会場 ラク ス　東京オフィス2F セミ ナールーム 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス]

はじめに こんにちは、 @rs_tukki です。新卒2年目です。 前回の記事は以下をご覧ください。 tech-blog.rakus.co.jp また、以前に書いた記事がじわじわアクセス数伸びてきているみたいです。ありがとうございます！ tech-blog.rakus.co.jp さて、本題に入りましょう。 社会人として2年目に入り、テストの結果を資料にまとめたり、バグ修正の対応方針を伝えたりと、自分のやったことを先輩や上司に報告、発表する必要性が増してきたように思います。 自分は今まであまり説明やら発表やらが好きではなかったのですが、今では得意というほどではないにしろ、徐々に苦手意識はなくなってきました。 今回は、エンジニアとして必須スキルである説明や発表の苦手意識を取り払うための1つの手段、 LT についてのお話です。 はじめに Lightning Talks(LT)とは？ 何故LTが有効なのか 「説明する」という行為の練習になる 色んな技術の知見が得られる 人と繋がる機会になる まとめ 参考 Lightning Talks(LT)とは？ ではまず、 LT とは何でしょうか？ 困ったときの Wikipedia 先生。 ライトニング トーク （英: Lightning Talks）とはカンファレンスやフォーラムなどで行われる短いプレゼンテーションのこと。様々な形式があるが、持ち時間が5分という制約が広く共有されている。 形としてのライトニング トーク は1997年の Python カンファレンスで初めて行われたとされている。[1]その時点では単に「ショート トーク 」と呼ばれていた。「ライトニング（Lightning：稲妻、電光石火）」という言葉が用いられるようになったのは、2000年6月に行われた YAPC 19100 Conferenceからとされている。[2]その後技術的なカンファレンスに於いて、この言葉が浸透するようになっていった。 LTというのは簡単に言えば短いプレゼンのことです。 プレゼンテーションというと、会社内では新しい企画の説明会、会社外では新商品の発表会…などなど、どちらにしても1時間以上は時間をかけてじっくりと話すイメージがあるかと思います。 ですが、LTは「稲妻 トーク 」という意味からも分かる通り、持ち時間はだいたい5分、長いものでも10分とごくわずかです。 LTの内容自体はある程度のテーマこそ指定されるものの、技術的な トーク に限定されないことも多く、皆さん限られた時間の中で自分の好きな話を自由に発表しています。(そして勉強会などでない限りは大体お酒がついてきます) connpass 等の募集サイトでも頻繁にLT会が開催されていたりします。 reedex.connpass.com connpass.com engineers.connpass.com 何故LTが有効なのか 最初に、LTとは 説明や発表の苦手意識を取り払うための1つの手段 と説明しました。 LT…というより発表自体に苦手意識のある人にはハードルが高いかと思いますが、それでも私としては、社内、社外問わず新卒のうちからぜひLTに登壇してみてほしいと思っています。 「説明する」という行為の練習になる LTの特徴は、何と言ってもその短さです。 「長い時間話すのに耐えられない」「目を合わせられない」という人でも、大体5～10分経ってしまえば強制的に終了ですから、割と失敗しても恥ずかしくないです。 社外のLTでヤジが飛ぶのが怖い…という人もいますが、大抵社外のLTは Twitter で実況されるので見ている人もヤジを飛ばしている余裕はないと思います(笑)。 togetter.com そんな環境の中で、自分が学んだことや気になっていることを短い時間で発表することで、資料の作成に慣れ、分かりやすい伝え方に慣れ、いずれは社内で人に説明することにも慣れていけるのではないかと思っています。 色んな技術の知見が得られる 新卒として会社に入社した皆さんは業務で使う技術を学んでいるかと思いますが、部署が異動になればまた別の技術が必要になるでしょうし、転職ともなれば今持っている技術では太刀打ちできないこともあるでしょう。 そんなときに、 新たな技術を(名前だけでも)知っている、というのは大きな武器になり得ます。 話をする側だけでなく、聴く側としても様々な人の様々な内容のLTを聴く中で、エンジニアとしての知識がどんどん身についていけると思います！ 人と繋がる機会になる こと社外のLTで言いますと、これも結構なメリットです。 先ほどLTの内容は Twitter で実況されると書きましたが、発表が終わり、懇親会になった後で気になった発表者にお話を聴いてみるのもいいと思います。そこから SNS 等で繋がることもありますし、話が盛り上がる中で別の勉強会に誘っていただけることもあります。 新卒の間はどうしても社外の人と繋がる機会が少ないかと思いますが、こういったLTの機会から輪を広げていってみてはどうでしょうか？ まとめ 今回の記事で言いたかったことは一つです。 「説明力」の向上のために、LTに積極的に登壇しましょう！ そして、 皆さんの面白い話をぜひ聞かせてください！ 以上です。ご視聴ありがとうございました。(LT風に) 参考 ライトニングトーク - Wikipedia IT業界でよく聞く「LT」ってなんなの？3つのメリットを知って、きみもLTしてみよう！ | トビラシステムズ株式会社

はじめに FM_Harmonyです、8月2回目の投稿になります。 ↓前回の記事はコチラです tech-blog.rakus.co.jp 今回はgitコマンドのfetchについて、学んだ内容をまとめてみました。 今回の記事を書こうと思ったきっかけは pullとfetchの違い について尋ねられた時、細かいところまで答えられなかったことです。 （大雑把に fetchはデータを持ってくるだけ、pullはmergeまで行う ということまでは答えられたのですが...） そこで、この機会にfetchについて学びなおしてみました。 Gitを学び始めたばかりの方や、復習したいと考えている方の参考になれば幸いです。 はじめに fetchの説明...の前にリモート追跡ブランチの説明 本題、fetchの説明 merge, pullの説明 おわりに 参考 fetchの説明...の前にリモート追跡ブランチの説明 fetchを説明するうえで リモート追跡ブランチ の説明は欠かせません。 では、リモート追跡ブランチとは何でしょうか？ リモート追跡ブランチ（Remote-tracking branch）とは、ローカル リポジトリ にあって リモー トリポジ トリの状態を保持する参照 です。 簡単に言うと、リモートにある同名のブランチと同一のコミットを指すブランチの事です。 このブランチの特徴として、リモート追跡ブランチのブランチ名は( リポジトリ 名)/(リモートのブランチ名)で固定される、ユーザが変更をコミットするなどしてブランチが指すコミットを直接操作することはできない、といったことが挙げられます。 そのため、ローカル リポジトリ からもリモート追跡ブランチを通じて、リモー トリポジ トリの変更を確認する、ローカルの作業ブランチにリモートの変更を取り込むといったことができるようになっています。 しかし、ローカル リポジトリ は24時間365日ネットワークに接続はしていません。 そのため、ローカル リポジトリ にあるリモート追跡ブランチは常にリモートのブランチと同じものを指すわけではありません。 誰かがリモートのブランチに変更をpushしてしまうと、リモート追跡ブランチとリモートにある同名のブランチが指すコミットが異なるということが発生します。 この状況を解消するために使うコマンドが fetch なのです！ 本題、fetchの説明 fetchコマンドを利用することで、リモー トリポジ トリの変更をローカル リポジトリ に取り込み、リモート追跡ブランチを同期することができます。 例えば、下記のコマンドを利用すると、リモー トリポジ トリ origin の master ブランチについて、変更をローカル リポジトリ に取り込み、リモート追跡ブランチ origin/master をリモートブランチ master と同期させます。 $ git fetch origin master この時点では、ローカルの作業ブランチに変更は反映されません。 そのため、例えばローカルのブランチ master に対してコミットを行っていた場合、リモート追跡ブランチとローカルのブランチとが分岐することになります。 merge, pullの説明 さて、こうして取り込んだリモートブランチの変更をローカルブランチに反映するにはどうすればよいでしょうか？ その方法の一つとして、 ローカルブランチにリモート追跡ブランチをmergeする という方法があります。 例えば、 origin/master とローカルブランチ master が分岐する場合、下記のコマンドを実行することで図のようなブランチ構造になります。 $ git checkout master $ git merge origin/master また、同じコマンドを実行した場合でも、 origin/master がローカルブランチの先のコミットを指しているだけで分岐していない場合、 master の指すコミットを変更するだけのいわゆる Fast-forward マージを行います。 別の方法として、 pull コマンドを利用するというものがあります。 これは、 fetch + merge と同じ動作を行います。 すなわち、 $ git checkout master $ git pull origin master というコマンドは、下記のコマンドと同義です 。 *1 $ git checkout master $ git fetch origin master $ git merge origin/master おわりに fetchについて簡単にまとめてみたのですが、いかがでしたでしょうか。 個人的にはリモート追跡ブランチの存在を知らなかったため、この機会に知ることができて良かったと思います。 今回の記事作成を通して、Gitについてまだまだ知識が足りないことが分かったので、また別の機会に他の操作(addやpush, etc...)について、機会を作って調べてみようと思います。 参考 Git - リモートブランチ Gitの公式によるリモート追跡ブランチとfetchの説明です エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : 厳密には同義ではなく、masterにmergeされるのはFETCH_HEADというfetchした際に作成されるブランチです。

id:radiocat です。既に記事で紹介されていますが、大阪オフィスの開発部内で毎月開催しているビアバッシュで『タスク管理のやりかたとツールの使いかた』というタイトルで発表をしました。 tech-blog.rakus.co.jp 今回はこの発表で紹介した スクラム 方式のタスクマネジメント手法を改めて記事にまとめます。 個人のタスクマネジメントとは？ そもそも個人のタスクマネジメントというのはいつ、何を、どう管理するのでしょうか？ 家族と生活している人は家族に頼まれた買い物を会社帰りに買って帰るために買い物というタスクを管理したいかもしれません。反対にプライベートは自由気ままに過ごしたいので細かい事まで管理したくない人もいるかもしれません。 ツールの選びかた 何をどこまで管理したいのかは人それぞれなので、ツールの選びかたもその人の生活スタイルや環境によって変わってきます。 世の中には様々なタスクマネジメントツールがあります。ネット上ではTrello、Todoist、asanaといったサービスを使った事例をよく目にします。私の所属するチームではTrelloを使っています。 trello.com ja.todoist.com asana.com 私の場合は家族と生活をしていて自分の時間は限られているのでスキマ時間は大切です。また、 スマホ は Android で、カレンダーやメールは Google のサービスを使うため、これらと連携した使い方もポイントになります。 また、性格的にプライベートをあまりキッチリ管理するのは息苦しく感じるため、スキマ時間を使うにしても手軽さやカジュアルさも重要です。 Google Keepの使い方 以上を踏まえて私が選んだツールが Google Keepです。 Google Keepはタスク管理ツールというよりはメモツールですが、それが逆にシンプルで個人でタスクを管理するならこのレベルで十分と感じています。 スケジュールとの連携など Google の他のサービスとも連携できます。 スマホ のホーム画面に表示される ウィジェット や、駅などの特定の場所に到着したら通知してくれるリマインド機能も便利です。 外出中であれば音声で登録したり、 スクリーンショット を撮って残りは自宅でという、その場の状況に応じた使い方も可能です。 スクラム 方式のタスクマネジメント実践方法 そして、 Google Keepを使い、 スクラム のやり方にヒントを得たタスク管理の手法が今回紹介する スクラム 方式のタスクマネジメントです。 スクラム 同様にシンプルで軽量なマネジメント手法です。 バックログ のように重要なものから1列に並べる Google Keepはメモツールとして登録したメモが縦一列に並ぶようになっています。そのため重要なものから順番に並べるだけで バックログ のように扱うことができます。 バックログ のように「完了した／していない」だけを管理 スクラム ではスプリントの期限までに完了していないタスクはたとえ途中まで完成していたとしても未完了として扱います。個人のタスクマネジメントも同様です。買い物をしたり、ブログに記事を書くというタスクが途中まで終わっていてもあまり意味がありません。そのため、完了したかどうかだけを観測するようにします。また、完了したタスクは「 アーカイブ 」することで一覧からは除外されますが、メニューから アーカイブ 一覧を表示することができるためいつでも完了したタスクを確認することができます。 タイムボックスを決めて繰り返す 私は毎週日曜日に1週間を振り返って、翌週のプランニングをしています。プランニングでは1週間でできそうな範囲の上位のタスクだけを重要な順に並び替えて、リマインドを設定したり、タスクの内容を整理します。 スクラム でもユーザーストーリーを具体化したり完了の定義を明確化したりして バックログ をReadyにしますが、個人のタスクも同じようにブログのアウトラインをメモしておいたり、 Google Keepのリスト機能を使ってやることの詳細をチェックリスト化してReadyにします。 スクラム 開発とは違うところ スクラム 開発とは違って個人のタスクマネジメントではやらないこともあります。 全体の見通しを立てない 何かを開発したりリリースするわけではないので、個人のタスク管理には終わりがありません。そのため全体の見積もりやバーンダウンチャートを作って見通しを立てるようなことはしません。 個々のタスクを見積もらない 全体の見通しを立てる必要がないので個々のタスクも見積もりません。ただし、個々のタスクがどれくらい時間がかかるかなどを細かく管理したい人は見積もりをしてもいいかもしれません。 これらはあくまで私の場合はやる必要がないと感じていることですが、必要に感じる場合はやりかたをアレンジしてみても良いかもしれません。その場合は Google Keepではできないこともあるので、上記で紹介したTrelloなどの本格的なタスク管理ツールを使うほうが良いかもしれません。 おわりに この手法はやりかたはシンプルですが、プロセスがきちんと回るようにするためには、日々の状況チェックや1週間単位の完了確認、ふりかえりをどこまでやるかなどを、自分でルールを決めてブラッシュアップする必要があります。理解は容易ですが、習得が困難な点も スクラム と同じです。 今回は私が愛用している Google Keepを使ってのやりかたを紹介しましたが、同様のやりかたは他のツールでもできるかもしれません。自分の使いやすいツールで実践してみると良いでしょう。ただ、 Google Keepは軽量で扱いやすいツールなので、今回紹介した手法に向いているツールだと思っています。私と同じように普段使うツールは Google のサービスが中心で手軽にタスクマネジメントしたいという人は Google Keepを使って スクラム 方式の個人のタスクマネジメントを実践してみてはいかがでしょうか。 当日発表したスライドは公開していますので良ければご覧ください。 speakerdeck.com 告知：Meetupで スクラム 開発について発表します 当ブログでも既に告知済みですが、9/13に開催される弊社主催のMeetupで楽楽精算の開発チームが実践している スクラム 開発の取り組みについて発表します。今回の発表は過去の 社内イベント の資料がベースですが、資料をアップデートして当時はリリース前で話せなかった内容や、プロジェクトのその後の状況についても話をする予定ですのでぜひご参加ください。 rakus.connpass.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

kuwa_38です。 ラク スでは月１回のペースで開発メンバーの交流会としてビアバッシュを開催しています。 ビアバッシュとはビールなどと軽食を片手にフランクに技術内容について発表したり語り合う交流会です。 （7月分のビアバッシュについては下記の記事をご覧ください） tech-blog.rakus.co.jp 大阪開発部のビアバッシュでは、決められたテーマに沿った発表を行う「テーマ枠発表」と自由なテーマで発表を行う「LT（Light Talk ）枠」が存在します。 今月のテーマは「 ツール特集 」です。各々が使用している便利なツールや業務効率化のために使っているツールについて発表して頂きました。 本記事ではテーマ枠、LT枠（自由発表）それぞれの発表についてご紹介します。 テーマ枠（ツール特集） ツール紹介 Node.jsとnpmの関連ツール My Powerful Scripts タスク管理のやりかたとツールの使いかた 個人的に使っている便利ツール 業務効率UP iOSアプリ LT枠（自由発表） インフラエンジニアの怖い話 トウダン・ジャーニー おわりに テーマ枠（ツール特集） テーマ枠で行われた6件の発表についてご紹介します。各発表の紹介を少し記載した後、発表内で述べられていたツールを列挙します。 ツール紹介 Snipping Tool や Tampermonkey の スクリプト など業務で使用している便利なツールや スクリプト を紹介して頂きました。業務でどのような時に使っているのかというお話もあったため、使う場面が想像し易すく、他のチームの方がどのような業務や進め方をしているのかといった点でも参考になる発表でした。また、 Snipping Toolが廃止される ことは知らなかったため驚きでした。 Snipping Tool phpStormのDiff Node.jsとnpmの関連ツール Windows でのNode.jsやnpmのバージョン管理ツールであるNodistやnpmのバージョン5.2.0で導入されたnpx、自作したパスワードを生成するツールについて紹介して頂きました。npmを使用する従来の方法と、npxを使う方法を前で実践して下さったため、npxを使うことでワンラインで簡潔に実行できることがわかる発表になっていました。 Nodist npm npx パスワードを⾃動⽣成するツール My Powerful Scripts Tampermonkeyで自作した便利な スクリプト についてランキング形式で発表して頂きました。GitLabでのレビューを簡単にするために優先度を付加するボタンを表示する スクリプト やMattermostで未読のみを表示する スクリプト などを紹介して頂きました。「Mattermostで未読のみを表示する スクリプト 」はチャットがスッキリして見易くなるので私も普段から使わせてもらっています。 Tab キー押下時に、タブ（Hard Tab）の代わりに、スペース x 4（Soft Tab）を入力するスクリプト GitLab の Merge Request の Code Review コメントに対応優先度を付加する スクリプト Mattermost で未読チャンネルだけを表示する スクリプト タスク管理のやりかたとツールの使いかた 色々なタスク管理ツールを紹介した後、現在使っているタスク管理ツール（ Google Keep）とその使い方、何が良いのかについて発表して頂きました。業務向きというよりはプライベートでのタスク管理にフォーカスしたお話でした。 Google Keepでは Googleカレンダー などの他の Google アプリと連携ができること、どこでも見れることが便利とのことです。また、メモのように手軽に書き込み週末に優先順位を変更し、次の1週間のタスクを決めているそうです。 Google Keep （発表者おすすめ） Trello （今の主流） Todoist asana Toodledo Google Tasks Microsoft To-Do 個人的に使っている便利ツール コピー履歴を保存してくれるツール（Clipy）や Markdown 記法を用いて綺麗に書くことのできるエディタ（Typora）、 Mac 上のアプリ・ファイルなどを検索できるツール（Spotlight検索）など業務の中で個人的に使っている便利なツールの紹介を行いました。業務で Markdown 記法を用いることが多いため、TyporaやMarpは愛用しています。 Clipy Typora Spotlight検索 Marp 業務効率UP iOS アプリ 業務効率化のために使用している iOS アプリについて紹介して頂きました。現在、発表者の方が行っている業務の関係上、Office LensやSkitchなどの画像加工アプリがメインでした。おまけとして、文字に濁点を付けていく、Dakutenといった面白いアプリの紹介もあったため、 堅苦しい ものでなく聞き手から笑いの起こる発表でした。私も情報共有のために スクリーンショット をとり、説明を付加することは良く行うためいつくか試してみようと思います。 Office Lens Skitch Key 楽楽精算 モザイク ぼかし&モザイク加工アプリ Dakuten LT枠（自由発表） LT枠で行われた2件の発表についてご紹介します。 インフラエンジニアの怖い話 夏といえば怖い話。この発表ではインフラエンジニアが実際に起こした、または、起こすと肝が冷えるミスについてご紹介頂きました。発表中は笑いが起こっていましたが、 rm -rf / やshutdownコマンドなど、誤って実行してしまうと笑いごとでは済まないミスについてご紹介頂きました。rmコマンドやshutdownコマンドを業務で使ったことはありませんが、機会があるときは本当に気を付けないといけないなと考えさせられる発表でした。 トウダン・ジャーニー php conference 2018 Kansai に登壇したことについて、登壇が決まるまで、業務として登壇するにあたり準備したこと、資料作成などについてご説明頂きました。公開リハーサルや当日の発表に至るまでの発表者間でのタスク管理や情報共有など、登壇までの過程や裏側について知ることができる発表となっていました。 （登壇された様子については下記の記事を御覧ください） tech-blog.rakus.co.jp おわりに 今月も様々なタイプの発表が聞くことができて、大変充実したビアバッシュになりました。 次回のテーマは「 他人のスライド発表会 」です。他の人が作ったスライド、面白かった記事やスライドを用いて発表して頂きます。今までにない発表形式なので、どのような発表がされるのか楽しみです。

ラク スは「 IT技術 で中小企業を強くします！」をミッションに掲げ、 メール共有・管理システムのメールディーラーから始まり、経費精算システムの楽楽精算に至るまで、 延べ40,000社を超えるお客様に自社開発した クラウド サービスを提供してきました。 今回（9/13(木)）は、 ラク スで主力 クラウド サービスの開発を牽引するエンジニアによる トーク セッションと交流会を開催します。 クラウド サービス開発のエンジニアとして活躍している方はもちろん、 クラウド サービス開発にご興味をお持ちのエンジニアの方も気軽にご参加頂ければと思います。 自社開発ならではの技術・運用ノウハウや、新しい取り組みの成果や失敗談など ご参考にして頂ける情報を積極発信していきたいと考えております。 このイベントが新しい気づきや成長につながる機会を提供する場になるとともに、 ラク ス社員と参加者の皆さま、また参加者の皆さま同士で新たなつながりが生まれるきっかけになれば幸いです！ 開催概要 【日時】2018/9/13(木) 19:30～21:30(開場は19:00) 【会場】 ラク ス 東京本社 （〒151-0051 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス] ） 【定員】30名 【申込み】 connpass 【参加費】無料 【主催】 ラクス 今回の トーク テーマ 終わらない スクラム 　～楽楽精算のサービス拡大を支える スクラム 開発の取り組み 大塚正道（おおつかまさみち） ラク スでは、まだ多くの開発チームが ウォーターフォール 型の 開発プロセス を採用していますが、 一部のチームで スクラム による アジャイル 開発に取り組んでいます。 今回は楽楽精算チームでの取り組みを紹介します。 実際にやってみると様々な問題が発生しました。問題解決に向けたアクションや取り組みを通じて得た知見、今後の課題等を事例を交えてお話しします。 テッ クリード （自称）としてのやっていき！　～ iOS アプリ開発 チームを率いて 川並裕（かわなみゆう） 若手エースエンジニアが初めての iOS アプリ開発 でテッ クリード として奮闘したお話しです。 iOS アプリ開発 は、自身も初、メンバーも初、しかも短納期（3ヵ月．．．）。 この デスマーチ を予感させる不利な条件下で、テッ クリード としてどのようにチームをリーディングしたのか。 様々な事例を交えてご紹介します。 流行の開発手法ChatOpsとは　～楽楽明細チーム/ChatOpsでルーティン作業をまるごと自動化～ 三田英一（みたえいいち） Jenkinsの導入で自動化が進んだけど、「Jenkinsを毎回開くのは面倒」、「アカウントの作成も面倒」、「非エンジニアに使ってもらうにはちょっとハードルが高い」。 そこで導入したのがChatOps! Slack互換のチャットツール「Mattermost」でルーティン作業を丸ごと自動化しました。 利用した bot ツール、システム構成、Hubot スクリプト の実例など、ノウハウを余すことなくご紹介します。 タイムテーブル 19:00 開場・受付開始 19:30 イベントスタート 21:30 終了予定 トーク が終わり次第、交流会に移ります。 交流会では、フィンガーフード、ドリンクをご用意致します。 お気軽にご参加ください。 エントリー方法 [connpass] よりエントリーをお願いします。 ※当日はお名刺2枚ご持参ください ※提供可能な設備： Wi-Fi 、電源 会場 ラク ス　東京オフィス2F セミ ナールーム 東京都渋谷区 千駄ヶ谷 5-27-11　アグリスクエア新宿2F [アクセス]

こんにちは。エンジニアのmickey-STRANGEです。 今まではめんどくさがりをテーマに、「簡単に○○する方法」を紹介してきました。 tech-blog.rakus.co.jp 今回の記事では、3年目になった私が、これまでのエンジニア生活の中でやっててよかったと感じる「 JavaScript で遊ぶ」ことについてお話したいと思います。 エンジニアになると周りから「勉強しといた方がいいよ」「いろんな技術触っといた方がいいよ」と声をかけられることが多いと思います。 しかし、何から手を付けていいか分からない、どんな技術を、どんな言語を触ってみればいいか分からない、と最初は思うかもしれません。 そういった新人エンジニアの方が勉強と気負い過ぎず、軽い気持ちで「 JavaScript で遊ぶ」ことから始めるメリットについてお話していきます。 実行環境の準備が要らない JavaScript の実行環境はブラウザです。勉強を始めるための環境構築というフェーズが必要ありません。 テスト用のHTMLファイルさえ用意してしまえばブラウザで開くだけで実行してくれます。 ただ、最初はHTMLの記述と JavaScript の記述を同時に考えるのが難しいと思います。そんな時は普段見るサイトのHTML構成をそのまま引っ張ってくることをお勧めします。 実際に公開されているHTML構成なので作り込みがされていて、簡単にしっかりとしたテスト用HTMLを用意することができます。 こうすることで、自分でベースのHTMLを用意しなくても JavaScript の練習が出来るようになります。 環境構築が必要ないのは、とっつきやすさという面でかなりの強さになりますね。 実際に使える業務知識が得られる JavaScript は業務でもよく使う言語です。Web系エンジニアなら当然、画面上の動きは JavaScript で記述することになります。 とはいえ、非同期処理があったり、画面上のユーザ操作との兼ね合いがあったりで、実行順が分かりにくくなる傾向があり、私の周りでも JavaScript に対して苦手意識を持つメンバがちらほらいます。 私も最初はそうでしたが、 JavaScript でちょくちょく遊んでいた結果、大規模な画面改修タスクを担当することになっても怯まなくなり、今では苦手意識は自分ではほぼないと感じています。 また、 JavaScript はもはやブラウザ上だけの言語だけではなく、 JavaScript ベースの言語でネイティブアプリの画面を構成できたり、サーバサイドの処理を記述したりすることもできます。 以前投稿されたGASも、 JavaScript ベースの言語だったりします。 tech-blog.rakus.co.jp JavaScript は他の言語と比べて、得た知識がどこかで業務に繋がる可能性の高い言語であるといえるでしょう。 小さな改善がすぐにできるようになる 普段見るサイトやブラウザアクセスするシステムの画面に対して、使いにくいなーめんどくさいなー、と思ったことはありませんか？ そんな時は chrome の 拡張機能 のTampermonkeyがおすすめです。 chrome.google.com Tampermonkeyは、指定したURLのページが開いたときに自動で JavaScript を実行してくれる 拡張機能 です。 これを利用することで、普段使うシステムの画面をちょっと使いやすくする、といったことが気軽に行えます。 また、作成した スクリプト は他のメンバのTampermonkeyの画面に貼り付けしてもらうだけで共有が出来るので、小さな改善をすぐチームに共有することが出来ます。 私も社内の基幹システムの膨大な数のメニューをいい感じに検索出来る スクリプト を作成して、チーム内に共有していたのですが、いつの間にか広まっていき、他のチームの方から感想をいただくこともありました。 用事がない限り他チームの方に話しかける機会はあまりないので、こういった面でもとてもよかったと思います。 さいごに 私が感じた「 JavaScript で遊ぶ」ことで得られたよかった点をまとめてみました。いかがでしたでしょうか。 とっつきやすく 、 業務に繋がりやすく 、 改善にもつながる 、というのはかなりのメリットだと思います。 また、 JavaScript は ajax を用いることで他システムの API を叩くことも可能ですので、1つの スクリプト 内で出来ることの幅がかなり広いです。 「勉強しよう」と思うと難しいかもしれませんが、このページのここをこうしたいな、を原動力に「 JavaScript で遊ぶ」感覚で手を付け始めると楽しさが分かっていただけるかと思います。 楽しいという感覚になってしまえば勝手に持続するので、遊び感覚で スキルアップ してみましょう！

はじめに エンジニアのFM_Harmonyです。 Rakus Developers Blogには、何度か記事を投稿させていただきました。 tech-blog.rakus.co.jp ↑前回の投稿記事はこちらです さて、今年も早いもので7月初旬に開発部へ新卒社員が配属されました。 また、同時期にオフショア先の ベトナム 子会社から出張者の受け入れを行いました。 そこで先日、新卒社員＆ ベトナム メンバーの歓迎会を開催いたしました！ 歓迎会の内容をまとめましたので、みなさまに ラク ス社内の雰囲気が伝われば幸いです。 交流の様子 まずは自己紹介から行いました、名前と顔を覚えていただくのは重要です。 今回は、普段のビアバッシュで用意しているものよりも、豪華な食事をご用意させていただきました！ 参加された方に伺ったところ、みなさんご満足いただけたようで何よりです。 普段はなかなか話す機会のない、先輩や管理職の方ともこうして話す機会を設けることができるのが、歓迎会のよいところです。 新卒の方も積極的に話しかけています。 ベトナム のメンバーの方はすっかり日本のメンバーとも打ち解けられようで、こうして記念撮影も行っておられました。 アイスブレイク：ペーパータワー 会の終わりごろには、アイスブレイク（Ice break）として ペーパータワー というゲームを行いました！ 簡単に説明しますと、A4用紙20枚を使って最も高いタワーを作ったチームが勝利するというゲームです。 では、ゲームの様子を写真とともにご覧ください。 ルール紹介 今回は以下のようなルールでゲームを実施いたしました。 1チーム4～5名で行う 2回ゲームを行い、それぞれで勝利チームを決定する 作戦を検討する時間は5分、実際にタワーを組み立てる時間も5分とする 利用して良いのは、A4用紙20枚および紙テープ1m分のみとする ↓ルールはこちらのサイトを参考にさせていただきました heart-quake.com ↓ルール紹介の様子、彼の厳正な審査により各チームの勝敗が決まります 作戦タイム ↓あるチームの作戦会議の様子、このプランニングにより作業がスムーズに行えるか決まります ↓別のチームの様子、紙を片手に作戦会議中です ↓ ベトナム メンバーの方々は1チームとして集まっていただきました 続いて実際の組み立ての様子といきたかったのですが、残念なことに撮影担当者もゲームに参加していたため、組み立て時の写真はありませんでした… そのため、結果発表の様子に移りたいと思います。 結果発表 ↓計測の様子、タワーが倒れないようみなさん必死です ↓中には予想外の組み立て方をされたチームも！ 肝心の結果はどうなったかというと、なんと 2回とも ベトナム メンバーチームの勝利 でした！！ ↓成果物と一緒に記念撮影、みなさんおめでとうございます！ おわりに というところで、今回はここまでとさせていただきます。 この記事を通して、みなさまに ラク スという会社の雰囲気を伝えることができたのであれば幸いです。 今回は私もイベント開催を担当したのですが、本当に楽しい歓迎会を開催することができて良かったです。 また、新人や ベトナム の方だけでなく、私たちも普段あまり話す機会のない方とお話しできたことも良かったと思いました。 最後になりますが、新卒の方にはこれからの活躍を、 ベトナム の方には日本で貴重な経験が得られるよう、心から祈っております。