スピードチェック入稿リリース秘話

ラクスルの数少ない女子エンジニアの加藤です。

今回は、8月末にリリースしたスピードチェック入稿のリリースまでのプロセスを書いてみたいと思います。

スピードチェック入稿とは

そもそも、チラシや名刺などの印刷をインターネットで注文したことのない方もいらっしゃるかもしれません。

ラクスルは、印刷物を扱うECサイトです。通常のECサイトと違って、商品を選んで配送先と決済方法を選んでもらうだけでは注文は完結しません。お客様が印刷するデータを入稿するという印刷ならではのステップがあります。

また、印刷用データはラクスルで印刷に適しているかどうかチェックして、適していない場合、お客様は再度入稿する必要があります。

これまで、ラクスルではデータが印刷に適しているかどうか、オペレーターが一つ一つチェックし、場合によっては微修正をしていました。人手でやっているため、印刷データが確定して実際に印刷工程に進む準備ができるまでに1日以上かかってしまうこともあり、急いで印刷物が欲しいというお客様の要望になかなか答えられていませんでした。

そこで、サイトを訪問している最中にその場でチェック結果がわかるようなシステムを開発しようということになりました。それが「スピードチェック入稿」です。

スピードチェック入稿画面

スピードチェック入稿画面

プロジェクトの始まり

入社してしばらく経ちそろそろ会社に慣れてきたかと思っていた4月末、プロジェクトのミーティングに呼ばれました。データチェックを自動化する理由が共有されて、成功させるぞという強い意志が感じられましたが、参加メンバーのドメイン知識が十分ではない状況で、議論も少し混乱気味。私個人としては不安がありつつも、とにかくやってみようという気持ちでミーティングを終えました。

プロジェクトは、ラクスルで提供しているデータチェック業務理解から始まりました。実際に、オペレーターの方が作業している所をメンバーみんなで見させてもらう時間もとりました。

・どんなデータが入稿されるのか
・どんなデータのどんな点を確認しているのか
・どんな修正を行っているのか
・どんなメールをお客様に送っているのか

最初はこのような基本的なポイントを一つ一つ確認していき、データチェックのドメイン知識の理解を深めていきました。

デザインと設計のプロセス

スピードチェック入稿のデザインチームはデザインスプリントを実施。毎スプリントごとにお客様からのフィードバックを受けてデザインが進みました。

使う人はどんな印象を受けるのか、どんなところで操作に詰まったり、戸惑ったりするのか。私自身はデザインチームではありませんでしたが、週ごとのデザインとフィードバックのシェアや、お客様へのインタビューの同行を通じで、ユーザ理解を深めることもできました。

ビジネスチームによるデータチェック要件の詳細化とデザインと同時並行で、システムの設計も始めました。

システムは、すぐにWebで時間のかかる処理を実装するときのオーソドックスな構成に決定。
・フロント:データチェック用のAPIを呼び出し結果を描画
・データチェック用のAPI: フロントから受け取ったリクエストを受けてジョブをキューイング
・バックエンドジョブ:データチェックやPDF変換を実施

システム構成

システム構成(模式図)

デザインスプリントが進んでいる間に、最小単位で連携して動くものを実装していきました。

初めて一緒に仕事をするメンバーで構成されたチームでしたが、REST APIなど共通した設計スタイルがあると設計検討も早く進むのを改めて感じました。

自走チームの開発スタイル

メンバーが各作業を進める中、試行錯誤したのはコミュニケーションとタスク管理でした。

ビジネスメンバー、デザイナー、エンジニアそれぞれに違うバックグラウンドを持ち、比較的自由に仕事をするメンバーが揃ったため、仕事自体はすごく速く進むのですが、みんなが協力しないと一つ一つの機能が動きません。

どんな風にコミュニケーションするか、どんな風にタスクの状況を共有したり管理したりするか。朝会や毎週の振り返りで、率直に意見やアイデアを言い合って、改善して進めました。

振り返り

毎週末の振り返り

以前のブログ記事では、開発スプリントやペアプロの紹介もありましたが、今回はペアプロは実施せず、また開発スプリントは回しつつも運用は比較的ゆるめ。それぞれのメンバーのやりやすさを優先させつつ、アクションが滞らないようにコミュニケーションをとって乗り切りました。

やっぱり何か起こる結合とテスト

いくつかのコンポーネントが連携するシステムの開発では、結合とテストの段階になって様々な考慮漏れが判明してスケジュールが遅れるというのが開発でよくある光景ではないでしょうか。

今回のプロジェクトでは、かなり前段階で様々なケースのテストデータを準備したりエラーケースの検討をしてきましたし、結合して動かすこともその都度行なっていましたが、それでもやはり本格的な結合やテストの段階で色々な問題が起こりました。

例えば、初めは入稿している原稿の縦横の方向を自動判別しようとしていましたが、チラシでは判定できるけれども、名刺では判定できないケースがあるということが間際になってわかったりしました。

