id:radiocat です。2/26に大阪オフィスで実施したMeetupでは楽楽精算開発2課のメンバー全員で半年かけて準備をして発表しました。今回はMeetupの内容と合わせて、全員で役割を持って取り組んだ勉強会発表プロジェクトの内容をご紹介します。 rakus.connpass.com プロジェクトの経緯 私たち楽楽精算開発2課は成長サービスを支える開発組織として、常に新しい領域の開発に取り組んできました。一方で、開発部門としてMeetupというイベントを継続的に開催していくことになり、私たちのチームがどう関わっていくべきかを考えた時に、チームでイベントのコンテンツを作り上げるという新しいチャレンジを行ってその知見を残すことが私たちのチームらしい取り組みではないかと考えました。そして2月のMeetup発表者としてチームで名乗りを上げてプロジェクトをスタートさせました。 2018年10月にプロジェクトスタート 前回のMeetup の開催翌月にキックオフを行いました。 まず、どういうイベントにしたいかを全員で話し合って、発表テーマの候補を出しました。その中からいくつかのテーマに絞り込んでそれぞれのメンバーがいったん持ち帰り、次回までに発表テーマを検討することにしました。 11月 前月にそれぞれが持ち帰って検討した発表テーマと発表のイメージを共有して、イベントの全体像をすり合わせしました。 この時にそれぞれのメンバーが担当する発表内容の大枠が決定しました。若手メンバーは3人1組で発表資料を作って代表者が発表することになりました。 12月 前月に決まった発表テーマと内容の大枠をスライドに落とし込んでアウトラインレベルで中間発表を実施しました。そしてお互いの発表を聞いてフィードバックし合いました。このとき、主力エンジニア、中途社員エンジニア、若手エンジニア、 スクラム マスターというそれぞれの視点で発表するという流れがだいたい確定しました。 1月 ドラフト版レベルのスライドで発表練習して、全員でレビューしました。ここまでは スクラム マスターが最初に発表する流れにしていましたが、「いきなり スクラム マスターが場を引っ張って発表するのはなんか違うよね」となって、 スクラム マスターは最後に発表する流れに変更しました。 2月 本番さながらの練習会を実施し、資料と発表内容の精度を上げていきました。チームで整合性を合わせる部分があるため前日までスライドのチェックや修正を行って当日を迎えました。 発表したスライド 当日のスライドと合わせて発表に関わったメンバーのコメントをご紹介します。 大阪開発チームが取り組んだ スクラム 1年目の開発現場 まずはチームを取り巻く状況と、 スクラム に取り組んできた経緯を簡単にご紹介しました。 1. 開発チームク エス ト 楽楽精算開発チームの岡本です。 Meetupでは「開発チームク エス ト」というタイトルで、開発チームが歩んだ１年間の振り返りを発表しました。 タイトルは直訳すると「開発する仲間たちで探求する」になります。 探求とは「さぐり求めること。さがし回ること。※1」らしいですが、この1年はまさに仲間たちで課題の解決方法を探し回った1年でした。 中でも一番深刻だった課題がチームの分断問題です。若手とベテラン、新規メンバーと既存メンバーで知識量に差があり、フォローによる稼働圧迫が慢性的に発生していました。我々のチームでは、モブプロ／モブワークの手法を採用して、この課題を克服しようとしました。 当初は知識のあるメンバーがモブを主導することが多かったのですが、回数を重ねるうちにチームの平均知識が上がっていき、今は知識のあるメンバーが一方的に発言するというシーンは少なくなっています。また、モブで開発を進めた結果、必然的にメンバー個々へのフォローも少なくなりました。 ところで、モブプロとは全員でひとつの課題に取り組む開発手法ですが、これを言い換えると「開発する仲間たちで(ひとつの課題を)探求する」と言えるんじゃないかと思います。つまり、色々書いていましたが、今回の発表の結論としては「モブプロやってみると意外と良かった」に尽きると思います。 ※1 出典:精選版 日本国語大辞典 2. 中途社員がチームに参加しました 中途入社の福岡です。昨年5月に入社してからの1年間について発表しました。 当初は、入社してからの苦労話を発表しようとしたのですが、全く思い出せず、最初は何を話せるだろう、どういった価値を参加者へ提供できるだろうと悩みました。そこで発想を変え、どうして苦労話がでてこないのか？から、 スクラム チームが実施しているイベントを振り返り、これがなかったら苦労しただろうなという事例をピックアップしました。 またイベントだけでなく、HRTという考えから得るもの、これまでの自分を反省することが多々ありました。このブログを見た方は「HRT」についてだけでも、 Google先生 に聞いてみてください(笑) 今後チームに新たにメンバーを迎えられる方、またチームへ参加される方に何か響くものがあればと思います。 3. 学習 スクラム をやってみた件 入社3年目の中野です。私は「若手エンジニア」パートの発表を担当させていただきました。 チームの教育課題に スクラム を適用するという内容で登壇させていただきましたが、今回のMeetupに参加された方の多くは、プロダクトの開発に スクラム を適用することはあっても、新人の教育課題にまで スクラム を適用した例はあまり無いのではないかと思います。 実際、弊社のチームでも教育課題に スクラム を適用したのは今回が初めてでした。「教える側」は スクラム の経験が約1年と浅く、「学ぶ側」は スクラム の経験が皆無という状況で、お互い様々な苦労がありました。登壇の際にも触れましたが、最初の頃はタスクの残量がバーンダウンせず、どうすれば計画通りタスクを消化できるかを考える日々が続きました。スプリント内で確実にタスクを完了させるために1つのタスクの粒度を小さくしてみたり、前提知識を補うための事前学習的なタスクを作ってみたり、試行錯誤を繰り返しました。思い返せば スクラム において最初の難関はこの「バーンダウンしない問題」なのかもしれません。 今回は上記のような問題が発生するたびに「教える側」と「学ぶ側」が一緒になって解決策を考えたので、お互いにとって学びや成長があったと思っています。まだまだ スクラム 初学者の私が言うのも恐縮ではありますが、もし貴社で新人教育に スクラム を取り入れようと考えておられるならば、今回の発表が少しでも参考になれば幸いです。 入社二年目の桑原です。 私は学習 スクラム に教える側として参加し、Meetupでは資料作成に協力しました。ここでは発表であまり触れることのできなかった、学習 スクラム の中で、教える側がプロダクトオーナー(以後PO)や スクラム マスター(以後SM)のロールを体験して感じたことについて記載したいと思います。 私は1年ほど スクラム の開発に参加してきました。もちろん、POやSMの立場の人とも関わることがありました。そのため、学習 スクラム 実施前は、それなりにロールを担うことができるだろうと考えていました。しかし、実際に学習 スクラム が始まると全然ダメでした。例えばPOを担当した際のプロダクト バックログ 1つに着目しても、 バックログ の順番やどこまで作りこむか、エラー時の動作等、考慮が足りないことは多くありました。結果、最初のスプリントは計画段階で躓き、開発時間を圧迫、進捗も悪くなり、次のスプリントの準備も不十分になるという悪循環に陥っていました。最終的に、イベントの実施日は決めたものの、そのイベントのゴールは何か、そのゴールのために誰が何をどこまで準備するのかを整理できていなかったことに気づき、各イベントで最低限やることをリスト化、イベントまでに誰が何をするのか整理することで改善しました。 今思い返してみると、POやSMの役割、チームが動きやすいように舵をとることに関して、表面上は知っていた（見ていた）ものの、その役割を果たすためにどのような準備をしているのかが分かっていなかったのだと思います。１年間 スクラム に触れ、少しは分かったつもりになっていましたが、まだまだ学ぶべきことは多いのだと感じさせられました。学習 スクラム という取り組みは、新規メンバーが スクラム に慣れていくという面だけでなく、教える側の若手にとっても、チームがよりよく動くために自分達が何をすべきかを改めて考えさせられる良い取り組みであったと思います。 入社一年目の庄禮です。 「学習 スクラム をやってみた件」で実際に教えていただく立場にあり、中野（登壇者）の資料作成に協力しました。 学習課題を スクラム で回すという初めての取り組みで、「こんなの上手くいくわけがない！」と始める前や始めた当初は思っていました、しかし、 スクラム を回していく中で徐々に改善していき、イベントの役割などを身をもって体感することができたので、結果的に取り組んでよかったと思っています。 この度Meetupの題材にあがって資料作成をおこなうまで教育者側の苦労などは意識できていなかったのですが、資料づくりの中で今後のチームや教育の改善の観点から学習 スクラム を見ることができたので、今回のMeetupでアウトプットすることができて良かったと思っています。 来年、チームに入ってくる新人がいれば私も教育に関わることになるので、今回の反省点や課題点も踏まえて取り組んでいきます。もし機会がありましたら、学習 スクラム の取り組みの進捗・変化をみなさんにお伝えしたいと思います。 4. アジャイル であり続けるためのチームリーディング スクラム マスター担当の大塚です。 9月末に大阪オフィスで1回目のMeetupを開催した時に、次回は私たちのチーム全員で取り組んでみたら面白いのではないかと考え、チームに提案してみたのがきっかけで準備がスタートしました。半年もあれば準備万端で当日を迎えられるかというと、実際はそんなに単純ではありませんでした。業務の合間を縫って少しずつ準備を進める必要がありました。また、半年前から内容が決まっていたわけではなく全員が「これからやること」をイメージして2月に「こういう発表ができそう」というテーマを決めて、仕事でそのイメージに向かって進んでいくことで発表内容も同時に組み立てられていきました。つまり、Meetupに向けて発表の準備をすること自体が、ひとりひとりがチームの未来をイメージしてそれに向かって進んでいく作業にもなっていました。 主力メンバーが別のチームに移った時、今こそチームで アジャイル になるべきだと私は考えました。「誰か」ではなく「私が」でもなく「チームで」が大事な理由は同じことを繰り返さないためです。誰かがチームを引っ張るのではなく、チームで未来をイメージしてみんなで取り組んで作り上げる過程こそ アジャイル ではないでしょうか。そうやってMeetupに向けて進みながら少しずつイメージを具体化していく過程を スクラム マスターとして支援してきました。 「やってみたら面白そう」と思えるようなア イデア を見つける それを実践するきっかけを作る 実現イメージの具体化をファシリテートする 実行するうえでの課題や懸念の解消を手伝う このようなちょっとした支援で少しずつチームが前進していくのを手助けすることこそが サーバントリーダー の醍醐味だと思います。 ふりかえり アジャイル Night らしく、ふりかえりは 「Fun Done Learn」をやりました。 Fun Done Learnって何？というかたはこちらをご確認ください。 qiita.com Fun Done Learnをやってチームで議論した内容を以下にまとめます。 良かったこと・学び スクラム の取り組みについて参加者との交流や外部のエンジニアとの情報交換ができた 自分たちがやってきた事へのフィードバックが得られて今後のモチベーションに繋げられた 自社開催でチームでの取り組みなのでアウトプットへのハードルが低く、 心理的 障壁が少ない中で前向きに取り組めた 半年間の活動でしっかり時間を確保して学んだことや取り組みの総括ができた 改善点や今後に向けたTry 資料作りが基本であり一番大事、これを極めればもっと良い内容にできそう スケジュールを立ててチェックポイントを設けて計画的に取り組むことが大事 当日の発表を想定した練習が大事（もっとやっておくべきだった） ふりかえった内容は社内で共有して、他のチームの新たなチャレンジに役立ててもらいたいと思っています。また、社内だけでなくこの記事を読んで頂いた皆さんの何かの取り組みに役立てば幸いです。 おわりに 次回のMeetupは6月を予定しています。内容は決まり次第、connpassで告知します。 rakus.connpass.com また、大阪オフィスでは毎月1回エンジニアもくもく勉強会を開催しています。今回の発表内容に関しても興味を持たれましたら情報交換できればと思っていますので、是非ご参加ください。 rakus.connpass.com

