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

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

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

ラクスルではXPでTDDを実践しはじめてからかれこれ１年近く経ちますが、なぜ今まで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 番地のフィールドにカーソルが移動する

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

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

実践例

実際、我々が運営する物流サービスの「ハコベル」のバックログを上記の書き方にして見ました。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反映させたり、実際プッシュ通知の制御をすることも同ストーリー内で定義されてました。

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

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

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

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

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

ぐっとこらえる！

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

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

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

結論

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

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

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

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

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

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

9月上旬に行ったAWS移行・・・前編につづいて、後編では移行の直前から移行後までの詳しい流れと、そこで得た学びについてお伝えできればと思います。

移行時の準備

システムの移行は常に「何か問題が起きる」もの・・・事前に用意できるものは、なるべく事前に用意しておきたいものです。

今回準備したものの一例としては、移行当日までに「いつまでに」「誰が」「何を」やっておくべきかをリストにした事前作業チェックシート。これに沿って当日本当に移行できる状態にあるかを確認します。 続きを読む

ラクスルに入社してから今月でちょうど入社から1年経った新米エンジニアの泉です。
思い起こすと「一年色々あったなぁ」と感傷にふける今日この頃です。

さて、9月上旬に行ったAWS移行について、インフラチームの渡邉よりインフラ側のブログ記事がありましたが、今回はアプリ側がどのような準備を経て移行をしたかを説明します。

続きを読む

昨年の10月にラクスルに入社し、３月よりCTOに就任した新米エンジニアの泉です。

最近スタートアップ界隈のビジネスパーソン、飲食を経営されている方など、何気なく出会った人に「あ！ラクスルさんなんですね！実は私も（チラシ｜名刺）刷ってます！」と突然「お客様」に遭遇してヘコヘコしてしまうことがありますｗ。嬉しい限りです。

CMなどもガッツリ力をいれているのもあって、ようやくエンジニアの方でも最近「CMで見ました」「名前は聞いたことはあります」と言っていただくことはあるのですが、さすがに個人でチラシを100部印刷したいといったニーズはなかなか訪れず、比較的サービスに触れる機会は少ないためか、よく「え？ラクスルってそんなに技術に力入れてるんですか？」とか「ラクスルのシステム部って何開発してるの？」と聞かれます。

というわけで、そもそも「ラクスルのエンジニアが何をやっているのか」というお題で少しご紹介したいと思います。

続きを読む

待望のPHP 7.0.0がついに2015/12/03にリリースされました。
っというわけでサクッと検証してみました。

スペック

使ったサーバー: IDCF 500円サーバー x2台
OS: CentOS 7.1

PHP 7.0  インストール

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm
yum install php70w php70w-opcache

 

でたー。
続きを読む

AWSがt2.microよりさらに小さいt2.nanoをリリースしました。
サービスの詳細に関しては EC2アップデートー T2.Nanoインスタンスが利用可能に を
参照してください。スペック的には下記の通りです。

($1.00 = ¥122で計算 2015/12/18時点)

インスタンスを立ち上げる

続きを読む

初めまして。入社して3ヶ月ちょっと、エンジニアの天野です。

さて、

はじめに

先日、運用中のWebシステムの一部に関して、ここはバーコードで楽にしたいねーという話が上がりました。
紙でやりとりが必要な作業があり、それに印刷されたバーコードをスキャンして、対応する情報をブラウザ上に表示するというものです。（それまでは人力で紙の情報とWeb上の情報の紐付けを行っていました）

バーコードリーダーという単語から、コンビニやスーパーのレジで使用されているあのゴツイやつを連想してしまった僕。
「それって組込み系言語でがっつりネイティブアプリ作んなきゃなんでしょ。うひょー」とか思っていたわけですが、実際はJavaScriptでさっくり実装できました…

ということで、今回はWebシステムとバーコードを連携させたお話です。
続きを読む

エンジニアの大嶋です。

先日、吉岡がブログでGoogle Mapsを使ったアプリケーションの作り方を紹介しましたが、

今回は同じAPI でも

Yhaoo GeoCoding API

についてご紹介したいと思います。

