食べチョク開発者ブログ

食べチョクエンジニアによるプロダクト開発ブログ

2019年6月の改善報告

こんにちは。食べチョクの鹿倉です。

食べチョクは、お客様・生産者様からのご意見を頂きながら、日々サービスの改善を行なっています。

今月より改善の内容や新機能などについて月次、週次でご報告してまいります。

是非、新機能などここでチェックしていただければと思います。

6月全体では以下の件数の改善を行なっております。

6月の改善サマリー

67件(機能改善:45件 、バグ改修:13件、その他: 9件)

上記の中から、いくつかピックアップして改善内容をご紹介いたします。

1. お中元特集ページを追加しました

お中元シーズンに向けてお中元特集をリリースしております。熨斗の対応なども可能な商品を集めております。

個人だけでなく法人のお客様も是非ご利用ください。

www.tabechoku.com

2. コンシェルジュのお届け農家の選定の精度向上

毎回違う農家さんからお野菜が届く定期便サービス(食べチョク コンシェルジュ)の改善を行なっております。

お客様によりマッチする農家さんが選ばれるよう、裏側の選定機能(過去の注文の評価、地域などを加味する機能)の改善です。

目には見えない機能ですが、リピーターのお客様に喜んでもらえるよう日々改善しているサービスですので、是非ご利用ください。

www.tabechoku.com

3. 購入履歴でレビュー済みかどうかを明記

お客様より多くのレビューを頂いておりますが、リピーターのお客様よりどの商品がレビュー済みか分かりやすくしてほしいといったご意見を頂きました。

購入履歴一覧にレビュー済みかどうかを明記するようにしております。

f:id:vividgarden-tech:20190717182754p:plain:w300

4. 予約販売商品はお届け開始日を明記

今までは予約販売商品はいつからお届け可能か注文ページまで行かないとわかりませんでしたが、商品ページにて確認できるようになりました。

f:id:vividgarden-tech:20190717192230p:plain:w300

5. 注文時にローディングアニメーションを表示

注文確定時に少し処理が長いことがあるのでローディングを表示するようにしています。

6. 住所登録時のバリデーションを追加

郵便番号と市町村の整合性取れていない場合は、警告を出すようにしました。

6月は7月、8月にリリースに向けての改修が多かったですが、 来月の改善報告では、また楽しみな報告ができると思いますので、引き続き食べチョクをよろしくお願いいたします。

2019年6月の改善報告 | 生産者様向け

こんにちは。食べチョクの鹿倉です。

食べチョクはエンジニアも直接生産者の皆様と連携を取りながら、日々サービスの改善を行なっています。

今月より改善の内容や新機能などについて月次、週次でご報告してまいります。

6月全体では以下の件数の改善を行なっております。

6月の改善サマリー

67件(機能改善:45件 、バグ改修:13件、その他: 9件)

上記の中から、生産者向けの機能改修をいくつかピックアップしてご報告します。

1. お届け日指定不可の商品を作成できるようにしました

今までお客様が購入の際、必ずお届け日を指定できるようになっていましたが、予約販売商品などお届け日をお約束できない商品もあるため、お客様がお届け日を指定できないように設定できるようにしました。 お届け日指定不可の商品は注文時に収穫でき次第お届けという旨のご案内をいたします。

2. 商品のお届け希望日指定可能期間を設定できるようにしました

今まではお客様が注文時に商品のお届け希望日を3ヶ月先まで指定できました。 生産者様より商品によっては長過ぎるとのご意見を頂き、今回、注文頂いてからのお届け日を指定できる期間を設定できるようにしました。

3. 注文一覧の改善

注文一覧に商品名を表示するようにしました。また、お届け日やステータスで並び替えができるようにしました。

4. 冷凍便設定をできるようにしました

今までは商品のクール便設定にて「冷蔵」しか設定できませんでしたが、「冷凍」も設定できるようになりました。 冷凍の場合は期間指定の必要はございません。

5. 注文詳細ページのデザイン調整

注文詳細は情報量が多いため、細かい微調整で生産者様の使いやすいようなデザイン調整を入れております。

