未分類

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/

TDDがうまくいかないときは、BDD形式でバックログを書いてみる

ラクスルに入ってはや2年を迎えたおっさんCTOの泉です。ラクスルに入ってから 6kg 体重が増え、ますますおっさんとしての安定感が増してきました。次の2年で 6kg 減らす予定です。

さて、今回のお題はエンジニアなら誰しも知っている有名な開発プラクティスであるTDDを実践する上でのTIPSです。

TDDはなかなか実践に至らなかったり、実践してみてもなかなかうまく行かず、挫折してきたエンジニアも多いのではないでしょうか。

ラクスルではXPでTDDを実践しはじめてからかれこれ1年近く経ちますが、なぜ今までTDDはうまくいかなかったのか、いままでとは何が決定的に違うのか、というのをそれとなく考えてみたところ、「バックログをBDD形式で書きはじめた」ことがTDDの実践に大きく影響を与えているのでは、と思うようになりました。

テストに入りやすいストーリーの書き方とは?

いざTDDでやってみよう、と思ったときに一番困るのが、「ストーリーに書かれている要件は理解したが、俺は何をテストすれば良いんだっけ?」と、テストケースそのものが想像できずに悩んでしまうことです。

例えば、「ユーザーは、届け先の住所を郵便番号検索で自動入力させることができる」というストーリーに対してテストケースを作れって言われても、一見シンプルそうなのにどんなテストケースを書けばよいのか、わかるようで正直いまいちわからない。

この時にAS/GIVEN/WHEN/THEN というBDD形式でストーリーを書くと、テストに簡単に入ることができます。(BDDはTDDの流儀の一つと考えると、当たり前っちゃ当たり前なんだが)

もともとこの書き方は、Pivotal Labsとの協業で学んだバックログの記述方法なのですが、この形式で定義されていると、圧倒的にテストに繋げやすい。

いままで自分は、BDDの定義は「エンジニアのお仕事」という理解だったのですが、プロダクトマネージャーが行うことで、エンジニアに要件がより正確に伝わり、結果エンジニアの考える工数を大幅に減らせることがわかりました。

書き方は以下の通り

  • AS – 誰が?
  • GIVEN – 前提条件: テストケースに入る前のシステムの状態は?
  • WHEN – どのような操作や入力があるのか?
  • THEN – その操作や入力のあとに期待すべき結果は?

AS

ここではシステムを使うステークホルダーの名称を書きます。「エンドユーザー」「管理者」「未登録のビジター」等の役割でも良いです。より良いのはオペレーターの「佐藤さん」調達管理の「鈴木さん」ヘビーユーザーの「加藤さん」等、チームで定義したペルソナの名前を表記すると、その人に対する価値提供をよりイメージしやすくなるかと思います。

GIVEN(OPTIONAL)

これはテストの前提条件を表します。例えば、

  • ログインしている状態
  • 「仮受付」の注文データが既に登録されており、支払いの入力が済んでいる状態

等、ユーザーの操作が行われる前に、システムがどういう状態にあるのかを明確にします。

そうすることで、エンジニアがテストを書く際、ログイン状態を作っておいたり、それに必要なフィクスチャーを準備することができ、テストの書きやすさにダイレクトに効いてきます。

ちなみにGIVENは OPTIONAL と書きましたが、たまに「ログイン状態に決まってるだろ」みたいに冗長になることが多いので、前提が書かずとも明確な場合は省いても良いと思ってます。

WHEN

ASで指定したユーザーはどのような操作を行うのか?平たく言えば、システムに対するインプットの定義を記述します。例えば、

  • 届け先フォームの「郵便番号」に「1060047」と入力すると
  • 「検索」ボタンを押すと

等。

かならずしも入力の伴わない行動もあります。例えば導線をクリックするとか。その場合は

  • AS ユーザーとして
  • GIVEN ログイン状態でマイページを表示しているとき
  • WHEN グローバルナビゲーションから「お問い合わせ」をクリックすると

といった形で、「結果をトリガーするアクション」を記述すれば良いのだと思います。

あるいは、バッチスクリプトなど、人間が行動を起こさない場合でも、「AS バッチ WHEN 9:15AMにバッチが起動すると」と記述することも可能です。

THEN

