「aCrew Vol.1 for FinTech ~メルペイ、Origami、d払い登壇！スマホ決済サービスのグロース特集~」に参加してきた
本編
講演 ① App Annie 向井氏 「スマホ決済アプリ市場の海外/日本のトレンドについて」(仮)
参加できなかったので割愛。
講演 ② Repro 平田「スマホ決済アプリのグロースのポイント」
参加できなかったので割愛。
トークセッション「キャッシュレスアプリとデータ活用（仮）」
登壇者
モデレーター
- Repro株式会社 CEO 平田 祐介
- App Annie Japan（株）日本代表ディレクター 向井 俊介 氏
パネリスト
- Fintech協会 代表理事 丸山 弘毅 氏
- （株）メルペイ 営業統括 兼 社長室長 金 高恩 氏
- （株）ＮＴＴドコモ プラットフォームビジネス推進部 ペイメントビジネス担当課長 高須 真 氏
- （株）Origami マーケティング責任者 古見幸生 氏
各サービス紹介
d払い
- docomoのpaypay w
- 500万DL
- 使える店舗も増えてる
- 1600億ポイント/年
- 2019FY〜
- ウォレットチャージ機能
- ミニアプリ
- 中小店向け 読み取る決済
Origami
- ミッション：お金、決済、商いの未来を創造する
- 2015年でOrigamiPayローンチ
- 2016年11月：Alipayと提携
- アプリの機能
- 支払い前: 使える店舗の情報、キャンペーンなど
- 支払い後: 支払履歴など
- 強み
- 即時割引
- チャージ不要
- キャンペーン
- 地域活性化型キャッシュレス
- インバウンド/アウトバウンド
- オープン化（金融プラットフォーム解放）
- データも他の銀行とかも使えるように
merpay
- 信用を創造して、なめらかな社会を創る
- 他のサービスとは、給料以外のお金の流入源を持ってるのが大きな違い
トークセッション
アプリを使ってもらうために、可処分時間やマインドシェアを取るために、意識してること
- Origami
- merpay
- 決済は目的ではなく、あくまでも手段
- 独立とかメディア化は考えてない
- メルカリ自体が滞在時間長いアプリで、アプリの種類としてはSNSでの行動に近い
- d払い
- 長期的にはメディア化を目指す
- 決済だけだとお得かどうかで選ばれてしまうので、便利な方向性を目指す
- ミニプログラムの提供等を通して、安心安全な決済基盤の上に他社が乗っかるプラットフォームを目指す
日本ではアプリ多すぎるが、どうなっていきそうか
- Fintech協会
- Origami
- ドンドン増えていくと予想
- クレジットカードを見てるとドンドン増えてる
- Origamiはクレジットカードでいうvisaとかになるイメージ
- merpay
- ユーザがどう使うかを重視していて、paymentは手段でしかない
- merpayを全員に使ってもらうというよりは、paymentがシームレスになることが重要
- 3,5年後アプリでない形になるのもありえるのでは
- d払い
- 6個ぐらいでは
- QRコードが統一されていないので、淘汰されていく
- 送金とかの決済以外のシーンとかを考えると特にいくつかに絞られていくのでは
お金ばらまいてるがビジネスモデルは？
- merpay
- 信用を創造して
- 後払いは既にローンチして使われている
- paymentという文脈でECとか見てると決済は儲からない
- 価値交換や物々交換とかを考えると、信用に行き着く
- 信用でマネタイズしていくのが一つ
- 銀行
- 現金なくなった方が管理コスト減るので、ATMの設置費用とか減る
- B2Bとか含めて送金できてるのが差別化になりそう
- Origami
- できることとやっていいことは別
- 個人情報で信用ビジネスになるのは少しアレルギー感
- 1企業がデータを持つのはGAFA問題みたいになるので、オープンにしていくべきでは
- LINE@的なポジションを狙いたい
- d払い
- 携帯回線7000万人のデータはある
- オフラインだけの額はそんなに大きくないが、リアルの決済額は大きいので決済手数料0.5%でも事業は成り立つのでは
- Fintech協会
- 信用が変わるのは革新的
- 現在は、勤め先や収入と給与で信用が今決まってる
- それ以外で決まるのは、大きな革新
- マネタイズ
- キャッシュレスが進むとレンディングは伸びる
- 今はキャッシュレスの割合が2割とかなので、レンディングの額が小さく使われていない
- キャッシュレス化が進めば、レンディングの額が大きくなっていく
- 銀行がAPI使って勝つ可能性も
- 信用が変わるのは革新的
外国人に向けた何かは考えているか
外資のサービスが日本に入ってきていて、データが海外に行ってる。
日本の労働人口もどんどん減っている一方で、海外からくるヒト（観光客、労働者）も増えてる。
人口と流通額に依存したビジネルモデルだとシュリンクしていくので、インバウンド狙った方が良いのでは
- d払い
- 現状は、国内で手一杯
- Origami
- 各社が各店舗に営業していくのは厳しいので、連携していく流れになるのでは
- merpay
- 法律で守られてるとこもあるが、データの取扱に関しては別
- 詳しくはここでは話せない
- Fintech協会
- エコシステムでデータ保護主義
- data flow with trust
- エコシステムでデータ保護主義
- Origami
- やりきるつもりではいる
- merpay
- やるつもりだが、仕様を早く決めてほしいw
- Fintech協会
- 協議会が決めていて、今進めているので仕様はもう少し待ってくれ
- d払い
- 努力はしてる
日本は災害大国だが、災害時の対応は想定しているか
Maas
ETCの普及はしたが、ドライブスルーの支払いはまだ物理だが、車載のアプリ等で解決しないのか
- Origami
- TOYOTAとのLEXUS Origami Payで進めてる
- スマートシティとか街全体の環境が必要
- QRコードが普及してるのもコストが低いから
- merpay
- インフラ重要
- 他の国で進んだのは国策なのが大きい
- d払い
- ミニプログラムの根本は、利便性を向上したいというところからなので、そこにつながる
- 今年は提携業者と組んでリリース。来年は順次解放予定
「顧客体験をデザインする。#03」に参加してきた
参加メモ
大規模B2B Eコマース "モノタロウ" におけるテクノロジー - ECサイトから物流まで -
登壇者: 株式会社MonotaRO 執行役 データマーケティング部門長 久保 征人 @masatokubomro
フルスタックEコマース
モノタロウの紹介
- 特徴
- 在庫を持ってる
- 全て自社開発、運用
- 商品1800万点 353万事業者
- グローバル企業
フルスタックECにおける顧客体験の向上
会社として、顧客の接点の種類が多い
当社のケースでは、全ての業務担当者が、顧客体験を向上させることが可能な当事者である
- 管理
- CS
- IT
- 物流
=> その全ての業務担当者をエンジニアがサポートできれば、それが最も顧客体験の向上に繋がる
仕事が捗る基盤を作るとは
- 業務を自動化して生産をあげる => IT基盤を整える
- 業務分析と改善を加速させる => データ基盤を整える
データドリブンカンパニーとは
- 意思決定を支える経営と文化
- 意思決定を支える基盤
- 意思決定を支えるデータリテラシー
モノタロウのデータ基盤
- オンプレ時代
- 日時バッチでdata warehouseに突っ込んでた
- 新しいデータ基盤の必要性
- データが分散してる
- テーブル増える度に運用が限界
- スペックが足りない
- まだまだデータ増やしたい
- BigQuery
- GoogleAnalytics
- ApplicationLog
- MySQLのデータをリアルタイムで
- Binlog Connector
- 擬似的にMySQLのスレーブとして接続
- GitHub - shyiko/mysql-binlog-connector-java: MySQL Binary Log connector
- 3〜5分ぐらいの遅延レベルでリアルタイムに同期
成果
- データ量の限界はなくなった
- 100テーブル => 1000テーブル〜
- ダッシュボードの数も増えた
- 〜30 => 300
まとめ
- ECにおける顧客体験には業務担当者の業務が関わる
- それを達成する一つの方法が、業務分析 => 改善をサポート
ショップと顧客の絆を深める、デジタル＆リアルでデザインするEコマース顧客体験
登壇者: 株式会社ecbeing 製品開発統括部 統括部長/執行役員 渡邊 健太
会社紹介
本編
ECの中では、アプリの割合が大きいので、アプリも重要。
しかし買い物全体のうちECの占める割合がだんだん増えている一方で、オフラインでの行動が購入には重要であり続けている。
そのため、ECとオフラインの連携が重要である。
デジタルとリアルの顧客体験が重要
カスタマージャーニーマップ
デジタル&リアルで
nano universeの事例
ちゃんと、リアル店舗の在庫を連携できてるところは少ない
絆を深める、専門性の高いコンテンツ
ユーザが納得して購入できるように、ストーリー性を持って理解できるコンテンツを提供。
ライフスタイル提案・体験機会の提供
インテリア領域では特に、実際に家具を置いたらどうなるのかイメージを持ってもらうことが重要である。
unicoでは、3Dコーディネートの機能でカバーしている。
ユーザとブランドの絆の創出
設計・開発のポイント
- 「体験」を先に設計する
- デジタルとリアルの補完関係
- プロトタイピング
- 開発チーム / UXデザインチームの密度
- 「万人受け」よりも「こだわり派の納得性」を重視
- ペルソナ設定
- ユースケース記述
- リサーチと使い込み
- 体験の中心にスマホを考える
- スマホのGPS連動で、店舗の近くにユーザが来たらプッシュ通知
- 店舗に入ったユーザに対して、チェックインスタンプ、来店クーポンの配布
- スタッフ用のアプリで、連携してユーザを特定して、購入履歴、接客履歴、レコメンド商品
ABCマート スタッフ用のアプリで在庫状況をデータで把握
このあたりから、インスタとの連携などのチャネルや少しボイスコマースなどの話がありましたが、個人的にはあまり興味の範囲でなかったので割愛します。
まとめ
- あらゆる行動の中心にスマホがある
- モノ・情報・ヒトをデジタル＆リアルの体験に活用する
- 体験から先に、ペルソナを明確に設計する
- ファンと共に創り上げる顧客体験がSNSによって拡散する
- 5G時代には、顧客体験は動画が中心になる
- これから来るかも「ボイスコマース」
楽天スーパーSaleの舞台裏 - お買い物カゴシステムの負荷対策
登壇者: 楽天株式会社 ECマーケットプレイス開発部 Marketplace Core Architect Section シニアマネージャー 橋山 牧人 @capyogu
自己紹介
- 経歴
- 現在の仕事
- プライベート
- ゲーム
- プログラミングスクール講師、執筆活動
前提の説明
楽天スーパーセール => 2012年3月より開始した大型セールイベント
楽天スーパーセールの当日の様子
100名以上のエンジニアが同じフロアで監視
監視内容
- The Four Golden Signals
- Latency
- Traffic
- Errors
- Saturation
独自の監視項目
ビジネス的に重要なポイントを重点的に
- エントリー数
- 売上高
- 受注件数
- メール配信
トリアージの具体例
あくまでも、お買い物の継続が最優先で、外部要因であれば機能を切り捨てる。
例えば、外部APIを利用して表示してる機能や、お買い物のフローに関係のないサブ的な機能は切り捨てる。
トリアージの失敗例
会員ランクに応じて付与するポイントが変わるため、半年ぐらいかかる地獄に陥った。。
事後影響を考えると、会員サービスダウン時はお買い物かごを停止させるべきであった。
緊急時に何を優先するか、ビジネスや補償の観点を含めて事前に決めておくことが重要。
負荷試験
負荷状況の再現方法
※ 結構過去の話だそうです。
開始直後のピーク時には、通常ピーク時の約20倍のアクセス
深夜に本番環境で負荷試験
当時のエンジニアがノウハウを持っていたJMeterを採用。
イメージとしては、負荷生成サーバを構築して本番のユーザと同様に振る舞ってリクエストするみたいです。
試行錯誤その1 負荷テストの設計
- 全ユーザシナリオを再現するのは非現実的
- 90%のユーザアクセスがカバーできるシナリオを設計し、呼び出すAPI・システムを選別
- 何を目標とするか:
- 共通の目標数値: 分間受注件数
- 覚えやすい、理解しやすい共通目標を設定することで、課題や達成度を明確にできる。
試行錯誤その2 データの追加、フィルタリング、破棄
- トラフィック量・レイテンシが想定よりも少ない
- 原因1: 各ダミーデータのデータサイズが本番よりも小さかった
- 原因2: 特定のページや商品に集中したためキャッシュが効いた
- 大量のダミーデータを用意(20万の会員、6500の店舗、100万の商品)
- テストデータのフィルタリング、掃除
- 負荷試験のために、ダミーのデータの処理はさせたい
- その一方で、サービス影響出ないようにダミーのデータは早く破棄したい
対策
人気商品への対応
セール商品の分類
特性が異なるので、対応策も別々になる。
| 商品タイプ | 概要 | アクセス | 在庫数 | 商品例 |
|---|---|---|---|---|
| タイムセール商品 | 通常のセール商品。普段から売られてることが多い。 | 中 | 多い | カニ、肉、水 |
| 目玉商品 | スーパーSaleのみで販売。希少性や割引額が特に高い商品。 | 大 | 少ない | 車、宝石、時計 |
| 人気商品 | 特定の層に人気。値段はそれほど高くない。テレビで紹介された、など。 | 大 | 多い | 特定のファッションアイテム、おもちゃ、消耗品 |
今回の事例では、 人気商品に該当する、当時人気だった妖怪ウォッチのおもちゃ等の事例。
なぜシステム上の問題が出たのか
対策1: 専用システムを構築し、検知の仕組みを導入
人気商品を別のシステムに隔離することで、負荷でシステムがスローダウンしても通常のお買い物は継続させる。
対策2: 在庫キャッシュの更新を非同期にする
そもそも同期処理したところで、ユーザがアクションするタイミングで在庫状況がずれるので意味がない
今後の取り組み
| 課題 | アクション |
|---|---|
| スーパーSALE同様の負荷を受けきれる試験用の環境が用意できていない | クラウドプラットフォームに簡単にデプロイできるためのコンテナ化、マイクロサービス化 |
| スーパーSALE同様の負荷を柔軟かつ安全にかける手段が十分に用意できていない | システムメトリクスと紐付いた、クラウドベースの自動テスト実行プラットフォームの開発 |
| 複数のサービスを跨ったトラブルシューティングが十分なスピード・精度・統一された手段でできていない | 統一プラットフォーム上のサービスメッシュの導入 (1)分散トレーシングによるトラフィックの追跡 (2)Circuit BreakerによるSystem Reliability |
今後のシステムアーキテクチャ
素数の一覧を求めるアルゴリズムのメモ
素数の一覧を求めるアルゴリズムの問題を出されて、良い計算量のアルゴリズムがわからなかったときに調べたメモです。
素数の一覧を求めるアルゴリズム
素数の定義
学術的には不正確かもしれないですが、今回はwikipediaで十分なので、こちらで進めます。
1 より大きい自然数で、正の約数が 1 と自分自身のみであるもの
普通の方法
約数が1以外は自身のみなので、自身より小さい素数で割り切れるものが一つも無ければ、自身は素数となります。
def normal(max_number) (2..max_number).each_with_object([]) do |i, primes| primes << i if primes.detect {|p| i % p == 0 }.blank? end end
この方法では、計算量がO(N2)になるので効率が悪いです。
エラトステネスの篩(ふるい)
というアルゴリズムがあるそうです。
ステップ 1 探索リストに2からxまでの整数を昇順で入れる。
ステップ 2 探索リストの先頭の数を素数リストに移動し、その倍数を探索リストから篩い落とす。
ステップ 3 上記の篩い落とし操作を探索リストの先頭値がxの平方根に達するまで行う。
ステップ 4 探索リストに残った数を素数リストに移動して処理終了。
例はwikipediaにも詳しく載ってるので割愛します。
アルゴリズムのイメージ
上に示したステップだけだとよくわからなかったので、腹落ちするように流れを分解して解釈しました。
- 数字のリストから、素数の小さいものから順にその素数の倍数(ex. 3の場合は 9, 12, 15...)を取り除いていけば、リストに残るのは素数のみになる。
- また除外する際には、自身の2乗以上の倍数のみでよい。
- 自身より小さい値との組み合わせは既に取り除かれているため(ex. 3の場合は 6は2の倍数なので、取り除かれている)
- その倍数として取り除いていく素数の必要最小限の値は、リストの最大値の平方根になる。
- 平方根の値より大きい値との倍数は、リストの最大値を超えるため
実装
def eratosthenes(max_number)
primes = []
max_sqrt = Math.sqrt(max_number).to_i
options = (2..max_number).to_a
prime = 1
while prime <= max_sqrt
prime = options.shift
primes << prime
multiples = (max_number / prime - (prime - 1) ).times.map {|m| prime * (m + prime) }
options = options - multiples
end
primes + options
end
結果の比較
MAX_NUMBER = 10000 Benchmark.bm 10 do |r| r.report 'normal' do normal(MAX_NUMBER) end r.report 'Eratosthenes' do eratosthenes(MAX_NUMBER) end end
| MAX_NUMBER | normal | Eratosthenes |
|---|---|---|
| 1000 | 0.001585 | 0.000413 |
| 10000 | 0.070549 | 0.004512 |
| 100000 | 3.807569 | 0.059691 |
| 1000000 | 248.255773 | 1.362347 |
「Discover hey(入社体験制度)」でSTORES.jpに1日入社体験してきた
Discovery heyに参加してきたので、感想等をまとめました。
Discovery heyとは
Discovery heyとは、heyが行っている、1日体験入社制度です。
詳しくはこちらに記載されている通りです。
note.mu
参加のモチベーション
- 転職活動の一環で、heyに興味があり、どんな会社なのか知りたかった
- 自分の働く上での価値観を改めて洗い出したかった
- Ruby・モール型ECで本業と環境が似ていて、開発環境とかどういう風になっているのか気になった
- エンジニアチームのリーダーを務めており、他のチームがどういう風に働いてるか知りたかった
- slack等のコミュニケーションの方法
- チーム構成、PMやデザイナーとの距離感、コミュニケーション方法
体験の流れ
申し込み
私のときは、職務履歴書を送っただけで、当日まではオフィスに1度も伺いませんでした。
書類審査が通った旨をメールで連絡をいただきました。その後は以下のようなやり取りをして当日を迎えました。
当日
事前のヒアリングで興味のあることを以下のように回答したところ、
私の要望を満たせそうなSTORES.jpの顧客管理機能を中心に担当しているチームの1メンバーとして仕事をさせていただきました。
- サービス的な面
- 施策の優先順位をつける上での価値観
- PMやデザイナーとどのようなコミュニケーションで仕事を進めているか
- 施策を行う一連のフロー
- どのように仮説検証を行っているか
- 技術的な面
全体のスケジュールは以下のような流れでした。
| 時刻 | やったこと |
|---|---|
| 10:00 | 顔認証登録、オフィス案内 |
| 10:15 | PCセットアップ |
| 10:30 | 作業の説明 |
| 11:00 | コードやドキュメント読んだり、開発環境で遊ぶ |
| 12:00 | 定例MTG |
| 13:00 | ランチ |
| 14:00 | 開発 |
| 18:30 | 作業終了、アンケート回答 |
| 19:00 | 業務終了 |
10:00 顔認証登録、オフィス案内
12〜16時のコアフレックス制らしく、10時にオフィスにはそんなに人がいませんでした。
週1回はリモートOKらしい。
10:15 PCセットアップ
slack, Qiita::Team, emailのセットアップや、開発環境構築を行いました。
体験入社の方のための手順書もご丁寧に用意いただいてました。
開発環境構築はドキュメントにまとまってあり、事前に先方がある程度進めていただいてたので、スムーズに行うことができました。
10:30 作業の説明
ざっくり会社や開発周りの理解を深める時間。
コードやドキュメントを読んだりしました。
Qiita::Teamもフルオープンで、永遠に読んでいられるぐらい興味深かった。Qiita::Teamで残してる情報を見てると、会社として大事にしてることも見えてきて面白かった。
12:00 定例MTGに参加
STORES.jpでは、エンジニア、デザイナー、PMで構成された3つのチームがあるそう。
参加したチームでは、毎週スプリントのプランニングを行ってるそうで、そのMTGに参加させていただいた。
個人的に印象に残ったメモ
- Github projectsで管理
- コードレビューもしっかり作業としてみなしていて、その場でリソースに応じてざっくりレビュワーの割り振りも行われていた
- 「ユーザ的には〜」みたいな会話がちゃんとエンジニアやPM関係なく話されていた
- リモートの業務委託の方も画面越しに参加
13:00 ランチ
6名ぐらいのエンジニアの方々と行きました。
ランチ代も先方に負担していただき、本当に手厚かったです。
話していても、普段から仲が良さそうだなという印象を受けました。
14:00 作業
バグ修正とslack通知のバッチを作成するという内容でした。
なんと一部はリリースまでできました！(が、軽いバグ出してしまった :bow:)
私も普段ECを担当していますが、最近の大きい改修の話も伺うことができて、辛いとか悩ましいところが共感できたのがとても楽しかったです。
技術スタックはマッチしてないと何もできずに終わりそうだなとも思いましたが、使ったことのない技術も触れて楽しかったです。
- MongoDB
- MySQLの
show tables等のコマンドが異なって慣れが必要 - ActiveRecordではなく、Mogoidを使う
- パッと使った感じでは共通のインターフェースの部分もまぁまぁありそう
- migrationという概念がないそう
- 大きいテーブルとかの操作は楽そう
- MySQLの
- AngularJS
- 詳しくは理解してない（本当は良くない）が、そこまで癖はなさそうで、コードを読んでたらなんとなく動作するものができたり、改修すべき箇所の特定はしやすかった
- すぐゴチャゴチャしやすそうなので、設計は考えないといけなさそうだと思った
18:30 作業終了、アンケート回答
アンケートを記載したり、今日の感想を話したりしました。
他のチームのエンジニアの方も向こうからお声がけいただいて、お話させていただいたりもしました。
19:00 業務終了
楽しかったので、あっという間に終わった！が、なんだかんだ気を遣ったりしてたのか、疲れたｗ
感想
会社の印象
わたしたちの素の空気に魅力を感じて入社を決めてくれた
Discover hey(入社体験制度)はじめます｜naoko｜note
全体的には、非常に心地のよい会社で、上のように記載されていた理由が理解できた。
イケイケのようなイメージが強かったが、結構落ち着いてる
- オフィス内もガヤガヤしておらず、静かだった
- 音楽とか写真が好きなサブカル的な人は比較的多い気がすると伺った
- アイドル風の女性の写真が何枚も貼られたホワイトボードがあり、何の事業に関係あるのかと思ってたら、好きで社内で布教したいだけだそうで、自由で良い会社だなと思ったｗ
- ※ 変な印象受けるかもしれないですが、皆さんちゃんとしてました
性善説に基づいて組織されていて、プロ意識が高そう
- プロとして、パフォーマンスを出すためにお互い管理しあうのは良くないので、性善説に基づいてるそう
- そのためか、人柄が良い人が多くみんな穏やかで変な意味ではなくアットホームで居心地がよかった
- あまり関係ないですが、みんなちゃんと挨拶してました
- このブログを書くのも「事前確認が必要か？」と伺ったら、「私たちは恥ずべきことはしてないので、大丈夫。文句が書いてあっても事実なら大丈夫」と言われて、とても好感を持った
情報がオープン
- Qiita::Teamを使用していて、経営会議から採用の状況、各議事録まですべて共有
- 会社として、成功の再現性を求めてるという背景が大きいらしい
サービス愛
- エンジニアがみんなサービスやユーザのことを考えて開発していそう
- 開発していて楽しそう
- 福利厚生でSTORES.jpで5000円/月買える制度もあり、みんな自分のサービスを使ってる
- ECは特に自分で買わないとドメイン知識とか、ユーザの課題感も掴めないので、良い制度だと思った
- メンターのエンジニアの方は自分のストアまで持っていた
Discover hey
- 会社の雰囲気は掴めて良い意味で印象も変わり、良かった
- あくまでも1社員として扱っていただいた
- MTGでも（恐らく）いつも通り何でも話していただけた
- 情報のアクセス権限等も基本的には全部使えた
- 受け入れは私で2人目だったそうだが、用意周到で開発までスムーズに進めた
- 受け入れ側は時間割く必要あり
- 当日だけでなく、準備のコストもかかりそう
- いい感じのissueの用意
- 時間がなく、ドメイン知識もない、技術スタックの経験が一致するとは限らない
開発周り
先方に事前にやっていただいて、助かったこと
開発環境
- 構築は20分前後で開発できるように
- シードデータがあると、更に開発しやすかった
- キーボード配列
- 希望通りUS配列のPCを使わせていただけた
- 各種アカウント(mail, slack, Qiita::Team)等の発行
その他
- どのチームに配属されるかの事前告知
- 当日に短時間でドメイン知識を補うのは難しいので、事前に少しでも情報をキャッチアップできて良かった
- 私受け入れ専用のslackチャンネル
- みんなが普段使ってるdev用のチャンネルだけだと発言し辛いので、地味に非常に助かりました（かと言って大した発言はしてないｗ）
こちらで準備しておけばよかったこと
即席の開発環境をすぐに整えられるようにしておけば良かった。 少ししか開発時間がないため、ガッツリ開発環境を整える訳にはいかないが、短時間にそれなりに開発しやすいようにする工夫が必要。
エディターやitermの設定等をgithubから簡単に
普段はNeovimを使っているがインストールするほどの時間もないので、vim.rcも用意すべきだった。
Macのキーボード等の設定
設定エクスポートできるのかはよく知らないので後で調べる。
キーボード持参
US配列のMacを使わせていただくので問題ないだろうと思いきや、少し盲点があった（午前中には慣れた）。
※ 文句ではなく、感想です
- 初めて物理ESCキーのないMacを使ったので、少し違和感
- 15インチを使わせていただいたが、普段13インチ使っていて微妙に感覚が違った
まとめ
非常に魅力的な会社で大変楽しかったです。
heyが少しでも気になっている方は、素の空気を味わうことができ大変オススメです。
受け入れていただき、本当にありがとうございました。
「merpay Backend Engineer Meetup #3」に参加してきた
参加のモチベーション
- Golangを副業等で使っていて、初心者を抜け出したい。
- Golangが使い慣れたら、どのような印象に変わったかを知りたい。
- 今のところ、パワフルかつ緩やかに型が強制されるメリットを感じつつも、書いててあまり楽しくはないw。
参加メモ
※ 客観的に書いてるつもりですが、私にとって自明なところは省略したり、勘違いしてる可能性もあるので予めご了承ください。
パネルディスカッション
登壇者
なぜGoを選択したのか？
- メルカリの歴史的経緯
- 機能面
- Dockerと相性がよい
- みんな同じ書き方になるので、不毛な戦争が起きない
- 型がある
勉強方法は？
syumai
- 出会い
- 勉強法
- A Tour Of Goから始めた
- 本
- スターティングGo言語 (CodeZine BOOKS)：易しめで個人的には良かった
- プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)：CSの知識がある前提で進められる部分もあり、最初は難しく感じた。訳者の柴田さんと毎週1時間半読み続けてる。
toshi0607
- 出会い、どうやって勉強したか
- 前職の別のチームで採用して楽しそうだと思ってた
- Udemyで独学
- プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)を読んだ
- しっくりきた
- 何回読んでも、学ぶや発見がある
- A Tour Of Goはやったが、あまり合わなかった
- サーバレスアーキテクチャでは大体Golangが採用されてる
- Gopher道場に参加
- オススメ勉強法
- Gopher道場
- CLIを作るのは勉強になった
- 簡単にマルチプラットフォーム対応できて、いろんな人に見てもらえる
- 他の言語で書かれたものをGoで書き換える
- 技術書典で Goで学ぶAWSラムダ を出版
execjosh
- MySpaceでRubyでザッピングのツール使ったら遅い
- 当時α版のGolangを使ってみたら、めちゃくちゃ速かった
- 社内のツール（？）でGolangが使われてた
- バグを修正しようと思いコードを読んだら、スラスラ読めた
- PR投げて経験つけた
- Gopher道場に参加
メリットやデメリット
- Goを採用して良かったこと
- 別の言語からGoに変えた経験談
toshi0607
- Rubyと違って型があるので安心
- パッケージとか構成とかの設計とかの方が悩んだ
- 他のプロジェクトや本でキャッチアップ
- Golangそのもののキャッチアップにはあまり苦労しなかった
- マイクロサービスやgRPC, GCPとかのキャッチアップに比べると楽
- k8sが一番きつかった(人類にはまだ早いｗ)
execjosh
- そこまで苦労しなかった
- オブジェクト指向から抜けるのが時間かかった
- エラーハンドリングは特徴的
syumai
- 型で安心
- protobuf採用してるので、ビルド時に気づけるので
- リファクタリングが速い（Golandのメソッドの置換）
- インターフェースは苦労した
- 差し替えるモックとかDIのありがたみがわかるまでは特に
- エラーハンドリング
- errorのstructにどういう情報もたせるべきかが最初は悩ましい
気をつけてることなど
toshi0607
- 標準パッケージが読みやすいのでそこから学ぶ
syumai
- レイヤー間は厚めに
- チームによってアーキテクチャが異なる
execjosh
Q&A
- goroutineはメルカリでも使っているか
- 負荷がなくても、SQLを複数投げるときとかに有効で使ってる
- なんだかんだ避けては通れない
感想、個人的な学び
- Gopher道場良さそうなので、参加してみたい
- プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)読む
- 簡単なCLIを作る
