はじめまして。EC事業部特攻隊チームのばんちゃん(@unionsep)とEC事業部ハッカーチームのぬまっち(@yinm)です。
先日(2017/03/09)、EC事業部が主導して社内勉強会を開催しましたので、その様子をお届けします。
ペパボはminneやホスティング事業部が注目を浴びがちですが、我らがEC事業部のエンジニアも、 大切にしてほしい3つのこと
「みんなと仲良くすること」「ファンを増やすこと」「アウトプットすること」を意識して日々働いています。
そんなある日、EC事業部の女神様（@nyanyami）より技術知見を共有してチーム感を出していきたい、と神託を賜りました。
大切にしてほしい3つのことを大切に過ごしていますが、今回は「アウトプットすること」を全面に出した、EC事業部として初めての試みになるので、はじめはみんな緊張した面持ちでした。でも、後半は緊張がほぐれたのか、わいわい意見が出てきて「他のアイデアと合わさることで新しいものになる」きっかけになったと思います。
EC事業部 TechMTG の狙い
Speaker : @kenchan Writer : ばんちゃん(@unionsep)
Keynoteは我らEC事業部のリーダー、@kenchan です。
日頃から意識高いなって思ってましたけど、「40年働いたとして480人月しかないんだよ」という言葉がとても印象深かったです。
客先常駐していた時の人月計算していた過去が思い出されて、たった480人月かと感心してしまいました。
独りよがりな行動をしても大規模なものは作れないし、480人月を何人集めても効率的に知識をプールしないと個人の成長スピードはそれ以上を望めません。 各480人月が密接に結び合って影響を及ぼすような関係を構成しないと、横に並んだ480人月でしかなく、最高到達地点は480人月でしかなくなり、組織立って活動するメリットを享受できなくなります。
最高到達地点を∞にして最高なサービスを提供するために、文字通り「有機的」成長を各個人が意識し合うことが大切なんだなと改めて感じました。
Zendesk アプリについて
Speaker : @kumak1 Writer : ぬまっち(@yinm)
次のスピーカーは、ぬまっちと同じハッカーチームに所属している@kumak1による、Zendeskアプリを使った社内の問い合わせシステムを作成した際の所感についてのお話でした。
カラーミーショップでは、お客様の対応を専門に行う、カスタマーサポートのメンバーがいます(社内ではサポチと呼ばれています)。
サポチはユーザーへの回答だけでなく、お問い合わせの内容に応じて、エンジニアなどの他業種との連携を取る必要があるため、従来のシステムでは業務が煩雑になりがちでした。
しかし、Zendeskの導入によって煩雑な作業を省くことができ、サポチと他業種との連携が取りやすくなりました。
また、開発の設計時に行われたこととして、サポチが日常的に使っている用語で話すようにしたり、実作業を録画するなど様々な取り組みを行っているのが印象的でした。 他業種とのコミュニケーションの取り方・要望の抽出方法など、エンジニアとして改めて意識して開発しなければならないと思いました。
カラーミーAPIドキュメントの今後
Speaker : @Joe_noh Writer : ばんちゃん(@unionsep)
続いて、カラーミーショップAPIの開発を主導している新かごチームの@Joe_nohによる、ドキュメント作成も含めたAPI開発フローです。
私も以前、Googleさんが主導していた頃のApache ShindigでAPIを作っていました。
そんな昔話と比べるにはおこがましいですが、私はExcelでドキュメントを書いていました。
API設計において、柔軟なエントリポイントを表現することは、そのAPIがなにをするのかを利用者に伝える手段として有効です。 しかし、パラメタなどの仕様は、エントリポイントだけでは伝えられないので、精度の高いドキュメントは必須といえます。 外部公開するに足る仕様書の作成は、正確さをシビアに求められ、ドキュメント能力が高くある必要があるのですが、その大部分をYAMLで書けるのはかなりの労力節約につながるはずです。
素晴らしいなと思いつつ、ものぐさな私はYAML書き忘れたらどうしようって心配になったので質問してみたら、さすがにそれは・・・な感じになって少々恥ずかしかったです☆
カラーミーショップ 常時 SSL の非同期処理
Speaker : @inouetakuya Writer : ぬまっち(@yinm)
次は、カラーミーショップの常時SSL対応をメインで開発していた@inouetakuyaによる、非同期処理にする技術選択をしたの背景と現状についてのお話です。
導入にあたっての問題と、その解決策という形式で発表されており、常時SSL対応に関わっていないエンジニアでも、なぜ非同期処理を選択したのかわかりやすかったです。 発表後の質疑応答でも、「証明書発行時のUIにインジケータを使っていたが、メールでもよかったのではないか？」など、設計に関する質問がありました。 その際も、「ユーザーを待たせる時間などを考慮した上で、今回のインジケータを採用した」など、明確に回答していたことが印象的でした。 様々なパターンを考慮した上で、今回の設計になっていることがよくわかる発表でした。
非同期処理を導入する機会は、今後もあり得ることなので、参考になる知見だなと感じました。
サーキットブレーカー 〜 有料契約店舗数 国内 No.1 ECサービスに神を宿す 〜
Speaker : @NAKANO_Akihito Writer : ばんちゃん(@unionsep)
トリを務めるのは、ばんちゃんと同じ特攻隊チームの@NAKANO_Akihitoによるサーキットブレーカーについてです。
NetflixのHystrixをどこかで聞いたなぁぐらいの知識でしたので、ついていけるか心配でしたが、わかりやすいイラストが満載で安心しました。
サーキットブレーカーとは、マイクロサービスにおいて、あるサービスに障害が発生した時にシステム全体から切り離すことで、システム全体に障害が飛び火しないようにするための仕組みです。
@NAKANO_Akihitoの発表を聞いて私が感じたのは、どのようなサービスのどんな事象を障害とするのか？でした。
サーキットブレーカーが発動した時、いかに速く、どのように回復させるかをセットにして考えることが重要だと思います。
例えば、スタンバイ系とアクティブ系を常に用意しておき、サーキットブレーカーが Open になったときにスタンバイ系に切り替えを試みるなどです。
また、単一障害点が少ないマイクロサービス設計も重要で、その上で、サーキットブレーカーが光り輝くのだと思います。 聞いていて結構壮大なことを夢想してしまって、@NAKANO_Akihitoに取り留めのない質問をしてしまって申し訳なかったです。。
まとめ
以上、5名の発表で、EC事業部TechMTGの第1回は終了しました。
EC事業部TechMTGの終了後、参加者による振り返りも行いました。 その中でも多かった声が、「他チームのメンバーの取り組みがわかった」というものでした。 EC事業部では、意思決定のスピードを上げるため、少人数のチーム制で仕事をしています。 一方で、少人数制だと他のチームの仕事内容が分かりにくいという側面もどうしても出てきます。 しかし、今回のEC事業部TechMTGを通して、他のチームのメンバーの取り組みを知ることができ、EC事業部の結束が強まったのではないかなと思います。
さて、第1回が終わったところなのですが、早速次回の開催も予定されています。 今回の発表もバラエティに富んだものでしたが、EC事業部には他にも様々な取り組みをしているエンジニアがいるので、次回はどんな発表があるのか楽しみですね。
以上、EC事業部で開催した、EC事業部TechMTGのご紹介でした！