ZEALS TECH BLOG

チャットボットによる会話広告『fanp』を開発する株式会社ZEALSのテックブログです。技術やエンジニア文化について情報を発信します。

ZEALSエンジニアに開発者アンケートを実施してみた

ãenqueteãã®ç»åæ¤ç´¢çµæ

皆さんこんにちは!
ZEALSでVPoE兼サーバサイドエンジニアをやっている福本です!

さて、本日はZEALS社内のエンジニアに使っている「エディタ」や「shell」などに関するアンケートを取ってみました!

普段ZEALSのエンジニアメンバーには、テックブログで記事を書いていただくことに協力してもらっています(ありがとう!)。

ただ、どんなエンジニアがZEALSで働いているのかを皆さんにお伝えする機会があまりなかったため、皆さんにチーム全体の雰囲気を知ってもらおうと、アンケートを取って公開しようと考えました。

宗教戦争的なものからそうでないものまで、いろんな意見を集めておりますので、よろしければ最後までご覧ください!

  • いつも使っているエディタは?
  • 使っているshellは?
  • 好きなプロダクトやサービスは何ですか?
  • 好きなor尊敬しているエンジニアは誰ですか?
  • 技術の情報収集の手段を教えてください!
  • ZEALS開発チームの好きなところは?
  • さいごに

いつも使っているエディタは?

The 宗教戦争なエディタ選定ですが、ZEALS内では圧倒的にVS Codeが多いですね!

それ以外にも、熱狂的なVimmerが所属したりしています。 

 

f:id:zeals-engineer:20190614104625p:plain

code.visualstudio.com

使っているshellは?

こちらは予想通りの三頭状態。
以前fishの記事をZEALSテックブログで書きましたが、以外とfishユーザー多いんですね...

 

f:id:zeals-engineer:20190614104644p:plain

好きなプロダクトやサービスは何ですか?

こちらは自由記述形式で、エンジニアメンバーが思い入れのあるプロダクトやサービスについて回答してもらいました!

結果は見事にバラバラで、普段使っているスマホアプリを挙げるメンバーもいれば、開発で使用しているツールを挙げるメンバーも居ましたね!

Medium
esa
Tabby CatというChromeの拡張機能…癒し(=^..^=)
Dreamscope。まだβ版ですがコンセプトが好きです
Airbnb
snapchat
学習サービスのExercismとRustコンパイラ最近めっちゃ好きです
spotify
RubyonRails, GitLab
キャンプファイヤー
pintrest
Codepen
Google map

好きなor尊敬しているエンジニアは誰ですか?

ロールモデルとなるエンジニアが居るかどうか?という質問です!
CTOの島田(hosmada)を挙げているメンバーが多く、CTOの愛され具合が現れてますね(気を遣っているわけではないと信じたい...笑)。

松本勇気さん(元グノシー/現DMM CTO)
hosmada
特にいない
Paul Graham、上杉 周作
Hosmada
hosmada
Typescript/Rust Language ServerのJonathan Turner, ClojureのRich Hickey
Salvatore Sanfilippo
kamipoさん, 松田明さん
伊藤淳一さん
mattn
Dan abramov
Dusty(ZEALS)

技術の情報収集の手段を教えてください!

エンジニアメンバーが、普段最もよく使う情報収集手段です!

結果は大半がTwitterでした。
やはり日本のエンジニア文化とTwitterは馴染みが良いんですね..

ちなみに、筆者はFeedlyでRSSをよく使っております!

f:id:zeals-engineer:20190614104656p:plain


 

feedly.com

ZEALS開発チームの好きなところは?

最後に、ZEALS開発チームの好きなところを挙げてもらいました。

色んなバックボーンを持っているメンバーが、同じ方向を向いて開発しているところ
仲が良く、向上心があって、一緒に働いて刺激になるし楽しいところ!
プロダクトにまっすぐで、良いものはどんどん吸収していこうというマインド!
チームが若く、裁量権があること
謙虚でひたむきな人が多いところ
互いにサポートしてくれるチームです
真面目でクレイジーでストイックなところ
みんなのびのび開発してるとこ
明るく前向きなところ
みんな技術が大好きなところ!!!
I love our team, and takakuda
Cool guys. Very open to everything and everyone. No negative energy. Love them all

 「楽しさ」「チームのまとまり」「向上心」といった内容が目に付きますね!
