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にプログラミングスキルは必要か」というテーマの記事や勉強会を耳にしますが、やはり知見はあったほうがいいなと僕は感じます。

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

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

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

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

デザイン指針の必要性

こんにちは、ラクスルでUXデザイナーをやっていますガーワルロビンです。6月にオランダのアムステルダムで開催されたUXデザインのカンファレンス2つに参加してきました。UX戦略とUXデザインに特化した「UX STRAT Europe 2018」が6月11日・12日に開催され、またフロントエンドやテックの話も少し入った「CSS DAY 2018 UX Special」が6月14日に開催されました。

左:UX Strat Europe 2018の会場;右:CSS Day 2018の会場

ラクスルは2012年からネット印刷のサービスを提供し続けてしました。この6年間の間でサービスの形は変わり、ユーザーとのタッチポイントも変わってきました。変わり続けるウェブサービスを開発するにはプロダクトの形をリードする指針が必要だと思われます。ラクスルにそう言った指針がなかったため、ユーザー体験の一貫性がなくなってきました。ユーザーにより良い体験を提供するためには、どのようにプロダクトを作ればいのか、どのような組織でどのような開発を進めれば良いのか。いままでラクスルで進めてきた方法が正しいのか?もしくは別のアプローチがあるのか?その答えを探すため、カンファレンスに参加しました。

その答えになりうる勉強になった事項のひとつは、デザインプリンシプル(以下デザイン指針)でした。このブログでは主にデザイン指針とは何か、なぜ会社に必要かと最後に良いデザイン指針を作るためのコツを紹介します。では早速本題に入って行きましょう。

デザイン指針とは

CSS DAYの登壇者の一人で「Design Systems」の著者 Alla Kholmatova はデザイン指針を次のように説明しています。

デザイン指針は、特定の製品やチームにとって良いデザインが何を意味するかという共通の基準です。

