未分類

今年も Raksul Hack Week を開催します!

こんにちは。ハコベル(物流サービス)チームの加藤です。

今年も社内ハッカソンイベントの開催が決まり、準備が進んでいるのでその様子をご紹介したいと思います。

Raksul Hack Week #1

昨年9月に開催した社内ハッカソンイベント Raksul Hack Week #1

こんな概要で、オフィス内で4日間の日程で開催しました。

  • 参加者はエンジニア、プロダクトマネージャー、デザイナーとする
  • ハッカソンの期間は1週間とし、期間中はハッカソン100%コミット、普段の開発業務はやらない(※ ただし緊急対応系は最優先で)
  • チーム制とする
  • 最終日に各チームは成果発表する
  • ラクスルの事業、ステークホルダーに関わることであれば何に取り組んでも良い

(詳しくは 1週間やる、楽しい社内ハッカソンの作り方 をご覧ください)

Raksul Hack Week #1

いつもの業務から離れたテーマを行ったり、いつもとは違う技術を使って開発したり、他のチームのメンバーと仕事したり。それぞれのチームの発表もお互いに刺激になり、とても好評なイベントとなりました。

さらに、この中からプロジェクトとして採用されたり、実際に世に出たりしたものもあります。

ラクスルデザインブログもその一つ。バナー、LPから、各サービスのプロダクトデザイン、イベントブースのデザイン、RubyKaigi などのノベルティなど、オールマイティに活躍するラクスルの優秀なデザイナーが綴るブログとなっています。ぜひご覧ください。

どうなるかわからない不安を乗り越えて

さて、参加メンバーにも経営陣にも好評だった第1回を受けて、今年もめでたくRaksul Hack Week を開催することになりました。

今回の開催にあたっては運営メンバーを一新。UXデザイナーで入社した新卒2年目のロビンが手をあげてリーダーを務めます。印刷・広告・物流の各チームからメンバーが集まり、前回の運営メンバーのアドバイスをもらいないがら、週一回のミーティングをベースに準備を進めることにしました。

開催日程は、6月中旬の1週間。会社が成長しているので、参加メンバーも増加。2回目で大枠の進め方が見えているとはいえ、運営メンバーの中には前回まだ入社していなかったメンバーもいるのでどう進めるのか不安も出てきました。まずは、”Wednesday Raksul” という社内の技術勉強会中にみんなに前回の参加のJourney Map を書いてもらって、運営メンバーで共有するところから始めました。

とあるメンバーの Journey Map (イベント開催前)

とあるメンバーのJourney Map (イベント開催中)

第1回目は最終的にとても楽しく刺激になるイベントだったのですが、開催前には「やることを決められるだろうか」「チームメンバーを集められるだろうか」といった不安があったことが見えてきました。新しく入社したメンバーからも同じような声があがったので、なるべくその2つの課題のサポートができるばと思いながら進めることにしました。

Raksul Hack Week #2 のテーマは…

さてそんな中から生まれてきた、今年のRaksul Hack Week #2のテーマは

 

みんなで創る次の世界

〜好きなことから始まる挑戦〜

課題 ✖️技術✖️技術

 

事業部ごとに様々な背景を持ったメンバーが増えていたり、新卒メンバー4人は全員国籍が違うというほどダイバーシティーに力を入れていたりする現在のラクスル。

そんな中でラクスルの「仕組みを変えれば世界はもっと良くなる」というビジョンを実現する一つの手段として、次の世界をみんなの力を使って実現できるようなきっかけになるようなイベントにしたいという想いが込められています。

新しい試み Hack Week Lunch

Journey Map から見えてきたことや、今年のテーマを踏まえ、開催までの期間を以下のように区切りイベントを開催したり案内を出したりすることにしました。

  • 4月:アイデア月間
  • 5月:チーミング月間
  • 6月:Raksul Hack Week #2

4月から5月にかけては、各事業部のビジネスメンバーからお客様の課題、自分たちの業務の課題やこんなのがあれば嬉しいといった声を聞くランチイベント Hack Week Lunch を実施しました。

ディスカッションの内容をホワイトボードに記録。その場のディスカッションを盛り上げたり、その場でどんな話題が出たのか参加していないメンバーにも共有していきました。

Hack Week Lunch

さらにアイデアを共有するためのSlackチャンネル #hack_week_ideas を用意して、Hack Week に直接参加しないビジネスメンバーとエンジニア/デザイナー/PMがアイデアを出し合う場をオンライン上でも作りました。

#hack_week_ideas チャンネル

部門を超えて課題やアイデアを交換したりする場になってきて、次のステップの本質的な価値提供の話題も上ったりしています。このチャンネルを通年運用したいという声もありました。

開催まで1ヶ月弱

いよいよ開催まで1ヶ月弱となってきました。5月はチーミング月間。「チームメンバーを見つけられるだろうか」という声に少しでもお答えしようと、カジュアルなプレイベントを実施する予定です。

今年はどんなチームや取り組みが生まれるのでしょうか。意外な組み合わせが、面白い結果を生んだりすることもあります。偶然の流れも大切にしながら、Raksul Hack Week #2 を楽しんでいきたいと思います。

 

ラクスルでは事業をつくっていきたいエンジニアを絶賛募集しています!

自分の書くコードで、印刷・広告・物流といった大きな産業の課題を解決するようなインパクトを作り出してみませんか。技術・業界・業務など多角的に理解を深めながら、自らアイデアを出し、主体的に事業家人材と一緒に事業をつくっていく。そんな働き方をしたい方をお待ちしています!

“CircleCI agent received a kill signal midway through the job” と急に言われるようになった話(2/12追記)

ラクスルでサーバサイドエンジニアをやっている小林です。

追記(2019/02/12)

CircleCI のバグ(?)だったようで、すでに修正されてます。

また、原因を少し追ったので、追記しました。

結論

CircleCI の command 内で exit すると、エラーになるので、

true / false コマンドを使って回避しました。

 

本編

今日も元気に開発を行っていたら、CircleCI のテストが下記のようなエラーで

失敗するようなりました。

最初、メモリが足りなくて殺されたのかなと思い、Rebuild with SSH でコンテナに ssh して、

