福岡でチームビルディング合宿を開催し、Frontend Teamの開発行動指針をアップデートした

こんにちは、Kaizen Platform で Frontend developer やってます tatsuroro です。
先日、弊社Frontend Teamで初のチームビルディング合宿(以下、合宿)を福岡で開催しましたので、そのレポートをお伝えしたいと思います。

TL;DR

  • 「TECH DEEP SYNC: アプリ設計のベストプラクティス2018年春」と題し、福岡に集合して技術トピックについてディスカッション
  • 普段はリモートで働いているメンバーが一箇所に集まって集中議論することで日頃の開発知見を共有
  • 合宿のアウトプットとして、フロントエンド開発時の各メンバーの行動指針となる「チーム憲章」(後述) をアップデート
  • 福岡のごはんはとても美味しいです

なぜ「Frontend Team」合宿をやるに至ったのか

弊社の Frontend Team はメンバー4人のうち1人は大阪、もう1人は福岡でフルリモート勤務しているのですが、各人がそれぞれ別個のプロジェクトを担当していたりしてなかなか経験を共有する機会がなく、課題感を持っていました。 オンラインで Tech Sync やコードレビュー会を実施したりもしていましたが、皆日々忙しいのでなかなか時間を確保しづらかったり、オンライン開催だと議論の熱が失われがちだったりしていました。

そこで、合宿という形で集まって集中 Tech Sync をやろう、ホワイトボードを前に日頃の気づきや疑問、ベストプラクティスをぶつけあってみよう、どうせやるなら完全に業務を離れて地方開催だ!ということで Frontend Teamの合宿 in Fukuoka を開催する運びとなりました。

f:id:kaizenplatform:20180413145944j:plain 福岡オフィスとしてもお世話になっている The Company 福岡パルコ店にて開催

TECH DEEP SYNC: アプリ設計のベストプラクティス2018年春

朝の10時に集合し、ディスカッションテーマの確認から始めます。

今回は「TECH DEEP SYNC: アプリ設計のベストプラクティス2018年春」というお題のもと、各々気になるトピックを洗い出し、順にディスカッションしていくという形で実施しました。

f:id:kaizenplatform:20180413150034j:plain

SPAのルーティングやURL設計、認証などの構造的な話から GraphQL の活用スタイルまで、日頃溜め込んでいる知見や悩みがどんどんオープンに。
色んな視点・観点が重なり、議論は白熱してゆきます。

f:id:kaizenplatform:20180413150048j:plain

ランチ

ランチは会場近くの一風堂本店へ。

f:id:kaizenplatform:20180413163046j:plain 一風堂 大名本店

f:id:kaizenplatform:20180413163057j:plain ここ大名本店にしかない「元祖白丸・赤丸」は、味に深みがあってとても美味しかったです

f:id:kaizenplatform:20180413163108j:plain 九州人のソウルフード、ブラックモンブランを紹介してくれる laco 氏

午後:アイデア出し & ディスカッション

ランチの後もまだまだ話は尽きず。

「素の CSS 書くのやめて CSS in JS に一本化しません?」という提案に始まり、CustomElements の使いどころ、デザインチームとの協業の話、Google の Cloud Firestore を使って RealtimeDB をコンポーネントにバインドし、クライアントサイドの状態管理を無くすアイデアなど、話題は広がりおおいに盛り上がりました。

まとめ:チーム憲章をアップデート

1日の最後に、フロントエンド開発時の各メンバーの行動指針となる「チーム憲章」をアップデートして、今回の合宿のまとめとしました。

f:id:kaizenplatform:20180413163226j:plain 議論の内容をもとに、サービス設計・開発方針が更新されてゆきます

アップデート後のチーム憲章(一部)がこちら。

技術スタックについて

動作環境

  • 動作環境の保証ラインを設ける
    • プロダクトごとに変わってくるので、ちゃんと定めてメンテする
    • 基準を設けて機械的に判断する (e.g. 5%未満は切る)
      • リアルユーザー内での比率で見る
    • 後から切るほうが大変。マーケットに応じて広げることを検討する。

言語

  • 特別な理由がない限りTypeScriptを採用する

パッケージ管理

  • 特別な理由がない限りnpmを使う

フレームワークライブラリ

  • 基本的に自由

その他のライブラリ選定

  • 基本的に自由

コミュニケーションについて

with バックエンドチーム

  • FE / BE どちらか一方の都合を優先せず、相互に尊重する。スキーマに関するコンセンサスを最初に取る。

with デザインチーム

  • プロジェクト内での責務の分担を決めておく (UX設計 => UI設計 => UI実装)