ウェブ上で出てくるデザイン指針には様々な定義があるかもしれませんが、私にとってはこれが単純でストレートです。[参考までにInteraction Design foundation

デザイン指針の必要性がどこにあるのか

デザイン指針は、プロダクト開発において組織の基準を一方向に定めるために重要です。

Brio toys

Brioが色々なおもちゃを作っている中で、一目瞭然でBrioのおもちゃであることがわかります。

複数のプロダクト間の一貫性を保つ

デザイン指針があることによって、同じサービスやブランドに含まれるプロダクトにユーザーが接するときに迷わずに動作をすることができます。 ユーザーがプロダクト間で一貫性のある経験を持ち、同じ機能が違うプロダクトで複製することができれば、タスクをスムーズに進めることができます。 この一貫性は、Atlassianの幅広い製品で見られます。 Atlassianは3つのデザイン指針を定義し、プロダクトの必要に応じてそれぞれの度合いを微調整して行きます。

アトラシアンが定義している3つのデザイン指針

アトラシアンが定義している3つのデザイン指針

時間依存性を減らす・長期間で一貫性を保つ

事業会社では同じサービスを何年も、もしくは何十年も市場に出すことがあります。 ビジネス制約の変化やチームの変化によってプロダクトに対する良いデザインの定義も変わることがあり、長期間経つとサービスはユーザーにとって一貫性のない体験になりがちです。 デザイン指針を中心にプロダクト開発することによって長期的にものを同じ軸で評価することができ、組織やビジネス制約に依存性を減らすこともでき、一貫性の高い体験を提供することができます。

共通言語化で効率化

デザイン指針を明確に定義することで、組織のメンバーがプロダクトの開発や評価に関して同じ言語でコミュニケーションを行い、効率的に話を進めることができます。 開発ペースが早いウェブサービスにおいては短時間で精度の高いコミュニケーションを取り、デザイン判断を行えることがキモになると思います。

良いデザイン指針を定義するには

良いデザイン指針を定義するにはAlla Kholmatova民の「Design Systems」に戻って、話をしたいと思います。良いデザイン指針は以下の4つのパラメータで測ることができるそうです。
1. 本質的:実際の具体的な施策で説明をすることができること
2. 反意語が成り立つ:別の会社がそれの反意語でデザイン指針を定義することができること
3. 行動に起こせる:プロダクトの評価軸になること
4. 記憶に残る:シンプルで覚えやすい、いつでも思い出せること

またデザインプロセスをご存知の方はイテレーションを回す重要性がわかると思います。デザイン指針も同じように定義したもをでプロダクトを作ってデザイン指針のFine-tuningをする必要があります。これによってデザイン指針が会社のミッションや顧客価値からズレていないかを確認することができ、より洗練されたデザイン指針・プロダクト・ユーザー体験を作ることができます。

良いデザイン指針を定義するためのTIPSをいくつかあげます!
・会社のミッションから始める
・横断的なテーマを見つけ出す
・誰に向けてのデザイン指針なのかを明確にする
・仮説検証をおこなう  

サマリー

今回はデザイン指針について書かせていただきました。デザイン指針とは何か、それがあることによって会社へのメリットはあるのか、に加えて良いデザイン指針を作るためのTipsをいくつかあげてみました。

この二つのカンファレンスに参加することによって、確かにデザイン指針があることによって長期的により良い・洗練されたUXを設計することができると感じました。ラクスルでは現在以下のようデザイン指針を定義しています。私たちもデザイン指針の運用が初期段階にいるので、これからイテレーションを回して、改善する必要を感じています。
・シンプル:ユーザーがタスクを実行するうえで不要な機能やビジュアルエレメントが含まれていないか?
・明瞭:ユーザーがタスクを実行するうえで重要なアクション項目はひとつに絞られているか?
・一貫性:同じ機能で異なるビジュアルや性能をユーザーに提供し、混乱を招いていないか?
・速い:ユーザーは最短のスピードで必要な情報にアクセスできているか?

ラクスルでは、このデザイン指針を決めるためのワークショップをデザイナーやプロダクトマネージャーを交えて行う予定です!

私たちはユーザーにより良い体験を提供していくことに努めています!
良い体験づくりで世界をもっとよくしてきませんか?
ラクスルでは様々な職種の方々を募集しています。ラクスルの採用ベージへ
ラクスルについてもっと知りたい場合はこちらをご覧ください。

RubyKaigi 2018にSticker Sponsorとして参加します

こんにちは。エンジニアの三瓶です。

ラクスルは、2018/05/31 ~ 2018/06/02に仙台国際センターで開催される RubyKaigi 2018 にSticker Sponsorとして参加します。

RubyKaigiは、プログラミング言語Rubyに関する国内最大級のイベントです。
Rubyはラクスルを支える中心技術であり、今後も積極的に活用していきたいと考えているため、このような機会を通じて少しでもRubyの発展に貢献していきます。

今回のRubyKaigiではSticker Sponsorとして、毎年配られているRubyKaigiのステッカーをラクスルにてスポンサリング・納品させていただきました。

また、ラクスル自身のステッカーや便利でかわいいノベルティもご用意していますので、是非ノベルティ置き場にお立ち寄りください。

新卒エンジニアとしてのラクスルでの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/

【Ruby】Array から Hash を作る方法7選(a.k.a. やっぱり Array#zip はかわいいよ)

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

最近の業務では、主に Ruby を書いています。

さて、Ruby の組み込みライブラリにはいろいろな便利メソッドがありますが、
みなさん推しメソッドはありますか?

個人的推しメソッドは Array#zipHash#transform_values です。

Hash#transform_values について少し紹介すると、
もともと Rails4.2 の ActiveSupport で実装され、
Ruby2.4 で組み込みライブラリに移植されました。
移植の際は、名前をどうするかという議論でとても盛り上がったようです。
また、Ruby2.5 からは姉妹メソッドとも言える Hash#transform_keys が実装されました。

Hash#transform_values の話はこの辺にして、今回は Array#zip の推しポイントを紹介するため、
Array から Hash を作る方法について考えてみようと思います。

コーディングをしていると、下記のようなコードを書きたいことはないでしょうか?

  • ActiveRecord で取ってきて、id をkey、インスタンスを value にしたHash を作りたい
    • 例) [AR1, AR2, …] ⇒ { id1: AR1, id2: AR2, … }
  • 文字列のArrayに対し、元の文字列をkey、正規化後の文字列を value にしたHash を作りたい
    • 例) [Str1, Str2, …] ⇒ { Str1: NormalizeStr1, Str2: NormalizeStr2, … }

このようなときの実装方法をいくつかあげ、後半で性能比較をしてみようと思います。

 

以下、ActiveRecord で User 一覧を取得し、id を key、インスタンスを value とするHash を作成する場合を考えます。

空Hashに追加していく