楽楽精算開発２課 岡本です。 今年から月１回のペースで開催している「もくもく勉強会」ですが、３月もまた実施しますので、告知も兼ねて２月実施回の模様をお伝えしようと思います。 ちなみに、１月の模様はこちらの記事で紹介されています。 tech-blog.rakus.co.jp ２月実施の模様 前回(１月実施回)の振り返りで主に以下のような意見が出たので、２月はこれらの改善を実施しました。 参加者同士が離れて座りがち 食べ物があったほうがいい BGMの音が大きい ■参加者同士が離れて座りがち 前回は、机を離して設置していたため、それぞれの机に別れて参加者が座ってしまい、もくもく中にコミュニケーションが取りづらい状況でした。 前回の様子。空席が多くてどことなく寂しい感じ そこで、今回は参加者同士が近くに座れるように、机の配置を見直しました。 今回の様子。写真の時点では全員揃っていないので空席ありますが、最終的には各机に一人づつで全ての席が埋まりました。 ■食べ物があったほうがいい 食べ物があったほうがコミュニケーションを取りやすいのではという意見が出たので、今回はお菓子を用意してみました。 ちょうど実施日が２月１４日だったのでチョコレートをメインに用意。 ただ、あまり消費量は芳しくなかったようです。 まだまだ残っています。 次回以降も、お菓子は用意しようと思うので、お越しの際はガンガン消費していってください。 ■BGMの音が大きい もくもく勉強会の会場では普段からRaspberryPiからラジオが流されるようになっています。 こんな感じ、ちなみにこのRaspberryPiでエントランスのディスプレイに流れている映像も制御しています。 前回はここから流れてくる音が大きすぎるという意見が出ていたので、今回は予め音を絞ってBGMを流していました。 ただ、RaspberryPiの処理の関係で時々BGMが途切れ途切れになってしまっていたようなので、次回は別の方法でBGMを流そうと検討中です。 次回告知 次回は３月１４日に開催予定です。既にconnpassに公開中ですので。興味を持たれた方は是非お越しください。 rakus.connpass.com

はじめに こんにちは、 id:FM_Harmony です。 今回は先週開催された東京オフィスのビアバッシュに関する紹介記事を書きました。なお、東京オフィスでのビアバッシュについては、下記の記事にて詳しく紹介されています。 tech-blog.rakus.co.jp はじめに 発表内容 デブサミ2019で印象に残ったセッション デブサミ2019で興味があったもの PostgreSQL11のパーティショニングを試してみる おわりに 発表内容 前回 同様、東京のビアバッシュでは自由なテーマでの発表のみ行われました。 デブサミ 2019で印象に残ったセッション LTのタイトル① 前回に続き、今回も私が発表する場をいただけました。 2/14(木)、2/15(金)に開催された Developers Summit 2019（以下 デブサミ 2019）について参加しましたので、今年のテーマである「SHARE YOUR FUN！」にちなんだ以下のセッションの内容、感想を発表させていただきました。 event.shoeisha.jp event.shoeisha.jp セッションの感想ですが、楽しんで仕事をすることで利用者が幸せになるようなものを作りたいと思いました。また、東京のビアバッシュでも何度か話題になった技術書典についても、「面白い」と感じるポイントがあったので、次回開催分にはぜひ参加しようと思いました。 デブサミ 2019で興味があったもの LTのタイトル② 同じく デブサミ 2019に関する発表でした。興味がわいたセッションとして、下記のセッションについて発表されていました。 event.shoeisha.jp Node-REDを用いたコードレスなアプリケーション開発に興味がわいたとのことです。 PostgreSQL11のパーティショニングを試してみる 以前、 ラク スAdvent Calendar 2018に記事を投稿された方が、記事の内容について発表されていました。 qiita.com PostgreSQL 10から追加された宣言的パーティショニングについて、下記の二点が追加された PostgreSQL 11からは実用可能なレベルになったのでは？ということでした。 親テーブルにプライマリキーが設定できるようになった ただし、プライマリキーにはパーティショニングキー（分割の際に参照する項目）を含める必要がある パーティショニングキーを更新した場合、自動であるべきテーブルにデータが移動されるようになった 発表の最後には参加された方の間で、パーティショニング機能の商材利用についてディスカッションのように質疑応答が繰り広げられていました。 おわりに 東京オフィスの2月ビアバッシュについてお送りしましたが、いかがでしたでしょうか。 3月は拡大版ビアバッシュともいえる全社MeetUpの開催が予定されていますので、そちらで発表された内容もお伝えできればと思います。