今回のアップデートに際し、コミュニケーションについての項目が追加されたことはとても意義深かったです。
憲章には一言でまとめていますが、Production チームとしての成果を向上させるために積極的に他のチームと連携を取っていこう、スムーズな開発ができるよう尽力しよう、チームにとって必要であればデザイン作業も(得意不得意はあれど)担当するぞ、という各人の意志がここに結晶したのは大きな成果でした。

閉会〜打ち上げ

丸一日集中してディスカッションするのは大変ではありましたが、ともあれ初のFrontend Team合宿は充実した内容で終えることができました。 閉会後は、福岡の食を堪能しよう!ということで黒毛和牛もつのおいしいお店へ。

f:id:kaizenplatform:20180413163258j:plain 締めのちゃんぽんがこれまた美味かったです

f:id:kaizenplatform:20180413163311j:plain 中洲の屋台街へ。屋台のラーメンもまた乙な味です

おわりに

今回は知見を共有することが目的だったので、まずはやってみよう、発散も飛躍も大歓迎、行きすぎたら都度戻るというスタンスで議論していたのですが、やはり同じ空間で会話するメリットは大きく、終始多様なアイデアやアドバイスが飛び交っていました。 普段リモートで働いていて顔を合わせづらい分、業務を離れて1日でやりきるという意識のもと、集中して実施できたことも良い結果につながったのだと思います。

今後も、チームコミュニケーションの量と質の向上へ向けたイベントを継続し、より良いチーム作りを目指してゆきたいと思います。

Kaizen Platformで行っているOnboardingプロセス

Kaizen PlatformでSRE Group Managerをしている前田 (@glidenote)です。4月ということで転職や部署異動など新しい環境で働いている人が多そうなので、今回はKaizen PlatformのEngineering GroupとSRE Groupが行っているOnboardingプロセスを紹介したいと思います。

TL;DR

  • Kaizen Platformに入社してくれた人に最速でPerformanceを出してもらうためにOnboardingプロセスを策定し、運用、日々改善している
  • 入社してくれた人が自身のOnboarding Planを自分で作成し、CTO、メンターとで定期的に期待値の調整、振り返りを実施し、齟齬が発生しないようにする
  • ランチスケジュールを組み毎日別々の人と、別々の場所にランチに行き、一緒に働く人たちとオフィス周辺の情報を知ってもらう
  • 入社した人に「自分を知ってもらう努力」をしてもらう

背景

Kaizen Platformは創業時(2013年頃)から決まったOnboardingプロセスが特に存在せず、新しく入社した人がパフォーマンスを発揮するようになるまでに時間がかかっていたため、1年前(2017年前半)からEngineering GroupとSRE GroupではOnboardingプロセスを策定し、運用、改善している。

Onboardingとは

オンボーディングとは、組織やサービスに新たに加入した人に手ほどきを行い、慣れさせること。

Onboardingプロセスの流れ

  • 下記は入社前から入社3ヶ月後までのOnboardingプロセスの流れです。
  • 期待値の調整、振り返り、コミュニケーションの機会を増やし、誤解が発生せず、気持ちよく働ける状態に持って行くことが狙いです
  • 下記の共有のもの以外に、メンターの裁量でdailyやbi-weeklyなどの1on1などが設定されています
時期 やること 担当 備考
offer時 期待値の設定&すり合わせ CTO
入社前 メンターの決定 CTO
入社前 メンターとの期待値共有 CTO & メンター
入社前後 各種MTGへの招待 メンター
入社前後 歓迎会の設定 メンター
入社後1週間以内 CTOと1on1の設定 入社した人 会社のことをより知ってもらうため
入社後1週間以内 Product責任者と1on1の設定 入社した人 Productのことをより知ってもらうため
入社後1週間以内 自己紹介の記入 入社した人
入社後2週間以内 Onboarding Plan(3ヶ月)の策定 入社した人 Qiita:Teamに書く & メンターはサポートする
入社後1ヶ月経過後 1ヶ月のOnboarding Report(途中経過) メンター CTOにメールで提出
入社後1ヶ月経過後 CTOとの「1ヶ月面談」の設定 入社した人 1ヶ月の振り返り
入社後2ヶ月経過後 CTOとの「2ヶ月面談」の設定 入社した人 2ヶ月の振り返り
入社後3ヶ月経過後 3ヶ月のOnboarding Report メンター CTOにメールで提出
入社後3ヶ月経過後 CTOとの「3ヶ月面談」の設定 入社した人 3ヶ月の振り返り