他の言語でも実装できる、一番オーソドックスな方法かと思います。

array = User.all
hash = {}
array.each do |user|
  hash[user.id] = user
end
hash

 

Array#to_h を利用する

Ruby 2.1 から Array#to_h というメソッドが追加になっています。

レシーバを[key, value] のペアの配列として、Hash を返します。

これを利用すると、下記のように書くことができます。

array = User.all
array.map { |user| [user.id, user] }.to_h

 

Array#zip & Array#to_h を利用する

[key, value] のペアを作るのであれば、 Array#zip が便利です。

メソッドチェインですっきりと書けるところが、個人的気に入っています。

これだけでも、Array#zip がかわいいと思えます。

array = User.all
array.map(&:id).zip(array).to_h

 

Array#transpose & Array#to_h を利用する

レシーバを二次元配列として、転置配列を作成する Array#transpose を利用しても、
同じことができます。

array = User.all
keys = array.map(&:id)
[keys, array].transpose.to_h

 

Enumerable#each_with_object / Enumerable#inject を利用する

Array#to_h がない時代は Enumerable#each_with_objectEnumerable#inject を使うことが
多かった気がします。

array = User.all
array.each_with_object({}) do |user, hash|
  hash[user.id] = user
end

 

Enumerable#index_by を利用する(ActiveSupport)

よくあるパターンなので、ActiveSupport に Enumerable#index_by という、
まさになメソッドがあります。

ただ、こちらは Proc の返り値を key とする Hash を返すので、Array の要素を key、
Proc の返り値を value とする Hash を作りたい場合は、Hash#invert で一手間加える必要があります。

array = User.all
array.index_by(&:id)

 

Enumerable#reduce & Hash#merge を利用する

Lisp 的な発想で、 Enumerable#reduce と Hash#merge を使って畳み込みを行うことで 、
Hash を作ることもできます。

ちなみに、Ruby の Enumerable#inject とEnumerable#reduce は違う名前ですが、
同じ挙動をします。

少し話がそれますが、なぜ同じ挙動で名前が違うメソッドがあるのかについては、
るびまに書かれているので、読んでみると面白いかもしれません。

array = User.all
array.map {|user| {user.id => user} }.reduce(&:merge)

 

比較

みなさん、どの方法で実装することが多いでしょうか?

好みやコードの読みやすさなどで意見が分かれそうですが、一指標として、
各実装方法の性能評価をしてみたいと思います。

今回は、Array から Hash に変換する性能のみを評価するため、変換やメソッド呼び出しはせず、
Array から key と value が同じ Hash に変換する場合の性能を比較してみようと思います。

検証コード

ベンチマークの取得には、 Ruby on Rails Guides にも紹介されている
benchmark-ips gem を利用したいと思います。

検証コードは以下のとおりです。

#!/usr/bin/env ruby

require 'active_support/all'
require 'benchmark/ips'

array = (1..10_000).to_a

Benchmark.ips do |r|
  r.config(time: 20)

  r.report "Empty Hash" do
    hash = {}
    array.each do |num|
      hash[num] = num
    end
    hash
  end
  r.report "to_h" do
    array.map { |num| [num, num] }.to_h
  end
  r.report "zip & to_h" do
    array.zip(array).to_h
  end
  r.report "transpose & to_h" do
    [array, array].transpose.to_h
  end
  r.report "each_with_object" do
    array.each_with_object({}) do |num, hash|
      hash[num] = num
    end
  end
  r.report "index_by" do
    array.index_by { |num| num }
  end
  r.report "reduce & merge" do
    array.map { |num| {num => num} }.reduce(&:merge)
  end

  r.compare!
end

実行環境は以下のとおりです。

ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin16]
activesupport (5.1.4)
benchmark-ips (2.7.2)

 

結果

Warming up --------------------------------------
          Empty Hash    80.000  i/100ms
                to_h    73.000  i/100ms
          zip & to_h   108.000  i/100ms
    transpose & to_h    98.000  i/100ms
    each_with_object    70.000  i/100ms
            index_by    63.000  i/100ms
      reduce & merge     1.000  i/100ms