最後にその結果、何を期待するのかを記述します。例えば、

  • 「検索」のボタンが押下可能になる
  • 都道府県=「東京都」、市区町村=「港区南麻布」が自動入力される

等。これはテストにおいて、 assertion に表される部分です。

AND(OPTIONAL)

ちなみに、THENで期待することが二つになったり、アトミックな操作が後続する場合は、WHEN/THENを複数定義して、ANDを使って結合したりします。例えば、

AS ユーザーが
WHEN 届け先の郵便番号に106-0047と入力すると
THEN 「検索」ボタンが押下可能になり
AND
WHEN 自動記入のボタンを押下すると
THEN 都道府県=「東京都」、市区町村=「港区南麻布」が自動入力される AND 番地のフィールドにカーソルが移動する

等。ただし、上記のように、詰め込みすぎな案件が出来上がってしまうので、濫用するのはおすすめしません。このような形になるなら、「検索ボタンのステータス変更」「自動記入」と、2つのストーリーに分解するほうがよいかもしれません。

また分解することで「検索ボタンの押下可能制御は、ユーザビリティーの問題なので後回しにすっか」という意思決定もできるようになります。

実践例

実際、我々が運営する物流サービスの「ハコベル」のバックログを上記の書き方にして見ました。Before〜Afterで一例を見てみましょう。

この例は、いわゆるスマホアプリ内でみる「通知設定」的な機能です。

荷主様より新たな配送案件をお預かりする際に、ドライバーが使っているアプリケーションに新規案件が入ったことを知らせるためにプッシュ通知をしているのですが、ドライバーの方が休暇を取られたりする際にも通知が届いてしまい、ノイズが多くなってしまったので、アプリケーション側で通知の設定を行えるようにしたい、という案件です。

これが元々のストーリーです。

題名:ドライバーは、プッシュ通知、メールの新着通知ON/OFF、ONの時間設定をすることができる

詳細:
・設定ページ上でプッシュ通知のON/OFF設定ができる
・設定ページ上でメール通知のON/OFF設定ができる
・ONの場合は00:00~00:00で30分間隔で通知設定を行うことができる
・OFFになっていても、案件は従来どおり開示される
・XXXXXXの場合は、XXXXXXを優先する (企業秘密❤)

これがBDD形式にすることで、このように書き換わりました。

題名:ドライバーは、プッシュ通知、メールの新着通知ON/OFF、ONの時間設定をすることができる

AS ドライバーとして
GIVEN ログインしている AND 案件一覧を表示しているとき
WHEN 設定画面の⚙アイコンをタップすると
THEN 設定内容が表示されデフォルト値が設定されている(ON)
like
| プッシュ通知 | *ON*/OFF |
| 通知時間設定 | ON/*OFF* |
| 通知時間設定 | 00:00 ~ 00:00 |
| メール通知 | *ON*/OFF |

主語はもともとストーリーの題名ではっきりしていたものの、一体どの画面で何を期待しているのか、がエンジニアからみてもかなりクリアになり工数付けがしやすくなります。

因みにこの例では、 like 〜 (和訳:〜の様に)とありますが、このように表をつかったり画像を埋め込んだりして、どのようにそれが見えるのか、といった補足情報を入れる場合もあります。

元々の要件では、ドライバーが通知の設定画面を表示し、変更をDB反映させたり、実際プッシュ通知の制御をすることも同ストーリー内で定義されてました。

このストーリーは、表示・保存、さらに設定を適用した通知の振る舞いを変える、さらに(企業秘密❤)と4ストーリーに分解されました。この分解を行ったあと、元の要件に記述されていた(企業秘密❤)については、まずは、上記3点をリリースしてみて、その後に考えよう、ということになりました。つまり3つさえ終われば、「無駄な通知は届かない」という価値提供ができ、4点目の実装をまたずに先にリリースすることができるのです。

これくらい明確になれば、Request Spec で、設定ページにアクセス→デフォルト値が設定されている、というテストをすんなり実装できそうです。その後、実装に入り、テストをパスさせることだけに集中すれば、最小工数で実装を終わらせることができます。

TDDってなんでやるんだっけ?

TDDの目的には、テストカバレッジが上げることや、リファクタしやすさ、将来の変更に対する保険といった見方もあると思いますが、もっと本質的なメリットとしては「無駄な開発をしない」という点かと思います。