topps を見ていたのですが、どうやらメモリ不足というわけではなさそうでした。

また、過去にテストの通っていたブランチを Rebuild してもテストがコケるので、

CircleCI の挙動が何かしら変わったのかなと思い、.circleci/config.yml の設定を見直してみました。

すると、command 内で下記のようなことをしているコードがありました。

status=0
for file in $(
  circleci tests glob \
  "src/*/*Bundle/Tests/**/*Test.php" | \
  circleci tests split --split-by=timings
)
do
  php ./bin/phpunit -c app --log-junit $CIRCLE_TEST_REPORTS/phpunit/${file}.junit.xml ${file}
  if [ $? -ne 0 ]; then status=1; fi
done
exit $status

最後の exit が明らかに怪しいので、試しに消してみたところテストが通りました。

どうやら、exit すると circleci-agent も死ぬようになったのかなと推測されます。

というわけで、下記のように true / false コマンドを使うように修正しました。

status=true
for file in $(
  circleci tests glob \
  "src/*/*Bundle/Tests/**/*Test.php" | \
  circleci tests split --split-by=timings
)
do
  php ./bin/phpunit -c app --log-junit $CIRCLE_TEST_REPORTS/phpunit/${file}.junit.xml ${file}
  if [ $? -ne 0 ]; then status=false; fi
done
$status

変数にコマンドを代入すると、その変数を評価することで、コマンドを実行することができます。

2時間ほどハマったので、同じようにハマった方のお役に立てれば幸いです。

 

追記(2019/02/12)

CircleCI の挙動が何かしら変わった

のところを、もう少し深ぼってみました。

まず、再現条件をもう少し明確にするために、空のリポジトリに下記のような .circleci/config.yml を用意して CircleCI を走らせてみました。

version: 2
jobs:
  build:
    docker:
      - image: circleci/ruby:2.5.1

    steps:
      - checkout

      - run:
          command: exit 0

しかし、これではテストは失敗しませんでした。

問題の起きた .circleci/config.yml と見比べてみると、問題の起きたテストでは shell を変更していたので、下記のように .circleci/config.yml を修正してみました。

version: 2
jobs:
  build:
    docker:
      - image: circleci/ruby:2.5.1

    shell: /bin/bash --login

    steps:
      - checkout

      - run:
          command: exit 0

すると、前述のエラーと共にテストが失敗するようになりました。

shell を指定しない場合、 /bin/bash -eo pipefail で実行されているので、念の為、
/bin/bash -eo pipefail --login を設定してみましたが、やはりテストが失敗しました。

どうやら、/bin/bash --login を設定し、かつ exit するとダメなようです。

さて、--login オプションを指定すると、起動時に ~/.profile を、終了時に ~/.bash_logout を実行するようになります。

Man page of BASH#起動

そこで、Rebuild with SSH でログインして、~/.bash_logout の中身を見てみると、下記のようになっていました。

# ~/.bash_logout: executed by bash(1) when login shell exits.

# when leaving the console clear the screen to increase privacy