Calculating -------------------------------------
          Empty Hash    773.943  (±10.3%) i/s -     15.280k in  20.013161s
                to_h    733.483  (± 8.9%) i/s -     14.600k in  20.090466s
          zip & to_h      1.065k (±10.3%) i/s -     21.060k in  20.027320s
    transpose & to_h      1.005k (± 8.5%) i/s -     19.992k in  20.067946s
    each_with_object    719.383  (± 7.1%) i/s -     14.350k in  20.063602s
            index_by    654.471  (± 8.6%) i/s -     12.978k in  19.999714s
      reduce & merge      0.962  (± 0.0%) i/s -     20.000  in  20.834702s

Comparison:
          zip & to_h:     1065.3 i/s
    transpose & to_h:     1004.8 i/s - same-ish: difference falls within error
          Empty Hash:      773.9 i/s - 1.38x  slower
                to_h:      733.5 i/s - 1.45x  slower
    each_with_object:      719.4 i/s - 1.48x  slower
            index_by:      654.5 i/s - 1.63x  slower
      reduce & merge:        1.0 i/s - 1107.19x  slower

Array#zip 早いですね!!メソッドチェーンですっきりかける上、処理も早いという、
これは推さざるをえない感じがしませんか?

Array#transpose も Array#zip とほぼ同じくらいの性能ですが、
やはり個人的にはメソッドチェーンで書ける Array#zip のほうが好きですね。

他の手法についても見てみると、Enumerable#index_by が思ったより遅いです。
実装を見たところ、空Hashに追加していく実装と同じなので、
yield の呼び出し分オーバーヘッドがかかっている感じでしょうか。

Enumerable#reduce と Hash#merge を利用する方法は、
配列長分 Hash#merge が実行されるため、かなり遅くなっています。

 

ただ、実際のコードでは、key と value が同じということはなく、
key や value に対して何かしらの処理を行うため、Hash の作成コストより、
他の処理のオーバーヘッドが大きくなります。

別途、key を Integer#to_s して Hash を作成する場合のベンチマークも取ってみましたが、
空Hash に追加する方法が一番早く、Enumerable#reduce & Hash#merge を除く
実装方法については、それほど変わらないという結果になりました。

#!/usr/bin/env ruby

require 'active_support/all'
require 'benchmark/ips'

array = (1..10_000).to_a

Benchmark.ips do |r|
  r.config(time: 20)

  r.report "Empty Hash" do
    hash = {}
    array.each do |num|
      hash[num.to_s] = num
    end
    hash
  end
  r.report "to_h" do
    array.map { |num| [num.to_s, num] }.to_h
  end
  r.report "zip & to_h" do
    array.map(&:to_s).zip(array).to_h
  end
  r.report "transpose & to_h" do
    [array.map(&:to_s), array].transpose.to_h
  end
  r.report "each_with_object" do
    array.each_with_object({}) do |num, hash|
      hash[num.to_s] = num
    end
  end
  r.report "index_by" do
    array.index_by(&:to_s)
  end
  r.report "reduce & merge" do
    array.map { |num| {num.to_s => num} }.reduce(&:merge)
  end

  r.compare!
end

=begin
Warming up --------------------------------------
          Empty Hash    17.000  i/100ms
                to_h    15.000  i/100ms
          zip & to_h    19.000  i/100ms
    transpose & to_h    18.000  i/100ms
    each_with_object    19.000  i/100ms
            index_by    18.000  i/100ms
      reduce & merge     1.000  i/100ms
Calculating -------------------------------------
          Empty Hash    192.959  (± 8.8%) i/s -      3.825k in  20.060582s
                to_h    178.314  (± 9.0%) i/s -      3.525k in  20.023982s
          zip & to_h    181.005  (±10.5%) i/s -      3.572k in  20.065550s
    transpose & to_h    176.782  (± 9.1%) i/s -      3.510k in  20.039329s
    each_with_object    192.932  (± 5.2%) i/s -      3.857k in  20.054975s
            index_by    182.739  (± 4.4%) i/s -      3.654k in  20.036235s
      reduce & merge      0.905  (± 0.0%) i/s -     19.000  in  21.030102s

Comparison:
          Empty Hash:      193.0 i/s
    each_with_object:      192.9 i/s - same-ish: difference falls within error
            index_by:      182.7 i/s - same-ish: difference falls within error
          zip & to_h:      181.0 i/s - same-ish: difference falls within error
                to_h:      178.3 i/s - same-ish: difference falls within error
    transpose & to_h:      176.8 i/s - same-ish: difference falls within error
      reduce & merge:        0.9 i/s - 213.18x  slower
=end

