「人事労務freee」のEC2→EKS移行で、大変だったことと良かったこと

freee Tech Night で司会をしていますのぶじゃすです。4月23日に配信した「freee Tech Night Online #10 〜人事労務freee、EKS移行」の様子をご紹介します。人事労務freeeのアプリケーションエンジニアhanakeとSREのnekottyoの二人に、移行の経緯、プロセス、導入後のメリットとデメリットについて語ってもらいました。

登壇者の写真
登壇者の写真

  • hanake: 写真左上

    • 人事労務freeeのアプリケーション開発担当。
    • 前職でdockerの使用経験あり。インフラの知識を持ちながら、スクラムマスターとしてプロジェクトをリード。
    • 今回は、アプリケーションエンジニア側からEKS移行にチャレンジした。
  • nekottyo (@nekottyo): 写真右上

    • 人事労務freee担当のSRE。AWS、EKS周りの管理がミッション。
    • Datadogでの監視も担当し、安定稼働のための開発を担っている。
  • のぶじゃす (@noblejasper): 写真右下

    • ラジオパーソナリティ、2017年に中途入社
    • mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee に。入社後はエンジニア→エンジニア採用担当→エンジニアと DevBranding を担当。
    • しゃべりたがり。声が大きい。

EKS移行の目的は、障害からの復旧を早めることと、属人的な運用から脱却すること

ご存じない人もいると思いますので、EKSについて簡単に説明してもらえますか。

hanake: はい。EKS (Amazon Elastic Kubernetes Service) は、AWSが提供するKubernetesのマネージドサービスです。主にコントロールプレイでの管理を行うことで、高い可用性を担保できます。Kubernetesの知識を持っていれば、EKSで一般的なWebサービスの本番運用は可能だと思います。

なぜ、人事労務freeeをEC2からEKSに移行したのですか?

hanake: 2つの理由があります。「障害からの回復時間」を早めたかったのが1つ目の理由です。従来は大量のnodeがLoad Blancerにひもづいている状態で、そのうちいくつかのnodeが落ちないことがあって、障害からの回復のためのデプロイに時間を要していました。KubernetesをEKSで運用すれば、明確なpod shutdownのルールが存在しているので、正しく落ちないなどの変な挙動をするnodeの影響を無くすことができると考えました。

2つ目の理由は、「属人化されたインフラ運用」を仕組み化したかったからです。特定の人物しか理解していない運用箇所があったので、EKSで管理をすることで仕組み化することを目指しました。AWSのマネジメントコンソールを活用して、問題が生じた場合は誰でも特定できるように変えたのです。具体的にはTerraformとHelm Chartで管理するように、nekottyoが整備してくれました。nekottyo、ありがとうございます!(笑)

既存のEC2環境のAPMデータをもとに、EKSの負荷試験を行った

移行準備での困難を淡々と語るnekottyoさん
移行準備での困難を淡々と語るnekottyoさん

EKSへの移行は、誰が発案されたのでしょうか?

hanake: アプリケーション側が発端ですね。何人かのエンジニアで集まって、「もっとイケてるインフラにしよう」と話し合って、SRE側を巻きこんだことからプロジェクトがスタートしました。

移行準備で特に大変だったことを教えてください。

nekottyo: EKSに移行するためにコンテナを準備して、dockerファイルを整理してリハーサルしたのですが、そのときはうまく動きませんでした。アプリケーションを動かすための環境変数を入れていなかったり、プリコンパイルされたJavaScriptやCSSが読めなくて、文字だけのhtmlが表示されたり。

やっと動くようになったら、今度はパフォーマンスの問題が発生しました。人事労務freeeでの移行プロジェクトは、新規にEKSを導入するのではなく、EC2から移行する作業でした。EC2 環境と同じ性能を出すことが求められるのですが、プロジェクトの初期においては、私たちに知見が足りなかったんだと思います。

既存のEC2環境のAPMデータをもとに、EKS環境のレイテンシなどの平均・最大を取得しながら負荷試験を行うことで、何とか同じパフォーマンスが出せるようになりました。色んなボトルネックが見つかり、リソースの再設定や、Kubernetesのパラメータの調整を行うことで改善を重ねましたね。

最も大きなボトルネックになったのは何ですか?