6月は7月〜8月に向けての改善が多かったため、告知できる改善ボリュームが少ないかもしれませんが、内部的には今後に向けての改善をかなり行なっております。引き続き、生産者様と共により良いサービスを目指して行きますので、どうぞよろしくお願いいたします。

Developer向け企業アカウントの初ツイートを調べてみた

こんにちは、エンジニアの鹿倉です。

この度、食べチョクも開発者向けのツイッターアカウントはじめました。

イベントやメンバーの登壇情報、食べチョクの技術やリリース情報について配信していきたいと思います。 リリース情報については、生産者(農家)さん向けのシステムアップデートについてもツイートして行こうと思っています。

ということで、アカウント作成しましたが、1番最初のツイートを何にしようか、熟考しておりました。

ボケるのか、普通に行くのか・・・ 全然思いつかないので、普段よく使っているサービスのDeveloperアカウントの最初のツイートを参考にしようと思い勝手に調べてみました。

メルカリさん

いい。すごいいい。manコマンドで説明するセンス。痺れる〜。こういうのやりたい。

Cookpadさん

1ツイート目なんて関係ねぇぜ!って感じですね!惚れる!惚れるよ!

Wantedlyさん

出たー!HelloWorld!やっぱエンジニアならこれですよ!これこれ!

freeeさん

HelloWorld2票目!これは強いぞHelloworld!

SmartHRさん

Developer用アカウントではありませんが、SmartHRさんのツイートも気になったので調べてみました。

これは強すぎる!

ありがとうございます。

なんか見えてきたぞ。大体、初ツイート固まってきました。

これでいきます

仕事を任せられるエンジニアになるために意識してほしいこと

皆さんこんにちは。エンジニアの西尾です。

今日は仕事を任せられるようなエンジニアになるために意識してほしいことをまとめましたので、ここに公開いたします。

もともとは社内向けに公開したものです。

この文章は私がビビッドガーデンに入社する前の、前職での経験を踏まえて書いています。 今の食べチョクエンジニアが意識できていない、という話ではありませんのでご注意ください。

意識面

作業の見積もりができる

技術力が低い(コーディングができないなど)よりも敬遠されるエンジニアは、作業の見積もりができない方です。 第一線で活躍している方は、作業見積もりが他の方に比べて正確です。

見積もりをするためには、どういう設計をして、どういう機能を作り、どういう影響範囲があるのかを正しく理解する必要があります。 見積もりができないということは、作業内容を正しく理解できていない、技術的な困難性を理解していない、不確定要素を洗い出せていない、そして自分たちのスキルを正しく理解していないということです。

作業タスクを細かく洗い出すことができる、TODOを作ることができる

作るべき機能や設計を正しく理解していれば、作業を細かくタスク化できます。 タスクを細分化できないのならば、作るべき機能の理解が足りないということです。

TODOを作って細かくタスク分解をして作業を進められると、あとどのくらいでタスクが終わるのかをおおまかに把握できます。 紙にタスクを書き出すでもなんでもいいので、タスクを細分化できるようになってください。

進捗を正確に報告する

進捗報告は重要です。これは本当に重要です。

あと1日で終わりますと顧客に報告して、できていなかったら印象は最悪です。次の仕事をもらえなくなります。

もうすぐできますといって根性で何とかしようとする(徹夜してでも終わらせようという)のもやめてください。 徹夜して次の日のタスクがまともにできないのは困ります。重要なのは”正確に”進捗を報告することです。

遅れそうならば、遅れる旨を伝えましょう。 できてなくても、こういう理由で遅れそうとちゃんと伝えれば、お客さんもわかってくれます。 まわりもサポートしてくれます。できないのならば”できない”といいましょう。

言われたことだけをしない

「詳細設計書にはこう書いてあったから、変だと思いましたがそのとおりに作りました。」という人がたまにいます。 設計書に書いてあったからと行って、そのままうのみにして作らないでください。 変だと思ったらちゃんと報告してほしいし、そのへんはちゃんと自分の頭で考えてみてください。 言われたことだけをするエンジニアはいらないです。

優秀なエンジニアの方は、こんな機能も必要だと思うからつけておきましたっていう提案しつつすでに実装してた、みたいな方もいます。 報告なしで勝手な機能つけられるのは困りますが、そういう提案してくれる方のほうが、仕事をまかせたいと思えます。