はじめに こんにちは。若手エンジニアのchoreiiです。 最近、業務でswiftに触れる機会がありました。 Xcode での アプリ開発 が楽しく、swift勉強したい欲が高まり勉強会にも参加しています。初心者ながら、ある程度アプリの作り方も理解してきたので一度アウトプットをしようと思います。 swift勉強中の方の刺激・参考となれば幸いです。 目次 はじめに 目次 題材 完成形 地図の埋め込み 検索とピン配置 最後に 題材 取り上げるのは、 MapKit になります。 簡単に言うと、アプリの画面に地図を埋め込んだりできる フレームワーク です。 今回はMapKitを使って、近場の駅を表示するアプリを作ってみました。 完成形 最初に完成形をお見せします。 起動後 ラク スの会社住所で検索 駅にピンがたつ（検索地が ラク スです） ゴールイメージが掴めたところで実際の手順を説明します。 地図の埋め込み xibまたはstoryboardで MKMapView を貼り付けるだけです。 xcode で部品をペタペタ貼り付けるのは直感的にできるのですごく楽しいです。（しっかりとしたレイアウトを考えだすと面倒ですが） MKMapViewの配置 今回はテキストボックスに住所を入力して検索するので textField も貼り付けています。 検索とピン配置 検索はMKLocalSearchを使用しています。精度はあまりよくないようですが、ローカルで API のように簡単に検索機能が使えるので使用しています。 検索用の関数を作成している先人の方がいらっしゃったので、検索自体は そちら をお借りしています。 Map.search(query : "駅" , region : region ) { (result) in switch result { case .success( let mapItems ) : for map in mapItems { let annotation = MKPointAnnotation() annotation.coordinate = map.placemark.coordinate annotation.title = map.name ?? "名前がありません" mapView?.addAnnotation(annotation) } case .failure( let error ) : print ( "error \( error.localizedDescription ) " ) } } query: 検索したい建物　region: 検索範囲のイメージです。 帰ってきた検索結果それぞれに MKPointAnnotation() を addAnnotation することでピンを立てています。今回は駅固定にしていますが、ここも入力フォームやユーザデフォルトに保存しておいた値などを使うと、いろんな建物が検索できて使い勝手はよくなると思います。 最後に xibファイル上でのオブジェクトの配置と、コード上でのオブジェクトの操作の両方を体験できるので、 iPhoneアプリ の開発練習にはぴったりだと思います。私自身イベントの制御などまだまだ把握できていないところばかりなのでこれからも勉強は続けていきます。今回のアプリのソースは GitHub に置いておきます。練習用のコードで汚く読みづらいコードとなっていますが、基本的な操作は一通り試しているのでご自由にお使いください。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめまして、新卒のtaku_76です。 qiita.com 上記URLからチャット bot を作成したいと思ったのですが、これにNode.jsの知識が必要だと書いてあったので学習してみました。 その結果 フレームワーク であるExpressを使用すると簡単に Webサーバーが構築できることが分かったので試しに使ってみました。 Node.jsとは Node.jsのインストール Expressで新規プロジェクトを作成 おわりに 参考 Node.jsについての記事 Node.jsとは JavaScript を使ってサーバーサイドのコードを書くことが出来るプラットフォームです。 特徴 V8エンジン GoogleChrome で使われている JavaScript エンジンでブラウザとほぼ同じ JavaScript が書くことができます。 JavaScript を即座にコンピュータが理解できる 機械語 に変換して処理を行うため非常に高速です。 ノン ブロッキング I/Oモデル I/Oが終わったか何度もチェックし、終わっていなければ次の処理に進んで、次の処理が終わったらまたチェックする、この動作を繰り返します。 シングルスレッドの大量のアクセス制御が難しいというデメリットを回避します。 Node.jsのインストール https://github.com/nullivex/nodist/releases こちらのURLからnodistをインストールします。 nodistとは Windows 環境で動作する Node.js のバージョン管理ツールです。これを使うことで、複数の Node.js のバージョンを切り替えて使い分けることができるようになります。また、同時にnpmもインストールされます。 npmとは Node.jsのパッケージを管理するツールです。Node.jsのパッケージとは、予め用意された便利な機能をまとめたものです。 Expressで新規プロジェクトを作成 Expressとは Node.jsで利用できるWebアプリケーション フレームワーク です。 イベントループで非同期のため同時リク エス トに強く、多くのユーザーの同時アクセス・大量リク エス トを捌くことができます。 テンプレートエンジン(サーバーサイドで動的にオブジェクトを渡して、それをHTMLとして返す)を選べます。 今回はhtmlに近い形でかけるテンプレートエンジンのejsを使います。 Expressのインストール 以下のコマンドでインストールを行うことが出来ます。 C:\Users\takumi\Desktop\test\Nodist>npm install -g express-generator 公開までの手順 C:\Users\takumi\Desktop\test\Nodist>express -e newproject オプション-e でejsが設定された状態でプロジェクトが作成されます。 C:\Users\takumi\Desktop\test\Nodist>cd newproject && npm install 作成されたnewprojectのnode_module ディレクト リの中に必要なモジュールがインストールされます。 packege. json に何をインストールするのか設定してあり、これを参照してインストールを行います。 C:\Users\takumi\Desktop\test\Nodist\newproject>npm start サーバーを起動し、ローカルにWebページを公開します。 http://localhost:3000 と入力するとexpressにデフォルトで入っているhtmlが以下のように表示されます。 express おわりに 今回は、Node.jsのExpressを使ってローカルにWebサーバーの構築をしてみました。 次は、自分でWebアプリを開発してherokuを用いて公開するところまでやってみたいと思います。 参考 https://www.sejuku.net/blog/45745 https://techacademy.jp/magazine/16105 https://techacademy.jp/magazine/16119 Node.jsについての記事 こちらにも詳しい記事があります。 Node.jsの勉強会でお手軽にWebアプリを作った話

id:radiocat です。2/22〜23に開催されたScrum Fest Osaka 2019 へ私たちのチームから3人が参加してきましたのでレポートします。 Scrum Fest Osaka 2019とは？ www.scrumosaka.org 公式サイトには以下のように書かれています。 Scrum Fest Osakaは スクラム の初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。 アジャイル 開発のプロセスのひとつである スクラム のイベントで、関西では初の大型イベントです。約200人が集まって2日間開催されました。 ちなみに、弊社も大阪に拠点があり スクラム に取り組むIT企業のひとつとしてスポンサーをさせて頂きました。 なお、会場となった「 関西大学 梅田キャンパスKANDAI Me RISE」は大阪オフィスの隣のビルでした。その点でも何か不思議なご縁を感じて参加してきました。 登壇レポート 今回は登壇の機会も頂くことができました。せっかく頂いた機会ですので、私たちのチームが取り組んできた スクラム についてたくさん詰め込んで紹介しました。 スクラム はシンプルなルールの 開発プロセス ですが、その実践にはチームに応じた様々な工夫が必要です。私たちのチームもこれまでたくさんの試行錯誤を繰り返してきました。その中で支えとなったのは、既に スクラム に取り組んでいる先人やコーチなどの 有識者 の方々の取り組み事例でした。これまでも同様のイベントが開催されたり、同じ課題を持つ人が集まるコミュニティなどからたくさんの事例が世の中に発信されており、それらの情報を参考にして自分たちのチームに取り入れて スクラム を続けてきました。つまり、私たちの スクラム はこれまで取り組んできた人たちの試行錯誤に支えられているのです。 ですので、今度は私たちの取り組みを、同様に試行錯誤している人やこれから スクラム に取り組む人たちの支えにして頂けるように、たくさん詰め込んでお伝えしたつもりです。幸いなことに発表後の懇親会などで、たくさんの方々から共感のコメントや自分たちも同じ課題を持っていて勇気が湧いたという温かいお言葉を頂き、私たち自身もまたこれから スクラム を続けていくモチベーションを得ることができました。 参加レポート 一緒に参加したメンバーが印象に残ったセッションをまとめてくれているのでご紹介します。 楽楽精算開発チームの岡本です。印象に残ったセッションをまとめました。 プ ラク ティス厨から始める アジャイル 開発 クラスメソッドの 藤村さんのセッションです。 スライドは、こちらで公開されています。 プラクティス厨から始めるアジャイル開発 from Arata Fujimura www.slideshare.net スクラム の本に書いているようなプ ラク ティスについて、まずは、そのまま実行してみて、形骸化してきたと感じたら立ち止まり、 スクラム ガイド等の原典と現状の差分を確認してみればいい、といった内容のセッションでした。 スライド中には「プ ラク ティス厨が許されるのは、形骸化するまで」という言葉が出てきていましたが、うちのチームにも形骸化していそうなプ ラク ティスがちらほら出てきているので、原典との差分の確認時期なのかもしれないです。 スクラム フレームワーク を使用する具体的な方法。僕の場合。 楽天 の 椎葉さんのセッションです。 スライドは公開されていませんが、ブログで内容が公開されています bufferings.hatenablog.com 楽天 の大阪開発チームで実践している スクラム の方法についてのセッションでした。 色々と参考になるセッションで、特に、仕様の決め方や開発の進め方については、うちのチームでも取り入れてみたいと思いました。 仕様の決め方 何を作るのか？だけではなく、なぜ作るのか？をより重視して書く それによって、開発チームはより目的に沿った形で実装することができる。 開発の進め方 実装／テストで役割を分けて、それぞれ並行して進める 実装／テストそれぞれの観点で開発を進めるので見落としやバグを防ぎやすい。 オーディエンスとして参加して来ました、庄禮です。 私自身、現在の スクラム チームに参加してまだ半年ほどで、こういった スクラム のイベントにも参加したことはありませんでしたが、運良く参加枠をいただくことができましたので参加してきました。 以下、拝聴したセッションの中から一部ご紹介します。 お堅い企業で スクラム チームを一から作った話 3年前からチームに スクラム を導入した 三菱電機 株式会社さんのお話。 アナログなカンバンの導入に始まり、少しづつ自分たちの課題点を解消していく軌跡をお話しされていて、チーム体制の変更したり、デジタルなツールを導入して効率化をはかるなど、工夫しながら自分たちの スクラム を形作っており感銘を受けました。 ピンポンゲームで スクラム 体験ワークショップ 「Ball Point Game」というワークショップをおこないました。ワークの詳細は軽く調べるとでてきますので、気になる方は調べてみてください。 限られた時間、初対面の人と協力して目標にむかって行動するのはやりごたえがありました。やってみてダメな点は全員で振り返って、次にプランニングに活かす、といった スクラム の基本を体験学習できる良いワークでした。（ワークということもあり、実際の現場ではおこなわないようなチャレンジも行いました） 所感 交流会やコーヒーブレイクの時間に様々な スクラム 関係者と交流できたことも、参加してよかったと感じているポイントです。まだまだ自分自身の知識も浅く、お話を聞いて参考にさせていただく機会ばかりですが、いつか自分の経験をみなさんにアウトプットできるように精進していきます。 まとめ 2日間 スクラム のテーマにどっぷりと浸かり、参加者それぞれが交流と学びを深めて持ち帰ることができる場所でした。Scrum Festは、その名前のとおりカンファレンスや勉強会とは違った独特のフェス感のある素晴らしいイベントです。次回もぜひ参加したいと思います。 今回のイベントにも関連しますが、関西の アジャイル コミュニティの関係者の皆様には普段から大変お世話になってきました。今後もイベントへの参加だけではなく会場のご提供などでも関係を深めてコミュニティに貢献していきたいと思います。 devlove-kansai.doorkeeper.jp scrumdo-kansai.connpass.com スクラム 道関西さんには既に一度、弊社にお招きしてオープン・ジャムを開催して頂きました。また、3/18にはDevLove関西のイベントを弊社にお招きして開催予定です。 devlove-kansai.doorkeeper.jp また、弊社でも毎月１回エンジニアもくもく勉強会を開催してエンジニアの交流の場をつくっていこうとしています。よろしければぜひご参加ください。 rakus.connpass.com