ラクスルのポスティングのシステムの裏側ではGoogle Maps APIだけではなく、
ケースによってはYhaoo APIを利用しています。
続きを読む

プロダクト開発部のやすいです。
この前の安井と同一人物ですが、基本的には平仮名のやすいの方が字面が好きなので、
そちらを使わせていただきます。

過去の記事で、ノンエンジニアでもSQLを使えるようになろう的なブログを書いていましたが、
やはり慣れなかったので、Tableauで出来る方法を考えました。

MySQL社内勉強会をノンエンジニア向けに実施してみた

Tableauを使ってSQLと同じことをやるということは誰でも出来るので、
パクッてもいいのよ。と思いまして書きたいと思います。

●下準備（データ接続）

とにかくデータに繋がないことには始まりません。
簡単データの繋ぎ方講座から。

タブの「データ」から「データを接続する」を選択。うちはMySQLなので、そこから基本情報を入力します。
各自、エンジニアにパスワードなどは聞いてね。ちなみに、MySQLに接続するにはODBCが要りますのでお気を付けを。

データの繋ぎ方です。
SQLを書かなくてもデータを繋げます。
テーブルとテーブルを繋げるのはドラッグ＆ドロップするだけ。簡単ですね。
ただ、それだけだと繋げたことにならないので、2つの間にある〇みたいなのをクリックすると
下の画像みたいなものが出てきます。
「内部」って言うのが、選んだ変数の中で共通にあるものを残すという意味で、
「左」って言うのが、選んだ変数の中で左にあるデータは全部残すという意味で、
「右」って言うのが、「左」の逆です。絵でなんとなく分かります。

これで、データの接続はOK簡単ですね。
もし、個人情報を持ちたくないなぁなんて場合は、タブにある「データ」の「カスタムSQLに変換」って言うのを押すと、以下の画像のような画面が出てきます。この中で、個人情報に該当する行を消せばOKです。
ラクスルの場合はメールアドレスですかね。

下準備はこれでOKです。
後は、ピボットの感覚でグラフがほいほい書けます。
気分はデータサイエンティスト！

●対象の一覧を出したい場合

例えば、「東京で売上げが1万円以上のお客さんを抜き出したい！」みたいな時ってありますよね。
そんな場合は、大体エンジニアに頼んでSQL叩いてもらうってのが定番だとは思いますが、エンジニアが忙しそうな時は超気まずい。
実は、Tableauで出来ちゃうんです。

１．フィルタに条件を入れ込みます。今回は「県名：東京」と「売上げ：10,000円以上」

２．適当に見たいデータを行に入れます。今回は「ユーザー」と「性別」と「誕生日」を入れました。

３．後は「分析」タブの「データ表示」して、すべてエクスポートをするだけ。後は煮るなり焼くなりご自由に。

●エクセルみたいに集計した数値を出したい場合

Tableauにも関数がたくさん用意されています。
本当に多い上に、割と分かりやすくて簡単です。
よく使う関数ベスト3

～第1位～「COUNTD([あ])」

「あ」の数を被っているのを1個だけと数えてくれる関数です。
パラメータを指定する「メジャー」の中にある「カウント（個別）」と一緒です。
しかし、なんとも複合的に使うのが多いのがこのCOUNTD。だから、覚えておいて損は無いです。

COUNTD([ユーザー])

とシンプルですけど一番使います。次の2位にも使ってます　笑

～第2位～「CONTAINS([あ]、い)」

もし、「あ」の中に「い」が含まれていたら、trueにするって関数。
集計する時はくっつけちゃって、trueをカウントしちゃいますね。

COUNTD(CONTAINS([ユーザー],”やすい”))

的な感じで、やすいがユーザーの中でどのくらい含まれているのかを数えてくれます。
超便利。

～第3位～「IF　あ　THEN　い　ELSEIF　う　THEN　え　ELSE　お　END」

もし、「あ」だった時は「い」で、それ以外の「う」だった時は「え」で、それ以外は「お」というもの。
条件に合わせてフラグ立てする時とかに使えます。あいうえおの部分に数式も入るので便利。
条件式にCONTAINS（）とか使うと、含まれている時などで使えます。
具体的には以下のように使います。