わからなかったら相談する

わからないまま何日も考えて全くタスクが進んでいなかった、という人がたまにいます。 その方に割当てていた作業スケジュールが狂ってしまいまわりに迷惑をかけるので、早めに相談してほしいです。 プロジェクトが忙しくなると、リーダーも全員に意識がまわらなくなるので、その人の作業が進んでないということに気が付かないこともあります。

30分考えてわからなかったら、相談してください。 けど何も考えずによくわかりませんといってとりあえず相談するのも、やめてください。

自分が何ができて、何ができないのかを理解する

誰にでも得意・不得意分野があります。不得意で時間がかかりそうならば教えてほしいし、なんなら別の方にタスクを渡しても大丈夫です。 なんでもできますといわないでください。 スケジュールが狂うし、できていなかったときにまわりが尻拭いをしないといけなくなり迷惑です。

なんでもできるとは言わない

これは先輩の言葉です。

生産性のマイナスを理解する

エンジニアの生産性は、人によって10倍も100倍も違うといいますし、実際そのとおりだと思います。 そして生産性にマイナスに働く方がいるのも事実です。

設計・プログラムが適当すぎて、次に機能を作る人が全部作り直す、みたいな事になる場合があり、そういう仕事をする人は生産性にマイナスに働いています。 マイナスに働く人は居ない方がましなので、そうならないようにしてください。

成果物をすぐ見せる

優秀な方は作ったものをとりあえずでもすぐに見せてくれます。 逆になかなか成果物をみせてくれない人もいます。 いざ作業完了の期日になって見せてくる人もいます。そしてもう期限が無いのでこのままいこう、みたいな提案をしてくるのは最悪です。

方針が間違っていないかを確認するためにも、とりあえずすぐに成果物をみせてください。 プログラムを書く人ならば、最低でも1日1回はPRを送りましょう。 設計する人なら、雑でもいいので考えたことを文章なりなんなりでみせてください。

作った機能に責任を持つ

機能をとりあえず適当に作って放置し、バグがでても他の方にまかせるといった方がいます。 自分が作った機能は自分が最後まで面倒を見る気でいてください。 自分が作ったものに責任を持てない人には、仕事はまかせられないです。

技術に責任を持つ

新しい技術を採用するとき、なんとなく流行っているから、自分がやってみたいからだけで採用しないでください。 採用するのならば、自分が一番のプロフェッショナルになって、なんなら他の人に啓蒙するくらいの気持ちを持ってください。

触ったことのない技術をいきなりプロダクションで採用するとかもやめてください。 自分が詳しくないのにとりあえず新しい技術を入れて、まわりもよくわからずにシステムが崩壊するというのは、誰にとっても不幸せです。

スピードとクオリティのバランスを考える

フェーズや開発箇所によって開発スピードが求められる場合と、クオリティが求められる場合があります。

お金を扱う機能、契約を扱う機能など、この機能はバグってたら絶対にダメだろうというところは、開発スピードを落としてクオリティを上げることに神経を使ってください。逆に管理画面とか、まあバグってても大丈夫だろうというところはスピード重視で機能開発するなどしてください。

作る機能に興味を持つ

これから作るものに興味・関心をもってください。

ここはどうなってるんだろうとか、こういうパターンだとどうなるんだろう、実際に業務で使うときはどういう使われ方をするんだろうとか、想像して機能を作ってください。興味もなくとりあえず動けばいいや、みたいな考えで機能は作らないでください。

難しいタスクにもトライする

いつも簡単そうなタスクだけをとって、難しいタスクにはチャレンジしない人がいます。 難しいことをやって進捗がでなくなってしまったら印象が悪くなる、とかそういうことを気にしているのかもしれませんが、リーダーの方はちゃんと技術わかっているので、難しいタスクなんで時間かかったんだなとか理解してくれますし評価してくれます。 簡単そうなタスクだけやってとりあえずたくさん仕事してる、みたいなのは、見る人が見ればわかるし評価できないです。

優先順位を理解する

自分がやりたいタスクから着手ではなく、優先順位が高いものから着手しましょう。 最悪できなかったときに、どうでも良い機能作っていて遅れたとならないように。

集中力をあげる