こんにちは。堀内（ id:yhoriuchi ）です。 弊社が日頃からお世話になっている 株式会社アトラクタ 様が開催された 認定スクラムマスター研修 を受講してきました。講師は Gabrielle Benefield さんで、ジェフ・サザーランド博士が率いるScrum Foundationの共同設立者でもある方です。 Gabrielle Benefieldさん 研修内容が非常に素晴らしかったため、少しでもご紹介できればとの思いで研修の簡単な紹介、学んだこと、現場でやってみたことをお伝えしたいと思います。 研修概要 スクラム マスター研修は2日間のコースです。Gabrielleさんがメイン講師で、株式会社アト ラク タの 原田さん が研修をサポートする体制で行われました。 基本的に研修は英語ですが、プロの通訳の方が同時通訳を行いながら進行します。要所要所で原田さんがご自身の経験や考え方を交えた補足を行なって（日本語）くれましたので、 スクラム を学ぶ上でこれ以上ない講師陣だったと思います。 研修の始まり 研修が始まるとGabrielleさんから「全員と握手」するように言われます。40人ほどの参加者が部屋を歩き回って全員と握手するというワークショップ（？）です。初めて顔を合わせる人たちばかりでしたが、最初に握手をするだけで後の研修が非常にやりやすくなったと感じています。 スクラム マスター研修は多くのワークショップが取り入れられた内容になっているので、こうした 心理的 な障壁を最初に取り除く行動は研修そのものの効果を上げることにつながりました。 次のワークショップ：ピンポン玉回し 研修生が20人ずつくらいの2チームに分かれ、ピンポン玉を特定の時間内に落とさず手渡しで何個回せるか、という簡単なゲームをしました。2チーム同時に始めて優劣を競うのですが、チームごとにやり方が違うため、当然のように差が出ます。その後、一方がもう一方のチームのやり方を観察して自チームのやり方を見直し、改善するということを行いました。この時一番驚いたのが、相手チームを観察して良かったやり方をそのまま真似るのではなく、私が想像していた以上の改善が行われ、無駄がそぎ落とされた方法に一瞬で進化したことでした。観察して振り返り改善することの重要性に気付かされたその時の衝撃は今でも忘れることができません。 やり方は違えど、以前 吉羽さんに社内で実施して頂いたスクラムトレーニング で伝えようとしていたことが改めて理解できた気がします。 色々端折りますが その後は スクラム の全体の流れを説明頂いたり、チームに分かれてワークショップを行ったりして スクラム の理解を深めました。 疑問があれば随時質問を行うこともでき、貴重な意見やアド バイス を受けることができます。知識としての スクラム だけでなく、多くの現場を見て改善されてきた知見を持つ講師からのアド バイス は心に突き刺さるものがあります。私が質問をした回答の最後に、Gabrielleさんが "Good luck"と言ってくれたのは今でも心の支えとなっています。 学びを実践で試すと更に学べたこと 研修に参加すると、不思議と勇気と自信が湧いてきます。そのまま自社に学びを持ち帰り、一番試してみたかったことを早速試してみました。それが「他チームを観察する」です。タイミング的に他チームを観察することが難しかったため少し工夫して、他チームの スクラム マスターをやっている id:radiocat に自チームの振り返りの ファシリテーター をお願いしました。 「人は鏡」といった言葉があるように、人は人との対話を通じて自身の内面に気付かされることが多くあります。 スクラム の振り返りでの開発チームと ファシリテーター という関係性から考えて、チーム外の人が ファシリテーター を行うことにより、自分たちのチームが外からどのように見えているのか気付かされ、新たな改善や行動につながることに期待していました。 結果は思っていた以上のものでした。 開発チームメンバー個別に振り返りの感想を聞いてみたのですが、全員が口を揃えて同じことを言っていたのです。それが 「1週間で課題（problem）が多いのは正常なのか？」 という質問があったということでした。振り返りに KPT を利用しているのですが、“P”に上がる項目が多いように外からは見えるというチームへの見事な問いかけだったんだなと思いました。 感じ方は人それぞれあるようですが、この質問がチームにとって大きな意味があり、各自が深く考えるきっかけを与えてくれました。 更には、他チームの振り返りをファシリテートすることで ファシリテーター 自身も多くの気づきがあったようです。 下記がその一部。 チームの関心事によって出てくるものが全く違う。 振り返りのファシリテートはすごく重要で、すごく難しい。 チームが課題と感じているところを察知して石を投げ込まないと意味がない。 振り返りはプロセスの改善の場であると他チームの課題感を通して改めて認識することができた。 これらを聞いて私自身も学べることが多く、この一連の行動から学びで学びを繰り返すのだと気づかされました。今後はチームとしての学びを最大化するためにも スクラム マスターとしての学びは尽きることがないと気を引き締めた次第です。 そしてその先へ 認定 スクラム マスター研修を受けると、認定 スクラム マスター（CSM）になるための受験資格がもらえます。オンラインで受験できるのですが、私も無事合格することができました。CSMは資格取得して終わりではなく、むしろ果てしなく続ける旅路の始まりだと思っています。このような研修の機会を作ってくれた株式会社アト ラク タ様や自社にも感謝しつつ、これからも スクラム チームを支援していきたいと思います。 ジャーニーは始まったばかりです。

こんにちは、fuj_takです。 エレベーターがなかなか来なくてもやもやすることありませんか？ かく言う私もエレベーター待ちになると、いつ来るんだろうと悩まされます。 自分にエレベーターの制御をやらせれば、もっといい感じにできる 皆さんも一度は考えた事があるのではないでしょうか！ そんなあなたにこちらをご紹介します。 Elevator Saga Elevator Saga - the elevator programming game GitHub にも公開されています。 GitHub - magwo/elevatorsaga: The elevator programming game! ※私の環境だと IE でうまく画面表示できなかったので、 Chrome などのブラウザでお試しください プログラミング内容 ブラウザ上で JavaScript のコードを記述し、エレベーターの操作を行います。 エレベーターに乗った乗客の行先ボタンに応じた制御、 各階での上下ボタンが押された場合のエレベータの制御、 などを行い、時間内に多数の乗客を輸送できるかどうかにチャレンジするという内容。 ブラウザさえあれば誰でもお手軽に試せるので、チーム内ワークショップとかでも使えると思います。 2015年頃に公開されているようなので、一度は触ってみたことがある方もいそうですね。 API も公開されています。 Elevator Saga - help and API documentation やってみた エレベーターの数や各階の数が異なる設定で全18ステージあります。 https://play.elevatorsaga.com/#challenge=1 https://play.elevatorsaga.com/#challenge=2 　～ https://play.elevatorsaga.com/#challenge=18 頑張ってみたのですが、5ステージを超える事ができませんでした。。。。 色々と無駄な動きが多いですね。 エレベーターの制御プログラムを作っている方々、えらそうなことを言ってすみませんでした m(_ _)m 我こそはという方は是非チャレンジしてみてください！！ 参考に API を頼りに作ったコードです。 いけてない点があるのは承知していますが、笑って許してください。 { init: function(elevators, floors) { var waitFloor = []; var queuePush = function(floorNum){ if (waitFloor.indexOf(floorNum) < 0) { waitFloor.push(floorNum); waitFloor.sort(function(a,b){ if( a < b ) return -1; if( a > b ) return 1; return 0; }); } } // 動作対象のエレベーター取得 var getTargetElevetor = function(updown, floorNum){ var target = null; elevators.forEach(function(e) { // エレベータ内の混在率を考慮 if(e.loadFactor() < 1) { if (updown == "up") { if (e.destinationDirection == "up") { if (e.currentFloor < floorNum) { target = e; } } else { target = e; } } else if (updown == "down") { if (e.destinationDirection == "down") { if (e.currentFloor > floorNum) { target = e; } } else { target = e; } } } }); return target; }; // エレベーターの上昇／下降に合わせて停止階を決める var setStopFloor = function(e, floorNum){ // 上昇中は上階のみ止まる if (e.destinationDirection == "up") { if (e.currentFloor < floorNum) { e.goToFloor(floorNum); } // 下降中は上階のみ止まる } else if (e.destinationDirection == "down") { if (e.currentFloor > floorNum) { e.goToFloor(floorNum); } // 停止中は指定階に向かう } else { e.goToFloor(floorNum); } }; elevators.forEach(function(e) { // 待機中 e.on("idle", function() { // 1階で待機 e.goToFloor(0); }); // 行先ボタンプッシュ e.on("floor_button_pressed", function(floorNum) { // 上昇中 if(e.goingUpIndicator()) { if(e.currentFloor() < floorNum) { e.goToFloor(floorNum); } // 下降中 } else if(e.goingDownIndicator()) { if(e.currentFloor() > floorNum) { e.goToFloor(floorNum); } } else { e.goToFloor(floorNum); } // 行先を制御 setStopFloor(e, floorNum); }) // 移動中 e.on("passing_floor", function(floorNum) { }); // 到着 e.on("stopped_at_floor", function(floorNum) { // エレベーター待ちをクリアする waitFloor = waitFloor.slice(waitFloor.indexOf(floorNum), 1); }); }); // 各階で上下ボタンがプッシュされた floors.forEach(function(f) { f.on("up_button_pressed", function() { queuePush(f.floorNum()); var e = getTargetElevetor("up", f.floorNum()); if(e != null) { // 行先を制御 e.goToFloor(f.floorNum()); } }); f.on("down_button_pressed", function() { queuePush(f.floorNum()); var e = getTargetElevetor("down", f.floorNum()); if(e != null) { // 行先を制御 e.goToFloor(f.floorNum()); } }); }); }, update: function(dt, elevators, floors) { // We normally don't need to do anything here } } エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 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