心理的安全性を担保して、メンバー全員が働きやすい環境を作るのはマネージャー陣の仕事なので、楽しく開発しているという声が聞けたのはすごく嬉しいですね。

rework.withgoogle.com

続きを読む

Gotanda.rbをZEALSオフィスにて開催 & ZEALSエンジニアが登壇しました!

f:id:zeals-engineer:20190604184832p:plain

はじめまして!
ZEALSで Rails & Reactを書いている中村です!

4月に復活したGotanda.rbのイベントがZEALSオフィスにて開催されたので、その様子をお伝えします! ZEALSエンジニアの福本がGotanda.rbのOrganizerであるため、今回ZEALSオフィスで開催する運びとなりました!

復活第一回目のイベントについての記事もありますので、Gotanda.rbの雰囲気を知りたい方はぜひこちらもご覧ください!

tech.zeals.co.jp

今回のテーマは"リファクタリング"

なかなかに渋いテーマですね!

  • そもそも、リファクタリングとは何か
  • リファクタリングをいつやるのか
  • リファクタリングを(チームで)どのように行うか

などなど、人によって内容に個性が出そうなテーマだと感じました!

それでは早速見ていきましょう!

LT大会

最初の登壇者はZEALSでRailsエンジニアをしているtakkunです!

f:id:zeals-engineer:20190606185137j:plain

写真ではわかりづらいですが、Railsのエラーメッセージが書かれたTシャツを着ています!
Railsへの愛を感じますね。笑

登壇資料

www.slideshare.net

スライドに紹介されているgem一覧

github.com

github.com

僕もZEALSにJoinするまで、これらのGemは知らなかったです!
2つのgemをうまく使えば、使われていないコードを綺麗に削除できますね!

またスライドの中の言葉で

「コードを追加するのは簡単だが、消すのは難しい」

って言葉が心に響きますね。

普段のコーディングから意識したい言葉です!

弊社takkunに続いて、3名+飛び込みで1名の計5名の方が登壇されました!
資料をアップロードして下さっている方もいらっしゃいますので、ぜひ見てみてください!

RubyMineでリファクタリング

エンジニアの皆さんの中には、お気に入りのエディタはカスタマイズして使っている方が多いと思います。
そんな中一度でも使ったら戻れなくなると噂のIDE RubyMineの機能を最大限に生かしたリファクタ方法を紹介されていました。

www.jetbrains.com

個人的にすごくインパクトがあったのは、一括リネーム(ファイル名・メソッド名・変数名)でした!
すごい…!!

RubyMineは有料のIDEですが、30日お試しで使用できるとのことです!

speakerdeck.com

クラウドワークスリファクタリングチーム「バグハンター」

クラウドワークスさんでリファクタ専門チーム作った時のお話です。
リファクタリングをモンスターハンターになぞらえて「分析した弱点部位に対してどのような武器を使って、どんな戦術で対処していったか」を発表されていました。

ZEALSでもtakkunがデザインパターンやオブジェクト指向の本を読みリファクタした、という話をしていました。
こちらの発表でも設計パターンを用いたお話があったので、その辺りももっと勉強しようと改めて思いました。

また、発表の中で「人を育てるコード」って言葉がすごい素敵で印象に残っています。

f:id:zeals-engineer:20190607105548j:plain

一覧画面のFatController/Modelになる理由と向き合ってみた

indexアクションが汚くなりがちな箇所に対しPORO(Plain Old Ruby Object)に切り出したり、生SQLを利用したり、ViewModelで定義してみたり...
問題点に対して様々な方法でリファクタしてみた、というお話でした。

原因に対していくつかの修正パターンを持っておく、というのはリファクタに限らず常日頃から意識したいと思いました!

speakerdeck.com

dockerで動いている プロジェクトのrubocop解析 vim編 + おまけ

最後はGotanda.rb Organizerであるマツリカの隅田さんの飛び込みLTでした!
前回もjoeさんが飛び込みLTをされていましたが、飛び込みが頻発するのは面白いですね。笑