プログラムを設計する、あるいはコードを書くには相当な集中力が必要なことを理解しましょう。 集中力を上げる努力をする、そして作業の割り込みをできるだけ少なくする努力をしましょう。

一日の集中力には限度があることを理解する

エンジニアが一日に集中できる時間には限界があります。

システム開発は神経を使う作業です。 そんなに長時間ずっと作業できないですし、そういうものだとちゃんと理解して作業しましょう。 徹夜して仕事したら、次の日は絶対作業効率が落ちますし、ダラダラ長いあいだ仕事していても意味ないです。

長時間労働=仕事しているとは考えない

どういうわけか、いまだに長時間労働している人=できる人だと勘違いしている人がいます。 長い間働いているようにみえても、実際全然成果を上げていない人もいます。 海外だと長時間労働してる人は、時間内に作業ができないやつだと思われて評価低いですし、私もそう思います。

1日の集中力には限度があることを理解しましょう。 ダラダラ仕事してるくらいならば、短い時間でさっと仕事を終わらせて、残った時間で新しい技術でも勉強するとか、そういう時間に使ってください。

体調が悪いときは休む

体調悪いまま仕事しても成果はあがらないです。 集中して作業しないと成果はでないです。 休んでください。

何事も効率化する

同じ作業を何度もするのならば、なにか効率化できないか考えてください。 エンジニアは作業を効率化する人であってほしいです。

タスクを持ちすぎない

タスクを持ちすぎないでください。 なんでも自分で面倒みないと気が済まない、なんでもやりたがる、自分の能力を過信している、あるいは単純に人が足りていないのが原因かもしれません。 タスクを持ちすぎると、すべてのタスクがうまくいかなくなります。 他の人もそのタスクに振り回されることになります。

自分が処理できる限界を超えたタスクをもたないでください。 タスクが増え過ぎたらアラートを上げる、他の人に渡す・まかせる、あるいはやらないときめてやらないなどして対応してください。 やらないという決断ができる人は優秀な方です。

小さなタスクは大きなタスクより時間がかかることを理解する

1時間でおわるタスクが8つと、1日かかるタスクが1つある場合、前者のほうが圧倒的に作業に時間がかかります。 コンテキストスイッチにはコストがかかることを理解しましょう。

成果を0から1、1から9、そして完成にもっていくまでの作業時間は線形ではないことを理解する

何もない状態から機能を作るのと、ある程度作ってからの作業時間はイコールではありません。 そして完成にまで持っていくのはもっと時間がかかることを理解しましょう。 9割完成しているからといって、作業時間はあとちょっとではありません。

会議は人の時間を奪うということを理解する

何の考えも無しにとりあえず会議を要求するのはやめましょう。 会議は他の人の作業時間を奪っているということを理解してください。 どうしても会議が必要ならばアジェンダを決める、ゴールを決める、必要な人だけを呼ぶ、そして会議の時間を短くと決めましょう。 会議を効率化する努力をしましょう。 1時間以上の会議は集中力も続かず効率が落ちるので、無駄です。

Y理論で管理する、あるいはされるエンジニアになる

驚くことに、事細かに作業を指示しないといつまで立っても作業を進められない、してくれないエンジニアは一定層います。 細かく指示を出してくれないと何もできないと主張したエンジニアも過去にはいました。

あの人はいつも怠けている、仕事を命令しないとやってくれない、そう思われるエンジニアにはなってほしくないです。 まわりの優秀な方も、マネージャーがマイクロマネジメントに走るようになると迷惑です。

自主的に行動できるエンジニアになってください。 タスクは与えられるものではなく、みずから作れるようになってください。 X・Y理論でいうY理論である職場であってほしいです。

設計面

ビジネスを理解する

ビジネスあってのシステムだということを理解しましょう。 機能を使う人の身になってシステムを作る努力をしてください。 この機能はどういう使われ方をするのか、今現状はどういうフローで作業しているのか、あるいはどういう機能にしたら使いやすいのか、ビジネスサイドの業務を理解してシステムを作ってください。

業務系システムほど使いにくい傾向がありますが、多くの場合エンジニアが実作業を理解していないことが原因です。 エンジニアにまかせて作った画面は使いにくい、そう言われないようにしてください。

将来の事を考える