こんにちは。実は ラク ス大阪ビアバッシュ実行委員の、Y-Kanohです。 先日、毎月恒例のビアバッシュ@大阪を行いました。 今回のテーマは、「 他部署のお仕事紹介 」。 いつもは技術系の発表ばかりのビアバッシュに、他部署の方をお招きし、それぞれのお仕事内容を発表していただく、毎年恒例の人気企画です。 今回も内容をダイジェストでご紹介いたします。 営業のお仕事 まず、配配メールの営業担当に発表頂きました！ ネット申し込みなどが普及し、システムを売るために、人手が必ずしも必要でない中における、営業の存在意義を教えていただきました。 お客様の困っていることを解決するためにも、 人それぞれに違うシステムに対する価値観を、いかに高めて紹介するかが腕の見せ所だそうです。 また、営業担当としてプレゼン時に心がけているテクニックも教えていただきました。 ネットワーク純情派 つぎに、365日インフラを守っているインフラ部隊、「ネットワークチーム」からの発表です。 ログ調査から障害対応まで、幅広い業務内容についての話から、 日々取り組んでいる、サービス品質向上のために行っているプロジェクト活動についての話などを伺いました。 （表紙のデザインがシブいですね。） 情シスの業務紹介 多数の業務内容を抱えている情報システム部からも発表頂きました。 業務内容は多岐にわたり、比較的馴染みのあるPC管理や、問い合わせ対応から、 あまり表に見えない、社内システムの基盤整理、セキュリティ対策、新しいITサービスの導入などについてお話しいただきました。 また、実際に最近社内へ導入された、業務効率化のための Bot システムの紹介もしていただきました。 これからも、 ラク スグループで働く人（： ラク ト）のために、より良いIT環境をサポートして下さるそうです。 サポートお仕事紹介 楽楽精算の顧客サポートを行っている、大阪サポート課からの発表です。 顧客サポートの中でも、導入支援を専門に行っているチームです。 せっかく導入したシステムを最大限利用してもらうため、2か月間の専属サポートを行い、 できるだけ長く使っていただけるよう工夫しているそうです。 技術発表 いつも通りの技術系発表も行いました。 OSS の開発にJOINした話 OSS の開発にJOINした経験から、仕事や開発における積極的な行動の意義を教えていただきました。 フェリー ハッカソン 参加報告 先日、 こちらの記事 で紹介された、フェリー ハッカソン のレポートです。 記事には載らなかった内容まで、写真を交えて発表していただきました。 また、最後にはLTでの発表も行いました。 いつもはエンジニアばかりのビアバッシュですが、今回はエンジニア以外の方も巻き込んで、いつもとは違うビアバッシュを行うことができました。 毎年行っている企画ですが、毎回新しい発見や知らなかった情報が出てくるため、ぜひ今後も続けたいです。 以上、大阪開発ビアバッシュレポートでした。

いろ いろ なところでネタになっている開発エンジニアの坂田です。 以前の投稿 で周知されました通り、先日開催されたLaravel JP Conference 2019に登壇してまいりました。これも以前の投稿で触れていましたが、株式会社 ラク スは BRONZE スポンサーとしてイベントに協賛しました。 イベント概要 日時 : 2019 年 2 月 16 日 (土) 会場 : グランパークカンファレンス 公式 HP : https://conference2019.laravel.jp/ ハッシュタグ ： #laraveljpcon conference2019.laravel.jp 登壇 チャットディーラーの高速開発を支える Laravel（30分セッション） speakerdeck.com 昨年の PHP カンファレンス関西 2018 で発表 した内容から資料を修正して再演しました。 感想 個人的にはあまり満足のいく発表が出来なかったなというのが正直な感想です。 マイクを持ってしゃべればよかった 発表中、聞いてくれている人たちをあまり見れていなかった（話に興味を持ってくれているか不安になった） 時間を余らせてしまった 登壇力が足りない ただ良かったこともありました。 「Mustache Injectionという言葉を流行らせたいので覚えて帰ってください」がちょっとうけてた Mustache Injectionについてつぶやいてくれている人がいた mustache injectionという言葉を覚えて帰ってください。 #laraveljpcon #laraveljpcon3F — なずな🌱 (@akaa07_pg) 2019年2月16日 mustache injection 簡単に起こせますな！！怖い。。。 #laraveljpcon #laraveljpcon3F — KamiyaKizuku (@kizu19911020) 2019年2月16日 mustache injection こわい #laraveljpcon #laraveljpcon3F — 青ごへいもち (@blue_goheimochi) 2019年2月16日 これからLaravel＋Vueで開発する予定だったから XSS 対策の話聞けてよかった。知らなかったらやっちゃう、mustache injection。 #laraveljpcon3f — よだか (@engineerYodaka) 2019年2月16日 やはり 脆弱性 に関する話題は関心をひきやすいのだなという印象です。 Mustache Injectionに関して参考 Mustache Injectionに興味を持ってくださった方向けに参考情報を載せておきます。 https://laravel-news.com/laravel-5-6-9 https://medium.com/@taylorotwell/js-frameworks-server-side-rendering-and-xss-722805009892 https://github.com/dotboris/vuejs-serverside-template-xss

Y-Kanohです。 先日、弊社がスポンサーとなっている、Laravel JP Conference 2019 のライトニング トーク に登壇してきました。 イベント概要 こちらの記事で紹介いただいたイベントです。 tech-blog.rakus.co.jp 日時 : 2019 年 2 月 16 日 (土) 会場 : グランパークカンファレンス 公式 HP : https://conference2019.laravel.jp/ Laravel JP Conference は、今回が初めての開催です。 （このような登壇イベントでの発表は初めてでしたが、まさかのトリの発表でした...） 発表資料 発表時の資料はこちらです。 speakerdeck.com 資料作成前は、基本機能の紹介等をクイズ形式で面白おかしくできたらと思いましたが、 実際はもろもろの事情により GitHub のコードから非常にコアな問題を出題することにしました。 感想 思ったより受け入れられて、とても楽しかったです。少しネタ寄りの発表でしたが、 コードを読まないとわからない内容だったため、聞き手の方もクイズを楽しんでいただけたようで、 発表後の懇親会では「Laravel クイズの発表者です」というと、「1問しか正解できませんでした」とか、「Laravel の内部って面白いですね」など、様々な反響をいただけました。 ちょうど、他のセッションで「何らかの形で少しでもアウトプットを行うことが成長への近道」といった話がありました。 私も、今回の登壇を機に、ブログや登壇といったアウトプットの機会を増やせればと思います。

初めまして、新卒エンジニアのEngawaです。 今回は iphoneアプリ 作成で使っている Monaca についてかなり簡単に紹介させていただきます。 Monacaとは 統合開発環境(IDE) デバッガー おわりに Monaca とは アシアル株式会社様が提供しているハイブリッドアプリ作成の開発プラットフォームです。 統合開発環境 ( IDE )とデバッガーなどの機能を提供しています。 統合開発環境 ( IDE ) Monaca では クラウドIDE という IDE が用意されています。 名前の通り クラウド 上のあるためローカルで面倒な環境設定を行わなくても、会員登録さえすればどの端末でもブラウザ経由ですぐに開発ができます。 実際の編集画面はこんな感じです。 普段から eclipse を使っており、 Monaca の開発画面の見た目はほとんど同じだったので大まかな扱い方はすぐに理解できました。 実行結果も上図の右側の部分にあるのですぐに確認できます。 また、 Monaca が提供しているデバッガーを使用すれば スマートフォン でも実行結果を確認することもできます。 デバッガー 上にも記載したのですが、動作確認する時は Monacaデバッガー という デバッグ 用のツールを使えば スマートフォン で動作の確認をすることができます。 アプリ自体は普通に App Store 、 Google play で無料でインストールできます。 アプリのインストールが完了したら、アプリを立ち上げてログインし、作成したプロジェクトを選択するだけで簡単に確認することができます。 デバッガーの画面はこんな感じです。(作成したプロジェクト一覧(左)と実行結果(右)をくっつけてます) おわりに 今回は、 Monaca についてかなり簡単に紹介させていただきました。 面倒な環境設定をしなくて済む上、様々なテンプレートが用意されているので手軽に アプリ開発 を行いたい方にはオススメします。 Monaca に関しての詳しい記事は こちら にもあります。 参考サイト： https://www.asial.co.jp/business/mobile/ https://ja.monaca.io/features/