nekottyo: これ!という大きなものは無くて、細かい不具合が幾つか出ていた感じです。メトリックスを取ったり、アプリケーションの動きをAPMで追うことで特定していきました。1つを改善しても他のボトルネックが現れることも多く、問題を見つけては直す、の繰り返しでした。

DNSレベルでリクエストをEC2とEKSで分散。問題なく1日で移行作業を完了した

ヤバかったエピソードを笑顔で語るhanakeさん
ヤバかったエピソードを笑顔で語るhanakeさん

導入作業で最も大変だったことは何ですか?

hanake: 決まった時間・間隔で何らかのタスクを進める「CronJob」という機能があります。その中に「suspend」というパラメーターがあって、CronJobが動かない「true」のstatusでデプロイを進めていたのですが、何かのタイミングで「false」に切り替わったのです。夜中の12時に行うべきバッチが走ってしまった、というエピソードがあります(笑)。

それはヤバいですね!!

hanake: 検証環境だから問題は無かったのですが、ビックリしましたね。「startingDeadlineSeconds」を設定すれば回避できるのですが、当時はその知見がありませんでした。Kubernetesの「ハマりポイント」の一つに、順調にハマったという感じです(笑)。

nekottyo: 調べれば分かることなのですが、初めてだったので仕方が無いですね。

実際の導入作業自体はどうでしたか?

hanake: 割と順調に進んだと思います。すごく慎重に作業しましたので。route53 の weighted recordという機能を用いて、DNSレベルでリクエストをEC2とEKSで分散しました。最初は1%をEKSに流して、99%をEC2に流す仕組みをつくって、そこから徐々に、5%→10%→50%→100%と上げていったのです。何か起こったら作業を止めるフローを確立していたので、ドキドキはしましたが、1日で問題なく移行が完了。ユーザー側から見ると、何一つ挙動は変わらないので、クレームなども一切ありませんでした。

デプロイが圧倒的に安定するように。監視の一元管理を可能にした

それはすごいですね!移行の結果として、当初の課題は達成できましたか?

hanake: 解決できた部分は多かったですね。1つ目の課題「nodeがうまく落ちなくて、障害対策に時間が掛かる」については、podを落としてrolling updateをすることで解決しました。Kubernetesでは詳しい設定を行えば、スムーズに処理を行えます。変なnodeがあっても落とせる仕組みがあるので、デプロイは圧倒的に安定しましたね。

2つ目の課題「属人化されたインフラ運用」については、ほぼ全ての運用をTerraformとHelmfileで管理することで、誰がコードを見ても分かるようになりました。

nekottyo: 今回移行したのは「人事労務freee」ですが、ウチの会社はそれ以外にもEC2でサービスを運用しています。今後、移行が発生したときにスムーズに進められるようにHelm Chartを整備しています。アプリケーション開発側でこれらのツールを活用してもらうことで、異なるサービス間でも品質が統一される仕組みをつくれました。

実運用のフェーズに入って改めて感じた、EKSのメリットは何ですか?

hanake: やはり障害の回復が早くなったことでしょうか。スケールイン、スケールアウトの速度が全然違います。以前はnodeの立ち上がりに5-10分掛かっていたのですが、Kubernetesではpodでの管理になって、かなりスケールが速くなりました。1-2分くらいです。たとえば、給与計算は処理のタイミングが集中して多くのpodを要求する状態になるのですが、一気にさばけるようになりました。

nekottyo: 監視ツールも併せて移行することで、運用を強化できました。EC2のときは、Kibana、Mackerelといった複数のSaaSを使用していたのですが、EKS移行に併せてDatadogにまとめました。以前はオペレーションも煩雑で、学習コストも掛かっていたのですが、概ね解消できましたね。現在は、ログもメトリックスもAPMの状況も、ダッシュボードを見れば全て把握できます。不具合があればアラートが上がる仕組みも導入することで、障害対応も効率化できました。

EKS導入のデメリットは学習コストと、デプロイ時のコンフリクト

逆にEKS導入のデメリットはありますか?

hanake: アプリケーション側としては、現状では学習コストが高いです。Kubernetesは抽象化が進んでいるので、何か作業をする際にも、ある程度の知識が必要になります。

たとえば、アプリケーションはコンテナで動いているのですが、Kubernetesではコンテナはpodという単位で管理されていて、podが載っているnodeはAWS管理なんですよ。ですので、nodeのスケーリングなのか、podのスケーリングなのか、判断する知識が必要になります。どこで何を管轄しているのかを把握できないと、扱うのは難しいかもしれません。