その場しのぎの機能を作らないでください。 新しい機能を作るときは、将来どういう拡張がされるのか、どういう機能になっていくと思うかを想像してシステムを作ってください。

いきなりすべてを作る必要はありません。 ただし設計・想像をする努力はしてください。 一部のケースに対応できないためにすべてがひっくり返される、機能を全部作り直す、そういうことは往々にして発生します。 一度動き出したシステムを変えるのは容易ではありません。優秀な方ほど、先を見越してシステムを設計・開発します。 千里眼を身に着けてください。

影響範囲を理解する

新しい機能を足す、あるいは既存の機能を改修するとき、どの機能にどういう影響があるのか、影響範囲を必ず洗い出すようにしましょう。

保守にも手間がかかる事を理解する

新しい機能を何も考えなしに追加しないようにしましょう。 作って動き出した機能の面倒をみるのも、コストがかかるのです。

機能をシンプルに保つ

優れたシステムほど、驚くほど機能がシンプルです。 条件分岐が多いシステムは品質が下がり、開発、保守、テスト工数が指数関数的に増加します。 パターンを増やさない努力をしましょう。

異常系に目を向ける

正常系よりも異常系の設計をする方が難しいです。 そして異常系にどれだけ対処できるのか、設計できるのかがエンジニアの技術レベルの違いに現れます。

バリデーションが正しく書けるようになってください。 自分の思ったとおりのデータを入れて動いた、だけでは不十分です。 この項目は空のままサブミットしたらどうなるんだろうか、不正な入力値を入れたらどういう挙動をすべきだろうか想像できる人になってください。 ユーザーは想像もしないような操作をするものです。

テストの仕方を理解する

ソフトウェアテストの基本を学んでください。 テスト設計ができないと、品質の高いシステム設計はできません。

テストとはとりあえず適当に画面を叩くことではありません。 正しい要因(水準・因子)やシナリオを洗い出し、組み合わせを考え、さまざまなパターンを想定することです。 テストもまともにかけない、できないエンジニアは技術レベルが低いと断言できます。

本質を理解する

お客さんの言っている言葉を鵜呑みにしないでください。

「こういう機能が必要で、こういう画面にしたらいいと思うんだけど」。そういう提案をしてくる顧客はいますが、そのとおりに作る必要があるかは自分の頭で考えてください。 お客さんの言ってることをそのまま作っても、多くの場合良いシステムはできません。 うまくいかなかったとき、責任を顧客になすりつけないでください。自分から改善案を提案してください。

実装面

サーバーサイドでのバリデーション

バリデーションは必ずサーバーサイドでも実施してください。 クライアントサイドバリデーションは、UI・UXのために行うものです。データを扱うのはサーバです。 画面でいくらブロックしても、不正な値が保存されてしまう状態ができてしまうのでは、意味がないです。

何も考えずにコピペしない・わからないものをそのままにしない

ネットにあったコードをコピペして良しとしないでください。 よくわからない機能を放置しないでください。自分で考えてコードを書いてください。

開発時もログを見る

開発時にログを全く見てない人がいます。 見ればエラーだとわかるし、N+1のようなパフォーマンス問題も見つけられます。 そういう基本的な問題を見逃さないでください。

割れ窓を直す努力をする

割れ窓理論、というものがあります。 建物の窓が割れたままの建物を放置すると、その周辺の治安が悪くなるというものです。

システムも同じです。 汚いコード・設計が入ると、その周辺の治安が悪くなり品質が下がります。 窓を割らない努力をしましょう。 そして汚いところを見つけたら直す努力をしてください。

コードレビュー

レビュアーはテスターではない

コードのレビューを出す時、明らかに動かないコードを提出してくるエンジニアがいます。 自分でちゃんと動かしていますか。コードを書き換えて、自分で”テスト”してからレビューに出してください。 コードを書いて、一回も自分で動かさないままレビューを出すのは失礼です。 レビュアーはテストする人ではないのです。最低限のマナーを守りましょう。

強い言葉を使わない

「このコードは駄目だ」、「ひどい設計だ」、人の人格を否定するような言葉は避けましょう。 いくら優秀な人でも、言動に問題あるような人には仕事を任せたくありません。 その人の発言によって、まわりのモチベーションや生産性を大きく下げる可能性があるためです。