メールディーラー開発エンジニアの@neroblubrosです。「フェリー ハッカソン に行ってくる」というブログを前回書きましたが、実際に行ってきたことを書きます。 前回書いたブログの記事 tech-blog.rakus.co.jp 若手社員と一緒に参加しました 前回のフェリー ハッカソン には私ひとりで参加しましたが、今回はなんと若手社員のふたりも参加することになり、 ラク スからは合計3名でフェリーに乗り込みました！ 若手社員が書いた参加レポートはこちら MasaKu tech-blog.rakus.co.jp Y-Kanoh tech-blog.rakus.co.jp フェリー ハッカソン に限らず、私はいままでいくつかの ハッカソン に参加してきましたが、今回のフェリー ハッカソン はプレイヤーではなく、スタッフとして参加しました。 スタッフの中でもプレイヤーのみなさんをサポートする「メンター」です。 どこまでサポートするか？で迷いました メンターのお仕事は前述のとおりプレーヤーのサポートです。具体的には下記のとおりです。 各チームのア イデア をどうやって実現すればいいか？の提案 API の使い方などのサポート 時間が足りない！ときの助っ人 実際のところ、1と2はあまりありませんでしたが、2日目に進捗が遅れているチームが発生したので、そのチームに助っ人に入ってサポートをしました。 チームの助っ人を始めると「どこまで手伝うか？口出しをするか」ということに苦慮しました。 チームそれぞれの思いや考えがあるため、コンセプトといった成果の根幹に関わる部分に口出しはできません。そういう意味でメンターは受け身です。 その反面、チームメンバーは猫の手も借りたい状態なので「もっと手伝ってほしい」「いろいろ意見を言ってほしい」とメンターに求める気持ちも理解できます。 また、私自身「こうしたらいいのに」「こっちのほうが絶対いい！」という意見もあり、それをチームに伝えるか伝えないかで迷いましたし、「メンターが言うのだから」とある意味チームメンバーの方が気を使うことも恐れました。 この点がメンターをするにあたり難しいと感じたことです。 他のメンターと相談しながらサポートし、結果的にお願いされたこと以上のことはしない、聞かれたこと以外のことは答えないことにしました。 ですので、恐らくサポートしたチームメンバーの方々は物足りなく感じたと思います。 ハッカソン は自分ができることと足りないことを教えてくれる 最後に、私が ハッカソン に参加する目的について書いてこの記事を終わりにします。 私が ハッカソン に参加するのは「自分ができることと足りないこと」がわかるからです。 技術的な知識やスキルももちろん大切なのですが、 ハッカソン はごくわずかな時間の中で成果を出す必要があるので チームのタスクを効率よく処理するにはどうすればいいか 突発的に発生した問題にどう対処すればいいか 成果を審査員に理解してもらうにはどういう発表をすればいいか と言ったモノの考え方やチームの進め方がより大事だと私は考えています。 そして「自分のやり方は正しかったか？」「考え方は間違っていなかったか？」ということを ハッカソン 終了後に自問自答することで、自分が通用したところ、しなかったところ再確認できる。 だから私は ハッカソン に参加しています。 こういったことは一方通行の セミ ナーでは体験することができません( セミ ナーがダメだと言っているのではありません)。 今回は迷うところがありましたが、フェリー ハッカソン にメンターとして参加したことはとても勉強になりました。 みなさんも ハッカソン に参加しませんか？ ＃そうだ ハッカソン に行こう！

はじめまして、新卒1年目のエンジニアの id:aa_crying です。 今回はブログ運営でも使っている Google アナリティクスと、 UTMパラメータについて調べてみましたので、紹介させていただきます。 Googleアナリティクスとは UTMパラメータとは 実際にパラメータ付きURLを作成する アクセスして、結果を確認する まとめ Google アナリティクスとは Google アナリティクスとは、 Google アカウントの作成後、「 Google アナリティクスに申し込み」を行うだけで利用できるフリーの アクセス解析 ツールです。 申し込みをすると「新しいアカウント」作成画面に遷移するので、必要項目の入力後、ト ラッキング IDを取得できます。 このト ラッキング IDをサイトに埋め込むことで、 Google アナリティクスでサイトのアクセス計測が可能になります。 UTMパラメータとは UTMパラメータとは、プロモーション広告やバナー広告、メルマガなどの効果を計測するために設定するパラメータのことです。 Google アナリティクスでは カスタムキャンペーン と呼ばれています。 UTMパラメータには、以下のような種類があります。 パラメータ 説明 utm_source プロパティに トラフィック を誘導した広告主、サイト、出版物、その他を識別します utm_medium 広告メディアや マーケティング メディアを識別します utm_campaign 商品のキャンペーン名、テーマ、プロモーションコードなどを指定します utm_term 有料検索向けキーワードを特定します utm_content 似通ったコンテンツや同じ広告内のリンクを区別するために使用します *1 よく使われるのは utm_source , utm_medium です。 utm_source の部分を サイト名 にすることで、どこのサイトから 流入 したかを簡単に区別することができます。 実際にパラメータ付きURLを作成する パラメータ付きURLは以下のサイトで簡単に作成ができます。 https://ga-dev-tools.appspot.com/campaign-url-builder/ 今回は、 utm_source=mattermost , utm_medium=social でURLを作成します。 計測対象のURLと、それらの情報を入力すると、下の Share the generated campaign URL の欄にURLが作成されます。 UTMパラメータの作成 アクセスして、結果を確認する 実際に作成したURLからアクセスしてみます。 https://aa-crying.hatenablog.com/entry/20190206/tameshi1?utm_source=mattermost&utm_medium=social その結果を Google アナリティクスから確認します。 結果は、 リアルタイム > トラフィック から確認することができます。 Google アナリティクスでの確認結果 先ほど設定した utm_source の内容が ソース に、 utm_medium の内容が メディア に表示されていれば正しく計測が出来ています。 まとめ 今回は、 Google アナリティクスの初歩である、UTMパラメータ(カスタムキャンペーン)の扱いについてご紹介しました。 今回お見せした部分は Google アナリティクスの機能のほんの一部であり、他にも様々な機能があります。 誰でも気軽に、簡単にアクセス計測が出来ますので、興味のある方はぜひ活用してみてください。 参考サイト https://support.google.com/analytics/answer/1033863#parameters https://seolaboratory.jp/59695/#p01c エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : たとえば、メールのメッセージに行動を促すフレーズのリンクが 2 つある場合は、utm_content を使用して別々の値を設定し、どちらが効果的か判断できます。

id:radiocat です。年度末（弊社は3月です）が近づいてきました。私の所属するチームにとって2018年度は本格的に スクラム に取り組んだ1年でした。その締めくくりとして大きなイベントに登壇させて頂くことになりました。せっかく頂いた機会なのでしっかり振り返って我々の取り組みをお伝えしたいと思います。ぜひご参加ください。 Scrum Fest Osaka 2019（2/22〜23） www.scrumosaka.org 『あきらめない スクラム 』というタイトルで2/23に登壇予定です。 https://confengine.com/scrum-fest-osaka-2019/proposal/8554/- confengine.com 残念ながら採択されなかった Regional Scrum Gathering® Tokyo 2019 向けの発表テーマでしたが、大阪でも新たにScrum Festというイベントが立ち上がると聞いて改めてCfPに応募し採択して頂きました。もともと私たちは大阪拠点の開発チームなので、大阪開催のイベントで大阪のチームの取り組みを紹介できるのは非常に嬉しいことです。 この1年を大きく3段階の取り組みに分けてご紹介します。 はじめる闘い つづける闘い あきらめない闘い これらの闘いの中で「我々は何を学んだのか？」をお話できればと思っています。 当日はチームのメンバーもオーディエンスとして参加します。Scrum Festではセッションの発表を聞くだけでなく、ワークショップやCoffee/Tea Breakなどで参加者同士の交流の時間も設けられていますので、チケットをお持ちのかたはぜひ会場でお声がけください。 RAKUS Meetup Osaka #2 アジャイル Night（2/26） rakus.connpass.com 楽楽精算開発2課のメンバーがそれぞれの立場から スクラム 1年目を語ります。私たちはチームでの スクラム の取り組みをアウトプットするために、半年前からこのイベントに向けて準備してきました。 以下のそれぞれの立場でメンバーが発表する予定です。 主力エンジニアの場合 中途入社エンジニアの場合 若手エンジニアの場合 スクラム マスターの場合 メンバーの入れ替わりなどもあり、私たちはそれぞれの立場で様々な課題に向き合ってきました。それらは開発の現場ではよくあることかもしれませんが、同じ課題を抱えるエンジニアの皆様にお伝えすることで何かの気づきになれば幸いです。 LT枠も募集していますので、それぞれの現場での アジャイル な取り組みを共有しあえればと思います。ご参加お待ちしております。

Y-Kanohです。先日開催された、「フェリー ハッカソン 2019」に他数人のエンジニアと参加してきました。 ハッカソン イベントには初めての参加でしたが、チームにも恵まれて楽しく終えることができました。 眠かった。 イベント概要 詳しくは、参加前に@neroblubrosさんが投稿している記事をご覧ください。 http://tech-blog.rakus.co.jp/entry/20190125/interaction/engineer-learning/hackathon/ 日時：2019年1月25日～27日（二泊三日） 公式Webサイト ： http://ferryhack.code4.osaka/ 簡単に説明すると、「大阪港 - 別府間のフェリーに乗りながら、 ハッカソン を行うイベント」です。 公式Webサイト の「日程」からもわかりますが、 アイディアソン開始が21:30 、 ハッカソン 開始が24:00 という素晴らしいスケジュールです。 テーマ説明時にも不穏なスライドが！ 全体の流れ 一日目 作成するサービスのテーマ説明会 アイディアソン（作成するサービスの案出し） ハッカソン スタート（サービス作成開始） 二日目 別府会場にて ハッカソン / 発表資料作成 三日目 発表会 フェリーについて 今回はフェリーに乗りながらプログラムを書くという、非日常な体験をしてきました。 フェリー内には、運営チームのインフラ部隊が Wi-Fi 環境を整えてくださり、プログラムできる環境が用意されています。 そのため、船内のいたるところに Wi-Fi 機器が取り付けられていました。 ハッカソン について 私のチームでは、 QRコード を読み取ってサーバとやり取りを行うシステムを作成しました。 QRコード 読み取り機器などのハード側のプログラムや、読み取った後に接続するWebアプリケーションの作成、さらには表示する画面のデザインなど、やることは多岐にわたるため、チームメンバの方々と役割分担して進めました。私も微力ながら、読み取った QRコード の情報を判別する API の実装を担当しました。 復路のフェリー内では、アプリケーションの結合を行う傍ら、発表資料を作成し、最終日には発表も担当させていただきました。 惜しくも最優秀賞は逃しましたが、協賛企業の さくらインターネット 様による、「 さくらインターネット 賞」をいただきました。 デモ風景 所感 初めての ハッカソン イベント参加ということもあり、一番印象に残ったことは、 社外エンジニアのスキルを感じられる点 でした。 社内で使われていない技術や、自分が使ったことがない技術でも、社外では一般的なことや、技術に対する温度感を身近に感じることができ、自身の知識の低さや、認識の間違いに気づかされることもありました。 また、チームで作業をする中で、他社の業態や必要とされる技術など、実際の現場でのお話もお聞きできるため、勉強会やカンファレンスより深く知見が広がる印象でした。 参加前から過酷なイベントだと聞いていましたが 、終わってみると、とても楽しく、また得るものも多いイベントだっだと感じました。 フェリーというあまり自由が利かない環境の中で、社外のエンジニアの方と作業することはとても新鮮で、勉強になりました。