nekottyo: これまでは、新しいサービスはEKS側でつくって、デプロイは内製のGitOpsのスクリプトを用いるという形でした。運用手法としては、変更をしたいPRにコメントを打って、そのコメントにフックしてデプロイを促す仕組みを取っていました。

ただ、人事労務freeeは、関わるエンジニアも多く、プロダクトの規模も大きいのが特徴で、この仕組みがうまく機能しませんでした。同一リソースに対して複数PRからデプロイをすると、 PR単位で内容がコンフリクトする問題が起こったり、管理対象が多いので1デプロイあたりの時間が掛かるようになったのです。

そこで、Argo CDというOSSの活用を検証しています。別のプロダクトでは、Argo CDで運用がスムーズになったので。

hanake: Argo CDを入れると、めちゃくちゃ楽ですね!

最後に、EKSの導入を検討している方に向けて、教訓もしくはアドバイスをお願いします!

hanake: まずは、導入や移行の目的を明確にするのが大切だと思います。準備に手間も掛かりますし、導入作業も大変です。コンテナでスケーリングするアプリをつくりたいなら、ECSという選択肢もあります。なぜEKSなのか?どういったメリットを生み出したいのか?意識すると良いと思います。

nekottyo: hanakeさんに同感です。1クラスタで小さいプロダクトを運用したいケースならKubernetesを使う必要は無いと思います。スケールメリットを受けたい、ログ周りをキレイにしたいなどユースケースを想定して、ECSだと手間が掛かるのでしたら、Kubernetesへの移行を考えるのが良いのではないでしょうか。

イベントの本編はここまでです。この後は「アフタートーク」でより深い技術談議が繰り広げられました。

▶freee Tech Night 次回は5月28日に

「freee Tech Night Online #11 脆弱なサービスを守れ!hardening研修」を開催!

freee Tech Night 次回告知アイキャッチ画像
freee社内で実施したセキュリティ研修を公開!

freee-tech-night.connpass.com

▶今回のイベントのアーカイブ(録画)

youtu.be

freeeアクセシビリティー・ガイドラインVer. 202105.0を公開しました

こんにちは、freeeのアクセシビリティーおじさん、中根です。今年もどこにも出掛けない連休を過ごしました。家でだらだらするのは嫌いではないのですが、さすがにそろそろ飽きてしまいました。

さて、今回もfreeeアクセシビリティー・ガイドラインの更新情報をお送りします。

とはいえ、今回は更新内容が少ないので、今回の更新に関連してfreeeアクセシビリティー・ガイドラインで紹介しているブックマークレットをまとめて掲載します。 そして前回の更新情報でお知らせしたイベントについて、関連資料や当日の動画アーカイブを紹介します。

グレースケール表示のためのブックマークレットを追加

誤字の修正を除くと、今回の唯一の変更はグレースケール表示をするためのブックマークレットの追加です。

これまで、参考情報の「グレースケール表示への切り替え方」では、OSの表示設定の変更を用いてグレースケール表示に切り替える方法を紹介していました。 が、最近Webブラウザーで表示しているページについては、CSSでこれを実現できることが分かりました。 そこで、表示中のWebページをグレースケール表示に切り替えるブックマークレットを新たに追加しました。

Webコンテンツ以外の表示の確認や、このブックマークレットが正しく動作しない環境においては、引き続きOSの表示設定の変更で対応してください。

参考情報に掲載しているブックマークレット一覧

freeeアクセシビリティー・ガイドラインの参考情報で紹介しているブックマークレットが増えてきましたので、グレースケール表示のためのブックマークレットも含めて、現在掲載しているブックマークレットを以下にまとめておきます。

表示中のページをグレースケール表示にする

ウィンドウ・サイズを1280x1024にする

表示中のページを https://validator.w3.org/nu/ に送信する

マウス・ポインターを非表示にする

44x44 pxの4角形を表示する

表示中のページにカスタムCSSを適用する

チェックリストなどを紹介するイベントを開催しました

Ver. 202104.0の更新情報紹介エントリーでもお知らせしましたが、4月9日にチェックリストの使い方などを紹介するイベントを開催しました。 以下にその時の資料などをリンクしておきますので、ぜひ参考にしてください。