よりよいエンジニアになるために意識してほしいこと

新しい機能を自分で作れるようになる

既存の機能は改修できるが、新規の機能設計・開発を任せると全くできない、あるいは品質が著しく低いものを作る方がいます。 自分で新しい機能を生み出せるよう技術的な研鑽を積んでください。 新しいものを作れないのならば、いつまでたっても仕事はまかせられません。

昔から使われている技術を理解する

いまどきRDBは流行らない、Linuxの運用なんてマネージド・サービスに任せれば良い、そういって基本的な技術を理解していないエンジニアがいます。 昔から使われている技術を勉強するモチベーションを持ってください。 今なお使われているのには理由があります。 基本ができていないエンジニアは、応用もできません。

新しい技術を理解する

常に新しい技術をキャッチアップする努力を惜しまないでください。

ソフトウェア業界は技術の流れがとても早いです。 去年流行っていた技術が今年は廃れている、よくあることです。 重要なのは新しい技術を追い、なぜ流行っているのかを理解することです。 毎日仕事が忙しくて新しい技術を追いかけていなかった、のではいつのまにか使えないエンジニアになってしまいます。

巨人の肩の上に立つ

自分が最初に全く新しいアイデアを生み出すことは、ほとんどありません。 必ず前例があるはずです。誰かが作った成果物を真似し、その上に新しいものを作ってください。 巨人の上に乗れば、よりよいものを早く作れます。

関数型言語を勉強する

一度で良いので関数型言語を勉強してください。 優秀なエンジニアは関数型言語の基本を理解しています。 副作用のないコードを書く、命令的ではなく宣言的に処理を書く、正しく処理を分割する。 関数型の基本を学ぶと、プログラムの設計・書き方も大きく変わります。

一つの言語・技術を極める

自分の強みをもってください。 浅く広く勉強するのも大切ですが、何の特技もないのではどういう仕事を任せていいのかわかりません。

複数のプログラミング言語またはフレームワークを勉強する

1年に1つは新しい言語・フレームワークを学ぶ努力をしてください。 優秀なエンジニアは、必ず複数の言語を勉強しています。 他の言語から新しい考えを学ぶことができます。Rubyできれいなコードをかける人は、JavaだろうがPHPだろうが言語が変わってもきれいなコードがかけます。

デバッグ力を上げる

プログラムのデバッグができるようになってください。 バグが発生したら、なぜそのバグが起きたのだろうかとすぐ想像できる力を身に着けてください。 障害対応をするのは、大抵優秀なエンジニアです。

技術力を貯金する

休みの日に仕事ばかりしないでください。 新しい技術をみにつける努力をしてください。 技術力は貯金が必要です。 仕事と関係のない技術でも、必ずいつかプロジェクトの役に立ちます。

人の評価を気にしない、当てにならない

あなたの事を一番分かっているのは、あなた自身です。 人から評価されるように仕事をする、振る舞うよりも、自分が納得できる最高の仕事ができるよう、日々努力してください。

最後に重要なこと

楽しく仕事をする

仕事を楽しんでください。 つまらない仕事、興味のない仕事を続けていても成長はできないし成果も上げられません。 まわりにもその空気は伝わりますし、生産性・モチベーションに大きな影響を与えます。 つまらないと思うのならば、潮時なのかもしれません。

今やっている仕事を楽しむ、興味を持つ、より良くしていきたいと思えるようになってください。

www.wantedly.com

www.wantedly.com

食べチョクでもモブプロ始めました!

こんにちは!エンジニアの鹿倉です。

タイトルの通り、食べチョクエンジニアチームでも噂のモブプロ始めました。 ここでは、始めた経緯や継続してみた成果について紹介したいと思います。

チームにおける課題

食べチョクでは現在3名のエンジニアでゆるくスクラムを組んでやってます。
スクラム自体は去年の夏頃からはじめたのですが、ベロシティが中々、安定しないという問題がありました。
先週のスプリントでは結構ポイントを消化できたのに、今週は全然消化できてなかったり、チームとして安定した生産性を出せない日々がありました。

その原因