ちなみに、空Hash に追加するという Enumerable#index_by の実装も、
リファクタリングされて現在の形になっています。

まとめ

コーディングの際よくあるパターンとして、Array から Hash を作成する実装方法を7つあげ、
性能比較をしてみました。

個人的推しメソッドである Array#zip のかわいさが少しは伝わったでしょうか?

 

iframe で複数の管理画面を1つの統一されたサイトに見せるパターンのまとめ

こんにちは。エンジニアの二串です。普段はサーバサイドの開発をしていますが、今日は最近仕事で取り組んだフロントよりの話になっています。

iframe を使って複数の管理画面サイトをあたかも1つの統一されたサイトとして見せるパターンをまとめます。

iframe を使って別サイトをはめ込むことは簡単ですが、実際複数ページあるサイトをはめ込もうとすると、ただ iframe を使うだけでは力不足です。例えばiframe内でのページ遷移、高さ調整、パーマリンク等で問題を感じます。

今回紹介する tips のいくつかはインターネット上で見つけられますが、今回の複数管理画面を1つにマージするという視点でまとまった記事は見つけられなかったので、まとめたら便利なのではとおもい記事にまとめました。

コードスニペットを以下で掲載していますが、より詳しくはデモアプリも併せて見ていただければとおもいます。

背景

移行イメージ

ラクスルに存在する最もレガシーなシステムは admin と呼ばれるいわゆる管理画面です。PHPで作られています。そのレガシー管理画面を素早く新システム(Ops Rails製)へ移行する必要がありました。

当時の状況としては

  • 新管理画面はまだ機能が少ないが、今後の新規開発は新管理画面でしたい
  • 旧管理画面には多くの機能がまだあり、理想的には新管理画面に移植したいものの、工数的にさくっと移行できない
  • オペレーションの中心は旧管理画面から新管理画面に移行してしまいたい

というような状況でしたので、iframe を使って新管理画面の1機能として、旧管理画面の各ページを埋め込んでしまって、ユーザー目線での移行については少ない工数で完了させることにしました。

iframe埋め込みによる問題点

単に iframe の src 属性に URL を指定すると、以下の点が課題になります。

  • 旧管理画面のページ数は多いので、ページごとに iframe を設置するのは大変
  • iframe の高さ動的に変えれない(初期ページや子側でページ遷移した場合)。結果的にページが切れる
  • ブラウザアドレスバー問題
    • 子側でページ遷移を何回かした後に F5 を押すと元に戻る。またURL を他の人にシェアできない。
  • 子側ページ内のリンクが 旧管理画面URL 問題
    • リンク先 URL を Slack 等でシェアできない(できるけど iframe が外れる)
    • 別タブで開くと iframe が外れる
  • そもそも、デザインの統一性がない(子側のヘッダやサイドバーメニューが邪魔)

さらに補足すると、今回の2画面はドメインが異なるため、iframeの親・子間で window をまたいで javascript や css で操作しようにもクロスドメイン(CORS)のため DOM 操作できません。

仕組み全体像

以上の問題を踏まえ、以下の指針を立てました

ページ表示の流れ

  • 新管理画面側(Rails)では `GET /proxy?path=path/to/page` というエンドポイントを作り <iframe src=”https://旧管理画面/path/to/page”> をレンダリングする。つまりどんなページもはめ込むことができる。
  • 親・子それぞれに今回のための javascript  を設置し(parent.js, child.js)、window間通信は window.postMessage() API を使う。これによりクロスドメインであってもwindow間で通信可能
  • この通信路を使って子の page height などを 親に伝える。高さ以外の情報もあるので、メッセージタイプ(type)、メッセージデータ(data)を含めた object をデータペイロードに入れて送ることにする。
  • iframe内のリンクの諸々の問題は、a タグの href の値を力技で新管理画面のproxy URL に書き換える。
  • サポートブラウザは Google Chrome のみとする。社内利用のツールなので工数削減も踏まえ割り切れる点と、そもそも社内で Google Chrome が標準で使われているので。

以下、長くなりますが、1つずつ見ていきます。

GET /proxy?path= エンドポイント

# app/controllers/proxies_controller.rb
class ProxiesController < ApplicationController
  def show
    path = params[:path] || ''
    @src = 'https://旧管理画面FQDN/' + path
  end
end