引き続きご意見などお待ちしています

今回の変更についても、それ以外の部分についても、ご意見やお気付きの点など、GitHubリポジトリーのIssuesやPull Requestsでお知らせください。

確定申告を乗り越えるDBパフォーマンス改善 - Aurora 移行の舞台裏

アプリケーション基盤開発エンジニアの Nayuta です。私が先日登壇した freee Tech Night Online #9 の様子を簡単にご紹介したいと思います。「確定申告を乗り越える DB パフォーマンス改善」をテーマとし、会計 freee のデータベース移行 (MySQL→ Aurora) についてお話しました。

登壇者達の写真

Nayuta (@NayutaYanagisaw)

  • アプリケーション基盤開発エンジニア、2019年6月に中途入社(写真左上)。
  • ストレージミドルウェアに関する仕組み作りや運用改善を担当。趣味的に MariaDB Server にコントリビュートしている。

Terasawa (@terakoya76)

  • SRE、2017年10月に新卒入社(写真右上)。
  • 人事労務 freee の開発に参画した後、SRE チームでインフラの運用・改善を担当。サービスの運用、開発者のサポート、DB の改善がミッション。

のぶじゃす (@noblejasper)

  • ラジオパーソナリティ、2017年に中途入社(写真右下)。
  • mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee に。入社後はエンジニア→エンジニア採用担当→エンジニアと DevBranding を担当。
  • しゃべりたがり。声が大きい。

レプリケーション遅延が小さな Aurora を選択

nayuta が考え込んでいる写真
大変だったことを思い出しながら話しました

1年で最も負荷の高まる確定申告に向けて、どのような対策を行ったか教えてください。

Nayuta: 様々な対策を行ってきましたが、最も大きいのはデータベースを MySQL から Aurora に移行したことです。

なぜ Aurora に移行したのでしょうか?

Nayuta: Read をスケールアウトできるようにし、負荷を下げたいというのが一番のモチベーションでした。

会計 freee は、freee が提供する中では最大規模のサービスなのですが、サービスの特性上 write がとても多いんです。そのため、Aurora に移行する前はレプリケーション遅延のコントロールが難しく、レプリカをほとんど使えていない状態でした。

いままでは MySQL をスケールアップすることで負荷の増大に対応していたのですが、最近では最大に近いインスタンスタイプを使っていて、後がない状態でした。そこで、仕組み上レプリケーション遅延が小さく、read のスケールアウトが容易な Amazon Aurora への移行を決断しました。

Aurora 以外の選択肢は検討しましたか?

Nayuta: Spanner や TiDB などのいわゆる NewSQL は検討の俎上に上がりました。と言うのも、NewSQL を使えば read だけでなく write もスケールアウトできる可能性があるからです。

しかし、MySQL から NewSQL への移行は構成の変更があまりに大きく、確定申告に間に合わせるのは難しいと考えました。そこで、直近では MySQL と高い互換性を持ち、read のスケールアウトが可能な Aurora に移行することにしたんです。

もっとも、厳密な計測は行っていませんが、write 性能についても Aurora の方が MySQL よりは高いはずです。

いかにして Aurora の性能検証を行ったのか

移行前にどのような検証を行いましたか?

Nayuta: 主眼に据えたのは、本番クエリのリプレイによる性能検証です。会計 freee はかなりのトラフィックがあるサービスで、かつワークロードも非常に多様です。なので、人工的なシナリオに基づいた負荷試験をやるよりは、実際のクエリをリプレイする方がより正確に性能を見積もることができると考えました。

ちなみに、クエリのリプレイには Percona 社製の pt-upgrade というツールを改造して使ったのですが、今思えば独自にツールを開発した方が柔軟性が高かったかなと思います。これは反省点ですね。

どのような試行錯誤がありました?

Nayuta: 一部のクエリで Aurora の方が数倍レイテンシーが高くなるという現象が観測されました。IO が大量に発生しそうなクエリが多かったと記憶しています。このときは一瞬「もう移行は無理かも…」と思いましたね。

それは焦りますね。どのように対処したんでしょうか?

Nayuta: いやー、本当に焦りました。実はその後の調査で、buffer pool size を十分に大きくすれば上の問題は緩和されることがわかったんです。負荷試験のために本番より小さなインスタンスサイズを使っていたので、本番と比べて沢山の IO が発生する状態だったのが原因と推測しています。

