2018年7月の記事一覧

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

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

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