if [ "$SHLVL" = 1 ]; then
    [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi

試しに、/usr/bin/clear_console を手動で叩いてみたところ、無事(?)「”CircleCI agent received a kill signal midway through the job”」というエラーと共にテストが失敗しました。

どうやら、/bin/bash --login で exit すると、~/.bash_logout内の /usr/bin/clear_console が実行され、テストが失敗する、というシナリオのようです。

さらに、/usr/bin/clear_console の中で何をやっているのかを追ってみました。

https://github.com/linuxmint/bash/blob/master/debian/clear_console.c

コードを見たところ、/dev/tty/dev/tty0/dev/console 、stdinstdoutstderr の順番に、ioctl(fd, KBDKBTYPE, &arg) を実行し、キーボードの種類が取得できたものについて、コンソールをクリアするという処理を行っていました。

特に kill している風でもなかったので、また、Rebuild with SSH でコンテナにログインして、開いているデバイスファイルを順に確認することにしました。

screen コマンドをインストールし、順番にデバイスファイルに接続していきます。

すると、screen /dev/console を実行すると、「”CircleCI agent received a kill signal midway through the job”」とエラーになってしまいました。

どうやら、/dev/console を参照しようとすると、エラーになるようです。

と、ここまで調べたところで、CircleCI側で修正されたようで、/dev/consoleを参照しても、エラーにならなくなりました。

無事、修正されたということで、追加の調査はここまでになりました。

WebpackerをやめるならWebpackManifestというgemが便利、という話

先日、社内のSlackでpixivさんのブログ記事 今日から簡単!Webpacker 完全脱出ガイド がシェアされてて、『あっ、これは…弊社でもやったやつではないか。』とおもいました。Webpackerは便利なんですけどね。

本記事はこのpixivさんのポストを受けて WebpackManifest というgemを紹介します。

ラクスルでのWebpackerを辞めた経緯

  • もともとWebpackerを使った管理画面プロジェクトがあった
  • そこにECサイトも乗せるようなった
  • package.jsonは管理画面、ECサイトで分けて管理したかった
  • Webpackerは1個のpackage.json、1個のwebpackコマンド、1個のmanifest.json前提の作りなので、package.json分けて複数のwebpackビルド処理系を作りたいラクスルの用途に合わなかった => 脱Webpacker

pixivさんのブログで紹介されてるとおりで、manifest.json を Rails に組み込むための view helper が必要になったので、弊社内でも lib/ 以下に小さなライブラリを作っていました。

gem化

そして、社内で他にもRailsアプリが立ち上がりだしてきて、『そろそろ、gem化せななあ』とおもっていたところにこのpixivさんの記事でしたので、本記事執筆にあたって WebpackManifest というgemにしました。rubygemsよりインストール可能です。このgemを使うとwebpackerを使わずに webpack の webpack-manifest-plugin が出力するmanifest.jsonに従ってview helperが asset のパスやscriptaタグをrenderingしてくれるようになります。

もともとの社内にあった view helperのメソッド名よりpixivさんのメソッド名のほうが適切でしたので、ヘルパー実装部分はpixivさんの実装を参考に組み込み直しました。

使い方

  • Webpacker gem のアンインストール
  • 代わりになる webpack.config.js の作成
  • 素のwebpackの webpack-manifest-plugin を用いて manifest.json を出力する
  • WebpackManifest gemをインストールし、↑のmanifest.jsonのパスをセットする(詳細はgemの README を参照する)
  • gem付属のview helperを使う

という流れになります。

不具合等ありましたらPRいただければとおもいます。

まとめ

WebpackManifest というgemを使ったWebpackerをやめる方法をご紹介しました。

ラクスルではエンジニアを絶賛募集してます

ご興味ありましたらどうぞオフィスへ遊びに来てください。

 

wifi打刻システムをつくった話

出社時/退社時の打刻ってとても面倒くさくないですか?

わかっていてもついつい打刻するのを忘れてしまいます。そして月末の勤怠締めで打刻忘れの箇所を手動で1つずついれていく。。とても非生産的ですね。

そこでシステム的にこの問題を解決するべく、メルカリの記事を参考にwifi打刻システムをつくりました。

wifi打刻システムとは社員さんが持っている端末(携帯やPC)がwifiに繋がった時に出社打刻をし、最後にwifiに繋がっていた時間を退社時刻として退社打刻を行うシステムです。

それではwifi打刻システムを作る方法について説明していきます。大きくわけて3つのステップに分けることができます。

  • 社員が持っている端末がwifiに繋がっていることを検知する
  • wifiに繋がった端末から社員を特定する
  • wifiに繋がった時に出社or退社の打刻をする

社員が持っている端末がwifiに繋がっていることを検知する

携帯やPCなどの端末にはMac Addressという端末毎に固有な物理アドレスが割り振られています。

wifiルーターに繋がっている端末のMac Addressを取得することでwifiに繋がっていることを検知しました。

Mac Address取得する方法はいくつかありますが、今回はsnmpwalkというコマンドを使いました。

ルーターと同じネットワーク内にあるサーバー上でsnmpwalkコマンドを打つと接続している端末の情報が得られます。

あとはその出力をparseすることでwifiに接続している機器のMac addressの一覧を取得しました。

wifiに繋がっている端末から社員を特定する

wifiに繋がっている端末のMac Addressの一覧が取得できたので、どのMac Addressがどの社員のものなのか特定する必要があります。

今回は単純にMac Addressと社員番号を紐づけるデータベースを用意しました。

どのMac Addressがどの社員のものなのかはwifi打刻の利用申請を出す際にMac Addressも教えてもらうようにしました。

iPhone/AndroidのMac Addressの調べ方は以下のサイトが参考になると思います。

これでMac Addressの一覧を社員番号の一覧に変換することができました。

wifiに繋がった時に出社or退社の打刻をする

社員番号の一覧が取得できるようになったので、後は出社or退社の判定をして打刻をすればよさそうです。

判定を行うために社員番号を取得するスクリプトをバッチで数分間隔で実行し、wifiに繋がっている社員番号一覧を取得した際に、その時の時刻をwifiに接続していた時刻として社員番号と共に各社員番号について記録しておきます。

{
  1: { # 社員番号:1の人がいつwifiに接続していたかを記録
    connected_at: "2018-09-05 14:31:52 +0900"
  },
  2: { # 社員番号:2の人がいつwifiに接続していたかを記録
    connected_at: "2018-09-05 14:31:52 +0900"
  },
}

出社についてはその日初めてwifiに繋がった場合に、その時刻を出社として打刻すればよさそうです。

退社については最後に接続した時刻と次にwifiに接続した時刻が一定時間以上離れていた場合に退社時刻として打刻するようにしました。こうすることでランチなどで外出してwifiが切れた時でも退社打刻されないようにしました。

ラクスルの勤怠システムにはAPIで打刻する機能があったので出社or退社と判断された時にAPIを使って打刻を行いました。また打刻されたかどうかわかるようにAPIで打刻した際にslackでDMを送って通知するようにしました。

これでwifiに繋がった時に出社/退社打刻してくれるwifi打刻システムが出来上がりました。

まとめ

打刻忘れや打刻修正などの無駄な作業をなくすべくwifi打刻システムをつくった話を紹介しました。

実際にwifi打刻を使っている社員さん達から「すごい便利」「快適になった」と言った声も頂いています。wifi打刻の仕組み自体はとても簡単なので、やろうと思えばすぐに導入できると思います。

打刻が面倒だと感じたら導入を検討してみてはいかがでしょうか。

ラクスルではエンジニアを積極採用しています

ラクスルに興味を持たれた方は是非一度オフィスに遊びにきてください!

mini specが流行っている??うちもいつかやろう

こんにちは。
Raksul Platform Projectの水島です。

先日ふとProduct Manager(以下、PM)の平光さんから、「これって水島さんの昔の記事のことですよね?」と声をかけられました。

なになに??おお〜、私が前職のtechブログに書いたmini specに関する記事がカウルさんのブログで紹介されているではないですか!

スタートアップの現場で役立つ開発要件のまとめ方

涙ぐましい。魚拓から復元してくれたのかな。。。感謝。

実は、このときのブログの中で、「mini spec」でググると、外車のMINIのスペック情報が出てきちゃうし社内用語だよ、と書いていたのですが、今はちゃんとQiitaの記事がトップで引っかかるではないですか!

新機能をつくる前に整理しておきたい10のこと

しかもクラウドワークスさんも一部ご活用とのこと!そして、mid specなるものが。。。参考になります!
スタートアップ界隈でこういったノウハウがシェアされ、活用されていることに感激してしまい、ついついブログで書きたくなってしまっていました。

ラクスルでも当然mini specとかmid spec書いているんだよね?

。。。
いや、今は決まったフォーマットで書いていないです。。。

なんか書かなくても各スクラムのPMがストーリー分解できていて開発は一定回っていた状況なので今はいいかなと(本当はメンバー自身でストーリー分解するのが普通かもですが、ラクスルではPMが結構やる)。エンジニアからすると背景が見えないよ問題は時々起こりますが明確に導入するに至っていません。

あと私がメインでやっているRaksul Platform Projectは、相手にしているシステムと刷新の規模が大きくて、miniもmidも収まらない。。。 まさにlarge spec。決まったフォーマットはなくつらつらと方針とか計画とか意思決定したことなど、必要なドキュメントをチームで書いています。

プロジェクトの特徴的にも手を動かしたほうが見えてくる技術負債も多いような状況なので、ハイレベルなロードマップ、アーキテクチャーとデザインをエピック的に、Trelloにざっくりとcardを書いてとにかくガシガシ進めるスタイルをこのプロジェクトでは採用しています。後から漏れているタスクが多々出てくるので都度cardを追加していきsprint計画どころではないこともあります。。。泣。

このプロジェクトが落ち着いてきて中小規模な案件が増えてきたら、またmini specの運用をちょっとづつ考えてみたいと思っていますが、PMがmini specやmid specを書いてエンジニアに伝えて、というよりは、多少非効率でもエンジニア自身で大枠の仕様を決めたり、直接ステークホルダーに絡むともっと開発って楽しくなるのかなって最近思っています。

最近ベトナムでのオフショア開発も少しずつ開始していますので、言語の壁があったりリモートの開発部隊と協業するシーンで背景や仕様を伝える時には良さそうです。元々、mini specは、日本とサンフランシスコのエンジニア間で企画や仕様を共有するために生まれたものですから。

Raksul Platform Project の進捗

先日、会員登録、ログイン周りのUI刷新、内部的な認証認可のAPIの刷新をリリースしました。

見た目のデザインも変えていますし、今までメールの通達確認をしていなかったのでカスタマーサポートの観点でも問題があった部分を改善しました。
メールの通達確認を必須にすると会員登録CVRが落ちるんじゃないかという懸念がありましたが、計測してみるとむしろ良くなる兆しがあるくらいです。本当にやってよかった。

これで若干中途半端感があったraksul-authという内部APIのアプリをやっつけることができそうです。

また、平光さんリードでマイページ(ログイン後の注文などの確認機能)の刷新もリリースされました。

今までメニューが分かりにくかったり、ページング処理がない画面などが一部あり、エンジニアやカスタマーリレーション部のメンバーからも改善したいという声が大きかった機能です。
印刷ECは物販のECと比べて注文のステータスやお客様にしていただくアクションなどが複雑なので、マイページはとても重要な機能です。そのマイページの負を技術的にもユーザー体験的にも改善することができました。まだ、古いページも一部残っていますが。。。今後の機能拡張と併せて刷新していけそうです。

並行して、三瓶さんの活躍により決済のサービスが着々と仕上がってきており、より法人の方の決済ニーズを満たすことができる機能に刷新されていく予定です。

ガシガシ行きましょう。

新機能はrubyとgolangで開発する潮流

社内の潮流として、Raksul Platform ProjectでRuby on Railsのアプリケーション基盤が揃ってきたので、中規模以上の新機能については可能な限りRuby on Rails側のアプリで開発することを選択するようになりました。ここ半年で大きく変わってきた感触があります。

早いもので印刷サービスではそろそろ年賀状・喪中はがきの販売がスタートします。今年は新機能を乗せて販売開始をしようと準備をしていますが、新しいrailsアプリケーションの上で開発しています。

一部のタスクはとある事情でgolangで開発し、非同期の処理にはAWSのS3トリガーのSQSを組み合わせて実現したりと、なかなか楽しい感じのアーキテクチャーになってきました。
社内にもgolangの入門書が雑多に置かれています。ビジネス的にもエンジニアにとってもお客様にとっても今年のラクスルの年賀状は楽しみです。

詳細は追ってどなたかが書いてくれると信じて。。。

ラクスルではエンジニアを積極採用しています

赤裸々に書きましたが、こんな感じの私達と一緒に開発を楽しんでいただけるエンジニアをラクスルでは募集しています。是非一度オフィスに遊びにきてください!

We participated RubyKaigi 2018 as sponsor!

(日) こんにちは、エンジニアのゴンです。

先日、RubyKaigi 2018にSticker Sponsorとして参加します でお知らせした通り、今回はエンジニア合計5名が仙台で開催されたRubyKaigi 2018に参加しました。

RubyKaigiはRubyをテーマにした国内最大級のイベントで、Rubyのエンジニア同士がソフトウェア開発の知識を共有し合い、Ruby未来を議論するOSSコミュニティを拡大する場でもあります。Rubyはラクスルを支える中心技術です。ラクスルは今後もRubyを積極的に活用していきたいと考えており、このような機会を通じて少しでもRubyの発展に貢献していきます。

(EN) Hi, I’m Yiwen, a RakSul engineer.

Shortly before, we announced our sponsorship in RubyKaigi 2018にSticker Sponsorとして参加します. This year, I’ve joined the conference along with four other RakSul engineers.

RubyKaigi is one of the biggest conferences focused on Ruby programming language. It opens an opportunity for Ruby developers to share knowledge of building software, as well as growing an active OSS(open source software) community to discuss future of Ruby. Ruby is Raksul’s core technology, we hope we can make our contribution to Ruby community through sponsoring RubyKaigi.

今回のノベルティー

(日) スポンサーとしてのステッカー以外に、独自の温泉タオルも用意しました。受け取った方はぜひ温泉で使ってください!

(EN) Besides being sticker sponsor, we also designed our own Onsen towels. If you got one, don’t forget to use it when going for Onsen!

参加したエンジニアの感想——その1

※ Japanese version only

こんにちは、エンジニアの三瓶です。最近はラクスルの基盤となるシステムの開発をしています。
ラクスルに入社してまだ3ヶ月も経っていない新参者ですが、今回のRubyKaigiに参加させていただきました。自分は今回が初めてのRubyKaigiです。

興味深かったセッション

今回、個人的に興味深く感じたのは、Ruby製フレームワークの Hanami に関するセッションでした。

Architecture of hanami applications

というのも、ラクスルではDDDを取り入れた開発をしており、ソフトウェアの設計に関して考えたり議論することがこれまでよりもずっと多くなっていたからです。

HanamiはDDDの影響を受けていることに発表の中で気づき、またそれがフレームワークとして目に見える形で現れていることもわかりました。

Railsと表面上似ている部分もありますが、設計思想はかなり異なるように思います。
これまでRailsに触れる時間が長かったのですが、Hanamiの設計思想を学ぶことで、ソフトウェアの設計に関しても新しい知見が得られそうだなと感じたことが、興味深く感じた理由でした。

Rubyist達との交流

セッションだけでもお腹いっぱいですが、RubyKaigiは様々な人と交流する機会が多くあり、そういった点でも楽しむことができました。
また、各スポンサー企業の提供するノベルティや催しも充実していて、中には10000円のAmazonギフト券が当たるガチャポンを無料で提供している企業さんまでありました。

写真は、奇跡的に10000円のギフト券を引き当てた私の写真です。

 

 

 

参加したエンジニアの感想——その2

所感

こんにちわ、エンジニアの藤田です。私は、去年の広島に続いて2回目のRubyKaigiでした。初参加時もカンファレンスの規模の大きさとレベルの高いトークに圧倒されましたが、今年のRubyKaigiはより大規模になっていたと感じました。特に、参加者数やスポンサーの数、アフターパーティーの充実度は目に見えて伸びており、年々RubyKaigiの認知度や企業への影響力が上がっているのだなと実感しました。

気になったトーク

興味深いトークは非常に多かったのですが、個人的に衝撃的だったのは@k0kubunさんの「The Method JIT Compiler for Ruby 2.6」でした。発表はRuby2.6で導入予定のJITに関するもので、内容自体の面白さもさることながら、k0kubunさんの恐ろしいほどの早口と生き生きとした表情から、真のエンジニアとはいかなるものかを体現していたように感じました。

牛タンとOculus Go

仙台といえば牛タンですが、1日目のOfficial Partyが終わった後、弊社の有志でホテル近くの牛タン屋に飲みにいきました。最近、Oculus Goを買ったばかりだったので美味しい牛タンを食べつつOculus Goを初めて体験する同僚を見てニヤニヤしていました。(VRを体験している人を外から見るのって楽しいですよね)

Impression of the Conference From Our Engineers——Part 3

※ 以下英語のみ

Finally, it’s me, Yiwen. I’m a new graduate engineer, as well as one of the international employees in Raksul. While I was in college, I had one year exchange experience in Japan, and that’s when I met Ruby. I soon became obsessed with Ruby and decided to become a Ruby developer. Now I’m developing a new design service.

My Favorite Session

I’m overwhelmed with tons of new frameworks and topics from RubyKaigi! My favorite topic is Ruby code from the stratosphere – SIAF, Sonic Pi, Petal. It introduces a concept called live programming (a performance which people improvise music by typing programming instructions and let the program to create sounds). To me it’s a perfect combination of technology and art!

Communication with Other Rubyists

The other thing I enjoyed was building network with Ruby developers all around the world! After the conference ended, we moved to a park in the city center and kept talking about new technologies, Rails community, and career path as an engineer. The thing we had in common is that we all use Ruby to make great services!

Conclusion

We had so much fun in RubyKaigi this year! See you next year in Fukuoka!

お知らせ

ラクスルではRubyistを募集しています。ラクスルにご興味を持たれている方、カジュアルな形でぜひお話しましょう

PMに必要なスキルとは?新卒が1年を通して感じた4つの要素

こんにちは!ラクスルでプロダクトマネージャー(以下、PM)をしています平光です。
17卒の新卒として入社し、1年とちょっとが経過しました。
今日はこれまでの振り返りと学びを紹介しようと思います。

ラクスルにおけるPMの役割とは

ラクスルでは、要件定義からストーリー分解、スプリント / 長期の開発計画、受け入れテスト、サービスのリリースまでをPMが担います。
チームによっては、システムの設計にPMが入って議論したり、ワイヤーやデザインをPMが行うこともあります。開発チームによって求められる役割が異なりますが、チームに足りない部分を自分がカバーするかもしくはリソースを調達することで、サービスのリリースまで進めます。

役割が異なることによって幅広い業務に関われることはPMをやっていて楽しいですね。

課題設定が甘く優先順位が付けられない

入社してまず関わったのがラクスルのカスタマーサポート(以下、CS)チームが使う管理画面の機能拡張、再構築です。とはいえ、入社前にPMとして働いた経験があるわけもなく様々なことに戸惑いました。

例えば、

「機能一覧を書き出したり、実際に使う人にヒアリングして課題を書き出したりするもののどこから手をつけてよいかわからず優先順位が決められない」
「今のシステムがどのように作られているかわからず工数の見積もりができない」

大きなシステムだったので課題を把握した後、エンジニアと会話しながらスコープを小さく区切って開発していくのがよかったなと今になって思います。

シニアPMのもとで3ヶ月修行

約半年CSチームのPMをした後、ジョブローテーションの一環で発注基盤や物流などに関わるチームに異動しました。

シニアPMのもとペアワークをしながら、設計、ストーリーの作り方、プロジェクト管理、優先順位決め、エンジニアとのコミュニケーションなどについて学びました。
※ラクスルでは、ペアプログラミングだけでなく、場合によってはデザイナーやPMがペアワークをすることもあります。

この3ヶ月間で特に、ストーリーの作り方、分解の仕方について勉強になりました。

ストーリーは基本的なユースケースを満たせる幹となる部分から順に作り、その後エッジケースにあたる枝葉の部分のストーリーを書いていきます。

そうするとおのずとMVPから順にプロダクトを作っていくことが可能になります。

簡単な例ですがブログ投稿機能を題材に書いてみました。
ブログ投稿なので、ブログを投稿できるまでの必要な機能は幹となる部分ですね。
公開設定機能などは、ブログを投稿できるという要件に対してマストではなく、枝葉となる機能なので運用していく中で必要となったら開発。みたいな判断ができるかもしれません。
要件を考えれば考えるほど肥大化していきますが、開発リソースは限られているので本当に重要な機能かを見極めるのは大切だなというのを感じました。

また、ラクスルでは多くのチームで As / Given / When / Then… のGherkin記法を用いてストーリーを書きます。
ストーリーの書き方については過去の記事でも紹介しているので気になる方はそちらを見ていただければと思いますが、僕が実践している中で最も重要に感じたのはテスト可能な単位に小さくストーリーを分解することです。
そうすることで、工数の見積もりもしやすくなりますし、PMの受け入れテストもやりやすいです。
結果的に、見積もりが正確になっていると想定スケジュール通りに開発を進められるはずです。

プロダクト開発部のPMへ

その後、メインPMとしてスピードチェック入稿の商品拡張やマイページのリニューアルなどのプロジェクトに関わります。

デザイナーやフロントエンドエンジニアとプロダクトのデザインについて密にコミュニケーションを取り始めたのはこのタイミングが初めてでした。
また、属人的なテストを脱してテストを自動化するなどの守りの施策も重要だと認識したのもこのタイミングが初めてでした。
一歩引いた立場で全体を俯瞰し守りの開発も適度にプランニングできることも重要だと感じました。

1年を通して感じたPMに必要な要素

入社時は「PMの役割ってなんだろう」「PMのスキルセットってなんだろう」と思っていましたが、この1年を通して少しずつそれが明らかになってきた気がします。

  • 現状と課題を把握するためのドメイン知識
  • プロジェクトを進めるコミュニケーション
  • 意思 / こだわりを持って意思決定する
  • プログラミング、デザインへの理解

上記4つ、僕がPMに必要だと思った要素です。
一つずつ簡単に解説すると。

現状と課題を把握するためのドメイン知識

ドメイン知識が薄いと結果的に課題設定が甘くなり、プロダクトをリリースしてもエンドユーザーに使ってもらえなかったり、評価がいまいちだったりすると思います。

印刷 / データチェックの知識ももちろんですが、エンドユーザーがどうラクスルを使っていて何を課題に感じているのか、オペレーターが管理画面を使っていて何が使いづらいのかということを把握するのが大事だと思います。

プロジェクトを進めるコミュニケーション

プロジェクトを進める上で、エンジニア、デザイナー、顧客対応をするCSチーム、印刷委託先などなど多くの人が関わります。密にコミュニケーションをとらないとヌケモレが発生したりリリース直前でどんでん返しが発生してしまいます。特にエンジニアやデザイナーなどのプロダクト開発に直接関わる人たちに対しては、なぜそれが必要か?その課題に対して考えている解決方法が最適か?といったプロジェクトの意義について共通認識を持っておくことが特に重要だなと感じます。

悪い例だなと思うのは、JIRAなどのチケットに書いてある要件とかだけのテキスト中心のコミュニケーションしてしまうこと。
逆にいい例だなと思うのは、実際のUIや処理の流れの図を示したものをボードに貼るなどして、「ここに〇〇な機能が必要」「ここは〇〇の条件分岐で出し分ける」などを話すこと。そうすることで全体のゴールイメージの共通認識が持てるので、考慮漏れも発生しづらくなると思います。

意思 / こだわりを持って意思決定する

「この機能は初回のリリース時点では外そう」といったことが往々にしてあります。
開発工数の兼ね合いやリリース日との兼ね合い、または関係各所との調整で当初のスコープから変更をしたり、リリース日を調整したりすることがPMにはあると思います。そうした意思決定や判断ができてプロジェクトをとにかく前に進めていく力が必要です。

また、プロダクトや機能に対するこだわりを持てるともっと自分自身楽しくなるよ。とシニアPMからフィードバックをもらいました。

プログラミング、デザインへの理解

PMはエンジニアやデザイナー、ビジネスの人とのハブになっていることが多いです。
エンジニアとコミュニケーションをする上でもプログラミングへの理解があると「こういうやり方はどうか?」「こっちのほうが工数は少なくできそう?」といった話ができると思います。また、開発工数の見積もりもより正確にできるかと思います。デザイナーとのやり取りも同様です。

とはいえ、チームや会社によるのかなとは思います。
「PMにプログラミングスキルは必要か」というテーマの記事や勉強会を耳にしますが、やはり知見はあったほうがいいなと僕は感じます。

ラクスルのプロダクト開発のおもしろさ

プロダクトの企画、実際に形にしていく開発、リリースまでの全てに第一線で関われるところはとても魅力的です。

オペレーションの設計を考えて、それをシステムに落としていくところだったり、部署やチームが変わるに連れ印刷 / データチェック / 発注基盤など必要なドメイン知識が変わっていくところもラクスルのおもしろさだなと思っています。

今後は、より自分なりのプロダクトへのこだわりや強い意思を持ってリリースしていきたいと思っています。

新卒エンジニアとしてのラクスルでの1年間を振り返る

こんにちは、サーバサイドエンジニアの岸野です。

17卒の新卒2期目として入社してから1年が経った今、この1年間を振り返ってみようと思います。

1. 入社初日から開発着手

2017年4月3日、入社式で歓迎していただいて私は社内のオペレーションシステムの開発チームにジョインしました。開発環境のセットアップを終えた後、まずは簡単なタスクからでしたが入社初日から開発に着手しました。

新卒といえば1〜3ヶ月ほどの新人研修が設けられるイメージでしたが、勉強よりも実際に目的に向かって手を動かすほうが好きな私にとっては向いていたと思います。

もちろん研修期間がないからと言って放置されていたわけではなく、コードレビューや質問を通して多くのことを学びました。特に始めの数ヶ月では自分で調べる力と何が分からないかを伝える力が身についたと思います。

2. リアルな産業を相手にしているから面白い

ジョブローテーションで8月からは新聞折込やポスティングなどの印刷を利用した集客活動を支援する集客支援チームにジョインしました。

新聞折込やポスティングの大きな特徴としてはバリューチェーンが長いことがあげられます。

配布エリアを選ぶ、購入する、データを入稿する、データの審査、印刷、配送、配布

大雑把にあげただけでもこれだけ多くのプロセスがあります。この長いバリューチェーンを扱う時に重要だったのはプログラミングの知識はもちろんですが、それ以上に各プロセスに対する解像度でした。

配布エリアってどうやって決まっているんだ?

審査って何をしているんだ?

配布って誰がどこで何をして行っているんだ?

例えば、新聞折込の場合は印刷物を印刷した後に各地域の新聞販売店へチラシを差配する納品センターへ納品するのですが、納品センターや販売店によって納品日が早かったり遅かったりします。そこを各販売店ごとに納品日を最適化することで新聞折込の配布にかかる時間を短縮する事ができました。

このような各プロセスに対する解像度を高めることで新聞折込やポスティングの短納期化を実現することができました。また、この新聞折込の短納期化では社長賞をいただきとても感慨深かったです。

入社前は「印刷ECなんてそんな大して難しいことしてないでしょ」なんて正直思っていました。ところが蓋を開けてみると、現実の世界の複雑なプロセス、仕様をコードに落とし込む難しさがありました。そしてそこがラクスルの面白い部分なんだなと感じました。

3. ペアプロ

ラクスルの開発チームの一部ではペアプログラミングを取り入れています。実際にペアプロを体験して分かったメリットとデメリットをあげてみます。

メリット

  • パートナーがいるので集中できる
  • 知識の共有ができる
  • 属人化を防げる
  • キャッチアップが早い
  • 自信を持って作業を進められる

デメリット

  • 体力的にも精神的にも疲れやすい
  • コードレビュー以上に恥ずかしい
  • 二人共スタックしてしまうと効率が落ちる

メリットとしては生産性が上がったことがあげられると思います。2人で1つの作業を行うため生産性が半分になってしまいそうですが、自分が触ったことがない領域でも早くキャッチアップできることやレビューのコストが下がることでむしろ生産性は上がったと思いました。

また、学びが多いこともあげられると思います。プログラミングのテクニックや設計方法を学べることはもちろんですが、IDEなどのツールの効率的な使い方やドメインの知識などペアプロをするからこそ学べることも多かったです。

デメリットとしては集中して作業すれば体力的にも疲れますし、人に見られながらプログラムを書くことは恥ずかしいので精神的にも疲れやすいことです。なので疲れたときは休憩を入れたり、オフィスにある卓球台でリフレッシュを計るようにしていました。

まとめ

18卒入社式の写真

1年前は分からないことだらけで社会人としてうまくやっていけるか不安でしたが、今は温かい目で見守られながらのびのびと働くことができています。

また4月からは新卒3期目が入社したり別のチームにジョインしたりと新しい刺激の中、「世界をもっと良くする」ために2年目も頑張っていきたいと思います。

ラクスルでは新卒エンジニアインターンを大募集しています。一緒に世界の仕組みを変えていきませんか?

LTとコードゴルフで大盛り上がり!Hackers Partyレポート

hackers party

こんにちは。ラクスル内定者(2018年4月入社予定)の後藤です。
今回は、3月に開催されたラクスルエンジニアイベント『Hackers Party』についてレポートします。

Hackers Partyは、ラクスルのエンジニア・PMがカジュアルに交流できるイベントです!美味しいご飯とお酒を片手に、ライトニングトークやコードゴルフで盛り上がりました。


チキンや生春巻きなど、食事の準備も万端です。

catering
お寿司もありました!

イベントのコンテンツは大きく2つ。ライトニングトークとチーム対抗のコードゴルフ大会です。
これらについて順番にレポートしていきます。

ライトニングトーク

5名のスピーカーによる5分ずつのライトニングトーク。勉強になるお話や思わず笑ってしまう裏話で会場が盛り上がりました

スピーカー CTO 泉

LT

CTOののトークテーマは個人で裁定取引を使って暗号通貨で利益を出そうとしていたことについて。証券会社での勤務経験からいくつかのパラメーターに着目し、取引所の動きを追って適切なタイミングで暗号通貨を取引するプログラムを構築していたとのことでした。
新たなパラメーターを増やしプログラムの再度構築を試みたところ、パラメーターの関係がかなり複雑になって挫折したそう。利益獲得は一朝一夕にはいかないようです・・・

スピーカー 石田

LT

2018年入社の石田は1月にwebアプリ製作会社からラクスルに転職したエンジニアです。今回のトークは軽量マークアップ言語のasciidocの利便性について。途中からはライブコーディングを利用して、利用シーンをわかりやすく伝えてくれました。

スピーカー 加藤

LT

女性エンジニアの加藤は大手精密機器メーカー、食料品ECサイト運営、FinTechベンチャーを経て1年前にラクスルに入社しました。現在はプロダクト開発部に所属するサーバーサイドエンジニアです。担当業務の抱えている課題とそれに対する取り組み、今の苦悩と今後の理想の姿について話してくれました。

他にもpdfファイルの構造に関する話や、これまでのラクスルの裏話を発表するメンバーもいました。

 

チーム対抗コードゴルフ大会

コードゴルフとは、出題されたアルゴリズムを最も短いコードで書くことを競うものです。
出題は以下の3問です。※1
1.三項演算子をさらに短縮する問題
2.アスキーアートで円を描くコード
3.最短経路を探すコード

5名程度のチームに分かれ、メンバーと話し合いながら制限時間内で出題されたコードを短縮していきます。CTOの泉は、CTO力を試すためにチームではなく個人で参戦しました。
普段の業務とは異なる書き方に戸惑うメンバーもちらほら。果たして、その結果は・・・?

codegolf
コードゴルフの
準備をしていると、チームで協力しやすいようにデスクからディスプレイを持参する社員が!気合が入っています。

codegolf
新たな切り口を探して頭を抱えるCTO泉。
ぶつぶつと考え込むCTOの姿を見るのは初めてだったので新鮮でした!

codegolf
ディスプレイを覗き込んで相談するチーム。先ほどのディスプレイが大活躍しています。

codegolf
短縮できる箇所を入念に確認。
半年前に新卒で入社したゴン(写真左)のまなざしから真剣さが伝わってきます。

白熱する中、優勝したのはプロダクト開発部部長、水島率いるチーム!!喜びのガッツポーズです。
ちなみに、一人で戦ったCTOは見事2位。孤独な戦いを勝ち抜きました!

codegolf
優勝した水島チームは2台のパソコンで分担をしながら、こまめに話し合いを行っていた姿が印象的でした。
全員で同じ画面を見ているチームもあれば、各々が自由に解いて答えを確認しあうチームもあり、戦法にチームの特色が色濃く出ていたことに驚きました!

まとめ

コンテンツが終了した後も、コードゴルフの回答をさらに短縮しようと試みるメンバーがいたり、お酒を片手に話に花が咲いたりと大盛り上がり。
業務で多く関わらないメンバー同士、リラックスした表情で会話を楽しんでいたました。コミュニケーションが増えるだけでなく、リフレッシュにもなったHackers Partyは大成功でした!

talkingcodegolftalking

 

ラクスルでは現在、新しい仲間を募集中です!

今回のHackers Partyの他にも、毎月エンジニアのチームをシャッフルしたランチなど、エンジニア交流の機会があります。
次回のHackers Partyにはあなたも参加しているかも?


ラクスル採用ページ https://recruit.raksul.com/guideline/career

 

※1 コードゴルフ出典:プログラマのためのコードパズル ~JavaScriptで挑むコードゴルフとアルゴリズム(柳井政和著/技術評論社)

ノンエンジニアでも無線綴じ冊子の背幅計算ツールはできるのか?!

みなさん、こんばんは。
ラクスルの甲木です。

ノンエンジニアの私がふとしたニーズから超基礎のhtml/javascriptを利用して「無線綴じ冊子の背幅計算ツール」を作った話をしたいと思います。
(この記事、公開していいのかすらわからないレベルの初歩のオンパレード ※初心者なのでクソコードなのは勘弁してください。)

今回作ったもの

題名のとおり、「無線綴じ冊子の背幅を計算するツール」です。
まず冊子には大まかに中綴じと、無線綴じがあります。

  • 中綴じ冊子
    本を開いた状態で、本文を何枚も重ね針金で綴じた冊子。
  • 無線綴じ冊子
    本の背の部分全体に糊 (のり)を塗布(とふ)して表紙に貼り付けた冊子。

※中綴じ冊子・無線綴じ冊子の詳細は冊子ページからご確認ください。

このうち無線綴じで問題となっていたのが、表紙と本文の紙の種類・厚さ(斤量)・ページ数で、冊子になった際の厚さが決まるので、注文時に「これ1冊あたりの厚さ何mmなんだ??」とお客様が困っていたという点です。

エンジニアに頼めば15分くらいで作ってくれるかもしれませんが、頼むのも忍びないので作ってみました。

 

実際に作ってみる

まず最初にhtmlから。紙の種類・厚さ(斤量)の選択肢に対して、valueでミリ数を定義します。

<form name="keisan">
  <select name="hyoshi">
    <option value="0">用紙を選択してください。</option>
    <option value="0.065">光沢紙(コート) 薄手73kg</option>
    <option value="0.077">光沢紙(コート) 標準90kg</option>
    <option value="0.100">光沢紙(コート) 厚手110kg</option>
    <option value="0.132">光沢紙(コート) 最厚手135kg</option>
    <option value="0.072">マット紙(マット) 薄手70kg</option>
    <option value="0.107">マット紙(マット) 標準90kg</option>
    <option value="0.130">マット紙(マット) 厚手110kg</option>
    <option value="0.170">マット紙(マット) 最厚手135kg</option>
    <option value="0.098">普通紙(上質) 薄手70kg</option>
    <option value="0.120">普通紙(上質) 標準90kg</option>
    <option value="0.148">普通紙(上質) 厚手110kg</option>
    <option value="0.178">普通紙(上質) 最厚手135kg</option>
  </select>
  <select name="honbun">
    <option value="0">用紙を選択してください。</option>
    <option value="0.065">光沢紙(コート) 薄手73kg</option>
    <option value="0.077">光沢紙(コート) 標準90kg</option>
    <option value="0.100">光沢紙(コート) 厚手110kg</option>
    <option value="0.132">光沢紙(コート) 最厚手135kg</option>
    <option value="0.072">マット紙(マット) 薄手70kg</option>
    <option value="0.107">マット紙(マット) 標準90kg</option>
    <option value="0.130">マット紙(マット) 厚手110kg</option>
    <option value="0.170">マット紙(マット) 最厚手135kg</option>
    <option value="0.098">普通紙(上質) 薄手70kg</option>
    <option value="0.120">普通紙(上質) 標準90kg</option>
    <option value="0.148">普通紙(上質) 厚手110kg</option>
    <option value="0.178">普通紙(上質) 最厚手135kg</option>
  </select>
  <p><input type="text" name="page" value="0"></p>
  <input type="button" value="計算" onclick="keisan()">
  <output size="8" type="text" name="result">
</form>

次にこれだけだと、ただただ表示をしているだけなので、動的な処理をいれてみます。

 

無線綴じ冊子の背幅の計算式は下記となるので、この計算式に従ってjavascriptを記述します。

(表紙の厚さ(斤量) × 2) + (((本文の厚さ(斤量) × (ページ数-4)) ÷ 2 ) = 背幅の厚さ

※本文もvalueで定義している紙の厚さ(斤量)は1枚あたりです。入力してもらうページ数は2ページ = 紙1枚分なので最後に本文を2で割って紙の厚さにしています。
※本文を除いた背幅を計算するため4ページ(紙2枚分)差し引くようにします。

<script type="text/javascript">
  <!--
    function keisan(){

    var paper1 = eval(document.keisan.hyoshi.value) * 2;
    var paper2 = ((eval(document.keisan.honbun.value)) * ((eval(document.keisan.page.value)-4)));
    var calculated = Math.round(paper1 + (paper2 / 2));

    document.keisan.result.value = calculated;

  }
  -->
</script>

先程のhtmlにjavascriptを記述すると以下のようになります。
表紙・本文・ページ数を選択・指定すると何mmなのか計算することができました。

 

 

 

 

 

 

これで完成です。皆さんも冊子の背幅計算が必要になった場合は参考にしていただけると幸いです。

最後に

ラクスルには事業とものづくりが大好きなメンバーが揃っています。

そのメンバーと一緒に働いてくれる方を絶賛募集中ですので興味がある方は是非。

ラクスル採用ページ https://recruit.raksul.com/