また、この問題は本番環境では起きていないようです。実際、本番環境の DB を Aurora に入れ替えた後、主要な API のレイテンシーを監視していたのですが、大きな変動はありませんでした。

運用課題の対策としてクラスター切り替えの仕組みを用意

terasawa が神妙な顔をしている写真
神妙な面持ちで語るTerasawaさん

運用面での検証で苦労したことはありましたか?

Terasawa : マスター昇格のオペレーションの準備が大変でした。会計 freee は、サイズが非常に大きいテーブルが多く、マイグレーションの対象によっては完了までに1日近くかかってしまうものもあるんです。

そういった長時間のマイグレーションに対して、これまでは事前にマイグレーションを掛け終えた DB を別途用意しておき、定期メンテナンス時にアプリケーションからの向け先を入れ替えるマスター昇格を活用していました。

RDS for MySQL ではマスター昇格機能が Managed Service の一部として提供されていましたが、Aurora では内部的な仕組みが違うこともあり、そういったオペレーションをサポートする機能が提供されていません。そのため、こちら側でそこの仕組みを整備する必要がありました。

Nayuta: Percona の pt-online-schema-change を使うという手もあったと思いますが、何でマスター昇格の仕組みを作ったんでしたっけ?

Terasawa : 今回は性能特性の異なる Database Engine への移行ということもあり、移行直後に何かしらの問題が発生した場合、直ぐに切り戻したいと考えていたんですよね。そのため、移行時および移行後の運用双方で利用できるクラスター切り替えによる仕組みを整備することに決めました。

具体的には新旧マスター間で双方向レプリケーションを張って、データの書き込みを同期し、その上で実際に書込み可能なマスターは常に1つのみに制限します。あとは切り替えのタイミングで書き込み可能状態とトラフィックの向け先の切り替えを行うという仕組みを用意しました。

Nayuta: そういえば、3-4年前にの Aurora に移行する目論見はあったらしいんですが、当時はいま言った問題を乗り越えられず中止になったようです。

Terasawa: 我々が入社する前の話ですが、そう考えると3年越しの悲願が達成されたと言ってもよさそうですね(笑)

移行の判断から約2ヶ月で移行を完了

具体的に移行はどのように行いましたか?

Nayuta: あまりに大変すぎて移行時の記憶が飛んでいます…

そこを何とか、思い出してください。お願いします!

Nayuta: そうですね…、2020年の11月に経営陣の GO が出て、12月の中旬に移行したのですが、移行後問題が生じた場合に切り戻すための仕組みや手順の整備がとにかく大変だったと思います。そのあたりは主に Terasawa さんが頑張ってくれました。

Terasawa : 前提として、マスターの負荷が非常に高いので、レプリケーション遅延を考慮した移行手順および切り戻しのシナリオを整えるのに苦労した記憶がありますね。

移行作業自体は無事に済みましたか?

Nayuta: MySQL に戻せる状態を2〜3週間維持して、無事に年末年始も超えられたので、1月頭に移行完了となりました。様々なトラブルを想定して作業に臨みましたが、実際は割とスムーズに行きましたね。

移行してみてどのようなメリットがありましたか?

Nayuta: やはりレプリケーション遅延が小さいのが良いですね。今後負荷が高まった際には、クエリをレプリカに逃がすという選択肢が取りやすくなりました。Write 性能も高く DB 関連のアラートが激減したと思います。Terasawa さんからも何かありますか?

Terasawa : レプリカへクエリを逃がすのもそうですし、Parallel Query の利用など、アプリケーション開発者からも負荷を和らげる取り組みがしやすくなったのはとても大きいと思います。何より無事に移行が完了して、ホッとしています。

のぶじゃす: ぜひ、確定申告の際には『会計freee』を使ってみてください。安定していますよ!

イベントの本編はここまでです。この後は「アフタートーク」でより深いな技術談議が繰り広げられました。

▶freee Tech Night 次回は4月23日に

「freee Tech Night Online #10 人事労務freee、EKS移行」を開催!

freee-tech-night.connpass.com

▶今回のイベントのアーカイブ(録画)

youtu.be

【調査】freee のリモート入社ってどうなの?リモートネイティブの jaxx さんと開発チームのコミュニケーションを探ってみた