そこで一度、原因をチームで話し合いました。
いくつか意見は出てきたのですが、1番の大きな原因はRuby on Rails未経験メンバーが割合多いため、サーバサイドの改修タスクが多いスプリントは生産性が下がってしまうという結論に至りました。
また、2017年にローンチした食べチョクですが、フルタイムエンジニアを募集しはじめたのは2018年からで、今いるエンジニア全員、運用フェーズからジョインしてきたメンバーです。
それぞれのバックボーンや経歴がある中で、お互いが気を使いすぎて素直に分からないことを質問できないような雰囲気も多少あったかなと思います。

モブプロやってみよう

課題解決にはメンバーのRailsの技術力向上とチームとしてのルールの確立が不可欠です。
じゃあどうすれば良いかと考えていた時に、たまたまSmartHRさんのブログを見てモブプロやってみようとなりました。
SmartHRさんブログに挙げらている「モブプログラミングのメリット」を見て、モブプロめっちゃいいのでは?と考えた次第です。

tech.smarthr.jp

実際にやってみた!

まずは軽くやってみようということで、以下のルールではじめました。

  • 毎週月曜日
  • 4〜5時間くらいで終われる開発タスクを1つピックアップ
  • 弊社のハイパーRailsエンジニアN尾さんは基本的にナビゲーター
  • 他のメンバーは週替わりでドライバー

f:id:vividgarden-tech:20190301201914j:plain

こんな感じで進めました。

  • ドライバーは基本的には言われた通りにコードを書く。
  • 気になったところは都度ナビゲーターに質問。
  • ナビゲーター同士でも気になるところは純粋に聞く。意見を言う。

f:id:vividgarden-tech:20190301201800j:plain

成果

モブりはじめて1ヶ月が経ちました。
実際にすごい成果があったと思います!

日々のコミュニケーションも活発に

モブプロ中って3人以上でドライバーとナビゲーターって明確にポジション決めてやるので意見や質問が言いやすい雰囲気が生まれました。
そして、その雰囲気がモブプロ以外の日も続くようになってコミュニケーションが活発になった気がします。

ベロシティが安定してきた

いきなり技術力が向上するわけではないですが、元々、経験値のあるエンジニアメンバーです。
モブプロでRailsのお作法を早く習得できたことで、割と早めに結果が出てきたなと感じています。

最後に

今回、モブプロを通じてまたより良いチームワークが出来てきた気がします。
引き続きエンジニアが成長する働きやすい環境作りに積極的に取り組みたいと考えています。
そんな食べチョクでは毎週木曜日は食べチョクメンバーが食べチョク野菜を使って料理を振る舞う食べチョクランチも開催しています!
会社の雰囲気が気になってくれた方、是非お気軽にランチ食べに遊びに来てください!

とある日の食べチョクランチ

f:id:vividgarden-tech:20190301195851j:plain
f:id:vividgarden-tech:20190301200418j:plain

www.wantedly.com

本番環境のデータをマスクしてステージング環境に同期する

こんにちは。エンジニアの西尾です。

食べチョクのステージング環境では、本番環境のデータを日次で同期して利用しています。 今回はステージング環境の役割と、どのようにデータ同期をしているのかについてご紹介いたします。

ステージング環境

食べチョクでは、手元のマシンでプログラムを修正しコードレビューを実施後、改修内容をステージング環境にデプロイしています。 ステージングは、本番へのリリース前に修正箇所の動作確認・検証する環境です。この環境で動作や性能に問題がないかを確認後、本番環境へのデプロイを実施しています。

ステージング環境には、本番と同等のデータが入っています。 リリース当初は、ステージング環境と本番環境のデータは同期しておらず、テスト用のダミーデータで動作確認を行っていました。 しかしダミーデータでの確認だと、

  • ダミーばかりが並んだサイトと本番環境では見た目や印象が違っていて、UIが最適なのか、操作しやすいのか、性能は問題ないか等の検証がしにくい
  • 本番環境でしか再現しない、データに依存したバグに気がつかない恐れがある

という問題がありました。ステージングで動いたのに本番デプロイしたらエラーが発生した というリスクもできるかぎり下げたいものです。 そのため本番環境のデータをステージングに同期し、テストに利用することにしました。

データをマスクして同期する