「Docker+Vimでrubocopのリアルタイム警告を出すことができるようになったお話」と「OSS活動を続けてRubyMineのAll Products PackをGetした」というお話でした。
All Products Packを入手するには色々な条件とOSS活動を3ヶ月以上継続する必要があるそうですが、興味のある方は是非チャレンジしてみてはいかがでしょうか!

speakerdeck.com

交流会

f:id:zeals-engineer:20190607181910j:plain

LT大会後は、お酒を片手にお菓子をつまみながら参加者の方々と和やかに交流会の流れになりました。
こういう機会に社外の方といろんなお話ができるのはいい刺激になると思いました!

おわりに

今回は、各社向き合わなければならないリファクタリングというテーマについて掘り下げた会でした!

続きを読む

Kubernetesにおけるmanifestファイル, imageの管理について

f:id:zeals-engineer:20190603114959p:plain

こんにちは、CTOの島田です。

弊社サービスであるfanpでは、定期バッチ含む全サービスがGKE上で起動しています。

今回は Kubernetesのmanifestファイルやイメージを効率よく管理するための取り組みを紹介したいと思います。 Kubernetesを本番運用しているところだと基本的なことが中心の内容かと思いますが、お付き合いいただけますと幸いです。

  • Kubernetes化にあたって意識したこと
    • 環境の差異, manifestの再利用性
    • CD(Continuous Delivery)の効率化
  • ZEALSでの取り組み
    • container registry専用のprojectを作成した
    • manifest file専用のレポジトリを作成した
    • Cloud Buildで継続的デリバリ
  • さいごに

Kubernetes化にあたって意識したこと

環境の差異, manifestの再利用性

  • ステージング環境とプロダクション環境でそれぞれ異なる環境変数が定義されている
  • ステージング環境はプロダクション環境よりも少ないマシンリソースで運用したい

一方で、

  • 同じようなmanifest fileを大量に書きたくない
  • 別サービスの同環境で同じsecretを使いまわしたい

という思いがありました。

後者はcloud_sql_proxyのコンテナ起動に使用するJSONデータなどが該当するかと思います。
(複数サーバーで同一DBを参照する場合)

CD(Continuous Delivery)の効率化

数分で完了するデプロイ、大して複雑でないパイプラインを構築する上で、極力シンプルなCDツールを目指すことにしました。
CDツールを自分たちで構築/運用した場合, 定期的なバージョンアップも行わなければいけなかったりと手間がかかってしまいます。

また, 未だにKubernetesにおいてCDツールのデファクトは存在しないと考えています。
そのため、ツール依存の設定が増えてJenkinsおじさん的な事象が発生するのは避けかったという意図もありました。 

ZEALSでの取り組み

container registry専用のprojectを作成した

アプリケーションのコードを元にbuildしたimageを置くためだけのprojectです。
このcontainer registryでは環境依存のものは配置せず、再利用可能なイメージのみを設置します。

GCPは権限の設定がとても楽です。
Cloud Buildで別projectにあるContainer Registryからimageをpullするのも, Cloud Buildのサービスアカウントをcontainer registryのあるprojectに追加し, ストレージ オブジェクト閲覧者を付与したら動作します。

manifest file専用のレポジトリを作成した

全サービスのmanifest fileを1つのレポジトリに集約させました。
特徴は以下の通りです。

ディレクトリはざっくりこんな感じになりました。

.
├── bin/
│   └── gen_kustomize.sh
├── service1/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── service.yaml
│   └── overlays/
│       ├── fanp-prd/
│       │   ├── deployment.yaml
│       │   └── kustomization.yaml
│       └── fanp-stg/
│           ├── deployment.yaml
│           └── kustomization.yaml
├── service2/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── service.yaml
│   └── overlays/
│       ├── fanp-prd/
│       │   ├── deployment.yaml
│       │   └── kustomization.yaml
│       └── fanp-stg/
│           ├── deployment.yaml
│           └── kustomization.yaml
├── secrets/
│   ├── prd/
│   │   ├── kustomization.yaml
│   │   ├── secret-hogehoge.yaml
│   ├── stg/
│   │   ├── kustomization.yaml

Cloud Buildで継続的デリバリ