# app/views/proxies/show.html.erb
<iframe id="proxy-iframe" src="<%= @src %>" height="1024" style="overflow: hidden; border: none;" scrolling="no" frameborder="no"></iframe>

# config/routes.rb
get '/proxy', to: 'proxies#show'
  • GETパラメタの path から旧管理画面の URL を構築し iframe の src 属性へセット
  • height=”1024″ は初期値として。後述の方法で別途ページ毎に動的に変える。
  • その他、iframeのボーダー枠線。スクロールバーを消す。これはiframeっぽさを無くすための工夫
  • id属性 `proxy-iframe` は後述の javascript の処理で利用

これで旧管理画面の任意のページを新管理画面で扱えるようになりました。

なお、旧管理画面側が X-Frame-Options を返却していたので iframe 内で表示させるため nginx で消しこみました。

親・子window間通信

新・旧管理画面それぞれに以下の javascript を置きます。今回のケースでは、子から親に一方通行でメッセージを伝え親側でアクションさせればよかったので、子と親の通信はいわゆるクライアントサーバモデルになっています。

子側

const postMessage = (type, data) => {
  const rawData = JSON.stringify({ type: type, data: data })
  window.parent.postMessage(rawData, '*')
}

// iframe内でレンダリングされた場合にのみ発火させる
if (window !== window.parent) {
  window.addEventListener('load', () => {
    // 子の高さを親に伝え、親の iframe の heigit を変更
    postMessage('PageHeight', {height: document.body.scrollHeight})
  }, false)
}
  • iframe 内でレンダリングされた場合にのみ実行している
  • on load 時に高さを送る。メッセージには type と data がありJSON シリアライズして送る。

iframe 内でレンダリングされた場合にのみこの仕組が発動するようにすることで、移行をやりやすくしました。旧管理画面直アクセスでは発動しないので、旧管理画面直アクセスへのパスを残しつつ、緩やかに移行を進めれます。

親側

const messageHandlers = {
  PageHeight: (data) => {
    // iframe の height を調整
    let elm = window.document.getElementById('proxy-iframe')
    elm.style.height = `${data.height}px`
  }
}

window.addEventListener('message', (event) => {
  console.log('[ops] message received', event)

  // On development environment webpack-dev-server sends message, so skip message from it.
  if (/^https?:\/\/(localhost|127.0.0.1)/.test(event.origin)) return

  // Verify received message from for security manner of postMessage() API,
  const originRe = /旧管理画面URL/
  if (event.origin.search(originRe) === -1) {
    console.log('Blocked the message from ' + event.origin)
    return
  }

  const data = JSON.parse(event.data)
  if (data.type === null) throw new Error('[ops] Message received, but no type specified')
  if (!messageHandlers.hasOwnProperty(data.type)) {
    throw new Error(`[ops] Message received, but type "${data.type}" is invalid`)
  }
  messageHandlers[data.type](data.data)
})

細かいエラーハンドリングも載せましたが、中心は以下のとおりです。

  • window.postMessage() で送信されたデータは ‘message’ イベントで受け取れる
  • type に対応するメッセージハンドラ関数へディスパッチする
  • PageHeight ハンドラでは iframe の height 属性を変更

iframe高さの動的調整

1つ前のセクションのとおりです。

ブラウザアドレスバー問題

iframe内でページ遷移を繰り返してもブラウザアドレスバーのURLは最初のURLのまま問題。実際のカスタマーサポートなどの現場では、「あ、この注文、サポートが必要そうだから Slack で注文詳細のURLをシェアしておいて…」 といったことありますので、iframe内で遷移したあとの URL も気軽に貼り付けれる必要がありました。

そこで、子の a タグのクリックイベントを prevent default  で止めて、PageMove メッセージを送り、親側windowでページ遷移させてしまうことにしました。詳しくはサンプルアプリのコードを参照ください。

なお、a タグ以外に POST 等の後のサーバサイドでのリダイレクト処理される場合にも同様の課題はあります。管理画面の特性を検討した結果、リダイレクトについては特に何も対策せずとも運用上なんとかなると判断してます。

子側ページ内のリンクが 旧管理画面URL 問題

リンク先をシェアされたり、別タブで開こうとすると iframe が外れてしまう。

これに対しては、子側の DOMContentLoaded で hrefの属性値を 新管理画面の proxy URL に挿げ替えてしまうことにしました。