入社した人が自身のOnboarding Planを作成する

  • 入社した人は下記フォーマットを利用して、自身のOnboarding Planを書いて、全社員が見える場所(Qiita:Team)に投稿する
  • Onboarding Planは1ヶ月おきに振り返り(Onboarding Report)を実施し、目標に対してどれくらい達成出来ているか、または出来ていないのかを可視化。
  • 目標に対して、どのような登り方をするかなども考えないといけないので思考の訓練にもなります。
## Kaizen Platform で私が目指したいこと

xxxx を実現する。

## 3ヶ月後の目標

1. xxxx できるようにする
2. xxxx できるようにする
3. xxxx できるようにする

目標設定の背景は xxx。

## 3ヶ月後の目標達成に向けての施策

### 1. について

- 具体的に何をやるか

### 2. について

- 具体的に何をやるか

### 3. について

- 具体的に何をやるか


# 振り返り

## Month 1

TBE

## Month 2

TBE

## Month 3

TBE

毎日違う人、違うお店へランチに行く

  • メンターが毎日違う人(以下ランチゲスト)とランチに行くように日程を調整
  • ランチゲストの人は、オススメの店にチョイスする。なるべくお店は被らないようにチョイスして貰う
  • メンターはランチゲストと行ったお店をまとめてQiita:Teamで管理する
  • 追記 休憩時間なので、ランチ同行は強制ではなく任意で行っています

下記は実際のまとめ投稿のスクリーンショットです。

f:id:kaizenplatform:20180409143956p:plain

入社した人に「自分を知ってもらう努力」をしてもらう

  • 入社した人に「自分を知ってもらう努力」を積極的にしてもらう
  • 入社時の自己紹介だけでなく、社内勉強会やMTG、全社合宿などで人前で話す機会を増やし、アピールする場を設ける
  • 「自分を知ってもらう努力」とは、筆者の以前の同僚である宮下剛輔さんのインタビューから拝借している金言です

宮下氏は一貫して、「自分を知ってもらえば、周りから来るようになる」というスタンスを取っている。だからこそ、自分を知ってもらう努力を誰よりも大切にしているのだ。

「テクノロジーの話に限らないんですよ。例えば、僕はドクターペッパー大好きっていい続けてきたんです。そうしたら最近、会う人がドクターペッパーを手土産に持ってきてくれるようになってきた。スピーカーとして話すときも、普通は壇上に水が置いてあるところを、ドクターペッパーが置いてあったり。ほかにも、ゲームではメタルギアソリッドシリーズが大好きで、そのことをいい続けていたら、どこどこに等身大の人形があったよとか、サントラが出てるよ、とか。それが自分のブランディングにもなるし、情報も集まってくる」

「当たり前のようですけど、自分の好きなことや、やっていることを生かせる場を、周りが用意してくれるようになるんです。コミュニティじゃなくても、職場の中でもそうですよね。直接、一緒に仕事をしている人しか、自分のしていることって分からないと思うんです。でも、もっと広くアピールしていくと、職場の中でも自分に最適なポジションが来ると思うんですよ」

全員でサポートし、良いチーム作り、良いプロダクトへ

上記のようなOnboradingプロセスは基本的にメンターが中心になって実施していますが、メンター以外のメンバーもOnboardingに積極的に参加し、より良いチーム作りをし、良いプロダクトを生み出すことを目指しています。

AWS 上で利用している SSL/TLS 証明書を一括管理するツール aws-cert-utils を作った話

はじめまして、Kaizen Platform SRE の @tkuchiki です。

本記事では AWS 上で利用している SSL/TLS 証明書(以下、証明書)を一括管理するツールを作成したので紹介いたします。

TL;DR

  • aws-cert-utils を作成して AWS 上で利用している証明書を一括管理できるようにした
  • 証明書の一覧表示、証明書を利用している ALB / CLB / CloudFront の一覧表示も可能
  • aws-cert-utilsを利用し証明書を管理することで、更新・確認作業においてミスが発生しにくくなった
続きを読む

Rails Developers Meetup 2018 で「正しく失敗しつつ進むプロダクト開発」という話をしてきました

Application Engineer の ryopeko です。 3/24 と 25 に開催された Rails Developers Meetup 2018 で登壇してきました。 自分のセッションは 3/25 14:50~ の回で、「正しく失敗しつつ進むプロダクト開発」というテーマでお話ししました。 当日は2トラックのセッションだったにも関わらずたくさんの方に見に来てもらえました。ありがとうございました。

続きを読む

ユーザーの声の裏に潜む潜在的なニーズをリーンにつかんでいく

こんにちは。Kaizen Platformで新規プロダクトを開発しているチームにいる、kosukeです。