結果的にCloud Buildを使用しました。
Cloud Buildの使いところは、アプリケーションのimage build各環境へのデプロイ になります。 デプロイまでの流れは以下です。

  1. 各アプリケーションでgit tagを打ち、リモートリポジトリにtagをpush
  2. container registry専用のprojectにあるCloud Buildが発火, imageをbuild
  3. manifest専用レポジトリでimage tagを編集, deployブランチへプルリクを出す
  4. 3.のプルリクがマージされたら任意のprojectCloud Buildが発火しデプロイ

ZEALSではstgへのdeployブランチにマージされたらステージングのprojectのCloud Buildが発火、masterへマージされたらプロダクションのCloud Buildが発火し、デプロイが開始するようになっています。

さいごに

動きました!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

続きを読む

ZEALS第2回エンジニア開発合宿に行ってきました!!@三浦海岸

f:id:zeals-engineer:20190521171954j:plain

皆さんこんにちは!
サーバーサイドエンジニアの阿久津です!

5/11(土)〜5/12(日)の2日間、ZEALSで2回目となる「 エンジニア合宿 」に参加しました。
私は今回から初参加だったのですが、今回の合宿の様子を紹介させていただきます。

  • 概要
    • 開発合宿の目的
    • 合宿場所
    • 開発テーマ
  • タイムテーブル
    • 5月11日(土) 1日目
    • 5月12日(日) 2日目
  • 開発の様子
    • 1日目
    • 2日目
      • ダイエットアプリ
      • 顔認識
  • 良かったこと・反省
    • 良かったこと
    • 反省
  • 最後に

概要

開発合宿の目的

今回の開発の目的は以下3点です。

  • 普段の業務で触れることのできない技術に触れることで、組織全体の技術スタックの幅を増やす
  • 非日常でのコミュニケーションを取り、メンバーの結束を強くする
  • 今後、個人で勉強を進めていくきっかけを掴んでもらう

技術力の底上げはもちろんですが、普段できないような深いコミュニケーションも1つの大きな目的でした。

合宿場所

合宿の場所はモチベーションを左右する大切な要素ですよね!

社内の事前アンケートの結果、オフィスからのアクセス1時間以内の近場ということでマホロバ・マインズ三浦さんに決定しました!

開発は室内なのでどこでもよい派だったのですが、考え改めました。。
綺麗な海を間近で見ることができる環境最高!

f:id:zeals-engineer:20190521172338j:plain

開発テーマ

前回の開発合宿では、皆が持ち寄ったテーマをもとにチームに分かれて行うメンバーが多かったのですが、今回は以下のゴールのいずれかを満たせればテーマは自由でした。

  1. プロダクトに跳ね返る
  2. 外部に情報発信できる
  3. 技術の有用性を伝えられる

合宿に参加するにあたり、各自テーマを決めて合宿前に事前に共有してから開発をスタートさせます。

開発スタイルは個人でもくもくスタイルでも、チームでワイワイスタイルでも特に制限はありません。
各メンバーが一番開発しやすいスタイルで開発します。

今回のテーマは自由だったこともあり、バラエティーに富んでいましたが、大きく分けるとこんな感じでした。

  • 社内のアセット整理
  • これから学ぼうとしている言語を使ったアプリ開発
  • 社内のプロダクトに活きる新しい技術の深掘り
  • 開発の効率化ツールの導入

私自身は画像認識に前々から興味があったので、OpenCVを使った顔認識とモーションディテクションにチャレンジしてみました。

タイムテーブル

5月11日(土) 1日目

  • 12:00〜: 現地集合
  • 13:00〜:オープニング開発スタート
  • 19:30〜: 夕食
  • 21:00〜: 自由行動

5月12日(日) 2日目

  • 8:00〜: 朝食
  • 9:00〜: 開発スタート
  • 11:00〜: アウトプット発表
  • 13:00〜: 現地解散

開発の様子

1日目

開発場所はホテルの9階、眺めはバッチリです。 f:id:zeals-engineer:20190521172831j:plain

テーマは事前に決めていたため、簡単なオープニング後すぐに開発スタートです。 f:id:zeals-engineer:20190521172858j:plain

各々好きな場所で開発中。海を見ながらの開発は最高に気分がいいですね。 f:id:zeals-engineer:20190521172928j:plain