const fakeAnchors = function () {
  document.querySelectorAll('a').forEach(function (elm) {
    // getProxyUrlFromAdminUrl() は https://旧管理画面FQDN/foo/bar を
   // https://新管理画面FQDN/proxy?path=foo/bar に変換
    elm.href = getProxyUrlFromAdminUrl(elm.href)
  }
}

// iframe内でレンダリングされた場合にのみ発火させる
if (window !== window.parent) {
  // ...
  window.addEventListener('DOMContentLoaded', function () {
    // ...
    fakeAnchors()
  }, false)
}

なお、javascript を使わず、旧管理画面の view の各aタグを手で全て書き換える方が素直ですが、そうしなかった理由は、数が多いのと、暫くの間旧管理画面にダイレクトにアクセスできるパスは残しておきたかったためです。管理画面だから許される力技…です。

ページ内リンク問題

<a href=”#foo”>foo</a> のようなリンクです。iframe のオプションで scrolling=”no” している、また href をすげ替えた都合でスクロールしてくれないので、このようなリンクがクリックされた場合は、子から親に要素のポジションを計算して親側でスクロールさせるようにしました。詳細はサンプルコードを…といいたいところですがこの部分サンプル書けてないです :pray:

なお、production のコードではこの部分も window.postMessage() で 親にスクロール位置を通知させました。

ヘッダ・サイドバー消し

新管理画面の吸収されてしまった旧管理画面。もう旧管理画面のヘッダやサイドバーメニューは不要なので消します。旧管理画面側で DOMContentLoaded のタイミングで 追加の css ファイルを入れて、消し込むことにしました。

子側

const applyOpsCss = function () {
  const style = document.createElement('link')
  style.rel = 'stylesheet'
  style.href = '/css/additional.css'
  document.getElementsByTagName('head')[0].appendChild(style)
}


// iframe経由でのみ発火させる
if (window !== window.parent) {  
  applyOpsCss()
  window.addEventListener('DOMContentLoaded', function () {
    postMessage('PageDOMContentLoaded', {})
  }
}

  • iframe内でレンダリングされた場合に限り additional.css を適用する。additional.css 内では消したい要素に display: none; を適用している
  • DOMが読み込まれたら親に通知(次を参照)

親側

const messageHandlers = {
  // ...
  PageDOMContentLoaded: (_data) => { window.document.getElementById('proxy-iframe').style.visibility = 'visible' },
  // ...
}
  • スタイルを当てるまでの非常に短い間はヘッダ等が見えてしまうので画面がチラつく。これを防ぐために ngCloak 的なアプローチ、すなわち、iframe に `visibility : hidden;` で予め非表示にしておいて、追加のスタイルが適用されたら PageDOMContentLoaded メッセージを送信しiframe のdisplay visibility を `visible` に変更する

CORS でなければ親側だけで iframe 内の load を検知できそうな気はするのですが、CORS だったのでこのようにしました。

メニューのマージ

このタイミングでメニューバーを整理しました。新・旧それぞれのメニューバーにあった項目を整理し、新管理画面のメニューバーにマージしました。格段に見やすくなってこちらは評判です。

まとめと所感

iframe を使って複数の管理画面サイトをあたかも1つの統一されたサイトとして見せるパターンをまとめました。特に CORS 環境おいては window.postMessage() API を利用することで様々な課題を解決することができました。

この方式で本番運用して4ヶ月ほど立ちますが、大きなトラブルなく稼働できています。管理画面という特性上そのあたりは柔軟に対応できているのと、対応ブラウザを Chrome 1本に割り切ったので、導入後のメンテ工数は今のところほぼなく上手く動いてます。

本番の切り替えについては、旧画面と内容は変わらないので、導入調整コストがほとんどかからず、また利用者=オペレーターさん達の心理的負荷や学習コストも低く抑えることができました。これは本アプローチの最大のメリットではないかとおもいます。

ちなみに、このアイデアを思いついた翌週が運良く Hack It Day だったので、1日つかってプロトタイプを作って、どのあたりに技術課題があるか、工数感などつかむことができたのが良かったとおもいます。 * Hack-It Dayは月に一度、ラクスルのエンジニアが自由に開発することができる日)

さて、長くなりましたが最後までお読み頂きありがとうございます!!

ラクスルでは、絶賛エンジニア募集中です。
「仕組みを変えれば世界はもっとよくなる」
世界が変わっていく瞬間を一緒に体験したいエンジニアの方、お待ちしています☆