みなさんコロナ禍をいかがお過ごしでしょうか。

もう1年近くコロナと戦ってきた私たち。これまで色んな知見は溜まってきたけれど、コミュニケーションが限られる中での入社受け入れってまだやっぱり難しいですよね

今回はそんなコロナ禍で freee がどんな風に新メンバーを受け入れているかご紹介します。

すぎけんの写真

こんにちは sugiken です。
2019年に新卒入社し、会計 freee の開発チーム(愛称: 地獄チーム)で働いています。

去年の7月に入社した jaxx さんと、チームのマネージャーである him0 さん(ヒモさん)にコロナ禍入社がどんな感じだったかを聞いていこうと思います。

sugiken の顔写真 今日はよろしくお願いします。

him0 の顔写真 jaxx の顔写真 よろしくお願いしま〜す。

him0 の顔写真 対話形式珍しいね。

sugiken の顔写真 真面目な内容なので体裁はポップにいこうかなと。
インタビューするのは初めてなので質問雑だったらごめんなさい。

sugiken の顔写真 (企画したのは良いんですが、すでにちょっと記事を書くのがめんどくさいです。)

コロナ禍の入社のアレコレ

sugiken の顔写真 では早速、去年入社した頃のことから質問していきたいと思います。 僕が jaxx さんのオンボーディングパートナー*1を担当していましたね。

jaxx の顔写真 そうでしたねー。
入社初日に freee Tシャツの棚とドリンクバーとトイレの場所を教わりました。

him0 の顔写真 ん?Tシャツとドリンクバーとトイレだけ?

sugiken の顔写真 はい、衣食住は大事なので、まず真っ先に教えました。

him0 の顔写真 なるほど...

sugiken の顔写真 jaxx さんは入社前にリモートワークに対する不安はありましたか?

jaxx の顔写真 正直なかったですね。前職もリモート始まっていたし、転職活動もリモートだったから。

him0 の顔写真 (企画倒れじゃん)

sugiken の顔写真 なるほど、リモートネイティブ世代ですね。

jaxx の顔写真 世代でくくられたの久しぶりです。

入社1ヶ月目の雰囲気

sugiken の顔写真 入社して1ヶ月はどんな感じでしたか?

jaxx の顔写真 地獄チームがやっていることはすぐキャッチアップできました。
チームが和気あいあいとしたので、Slack でも質問しやすかったです。

him0 の顔写真 お手本のような回答だ。

sugiken の顔写真 him0 さん、こう言われてますけど、リモートだしやっぱり意識してサポートしてたんですか?

him0 の顔写真 いや、才能かな。

sugiken の顔写真 あの、記事にしづらいんで。

him0 の顔写真 はい。もちろんリモートで人を受け入れるのが始めてだったから、手厚くしたつもりではあるかな。

sugiken の顔写真 具体的にどんなことしてましたか?

him0 の顔写真 困っていることはないか、サポートできることはないか、コロナ前の受け入れをイメージして積極的に声をかけるようにしてました。

sugiken の顔写真 him0 さんは優しいですね。

コロナ禍のコミュニケーション

sugiken の顔写真 jaxx さん、 freee に入って人間関係はどうですか?

jaxx の顔写真 会計 freee に関わるエンジニアとは結構知り合えていますね。

sugiken の顔写真 そんなに一緒にプロジェクトやってるとかじゃないですよね。

jaxx の顔写真 会計 freee のエンジニア20名全員が参加する全体朝会で誰がどこで何をやっているのかが何となくわかってきました
あとはプロダクト横断的な委員会活動も色んな人を知れますね。

sugiken の顔写真 なるほど。jaxx さんはフロントエンド委員会に参加していますよね。

jaxx の顔写真 そうですね、そこで人事労務 freee のエンジニアや、普段一緒に働くことのないエンジニアともコミュニケーション取れてます。
出社したらご飯行きましょーとか話してます。

sugiken の顔写真 それ楽しそうですね!

地獄チームのコミュニケーション

sugiken の顔写真 ところで地獄チームと言えば雑談ですよね。
Slack の統計情報によると、bot 系のチャンネルを除くと地獄チームが一番投稿数が多いらしいです。

jaxx の顔写真 入社してすぐ雑談のしやすさは感じましたね。
Slack で何でも書きやすいです。

sugiken の顔写真 みなさん雑談のために意識していることとかあるんですか?