19:30に中間報告感を行い、待ちに待った夕食タイムです f:id:zeals-engineer:20190521172954j:plain

食後はフリータイムです。近場の海を散策したり、持ち寄ったゲームで楽しんたり、引き続き開発を楽しんだりしました。チームメンバーの距離感が一気に縮まる貴重な時間でした。僕自身普段あまり聞かない、エンジニアになるきっかけとなった話や仕事に対す熱い思いを聞くことができる、ある意味最も濃い時間でした。 f:id:zeals-engineer:20190522105150j:plain

2日目

朝食後いよいよラストの追い込みです。
みんな開発に集中しすぎて写真が一枚もない。。

11時から各自のアウトプットを全員に向けて発表です。

今回テーマを絞らなかったことで、アウトプットの形も様々で、聞くだけでワクワクしました。
そんな中から、いくつかアウトプットをご紹介します!

ダイエットアプリ

Reactの技術深掘りと本人のニーズがマッチしたプロダクトです。
開発期間短い中でもしっかり動くプロダクトをアウトプットとして出すところにプロ意識感じます!

f:id:zeals-engineer:20190522111609p:plain

顔認識

精度はまだまだですが、顔の認識ができるようになりました。
画像が荒くなってしまいましたが、PCのカメラからiPadで表示した弊社CEO、CTOをしっかり認識してくれています。

f:id:zeals-engineer:20190521174312p:plain

github.com

合宿を通して個人としては小さな成功体験を何度も感じることができました。
そして、新しい言語を学び始めたメンバーはこの合宿をきっかけに、学びが深まり業務にダイレクトに還元されています!

良かったこと・反省

合宿終了後、参加メンバーで振り返りを行いました。

良かったこと

  • 掲げていた目標はすべて達成できた
  • 開発環境が良かった
    • 海が見える開放的な場所でリフレッシュもできた
    • 片道1時間のため、移動で疲れることがなかった
  • コミュニケーションが取れた
    • 普段話せないメンバーと話したり、深い話をすることができた
  • テーマを事前に決めていたので、すぐに開発に取り掛かることができた
続きを読む

復活のGotanda.jsに運営&参加してきました!

f:id:zeals-engineer:20190516184449j:plain

皆さんこんにちは! 
ZEALSでVPoE兼サーバサイドエンジニアをやっている福本です!

5月10日に行われました五反田のJavaScriptコミュニティGotanda.js』が約1年振りに復活することとなりました!

gotandajs.connpass.com

今回は再始動イベントに参加してきましたので、そちらのイベント模様と今後のコミュニティ活動について簡単にお伝えできればと思います。

ちなみに、私福本が今回からGotanda.jsのOrganizerに加入させていただいており、イベントやコミュニティ運営をメインとして行っておりました!

github.com

再始動のご挨拶

今回の会場は五反田東口にあるモバイルファクトリーさんの会議室をお借りして実施しました!

f:id:zeals-engineer:20190516175829j:plain

こだわりを感じるキレイなオフィスでした

30名の参加枠に対して43名の方から申し込みが殺到し、さらに当日も申し込みをされた方がキャンセル無しで全員参加されるなど、相当な盛り上がりぶりでした!

JS界隈の盛り上がりやエンジニアの勉強意欲の高さを改めて感じましたね!

再始動にあたるご挨拶をufotsuboiさんに行ってもらいました!

かつてのOrganizerの方が五反田を離れられたのをきっかけに運営が止まってしまっていたのですが、今回約1年ぶりの復活となりました!

LT大会

ここから先はメインプログラムであるLTの実施が続きました!

JS周りのフレームワークやインフラとの兼ね合いについて、自社での取り組みや開発において気づいたことなどを思い思い発表していきました!

(それぞれのLTの簡単な内容は、モバイルファクトリーさんのテックブログで書いてくれておりますので、そちらをご覧ください!)

tech.mobilefactory.jp

LTを聞いて&懇親会でいろんなエンジニアの方の話を聞いての感想なのですが、GatsubyやNuxt.js, Next.jsなどのSSR(サーバサイドレンダリング)周りの話が非常に多かったと感じました!