IF　[ユーザー]＝やすい　THEN　1　ELSEIF　[ユーザー]＝とねがわ　THEN　2　ELSE　0　END

もし、ユーザー名が「やすい」だったら、1で「とねがわ」だったら2でその他は0ってことですね。
集計とかに使いやすいです。

まとめ

意外と、エクセルで出来ることは大抵出来ちゃうTableau。
さらに、SQLが書けなくても、同じようなことが出来てしまいます。
データの抽出なんかをエンジニアにお願いする時代はもう終了。
みなさんもTableauを使って、快適データライフを送ってくださいね。
といいつつ、やすいも使いこなせているのか自信は無いですが･･･

PR

ラクスルでは現在WEBディレクター・WEBデザイナーを絶賛募集中です！
<ラクスル採用サイト>

あけましておめでとうございます！
ラクスルの淵野です。

2015年も始まりましたね。
本日が仕事始めの方も多いかと存じますが、
いかがお過ごしでしょうか？

昨年の7月に開始したこのラクスルtechブログも、
半年で26もの記事を投稿させていただきました。
エンジニアが書く技術系の記事もあれば、
ディレクター/マーケターによる記事、
はては、これtechか？と思われる怪しい記事まで、
ラクスルのメンバーの多様性を体現するかのような本ブログ。

今回はその中でも人気の高かった、2014年の記事BEST5を発表いたします！

5位：ラクスルの開発フローについて(8/4)

ラクスルの開発フローで利用しているツールと利用方法についてのこの記事。
GitHub、Redmine、Skypeなど、
社内で使用しているツールの一部の事例についてご紹介しています。
やっぱりこういう記事は人気がありますねー。
techブログらしい記事で納得のランクインです！

4位：ラクスルのインターンで学んだこと(9/1) 

インターンの大学生4年生Kちゃんの記事が4位にランクイン。
何気なくラクスルにジョインした彼女が、
自身とラクスルの成長の2年間の変遷を綴った記事。
彼女自身の人柄が伝わるほっこりした内容で、
ソーシャル上でも感動の連鎖を呼びました！

3位：新しいIDCFクラウドを使ってみた(10/15) 

IDCフロンティアさんのIDCFクラウドの設定手順を紹介した記事。
サービスリリース当日というタイミングに、
設定手順の画面キャプチャを気合で貼りまくったおかげ(総数28枚！）で、
IDCフロンティアの中の人もソーシャルで本記事をシェアしていただき、
見事3位にランクインです！

2位：なぜ、上場直後のリクルートからラクスルに転職したのか？(12/1) 

ディレクターY氏が入社日にいきなりtechブログに投下した、
全くtechとは関係ないこの記事。
超刺激的なタイトルと生々しい内容が相まって、
Facebook上で多くのシェアを獲得いたしました。
大手企業からスタートアップへの転職をされる方は最近多いでしょうから、
一つのケースとしてかなりこちらの記事は参考になるのではないでしょうか？

1位：テック系ベンチャーのノンエンジニアに抑えて欲しい7つのポイント(11/5)

エンジニアからノンエンジニアへの悲痛な叫びをまとめたこの記事。
Facebook、Twitter、はてなブックマーク等でバランスよくシェアされて見事2014年の1位に！
ラクスルではエンジニアによるMySQL社内講習が連日行われており、
最近はディレクターがエンジニアに依頼せずに、
自らSQLコマンドを叩いて データを抽出している光景がよく見られます（笑）。

まとめ

いかがでしたでしょうか？
始まって半年ほどではありますが、
BEST5だけ見ても かなりバラエティに富むブログになってきている印象がありますね。

2015年も本ブログは、 一部の方には（？）突き刺さるテーマの記事を、
自由気ままにご提供していこうと考えております。

こんなブログを見てラクスルに興味を持った方。
ラクスルではエンジニア・デザイナー・ディレクターを積極採用中です。
ブログの記事で少しでも興味ある内容をお知りになりたかったら、
お気軽にお問い合わせくださいませ！

<ラクスル採用サイト>