実装をしていると、例えば「あ、ここは直しておきたいな」「こういうUIの気遣いがあるとユーザー喜ぶんじゃないか」など、ついつい「やっておこうかな、やっておきたいな」という衝動が湧いてきます。このような「ムラムラ感」に対して「いや、やめておこう。いまは、このテストをPASSさせることだけに集中しないと」と抑制が効いてきます。

ぐっとこらえる!

もちろん、そういったムラムラ感は大事です。でも、事業的には、今開発していることは他にやりたいことを犠牲にして優先順位を上げてやっているわけで、その開発に対する投資(つまり開発の時間的な投資)は最小限、すくなくとも計画通りにしておきたいとも思うでしょう。

同じ価値提供をしているのに、工数が2倍に膨れ上がってしまっては「そんなに時間がかかるのであれば他のことをすればよかった」とその投資の正当性が崩れることもあります。開発をTDDで行うと、テストを通すことを最優先にするため、必要最低限の開発に留めることが可能になるのではないでしょうか。

ここはぐっとこらえながら、そのリファクタリングのアイディアは、次のHack-It Day向けに貯めておきたいところです。(*Hack-It Dayは月に一度、ラクスルのエンジニアが自由に開発することができる日)

結論

さて、最後の方はちょっと脱線しましたが、ここまで開発スコープが明示化されていると、少なくともRequest Specを書くことは圧倒的に容易になりテストドリブンの実践がかなりラクになります。

「TDDが出来ないのは俺(エンジニア)が悪いんじゃない!プロダクトマネージャーが悪かったんだ!」って言いたい訳ではないが、「要件ってどうやってエンジニアに伝えればいいんだろう?」と実際悩むプロダクトマネージャー(PM)の方も居ると思うので、この手法はオススメです。

半面、実際に書いてみると意外と難しい作業です。この粒度で要件を定義するためにはそれなりに深く考える必要があります。主語を特定すること、システムにどのような前提があるのか、何をインプットすると何がアウトプットとして出てくるか。慣れないとなかなかチャレンジングな作業だと思います。

しかしPMが「自分が実現させたいことをもう一度整理してみよう」というきっかけにもなりますし、開発が終わった段階で受入テストをする真面目なPMであればその手順が明確なので、スムーズにテストをすることができるかと思います。

また副次的な利点としては、上の例にあるように自然に「分解」されることかと思います。大雑把な要件からこの書き方に変えると、自然に「1ストーリー1アクター1要件」に絞られてくるので、「あ、これだったらもう一つストーリー切らないと」といった感じに、分解が進みます。

それによって「一旦こっちを優先しよう」「これは後回しでいいや」「お、一旦ここまで終わってれば機能リリースできるじゃん」と、より俊敏に動くことができそうです。この「柔軟性」がオプションとして後々選択肢に加わるのであれば、もう少し頑張って定義する価値もあると思います!

RubyKaigi 2017 in 広島!!!

RubyKaigi 2017 in 広島、昨日から3日間の日程で広島国際会議場で開催されています! 直前に台風の通過で天気が危ぶまれましたが、蓋を開けてみたら3日間快晴! 心地よい秋晴れです。

ラクスルもスポンサーとしてブースを出展中。今年も世界各国から、Ruby開発者やRubyを取り入れている企業の方など国際色豊かな雰囲気でカンファレンスは執り行われています。今年のラクスルブースへの最初のお客様はカナダの開発者の方で、弊社エンジニアの吉岡とともに最初から英語で企業説明したりと、盛り上がってます!

今年もカンファレンス参加者の方からお陰様で「ラクスル使ってます!」「最近入稿の仕組み便利になりましたね!(スピードチェック入稿)」などと嬉しいコメントいただきました。開発者としては身の引き締まる思い・・・。

RubyKaigiはコアな開発者が集まる会議とあって、最前線の情報を収集できる貴重な場とあってエンジニアメンツとしても貴重な時間です。ラクスル、ハコベルではRuby/Railsを用いて各種APIやWebシステムを開発しており、参加したエンジニアはブース応援傍ら気になるトークセッションに聞き入ってます。印刷のラクスルでどういうことにRuby使ってる?… とご興味のある方は是非お声がけください。

P.S. 今年も弊社技術顧問のまつもとゆきひろ先生にお立ち寄りいただきました。お忙しいなかありがとうございます!