プロダクトやサービスによってはSEOが非常に重要な要素になっていて、使っているフロントエンドのフレームワークがReactだと、サーバサイドでJSがレンダリングされずGoogleのクローラーがページを上手く読み込んでくれない...

medium.com

そのような背景もありつつ、SSRに迂闊に手を出すとコードが複雑になり開発工数が増大になるという悩ましさがあるため、SSR界隈は独自の盛り上がりを見せているなと感じました。

それ以外にはAWS(CDK)やDockerなど、低レイヤーな領域を絡めた話も多かった印象です!

JS周りはトレンドの移り変わりが本当に激しいので、こういったイベントに参加して最新のトレンドをキャッチアップするのはすごく重要なことだと改めて感じまいした!(もっとJS書こう...)

続きを読む

ZEALSのSlack Public率を覗いてみたら結構おもしろかった件

f:id:zeals-engineer:20190426201205p:plain

はじめに

エンジニアチームの味わい深い領域を担当しているKodyです!
タイトルにもありますが、弊社SlackAnalyticsが激動すぎて面白かったので記事にしてみました...!!

以前SmartHR宮田さんSlackPublic率に関するツイート↓を見かけ、「なんて素敵なんだ...」と感じました。
それがきっかけで、SlackのAnalyticsを覗いてみることにしました!

ちなみにSmartHR社ではDM禁止、Privateチャンネル禁止みたいなルールで縛ることはやっていません。

この「ルールにしない」というところが、実にイケてますね!

shr_miyata_tweet_slack

オープンな文化がもたらす良い効果

「オープンな文化がもたらすいい効果」について、大きい効果が2点あると思ってます!

  1. 情報格差が起こりにくい
  2. 自然と建設的なコミュニケーションの取り方になる
情報格差が起こりにくい

Aさんは知ってるけどBさんCさんは知らないことがある事で

A「〇〇についてだけど...」 B・C「え、なんですかそれ?知らなかったです...」 A「あぁ、それはね....」

などというコミュニケーションが随所で生まれてしまいます。
不必要なコミュニケーションが生まれ、事業&開発スピードに影響が出てしまいます。

自然と建設的なコミュニケーションの取り方になる

publicな場所で誹謗中傷が起こらないなど、お互い気持ちいのいいコミュニケーションが促進されます。
誰に見られても恥ずかしくないようなコミュニケーションを、メンバーが自然と取るようになります。

ZEALSのSlackAnalyticsを見てみました

さて、それでは実際のZEALSのSlackの状況を見ていきましょう!

zeals_slack_public]

...移り変わりが激しいですね...笑
Active User の変遷は↓こんな感じです。

zeals_slack_active_user

大きく3つの動きが見受けられました!

ざっくり時期ごとに分けると、こんな感じで3つに大別できます。
時期ごとに詳しく見ていきましょう!

age_of_slack_pub_rate

秘密結社時代[ActiveUser:10名程度]

age_of_secret_company

ほぼ全てのやりとりがDMですね!
当時のZEALSは秘密結社か何かだったのでしょうか...笑

僕自身がこの時期にいなかったため推測ですが、

  • Slackって何?状態でとりあえず使っていた
  • 平均年齢がLINE文化世代なので必然とLINEのような使い方になっていた

というのが、DM率が高かった原因ではないでしょうか?

激動時代[ActiveUser:50名程度]

age_of_very_move

激しく人数が増え始めた時期ですね!
私自身この時期の後半にZEALSにジョインしました!

メンバーが増えてきたため、社内コミュニケーションの透明性に課題が生まれたのがこの時期だったと記憶しています。
この時期の後半には、ZEALSのValueの制定などもあり、オープンなコミュニケーションが文化として根付き始めました!

文化として根付かせるのは非常に難しいのですが、オープンな文化のメリットを説き続ける「味わい深い」ことができる人がいると進めやすいです。

安定時代[ActiveUser:70~80名]

age_of_stable

どんどんオープンな方向へと向かっていますね!
メンバーが増えているにも関わらずオープンになっているのは、文化として根付いた証ではないでしょうか?

個人的には、もう少しDMの割合下げていきたいと思っています!
今後もZEALSのオープンな文化を作っていくために、引き続き頑張っていきます!

大事なのは「変化する事」