もちろん前倒して考慮できればベストだと思いますが、初めての要素があるプロジェクトではなかなかそうもいかないものです。このプロジェクトでは見つかった時にその都度、チームで学習しながら、一つ一つアクションを決めていきました。

リリース!

風邪でチームメンバーが次々と休んでスケジュールが遅れ気味になったり、間際で解決が危ぶまれる課題が発生したりと、様々なことがありましたが、8月末に当初の予定通りリリース。日程的にタイトな状況になっていても、みんなでランチに行ったりとチームの雰囲気を保ち、コミュニケーションを密に取れるようにしていたのも、逆に予定通りのリリースに不可欠だったかもしれません。

リリース後も、スピードチェック入稿の状況をチームでモニタリングしながらの対応や改善、対象商品の追加が続き、多くのお客様に使われるサービスに育ってきました。フェーズが移り変わるとチームの状況ややることも変わっていきますが、これからもビジネスメンバー・デザイナー・エンジニアの垣根を超えて、お客様の体験がよくなっていくような開発を続けていきたいと思います。

 

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


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


脆弱性スキャナ「vuls」を導入 & updateしました

こんにちは。もうすっかり老害になったインフラエンジニアの渡邉です。

ようやく朝方涼しくなってきましたね。犬の散歩が捗ります。

突然ですが、みなさん脆弱性対応ってしてますか?

今に始まったことではないですが、特にインフラエンジニアにとっては脆弱性対応はとても面倒で手間がかかる頭の痛いタスクになっています。

というわけで今回は、弊社のraksul.com/hacobell.com環境に巷で話題の脆弱性スキャナ「vuls」を導入した話をしたいと思います。

続きを読む


ペアデザイン

ラクスルでデザインを担当している中村です。

ラクスルに入社してはや半年が経ちました。
ラクスルでは、ここ最近は主にUCD(ユーザー中心設計)などを取り入れたUX活動やUI設計・プロトタイピングなどをしています。

さて、今日は先日実践した「ペアデザイン」についてお話ししたいと思います。

続きを読む


京都オフィス立ち上げ秘話

4月ですね。

これをお読みの皆様の会社でも、新入社員が入ってこられたでしょうか。
ラクスルも無事2名の新卒を受け入れることが出来ました。
1名はエンジニアですので、ここに登場してくれる日も近いことでしょう。

前置きが長くなりましたが、早いもので入社してそろそろ1年になるエンジニアの渡邉です。
春ということで、今回はラクスルが新しく拠点として立ち上げた、京都オフィスについて
お話したいと思います。

まずはこちらを御覧ください。

京都事務所開設のお知らせ

続きを読む


エクストリーム・プログラミング(XP)を用いた開発

経緯

「複雑化する仕様、委託先との契約形態、稼働スケジュールやキャパシティーという課題を全部解消し、ついでに、雪や地震等で、委託先の変更を迫られてもすぐに対応できるシステムを作ってくれ」と言われて、一体どのようなソリューションにすれば、正しい課題解決ができるのか。そのような緊急度が高く、要件が極めてふわっとしている状態でプロジェクトが難航している中、CTOの泉に突拍子もなく「この課題は、この会社と一緒に共同で解決してみてくれないか?」と言われ、出会ったのがPIVOTALと、その会社が推奨するXPでした。

開始前:XPについて

書籍 エクストリームプログラミング などを読んで勉強しました。ただ、書籍の内容は理解できるのですが、本当にそうなのか?という疑問を抱きました。

  • 疑問1: ペアプロは生産性が下がるのではないか?
  • 疑問2: 将来を見越した設計よりシンプルな設計?

続きを読む


ラクスルでの開発スタイルについて

はじめに

ラクスルでサーバーサイドエンジニアをしている田中です。
印刷ECタスクフォース(以下ECTF)というチームでテックリーダーを名乗っています。

入社して1年ちょっとになりますが、その1年間でもオフィスが移転したりメンバーが増えたり組織体制が変わったり。。。と目まぐるしく状況が変化する中で、
エンジニアに焦点を当てるとドラスティックに変わった(んだろうなぁ)と感じるのが開発スタイルでした。

ちょうど新しい開発手法の導入期からジョインして色々なことを体験したので、そこを少しご紹介したいと思います。

続きを読む


Electronを使ってデスクトップアプリを開発しました

ハコベルの開発をしている吉岡です。

入社してからずっと印刷ECの開発をしていましたが、
今年の5月からハコベルチームに移って開発してます。

ハコベルはインターネットを使って簡単に荷物の配送を手配できる
運送のマッチングサービスです。
もっと詳しく知りたい人はこの辺とかをぜひ見てみてください。

ちなみに、先日「Ruby biz Grand prix 2016」でハコベルがグランプリを受賞しました。
興味のある方は是非こちらもご覧ください。
https://www.wantedly.com/companies/raksul/post_articles/46184

それでは開発の話へ。

続きを読む