Kaizen Platformでは主にプロダクト開発のメンバーが中心となり、お昼に皆でお弁当を食べながら代表者が技術ネタや社内のプロダクト作りに関する話をする会を毎週やっています。 先日、私の方からアンケートやフィールド調査の話題と共にどうやってユーザーリサーチしていくか?的な話をしたので、ここではその話をご紹介したいと思います。

ユーザーの声 VS 本音や裏に潜む声

ここに面白い話があります。大分昔の話ですが、ソニーのラジカセ(↓)が発売される前後、本体の色のニーズを探る調査が行われたそうです。会場には数十人が集められ、複数の色のモデルが用意された中でどの色が良いかを質問されました。

すると、会場の人々の声からは黄色のモデルが人気があったそうです。

f:id:kaizenplatform:20180317211756j:plain:w300

https://www.pinterest.jp/pin/688276755525215503/

そして最後に、会場にいた全員に特別にプレゼントされることになりました。好きな色のモデルを持ち帰ってよいと言われ、帰り際に皆が手にとって帰ります。すると、何故か会場での声からは人気があった黄色のモデルではなく、黒色のモデルを皆手にとって会場を後にしていったそうです。実際にユーザーの声としては黄色のモデルが人気だったのにも関わらず、所有者としての立場ではより無難な黒色が選ばれたということです。

表面には出てこない潜在的ニーズ

ユーザーの声を対話や回答として得るインタビューやアンケートでは、本音が語られないことが往々にあります。下図のように、いわゆるユーザーの声は表面的な部分であり、その下には裏に隠れている潜在的なニーズが存在します。

f:id:kaizenplatform:20180317214828p:plain

https://www.pinterest.com/pin/506655026808924800/

インタビューやアンケートなどのユーザーの態度を測る手法とは対極に、ユーザーのありのままの行動を観察するフィールド調査の手法があります。フィールド調査にも様々な手法がありますが、共通するのはユーザーのコンテキストにそのまま入り込むことです。そうすることで、ユーザーの声からは得られなかった、潜在的なニーズをつかむヒントになるインサイトに気づくことがあります。

ただこのようなフィールド調査は有効な一方で、ユーザーと同じ時間をそのまま共有することもあり、時間的なコストも必然的に高いという欠点もあります。また、フィールド調査で現れるのはユーザーの行動そのものであり、「なぜその行動をしているか?」の答えはあくまで推測でしかありません。(勿論、なぜ?が明らかな場合もありますが。)

フィールド調査の現代版SaaS

Kaizen Platformのプロダクトチームで欠かせないものになっているツールに FullStory があります。これはユーザーの行動を記録して、操作状況の画面をそっくりそのまま再現してくれます。

f:id:kaizenplatform:20180317215928p:plain:w400

私はこれが現代版のフィールド調査に近いと思っていて、そこまでコストがかからずに手軽にユーザーの行動を把握することができます。

FullStoryは複数のユーザーがある特定のパターンで行動しているなど、特徴的な行動が簡単に切り出せる便利なツールですが、フィールド調査の手法と同じように、ユーザーが「なぜその行動しているか?」の答えはあくまで推測でしかなく、すなわちこのツールだけでは答えを得ることが難しいことも多いです。

リーンに様々な手法を併用して答えに近づいていく

ユーザーリサーチには様々な手法やツールがありますが、一つの方法だけにこだわっていては潜在的なニーズを掘り出すのはやはり難しいです。アンケートやインタビューなどユーザーの声を得る手法と共に、フィールド調査のようなユーザーの行動をありのままの姿で把握する手法、両方を併用して行ったり来たりすることで答えに近づいていきます。IDEOではHybrid Insightsという定性・定量の両観点でインサイトを絞っていく思想があったり、どちらも一方では片手落ちになってしまうので相互補完し合うというのが良いそうです。

Kaizen Platformでは、上記のFullStoryに加えてインタビューやアンケートなどを併用して、潜在的なニーズを探っています。例えば、FullStoryで見られた特定の行動について何かしらの仮説を立て、それを深掘るためのインタビューを実施し仮説が合ってるかどうかを検証します。さらにアンケートで一定数の裏付けを得ることで、仮説をより強固にしていきます。

スタートアップは基本的にやることが沢山あるので、ユーザーリサーチに潤沢な時間を使えるわけではありません。そんな中で、ユーザーリサーチの手法の全容を把握しつつ、自身の目的にあったやり方を様々な手法の中から取捨選択して、かつリーンに実行していくことが大切だと思います。

参考

ユーザーリサーチの全体像は、ユーザーエクスペリエンス調査、どの手法をいつ使うべきかで紹介されている図が参考になります。

f:id:kaizenplatform:20180319123230p:plain