改めてですが、SmartHRさんの例、本当に素晴らしいと思います!
(なかなか真似できないと思いますが...笑)

初めから理想形で運用できていれば良いのですが、全ての組織ですぐに実行するのは難しいのではないでしょうか。

理由は簡単で、「僕たちが人間だから」です!

完全無欠のロボットではなく人間なので、間違いは必ずと言っていいほど起こります。
なので、間違いがあったとしても組織としていい方向へ「変化」する事が大事だと思います。

ZEALSの例でいうと、よくない状況を着実に改善し続け「変わることができた」のではないかなと思っています!

行動の軸となる ZEALSのValue

変化しようと思ってはいても、なかなかうまく行動できないことがあるかもしれません。

そんな時は、行動の「」となるものがあると、メンバーレベルでの意思決定で統率が取れ、チーム一丸となることができると感じています。

ZEALSの行動指針であるValueの1つに「United Will」というものがあり、「時と志を共にする」とう意味を持っています。
(= 志を一つにすること。チーム全体のことを考え、行動すること。)

Slackの使い方が改善されたのも、メンバー1人1人がチームを良いものにしようと動き続け、Valueを軸に行動できた結果だと思います。

今回のように、組織全体で一丸となって改善し合えるのがZEALSの大きな魅力のひとつと言えます!!

さいごに

チームでSlackを使っていて気になった方は、ぜひSlack Analyticsを見てみるのをお勧めします。
チーム力改善のヒントが見つかるかもしれません。

もちろんSlackPublic率が組織としてのオープンさの全てを表すものではないので注意すべきですね。 ただ、よほどセンシティブな情報以外はオープンにすべきだと思います。

papix.hatenadiary.jp

続きを読む

ZEALSではリーダブルコード読書会を実施しています

f:id:zeals-engineer:20190424155226p:plain

こんにちは!
Railsエンジニアのtakakudaです。

今回はエンジニアチームで取り組んだリーダブルコード読書会についてご紹介します!

目的

  • 理解しやすいコードとは何かを知り[to know what is "readable" code like]
  • 実際にそのようなコードを書けるようになることで[and to learn how to write "readable" code]
  • 今後の開発効率を向上させ、バグや障害の発生を削減する[aiming to improve develepment productivity and reduce software bugs and system troubles]

以上のことを目的として、今回の読書会を実施しました。

実はこのリーダブルコードの読書会は3回目で、最初は「またやるの?」という気持ちでしたが、新しい発見がたくさんありました。

やはり『リーダブルコードは』何度読んでも良い名著ですね…。
自分のコードの質が上がったのではないかと感じています!

内容

読書会ですが、以下のような流れで進めました。

1. 座学

リーダブルコードを3章区切りで読みます。
読んだことがある人は、再度読み直します。

2. プルリク作成

リーダブルコードを参考に、改善できそうなコードを見つけてプルリクを作成します。

その際にセルフレビューのコメントで、

  • リーダブルコードのどの章を参考にしたか
  • 質問(ex..このように改善したが、もっと良い書き方はあるか?)
    を追記していきます。

3. ピアレビュー

自分以外の参加者のプルリクを、1人2つ以上レビューします。

レビューの際は

  • 良いと思った点
  • こうしたほうが良いと思った点
  • 質問
    をコメントとして追記します。

4. 議論・講評

  • 1 ~ 3が終わったら全員で顔を合わせるタイミングを作り、議論をします

f:id:zeals-engineer:20190419202758j:plain

講評

  • コードオーナーが全体を通して気づいたことを話す

質問

  • 直接プルリクに記載はなかったが、聞きたいことを質問する

議論

リーダブルコードに書いてある内容で、プロダクトコードに合わせて読み替えたほうが良い点などを話し合う

結果

この読書会は任意参加なのですが、ほぼ全員のメンバーが参加し、プルリクを送りあってくれています。

この取り組みはCTO自らが中心となり推し進めており、ZEALSでは3回目の実施となります。
初回から参加していたメンバーが、教えてもらっていた立場から教える立場へと変わっていく...、という良いサイクルが回っていて、とても良い文化だなと感じています。

ちなみに

実際に参加したメンバーからも良い反応をもらいました!

続きを読む