はじめに こんにちはMasaKuです。 先日、ブログでも告知させていただきました「フェリー ハッカソン 2019」に参加しました。 tech-blog.rakus.co.jp ハッカソン への参加が初めてだったこともあり、参加前は非常に緊張しました。 しかし、社外のエンジニアの方とチームを組んで開発したり、普段使ったことが無い技術を組み合わせて新しいサービスを考えることができ、総じて貴重な経験ができました。 今回はフェリー ハッカソン 2019に参加してみて「 良かったこと 」と「 悔しかったこと 」について書いていきたいと思います。 はじめに フェリーハッカソンの流れ 作成したWebアプリ フェリーハッカソンに参加して良かったこと 社外のエンジニアの方と一緒に開発する経験ができた 自分のすべきことを全うしようという意識ができた 新たな技術習得に対するモチベーションが向上した 悔しかったこと 時間内に全ての機能が実装できなかった 開発環境をしっかり整えておけばよかった まとめ おまけ 参考サイト フェリー ハッカソン の流れ フェリー ハッカソン は３日間で行う ハッカソン です。 まずは、フェリー ハッカソン の流れについてご説明したいと思います。 ３～４人程度のグループで船や旅に対するイメージを ブレインストーミング 出てきた案を元にして船旅が楽しくなるようなサービスを考える 各サービスを参加者全員で評価 評価が良かったサービスを開発するためのチームを作成 開発開始 発表会 私は「旅先で見つけたお土産を船上で食べるグルメパー ティー 」を提案しましたが、全然刺さっていない様子でした・・・。 作成したWebアプリ 私はその後、ほかの方が考えた「大阪から大分までの移動時間約10時間を最大限暇つぶしできるWebアプリの作成」をテーマにした、乗船客が白組と黒組に分かれて対戦する50×50マスの リバーシ を作成するチームに参加しました。 50×50マスの リバーシ （対戦中盤から1手で変わる石の数が想像以上に多く爽快感があります） 私はサーバサイドを担当し、 PHP を用いてゲームの進行状況を管理する機能の実装を行いました。 ホワイトボードを利用したシステム設計 フェリー ハッカソン に参加して良かったこと フェリー ハッカソン に参加して良かったことはいくつもありましたが、その中でも特に印象に残ったものをご紹介したいと思います。 社外のエンジニアの方と一緒に開発する経験ができた 社内のMeetup やプライベートでエンジニアの方と交流することはありますが、一緒に作業した経験はありませんでした。 そのため、 ハッカソン で同じチームになったメンバーと技術領域が違った場合の作業の進め方についてまったく想像ができず、少し不安な気持ちがありました。 しかし、参加してみると、サーバサイドとフロントエンド、インフラなど、各メンバーが不足点を補いながらチーム全体として最大の効率を発揮できる担当割り振りができました。 技術領域が違っているからこそ、気を掛け合わなければならない点について意識するようになり、各機能の結合時には積極的にコミュニケーションを取りながら作業を進めることができました。 他のメンバーとは異なるユニークなスキルを持っていれば、できることの可能性も広がっていくと思ったので、自分の興味のある内容については 知名度 を気にせず、どんどん挑戦していきたいと思いました。 自分のすべきことを全うしようという意識ができた 自分の担当作業において、他のメンバーが扱ったことがない技術や プログラミング言語 を選択している場合は、メンバーに協力を依頼できない場合があります。 そのため、開発中にトラブルが発生し実装が予定よりも遅れたとしても、自分の力で解決しなければならない状態になる場合があります。 しかし、そういったプレッシャーのかかる状況だからこそ、自分の担当機能がほかのメンバーが開発した機能と結合できた際の達成感は大きかったです。 自分に任された作業をしっかりとやり遂げるために、自分の技術を磨くこととトラブル時の状況説明を明確にすることの大切さを改めて実感することができました。 新たな技術習得に対するモチベーションが向上した 普段の業務で利用している技術については、どのように利用できるかが明確なので、今回作成したWebアプリの開発においても、自分がどのようにチームに貢献できそうかも想像できました。 しかし、外部のエンジニアの方はそれぞれの技術領域での解決方法を知っており、アド バイス を頂いた際に「そういう方法もあるんだ！」といった気づきを得ることもできました。 自分の技術領域を広げていくことで、「自分ならこうして実現するな」であったり「あの技術を組み合わせたらこんなこともできるな」といった発想力を持つことができるようになると思いました。 自分の枠にとらわれず、積極的にいろいろな技術に触れて柔軟な思考ができるようになりたいと思います。 棋譜 をレシートとして出力したメンバーもいました 悔しかったこと 自分としてはうまくできると思っていたところも、かなり苦戦してしまった場面もいくつかありました。 反省点の振り返りも兼ねて2点ご紹介したいと思います。 時間内に全ての機能が実装できなかった 開発開始当初に実装しよう思っていた機能のうち、一部の機能が時間内に実装することができませんでした。 結果的に、ほかのメンバーが開発した機能とうまく連携できなかったものもありました。 Webアプリとして、より面白いものを作りたいという気持ちと、時間内に実現できそうなラインの見極めが重要だと思いました。 開発環境をしっかり整えておけばよかった 普段の業務ではマルチモニターにしたり、その他周辺機器を利用して開発を行っています。 今回、 ハッカソン に参加するにあたって、荷物の関係上あまり多くの周辺機器は持ち込めないと思ったので、特にツール等は持ち込まず、普段あまり使わない タブレットPC に最低限の準備だけをして参加しました。 案の定、小さなモニターと タッチパッド 操作に慣れず、実装中に操作面で足を引っ張られた場面が何度かありました。 開発環境を整えておくことで、開発の効率も変わってくると改めて実感したので、より効率よく作業をするために、今一度業務で利用している開発環境も見直すべきかと思いました。 まとめ ハッカソン 初参加ではありましたが、大変実りのある経験ができたと思います。 今回は３日間という短い期間でのチームでしたが、通常業務でのチーム開発にも通ずる経験ができたと思ったので、今回学んだ内容を反映させていきたいと思います。 開発チームという枠組みで個性を発揮しつつも、チーム開発で最大の効率が出せるようなチームメンバーになっていきたいですね。 おまけ 開発の休憩時間を利用して、別府観光にも行きました。 楽しく開発しつつ観光も楽しめる素敵なイベントになりました。 白池地獄 とり天定食 参考サイト フェリーハッカソン2019 - connpass Facebook 無効なURLです フェリーハッカソン2019のまとめ - Togetter

はじめに こんにちは、 id:FM_Harmony です。 今回は先週開催された東京オフィスのビアバッシュについて、紹介記事を書きました。 なお、東京オフィスでのビアバッシュについては、下記の記事にて詳しく紹介されています。 tech-blog.rakus.co.jp はじめに 発表内容 iOSアプリ開発でオススメのライブラリ ゼロから始めるPython入門講座に参加してきました 新規メンバーのための「TKG」と「過去問」のススメ おまけ おわりに 発表内容 大阪オフィスのビアバッシュとは異なり、東京のビアバッシュでは今のところ自由なテーマでの発表のみ行っています。 iOS アプリ開発 でオススメのライブラリ 簡単に使えておしゃれなUIが作れる iOS アプリのライブラリに関する紹介です。 ウォークスルー *1 や、読み込み中のアニメーションなどが簡単に実装できるライブラリが紹介されていました。 iOS アプリを利用していて、よく見かけるUIと同じものが紹介されていたので、それらが簡単に実装できるのは iOS アプリ開発 をする上で有用だと思いました。 ゼロから始める Python 入門講座に参加してきました 私、 id:FM_Harmony が Python 勉強会に参加した事について発表しました。 発表内容の紹介が、入門講座に参加した際の個人的な感想になりますが、非エンジニアと思われる方も参加されていたのが印象的でした。 講座内で「 Python はプログラミング入門に適している」というお話もあったのですが、個人的にはそのことが要因なのかと感じています。 新規メンバーのための「TKG」と「過去問」のススメ 若手メンバーがプロダクトについて理解するために取り組んでいることについての発表です。 東京の楽楽精算開発チームでは、若手メンバーの活動として以下の２つを行っているとのことでした。 過去問 過去にリリースした機能を題材とした学習、若手メンバーが既存機能の実装や開発手法を理解することを目的にしている。 定例業務改善グループ （通称 TKG ） 属人的な作業の引継ぎや、作業内容の改善を行っている。 今でも私は思いますが、楽楽精算は機能も多く実装内容の全容を理解することが大変で、実際の開発に入る前に覚えなければいけない知識も多いです。なので、それらへの理解を助ける上記の活動はチームに参加したばかりのメンバーにとってとても有用だと思います。 おまけ ラク スのサークル活動や今度の2/19(火)に行われるRakus Meetup Tokyoの宣伝発表もありました。 Rakus Meetup Tokyoについては、以下のリンクから参加登録可能です。参加枠の倍近く予約があり、増席予定とのことでした。 rakus.connpass.com おわりに 東京オフィスの1月ビアバッシュについてお送りしましたが、いかがでしたでしょうか。大阪側のように、今後は東京の社内イベントも定期的に紹介記事を書いていけたらと思います。 *1 : スワイプしながらアプリの説明をするような画面のこと