him0 の顔写真 weekly ミーティングの雑談コーナーで何か書きたいから、毎週末違うことをしてネタ探してるかな。

jaxx の顔写真 猫カフェ行ってましたね。

猫カフェに行ったことを報告する him0 さん
猫カフェに行ったことを報告する him0 さん

him0 の顔写真 猫カフェ良かったー。

jaxx さんは何か意識してます?

jaxx の顔写真 僕は疲れてそうな人とか、プロジェクトが佳境な人がいたらなるべく冗談を言うようにしています。

sugiken の顔写真 たしかに、jaxx さんは Meet (ビデオ通話) ミーティングの最初に雑談を仕掛けるイメージ。

jaxx の顔写真 逆に僕が忙しい時もあるので、持ちつ持たれつかなと思ってますね。

sugiken は?

sugiken の顔写真 僕は Slack で何かしらリアクションつけるように意識してます!
見てくれている感って大事だと思うんです。
例えばこんな感じ。

yodaさんの育児抜け投稿に emoji をつける
yodaさんの育児抜け投稿に emoji をつける

sugiken の顔写真 なんでもない投稿だし、リアクションも別に必要ないけど、「行ってらしゃい」的なね。

あ、噂をすれば。

何かを察知してインタビューのビデオ通話に入ろうとする yoda さんの Slack 投稿

yoda の顔写真 こんにちは。

sugiken の顔写真 突然ですけど、雑談のために意識していることありますか?

yoda の顔写真 (ほんとにインタビューされた)
えー僕は流れに乗ってますね。

jaxx の顔写真 盛り上げてくれますよね。

yoda の顔写真 はい、まぁみんなもボケたり面白い話とか、くだらない話ししているので、その流れに乗ってツッコんだりボケたり質問したりしてます。

sugiken の顔写真 yoda さんが聞いてくれてるんで、僕も話しやすいです。

コロナ禍のコミュニケーションで大事なことは

him0 の顔写真 思ったんだけど、地獄チームが雑談多いのは jaxx さんが来たからではないかも。
リモートでも雑談が絶えないよね。

sugiken の顔写真 確かに!!
jaxx さんの入社が決まったから何かをした訳ではないですね。

him0 の顔写真 そうそう。
普段からみんなが気軽に話して笑い合えるのが地獄チームの良さなのかも。

jaxx の顔写真 確かに元からいるメンバーがよくボケるから、ボケて良いんだって気持ちになりましたね。

yoda の顔写真 わかる。

him0 の顔写真 ボケだけなのか。


雑談を絶やさないために

sugiken の顔写真 いやー企画的にとてもよい結論が出た。(ニッコリ

地獄チームは雑談が、和気あいあいとした空気を生んでいたんですね!

jaxx の顔写真 でも”雑談”って難しいですよね。

him0 の顔写真 weekly のミーティングとかで意図的に話すきっかけを作ると、自然と雑談も増えてくるよね。

sugiken の顔写真 どこの猫カフェ行ったのかとか気になりますもんね。

sugiken の顔写真 僕はジャーマネ*2の him0 さんが Slack に times channel(個人用のチャンネル)を持っていないのが良い感じだと思います。
チームのチャンネルで独り言を書くから自然と会話が生まれてる。

him0 の顔写真 地獄チームのチャンネル = 自分のチャンネルくらいに思ってる。
ついついチームチャンネルって業務連絡だけになっちゃうから、積極的にハードルを下げていってる

桜の報告をする him0 さん
桜の報告をする him0 さん

jaxx の顔写真 雑談のきっかけが散りばめられてるんですね。

まとめ

地獄チームの魅力に迫ってみました。雑談が多いと毎日働くのが楽しいです。
コロナ禍での入社時のオンボーディングやコミュニケーションなどを手厚くやるのはもちろんだけど、雑談のきっかけを散りばめることで自然な雑談が増えるのかもしれません。
みなさんも普段の何気ない独り言を、チームに共有してみてはどうでしょうか。

雑談でみんな笑顔!!

みんな笑顔の地獄チーム

*1:freee に早く馴染んでもらうようにサポートする係

*2:freeeにおけるマネージャのこと。単にメンバーの上に立つ者のことではなく、”タレント”であるfreeeのメンバーを叱咤激励し、成長・活躍をサポートする役割のこと。