食べチョクはECサイトであり、DBにはユーザーの個人情報(氏名、メールアドレス、住所等)が入っています。 本番環境のデータを利用するにあたり、センシティブなデータをマスクしないで同期してしまうと、思わぬ情報流出や事故につながる可能性があります。

特に怖いのがメールアドレスです。 ユーザーの操作やバッチ処理でメールを飛ばす処理はいたる所に存在しています。 テストのためにバッチを動かしたら、実際のユーザーさんにメールが飛んでしまった等といった事故を防ぐためにも、ステージング環境へはデータをマスクして同期する必要があります。

データ同期に必要なこと

本番データをステージングに同期するにあたり、以下を実現したいです。

  • 個人情報やセンシティブな情報はマスクして同期したい
    • ユーザー名、メールアドレス、住所 etc はマスクして同期
  • データ同期はリアルタイムではなくてよい (1日1回 とか数回で問題ない)

また、食べチョクではデータベースへのマイグレーションはそこそこの頻度(週1,2回)で発生しています。 マイグレーション発生のたびに同期ツールの設定修正はできるかぎり行いたくはありません。 そのため、マイグレーションが発生してもいい感じにデータ同期してくれるツールが必要でした。

DB同期ツール Gamma

データの差分同期ができて、マスク処理も(Rubyで)簡単にかけて、DBのテーブルやカラムが増えても手がかからない、そんなツールが欲しかったです。 なかなか良さそうなものが見つからなかったので、自前でツールを作って対応しました。

https://github.com/nishio-dens/gamma というツールです。githubでも公開しています。

gammaでは、次のようなyaml形式の設定ファイルを作り、データ同期をします。

# data.yml
#
# 対象DBの ar_internal_metadata というテーブル以外をすべて差分同期する
# updated_at カラムの値を見比べて、差分があるかを判断する

- data:
    table:
      - "*"
    table_without:
      - "ar_internal_metadata"
    mode: "replace"
    delta_column: "updated_at"

あとはdatabaseの設定ファイル(settings.yml) が必要です。これらを用意して以下コマンドを実行すると差分同期ができます。

# settings.yml は DB設定ファイル(割愛)
# data.yml は上記設定ファイル

$ gamma apply --settings settings.yml --data data.yml

データをマスクする処理はrubyで記述できます。 例えば、usersテーブルのaddressという項目をマスクしたければ、次のような設定ファイルを書きます。

- data:
    table:
      - "users"
    mode: "replace"
    delta_column: "updated_at"
    hooks:
      - column:
          name:
            - "address"
          scripts:
            - "hooks/mask_address.rb"

hooks/mask_email.rb はマスク用のrubyスクリプトです。

# hooks/mask_email.rb のサンプル
# 住所のうち、最初の3文字だけ残して残りはすべてマスク
class MaskAddress
  def execute(apply, column, value)
    address = "#{value[0...3]}●●●●●●"
    address
  end
end

詳しい使い方は割愛します。興味のある方は、以下repositoryのREADMEを見てみてください。

github.com github.com

同期の方法

食べチョクでは、本番環境からステージング環境へのデータの同期は以下のようにして実施しています。

  1. 本番環境DBのdumpを取る
  2. 同期用のDBにリストアする
  3. 同期用DBからステージング環境にgammaでデータマスクしつつ差分同期する

f:id:vividgarden-tech:20181126210805p:plain

本番環境からステージングに同期するにあたり、同期用DBを用意しています。 本番DBから直接ステージングに差分同期すると、本番環境に余計な負荷がかかってしまう恐れがあります。そのため、一度別DBにリストアしてから差分同期しています。

おわりに

今回は食べチョクでのステージング環境の役割の紹介と、本番からステージングへのデータ同期の方法について紹介しました。

本番環境からのデータ同期は、個人情報などセンシティブなデータにはマスクを施すなど、細心の注意を払う必要があります。サイトや企業によっては、本番のデータを利用するのはなかなかハードルが高い可能性もあります。

食べチョクでは、ステージング環境に本番同等のデータがあることで動作検証が格段にやりやすくなりました。なにより本番同等のデータが入った環境でのテストは安心感があります。

みなさまも、もし可能ならば本番環境のデータをマスクしてステージング環境に同期してみてはどうでしょうか。