はじめに はじまして、新卒1年目エンジニアのyk_itgです。 今回は初めて参加したカンファレンス、 JJUG で知った プログラミング言語 、Kotlinについて調べてみました。 www.java-users.jp はじめに Kotlinとは なにができるの？ 実行してみた FizzBuzz Null安全 nullを許容しない変数と許容する変数 nullチェック まとめ Kotlinとは Kotlin(コトリン) は Java と同じ 静的型付けの オブジェクト指向言語 です。 開発したのは 統合開発環境 IntelliJ IDEAを構築している JetBrains で、 Java をもっと簡潔・安全になるように改良した産業利用向け汎用言語として開発されました。 また、 JVM 上で動作する のでほとんどの環境で実行が可能です。 なにができるの？ 利用用途は幅広く、Webアプリケーションや Android アプリなどの開発をすることができます。 また、2017年に Android の公式言語 になったので、安心して Android アプリの開発に使えます！ 実行してみた Kotlin公式サイトでお手軽に実行できます。 Kotlin Programming Language kotlinlang.org FizzBuzz 試しによくある FizzBuzz を書いてみました。 fun main() { for (i in 1..100) { val ret = fizzBuzz(i) print("$ret,") } } fun fizzBuzz(num: Int): String { return when { (num % 15 == 0) -> "FizzBuzz" (num % 3 == 0) -> "Fizz" (num % 5 == 0) -> "Buzz" else -> num.toString() } } 1,2,Fizz,4,Buzz,Fizz,7,8,Fizz,Buzz,11,Fizz,13,14,FizzBuzz,16,17… 書き方は元となった Java とは大きく違う ことがわかります。 Null安全 記事のタイトルの通り、KotlinはNull安全な プログラミング言語 です。 Null安全とは、ざっくり言えば NullPointerException が起きない ということです。 ですが、nullが使えないわけではありません。 nullを許容しない変数と許容する変数 Kotlinにはnullの代入を 許容しない変数 と 許容する変数 が存在します。 変えるのは簡単で型宣言の後に「 ? 」を付ければ、nullを許容する変数にすることができます。 fun main() { //nullを許容しない変数 var num1:Int //nullを許容する変数 var num2:Int? num1 = null num2 = null } num1 はnullを 許容しない変数 なのでnullを代入しようとすると コンパイル 時エラー になります。 num1 = null; //コンパイル時エラー num2 はnullを 許容する変数 なのでエラーが出ません。 num2 = null; //エラーにならない nullチェック nullを許容すると NullPointerException が起こってしまいそうですが、そんなことはありません。 nullを許容する変数を参照する場合、 nullチェックをしていないと コンパイル 時エラー になるからです。 fun main() { //nullの代入を許容しない val num1:Int = 1 //nullを代入を許容する val num2:Int? = 2 println(sum(num1, num2)) //num2にnullチェックを行っていないのでエラー } fun sum(num1: Int, num2: Int): Int { return num1 + num2 } なので、参照する場合には必ずnullチェックを行わなくてはいけません。 fun main() { //nullの代入を許容しない val num1:Int = 1 //nullを代入を許容する val num2:Int? = 2 if (num2 != null){ println(sum(num1, num2)) //これならOK } } このようにKotlinはnullを参照することがない、 nullチェックを コンパイラ が強制する仕組み を持っているNull安全な プログラミング言語 なのです。 まとめ Null安全な プログラミング言語 「Kotlin」についてご紹介してきましたが、いかがでしたでしょうか。 今回紹介した以外にも、 型推論 や Java のソースをKotlinに変換できる といった特徴もあります。 まだまだ特徴はあるので興味を持った方は是非調べてみてください。 参考サイト Kotlin - Wikipedia https://eigoninaritai.com/about_kotlin_of_official_language_on_android/ Kotlinとは――読み方、メリット、「Java」とのコード比較、実行までのチュートリアル (1/3)：Android Studioで始めるKotlin入門（1） - ＠IT Null安全がすごい - 騒音のない世界 BLOG

はじめに 今回は大阪オフィスで開催された1月ビアバッシュをご紹介します。 前回のビアバッシュ記事はこちら↓ tech-blog.rakus.co.jp はじめに テーマ発表 Chat Dealer 配配メール Mail Dealer 楽楽精算 働くDB 自由発表 Githubでタスク管理 CfP を書く技術 LT発表 コードの好みを知りたい おわりに テーマ発表 業務 カイゼン ジャーニー 新年最初のビアバッシュのテーマは業務 カイゼン ジャーニーでした。 ラク スの各製品の開発者にこんな業務 カイゼン をやったよ、というお話をしていただきました。 また、テーマ発表の後にはテーマ自由の発表やLT発表もあり、ボリュームのあるビアバッシュとなりました。 Chat Dealer リリース作業をAnsible化して 工数 削減が実現できたというお話でした。 Chat Dealerの発表内容 Chat Dealerはリリース頻度が高く、リリース作業が大きなコストになっていたそうです。Ansible化したことで作業手順がどのように変わったのか、どのあたりが楽になったのか、ということをお話いただきました。 お話しいただいた内容で私が開発に携わっている製品でも活用できないかと考えましたが、リリース作業を担当したことがなく実感がないので、まずは大変さを知るためにもリリース作業をやってみることから始めないとな、と思いました。 配配メール チームのタスク管理として最近始められたカンバン運用の振り返りについてのお話でした。 配配メールの発表内容 各メンバーが一日分のタスクを分割して付箋に書いて張り出し、遅れているタスクがないかチーム全員で 見える化 したそうです。 私もタスク管理が大雑把になっているので、個人的にカンバンのように 見える化 して カイゼン できないか試してみます。。。 また、今回の発表が一般的な業務改善の進め方と対比して振り返りを行うという形式でしたので、 カイゼン 活動を進める際の参考例として活用できるかなと個人的に思っています。 Mail Dealer ベトナム で行っているオフショア開発の カイゼン についてお話しいただきました。 品質が低いという課題とその対策の話も興味深かったのですが、特に気になったのは ベトナム メンバーの ヒアリ ングから分かった「日本メンバーが怖い」という課題があったことです。近くでコミュニケーションが取れない分、ミーティングの際は ビデオチャット で顔を映して、とにかく笑顔を意識するなど、細かなことから気を付けて カイゼン したという話が印象的でした。 Mail Dealerの発表内容 私自身も現在2年目ですでに後輩がいますし、来年度にはさらに増えますので、良好なコミュニケーションをとれるよう同じようなことを意識します。。。 楽楽精算 以前に取り組んでいたモブプログラミングを実際に業務プロセスの一部として盛り込んでみた、というお話でした。モブプログラミング自体の取り組みついてはMeetupの記事をご参照ください。 tech-blog.rakus.co.jp 今回は業務に組み込むうえで気を付けたこと、やってみた結果の振り返りをお話いただきました。 楽楽精算の発表内容 モブプログラミングの題材がリファクタだったので、どのようなソースがイケてないかという共通認識の形成に役立ったそうです。私の所属するチームでも、この「イケてない」という感覚を新人にどうすれば共有できるかという話が出たことがあるので、モブプログラミングをしてみるということは選択肢の一つとしてアリだなと感じました。 働くDB 開発規約に準拠したコードを作成し、さらにそれをテンプレートとして新規コードを起こす際に自動生成するツールも作成したというお話でした。 働くDBの発表内容 このチームでは明文化された開発規約が最近できたばかりだったので、規約に準拠したコードがほぼ無く、新しくチームに入った人が混乱してしまうことがあったそうです。 私が新しくチームに参加したらということを考えると、規約に準拠したコードがあればコーディングの細かな部分に悩まずに済みますし、自動生成ツールがあればなおさら楽に進められそうですね。 自由発表 Github でタスク管理 タスクをIssueをとして登録することで、 Github でタスク管理をするという話でした。 他のタスク管理ツールと比較をすると、プルリク エス トなどの開発関連作業含めて1つのアプリケーション内で完結することが利点だそうです。 Github でタスク管理 CfP を書く技術 CfPを書く際に意識したところを、実例を交えて解説していただきました。 ※CfPとはCall for Paperの略称で、カンファレンスのスピーカーとして応募する際に必要なものです。 トーク の内容や必要性などを記載し、主催者はこれを見て トーク を採択するか判断します。 CfPを書く技術 画像内の各色は、赤色が 推し ・オレンジ色が ニーズ ・ピンク色が エモ を意識して作成されたフレーズだそうです。 またこちらの内容については来月開催される Laravel JP Conference 2019 で登壇し発表します。 tech-blog.rakus.co.jp LT発表 コードの好みを知りたい ビアバッシュ参加者の方に対して「どっちのコードが好み？」というアンケート的な発表をしていただきました。今回は4つ事例がありましたが、参加者の好みが分かれるもの、偏るもの様々でした。 コードの好みを知りたい どっちが好み？は答えられますが、なぜ好むのかまでは改めて考えたことがありません。それを自分の中で明確にできると書くコードにも一貫性が出せそうなので、一度考えてみようと思います。 おわりに 1月のビアバッシュをダイジェストでお送りしました。 各チームとも課題を解決すべく様々な カイゼン 活動を行っていました。課題があることは成長できる余地があるということなので、引き続き カイゼン 活動を行っていきます。