Cybozu Inside Out | サイボウズエンジニアのブログ

 

オンラインイベント開催ノウハウの共有

はじめに

こんにちは、Necoプロジェクトsatと申します。

サイボウズは先日Japan Rook Meetup #2というイベント(以下、本イベントと記載)を複数企業合同で、かつ、オンラインで開催いたしました。オンラインイベントの開催が盛り上がっている昨今、本イベントの開催によって得た知見を読者のみなさまに共有しようというのが本記事の目的です。

使用したツールと配信形式

本イベントはオフラインイベントでよくある形式の、次のようなものでした。

  • 20分のセッション(質疑あり)が3本
  • 10分のLT(質疑なし)が1本

このようなイベントを以下のようなサービスを使って開催しました。

  • twitter: 普段の運営メンバ(発表者含む)の連絡のため。ダイレクトメッセージ機能を使う。
  • connpass: 勉強会支援サービス。開催日時やコンテンツなどの告知に使う。
  • zoom: ビデオ会議サービス。チャットも可。司会や発表者が喋って、その様子を録画するために使う。
  • youtube live: 動画配信サービス。zoomによって録画した動画を一般参加者が見るために使う

配信時の様子を簡単にあらわした図を以下に掲載しておきます。

f:id:cybozuinsideout:20200401162220j:plain

オンラインイベント開催に使用できるツールの組み合わせはいくらでも考えられますが、本記事では我々が実際に使った上記組み合わせを前提として話を続けます。これらを選んだ理由は、過去にこの組み合わせでオンラインイベント開催をした実績を持っている社員がいたことです。

個々のツールの使い方については本記事の対象外とします。

ノウハウ集

本節ではいよいよノウハウを紹介いたします。チェックリストのように使えるほうがみなさまが利用しやすいと考えたため、普通の文書を書き連ねるのではなく、列挙形式で紹介いたします。

  • 前節において述べたように関係者が喋るツールと参加者にその内容を配信するツールを分ける。参加者全員が互いにzoomの使い方を熟知して、かつ、見知った仲であれば全員zoomでもいいかもしれない。しかし、そうでない場合は予期せぬトラブル*1を避けたいため、発言できる人の数を絞っておきたい。
  • 質疑にはtwitterを使う。参加者には特定ハッシュタグ(本イベントの場合は#japanrook)で質問をつぶやいてもらって、運営がそれを拾って発表者が回答する。このとき次のことに注意する。
    • 質問チャネルが複数あるのが避けたいので1つだけに絞る。本イベントの場合はtwitterに統一した
    • twitterの画面を直接配信するのは避ける。理由は、かつて同じようなことをしたときに悪意をもって不適切な書き込みをした例を見たことがあるため。そうなった場合は後日録画したものを配信するのが面倒、あるいは不可能になる。
    • とりあげる質問はなるべく意味が複数にとれない答えやすいものにする。理由は参加者と「質問の意図は合っていましたか」のようなやりとりをするのが困難なため。なぜかというと、zoomで喋った内容がyoutube liveで配信されるまでには長いラグがあるため。たとえば本イベントの場合は30秒程度遅延が発生した。
  • 開始時刻にいきなりはじめるのではなく、数十分程度前からくらい「XX時から始まります」ということがわかる一枚スライドを出しておく。休憩時にも休憩中であることがわかるスライドを出す
  • 関係者が喋る際に顔を出すかは個々人に任せる。youtube liveに後々まで記録が残ることは周知する
  • 喋っていない人はミュートする、かつ、顔を出さないようにする。聴衆の気が散るのを避けるのが目的
  • 関係者間の業務連絡にはzoom chatを利用する。twitter上の質問をひろって記録しておくのにも便利
  • イベントは基本的には次の流れにする
    1. 司会の画面を共有して喋る。最後にスピーカーに振る
    2. スピーカーが画面を共有して喋る
    3. 喋り終わったらスピーカーの画面を共有したまま質疑応答
    4. スピーカーに画面の制御を戻して1に戻る
  • すくなくとも前日までには全員が流れを確認するリハーサルをするとよい。リハーサルは一度に全員でやる必要は無い。たとえば本イベントの場合は3回に分けた。リハーサルをする理由は次の通り。
    • 関係者が当日zoomの操作に手間取ることによる時間の浪費、最悪の場合は発表の断念を避けるため。たとえばzoomはOSによってはセキュリティ機能により画面共有に設定が必要なことがある。
    • オンラインイベントと異なり聴衆の反応が一切わからないという状態を体感して、慣れるため*2
  • 当日も運営やスピーカーは開催時刻の少し前に集まって接続確認などをするほうがよい。ちょうどオフラインイベントでスクリーンの表示確認をするようなもの

これらが唯一絶対の正解というつもりはありませんが、それなりにうまく回ったイベントのノウハウのひとつと考えていただければいいかと思います。

実際の配信結果

配信の模様は録画した上で公開していますので、ぜひごらんください。完璧に、とはいきませんでしたが、それなりに形にはなったかと思っています。

youtu.be

おわりに

本記事が「こんな状況でもなんとかイベントをしたい」という思いを持ったかたがたに役立つことを願っています。それに加えて、人と人との直接のやりとりが難しい中で、なるべく技術者同士で知見を共有する機会が増えることを願っています。

最後になりますが、本イベントの開催に多大なるご協力をいただいた運営メンバー、および発表者のかたがたに感謝の言葉を述べて、本記事を終わりにしたいと思います。

*1:たとえばミュートにしていない人がいて音がおかしくなる、など

*2:個人的には聴衆の反応を見て適宜アドリブを入れるやりかたを好むため、相当やりにくかった

 

Claraチームの開発・テストプロセスについて

こんにちは、ClaraチームでQAをやっている @ayuay46 です!

この記事では、Claraの概要と、Claraチームでの開発・テストプロセスについてご紹介します。

Claraの誕生秘話

Claraとは、AWS版Kintoneが使用する米国向け販売管理システムのコードネームです。

AWS版Kintoneのリリースまでは、日米ともにKintoneは自社クラウド cybozu.com を利用しており、販売管理システムも日本で作った共通のものを利用していました。

そのため、米国のマーケティングチームが現地に特化した新しい施策や売り方をしたい場合に、都度日本の開発チームに仕様変更・機能追加を依頼する必要がありました。

また、開発チーム側も日本向けと異なるロジックを実装する必要がありコストがかかっていました。

そのような問題を解決するために、米国向けのKintoneがAWSに移行するのに合わせて、販売管理のグローバルSaaSを利用した米国独自のシステムを構築しました。 国内データセンターからだとレイテンシが大きいため、AWSを利用しているYakumoを基盤としています。

Yakumoの詳細については他記事を御覧ください。

blog.cybozu.io

Claraの開発プロセスについて

Claraチームではアジャイル開発をしています。

f:id:cybozuinsideout:20200317143605p:plain
Clara開発プロセス

1週間スプリントで、要件ごとに上記の図のようなイメージで開発しています。 ※「相互レビュー」については後述。

要件は、販売管理システムを実際に利用する米国の現地メンバーと検討していくのですが、この段階からQAも入っています。 最もよく使われる操作方法はどういったものか、どういった手順をテストに落とすべきか、この段階から知ることができます。

また、リリース作業は、各要件のテストの進捗を把握しているQAが行っています。 回帰テストは自動化されているため、高速にリリースすることができます。

テストポリシー

Claraは外部サービスと多く通信するのですが、外部サービスの挙動についてはテスト対象としていません。

テストの範囲を明確に「自社製品」に限定することで、外部サービスを過剰にテストしないようにし、リリース速度の低下を防いでいます。

もちろん、手動でテストを実施するときは外部サービスを触るので、そこで外部サービスの仕様変更やバグに気づくことはあります。

また、テストはなるべく自動化しています。 テストピラミッドの考え方を参考にして、Large/Medium/Smallに分割しています。

Largeテスト

各サービスが結合された状態の挙動、かつ、ユーザーが最も利用すると想定しているケースをLargeテストとして実装しています。

Largeテストの範囲は「ハッピーパス」と呼ばれる正常系の代表ケースが主です。 他の細かなパターンはMediumテストやSmallテストでカバーしています。

f:id:cybozuinsideout:20200317143649p:plain
Largeテスト

Mediumテスト

APIテストがこれに当たります。Largeテストとは異なり、Mediumテストでは外部サービスと通信する箇所はモックを作成しテストしています。

f:id:cybozuinsideout:20200317143713p:plain
Mediumテスト

Smallテスト

いわゆるユニットテストです。 1つのクラスやメソッドなどのロジックのテストをします。 またフロントエンドのテストもSmallテストとして分類しています。

f:id:cybozuinsideout:20200317143751p:plain
Smallテスト

相互レビュー

ClaraではDevやQAという立場に関係なく、チームとして製品の品質を高める活動をしています。 活動の一つの例として、DevとQAがお互いの成果物をレビューします。

QAが作成したテストケースをDevがレビューし、過不足がないかを確認します。 基本的にはテストは自動化するのですが、自動化が難しい箇所などがあればQAが手動でテストを実施します。

また、テスト設計をもとに、QAはDevが実装したテストコードに過不足がないかを確認します。 不足しているテストは追加で実装します。 その場でDevとQAでモブプログラミングするか、または、Devが代表的な1ケースのみを実装しそれを参考にしてQAが実装します。

まとめ

Claraチームでは、DevとQAの境目が少しずつなくなってきたなと実感しています。

一方で、製品コードを見る機会も増えたため、テストがホワイトボックスになりすぎないよう気をつけていきたいと考えています。

テストプロセス改善も随時進めて行く予定です。 テストピラミッドの考えを参考にしてテスト自動化の方針を決めていましたが、開発が進みテストが充実してきた今、テストポリシーに沿えているのか振り返ったり、テストポリシー自体を見直したりもする予定です。

 

Folding@homeを通じてCOVID-19治療薬の発見に貢献します

こんにちは。Neco@dulltzです。

サイボウズでは、オンプレミス機材の一部を活用してFolding@homeによるCOVID-19のタンパク質構造予測に貢献することにしました。

ご自身で動かしてみたいというかた向けに、我々が使っているKubernetesマニフェストも記載しているのでぜひご覧ください。

Folding@homeとは

みなさんはFolding@homeを知っていますか?

Folding@homeとは、タンパク質構造予測に必要な計算処理を、世界中の有志による分散コンピューティングで推進するプロジェクトです。 10年以上昔の話になりますが、PlayStation 3を活用したプロジェクトを覚えている方も多いかと思います。

最近Folding@homeのブログにて、COVID-19の治療薬開発に使われるタンパク質構造予測を行っているという旨の記事が公開されました。

これを受け複数の企業がFolding@homeへの貢献、あるいは貢献の呼びかけを表明しています。

サイボウズもFolding@homeに参加中です

サイボウズもオンプレミス機材の一部を利用し、Folding@homeに参加しています。

2020年3月16日現在、24CPUコアのサーバ105台でFolding@homeのクライアントを実行しています。

デプロイ方法

今回の用途に使える機材はKubernetesノードであったため、Folding@homeのクライアントはPodとして実行することにしました。

KubernetesマニフェストやDockerイメージは https://github.com/richstokes/k8s-fah を参考にし、 それを元にいくつかの変更を加えています。

  • クラスタサイズに合わせてPod数を変えたいため、DeploymentではなくDaemonSetを使用する。
    • ただし、他のPodがスケジュールされるとPreemptされるようにPriorityClassresources.requestsを調整する。
  • PodSecurityPolicyによってread-onlyなrootファイルシステムの使用を強制しているので、Folding@homeのクライアントが書き込むパスにemptyDirをマウントする。
  • PodSecurityoPolicyによってrootユーザによる実行を禁止しているので、実行ユーザを変更する。
  • 万が一クラスタ内で不要な通信が行われるリスクに備えて、CalicoのNetworkPolicyでFolding@homeのPodがアクセス可能な範囲を制限する。
  • resources.limitsに指定したコアはすべて使って構わないので、 --power=full オプションを指定する。
  • 2020/04/01追加: 1クライアントあたりのCPUコア数が多すぎると "No WUs available for this configuration" というログメッセージとともにアイドリング状態に入ってしまうので1クライアントあたりのCPUコア数を減らす。具体的にはDaemonSetの数を6個にして、それぞれのPodに割り当てるCPUコア数を搭載数の1/6にする。

具体的なマニフェストは以下に記載しています。

github.com

まとめ

サイボウズのFolding@homeへの貢献と、Folding@homeクライアント実行方法について説明しました。
Kubernetesノードがあればすぐに参加することができるので、もし余ったノードがある方はぜひ参加してみてください。

COVID-19にまつわる状況が一刻も早く改善することを願っています。

 

OSSへの貢献ノウハウ: ユーザサポート編

はじめに

こんにちは、Necoプロジェクトsatです。本記事は先日公開した以下の記事の続編です。

blog.cybozu.io

上記の記事ではOSSプロジェクト全体を盛り上げる手段を次のように紹介しました。

プロジェクト全体を盛り上げるには例えば次のような方法があります。

  • 自社に直接関係が無いissue/PR発行、レビュー
  • ユーザサポート
  • イベントでの発表

本記事では、このうちのOSSにおけるユーザサポートとはどのようなものかについて、Rookにおいて発生した実際の問題を例として書きます。この問題の根本原因はカーネルだったためにカーネルの用語がいくつか出てきますが、あまり気にせずにフィーリングで読んでいただければとおもいます。本記事で一番伝えたいのはカーネルの技術的な知識ではなくOSSにおけるユーザサポートのノウハウです。

Rook、およびRookが管理するCephについては過去記事をごらんください。

blog.cybozu.io

blog.cybozu.io

きっかけ

筆者がKubeCon North America 2019に参加していたときに、Rookのgithubにおいて気になるissueを見つけました。

github.com

まずはこのissueがどういう問題かについて書きます。前提知識として、Rookが管理するCephクラスタは、多くのノード上にCeph用のサービスを動かしています。このうちのOSDというサービスが動いているノードが、特定の条件を満たすとCPU使用率が100%になり、かつ、その後にノード全体が無反応になるというのがこの問題です。

業務システムでこのような問題が発生した場合は大きな問題になりますし、かつ、同じ問題に遭遇した人は数人いたため、極めてレアなケースというわけでもないことがわかりました。

さらにissueを読み進めると、問題発生時には次のコメント内の画像のようなLinuxカーネル(以下カーネルと記載)のログが出力されることがわかりました。

github.com

ここで重要なのは次のメッセージです。

... task XX blocked for more than 120 seconds.

筆者はかつてカーネルの開発をしていたこともあり、このメッセージはユーザプロセスではなくカーネルの問題が起きた場合に出ることを知っていました。もう少し詳しく言うと、カーネル内の排他制御の問題で、特定のプロセスが長時間、あるいは永久に動けない状況になっていたことを示しています。

しかしながら上記のコメントの後の流れを見たところ、Cephを含めたユーザプロセスの問題について色々と議論しているものの、カーネルの話はまったく出てきていませんでした。このことから、このissueの関係者にはカーネルに詳しい人がいないのだろうということがわかりました。

ここまでわかった段階で、以下のような理由によって筆者はこのissueの解決に協力することを決めました。

  • Rookを使っているからにはプロジェクトに貢献して盛り上げたい*1
  • 自分の知見を活かせる、かつ、自分が協力しないと恐らく先に進まない
  • 現在Necoではこの問題に遭遇していないが、いずれ遭遇するかもしれない。その場合の影響が大きい

どのような貢献をするか

問題の解決に協力するとして、具体的にどのようなことをするかも考えなければいけません。このようなときに陥りがちな罠は、とにかく何でもかんでも貢献しようと勇み足になって全てを自分でやろうとしてしまうあまり、本業をおろそかにしてしまうことです。

筆者はこの罠に陥らないように、自分のやることを以下のように定めました。

  • 問題に遭遇した人から必要な情報を収集する
  • 上記の情報を使ってカーネル開発者とやりとりする
  • 得られた情報をissueにフィードバックする
  • 問題を回避できればそこまでで終了とする
  • カーネル修正が必要になった場合は積極的には手を出さない、あるいは自分の環境で遭遇するまでは低優先度で取り組む

企業の製品サポートでいえば製品内の不具合の直接調査する役割ではなく、関係者を巻き込んで問題解決を推進する取りまとめ役といえるでしょう。

調査の流れ

情報収集

問題がカーネルにあるとわかったものの、カーネルの中のどこに問題がありそうかを明らかにするために、もうすこし深掘りをすることにしました。具合的には、次のコメントにおいて、問題はカーネルにあることを述べた上で、問題に遭遇した人々に情報収集を依頼しました。

github.com

各情報の採取意図については本記事の範囲を超えますので、必要であれば上記コメントを読んでください。

幸いにも上記の依頼に対していくつかの反応がありました。そのうち最も有用だったのは以下のコメントです。

github.com

このコメントによって、問題発生時のカーネルのバックトレースの情報が得られました。

[51717.039319] INFO: task kworker/2:1:5938 blocked for more than 120 seconds.
[51717.039361]       Not tainted 4.15.0-72-generic #81-Ubuntu
[51717.039388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[51717.039426] kworker/2:1     D    0  5938      2 0x80000000
[51717.039471] Workqueue: xfs-sync/rbd0 xfs_log_worker [xfs]
[51717.039472] Call Trace:
[51717.039478]  __schedule+0x24e/0x880
[51717.039504]  ? xlog_sync+0x2d5/0x3c0 [xfs]
[51717.039506]  schedule+0x2c/0x80
[51717.039530]  _xfs_log_force_lsn+0x20e/0x350 [xfs]
[51717.039533]  ? wake_up_q+0x80/0x80
[51717.039556]  __xfs_trans_commit+0x20b/0x280 [xfs]
[51717.039577]  xfs_trans_commit+0x10/0x20 [xfs]
[51717.039600]  xfs_sync_sb+0x6d/0x80 [xfs]
[51717.039623]  xfs_log_worker+0xe7/0x100 [xfs]
[51717.039626]  process_one_work+0x1de/0x420
[51717.039627]  worker_thread+0x32/0x410
[51717.039628]  kthread+0x121/0x140
[51717.039630]  ? process_one_work+0x420/0x420
[51717.039631]  ? kthread_create_worker_on_cpu+0x70/0x70
[51717.039633]  ret_from_fork+0x35/0x40

どうやらXFSファイルシステムが関係していそうだということがわかりました。さらに、この問題はこれまでにXFSでしか発生実績がなかったことより、筆者はXFSが有力な容疑者の一人だとみなしました。

カーネル開発者への相談

ここからやるべきことは既存障害調査、およびXFS開発者への相談です。前者は自分だけでもできるので、まずはこちらからやりました。具体的には次のようなことをしました。

  • XFS開発メーリングリストの過去ログを上記トレース内の特徴的な単語を使って検索した
  • カーネルのコミットログを上記と同様に検索した

しかし、この問題に関係ありそうな議論、あるいは修正は見つかりませんでした。

github.com

続いてXFS開発メーリングリストでXFSの開発者達に相談してみることにしました。

ここで問題になるのが、報告するときに提供すれば好ましい情報がいくつか足りていないことでした。たとえば再現手順や最新カーネルにおける再現確認などです。ただし、次の事情によって、これらの情報を得るのは短期的には難しいと判断しました。

  • OSSのissueにおける情報収集依頼は商用製品のサポートに比べて要求した情報が得られる確率が低い。報告した後に無反応になる人も多い
  • 誰も再現方法を見つけられていない。ゆえに筆者の環境において最新カーネルでの再現も難しい

この手の情報が足りないと報告そのものが無視されがちなのですが、やむをえず、できる限りの情報を添えて、XFS開発メーリングリストに相談しました。幸いにもこの後すぐにXFSの元メンテナであるDave ChinnerさんがCephによってブロックデバイスを提供するkrbdドライバが怪しいということを教えてくれました。

この後はすぐにDaveさんのコメントを反映してCephのカーネル部分の開発者メーリングリストに相談しました。幸いにも、こちらの相談もCephカーネル機能のメンテナの一人であるIlya Dryomovさんからすぐに回答がありました。彼にはこの問題がkrbdとXFSの相互作用によって発生すること、既知のものであること、修正見込みであること、および回避策があることを教えていただきました

結果の報告

この結果をもとに、筆者はもとのRookのissueに、根本原因、回避方法、修正見込みについてコメントをしました。

github.com

このようなときに注意すべきなのはCeph開発メーリングリストで教えてもらったカーネルの言葉をそのまま使わずに、Rookユーザにわかるように書くことです。これはサポート技術の基本ともいえます。

ここまで書いたところでRookのメンテナの一人であるSébastien Hanさんから提案を受けて、Rookのよくある問題を掲載するドキュメントにこの件について書いたところで、このissueはcloseとなりました。

github.com

おわりに

本記事ではみなさまに次のようなことをお伝えしました。

  • OSSのサポートとは具体的にどのようなものか
  • 一般的なサポート技術、および、OSSのサポート技術

みなさんもお使いのOSSにおいて何かしら貢献できそうなことがあり、かつ、リソースに若干余裕のあるかたは、やってみて、OSSを盛り上げてみてはいかがでしょうか。きっとよい経験になると思いますよ。

*1:サイボウズにはOSSに積極的に貢献するよう努めるというポリシーがあります

 

リモート・モブプログラミングという働き方

こんにちは!kintone開発チームの太田 (@kigh) です。 この記事では、自分のチームで2年以上続けているリモート・モブプログラミング(以下「リモート・モブ」)について、 進め方の具体例や所感、実際にやる上でのTipsを紹介したいと思います。

リモートワークが急速に普及する中、リモート・モブは働き方の選択肢の一つとして存在感を増してきていると思います。 この記事から少しでも参考になる点が見つかれば幸いです。

リモート・モブプログラミング

この記事では、テレビ会議システムなどのツールを使いつつ、物理的に離れたチームでモブプログラミングをすることをリモート・モブと呼びます。

現在、kintoneの新機能開発メンバーは6拠点のオフィスに分散し、また多くのメンバーがカジュアルに在宅勤務を活用するリモートチームとなっています。 また2018年から2年以上、全ての設計・実装タスクを原則モブプログラミングで行っています。 チームメンバーは同じ場所にいるわけではないので、よくイメージされるような一つのPCを囲んでのモブプログラミングはできません。 そのためテレビ会議システムを使い、画面共有機能も活用して開発を進めています。

kintoneチームに限らず、サイボウズでは少なくとも10以上のチームがリモート・モブで開発を進めています。

自分のチームでのやり方

リモート・モブの一例として、自分のチーム(東京2名・大阪2名の4人チーム)でのやり方を紹介したいと思います。

まずイメージしやすいよう、スクリーンショットで作業の様子を紹介します*1。 このように、IDEを画面共有しつつ、議論しながら実装を進めます。 ふりかえりなども同様に、議事録などを画面共有しながらやっています。

リモート・モブ作業中のスクリーンショット。IDEのウィンドウが大きく画面共有され、その脇に各メンバーの顔のカメラ映像が並んでいる
リモート・モブ作業中のスクリーンショット

より具体的な進め方は以下の通りです:

  • テレビ会議に接続してデイリースクラム開始→終わったらその流れでモブプロ開始
  • 基本は全ての作業をモブで進める
    • 適宜ドライバー(=テレビ会議で画面共有して、キーボードをタイプする人)を交代する
      • 場合によるが、最短7分ローテーションで
      • コードが中途半端でも気にせずコミット、後で整理する
    • ただし調査や定型的タスクなど、個人単位でやった方が効率が良いと判断した場合は、再開時間を決めて、一時的にモブを解散することも
  • ミーティング・勉強会などチーム外での仕事がある人は、自由に離脱・合流してよい
    • 1〜2人抜けても、残った人でモブは続行する
  • 疲れたら休憩を取る
  • チーム外の人と相談が必要になったら、随時テレビ会議に接続し、モブに加わってもらう
    • 常時モブをしているのは実装エンジニアだが、試験設計はテストエンジニアと、仕様やスコープ調整などはプロダクトオーナーと、文言検討はライターと一緒に、など
  • 16時になったらデイリーふりかえりをして、以降は自由時間
    • 個人で勉強したり、メンバーに質問したり、細々した仕事を片付けたりなど自由に
    • 新しい試みやチャレンジは個人単位で始めることも多いので、この自由時間も重要

なお、サイボウズ社内でもチームによって色んな文化があり、リモート・モブのやり方も異なっています。 また、同じチーム内でもやり方は随時変化しています。 そのため、ここで紹介したのはあくまで一例です。

リモート・モブに思うこと

2年以上リモート・モブをする中で、メリット・デメリットどちらもわかってきました。 今の所、私たちにとってはメリットが上回っており、「常に一箇所に集まれるわけではないチームにとって、もっとも良い働き方なのでは」と感じています。 ここではメリット・デメリットを中心に、リモート・モブに関する自分の所感をまとめたいと思います*2

良いところ

拠点間および在宅メンバーとの情報格差を最小化できる

これが今の所、一番良い点だと思っています。 ある程度の規模のプロダクトの開発をチームで進める上で情報格差は敵です。 悪いことに、リモートチームではどうしても、情報格差が生まれる確率は高まります(特に多数派の拠点・場所がある場合)。

例えば「最近決まった〇〇の設計について、他の人は知っているけど、自分は知らない...」という状況を想像してみてください。 直近の作業の遅れにつながることはもちろんですが、それ以上に、仕事に対するモチベーション低下、さらにはキャリアに対する不安にまで発展することもあるのではないでしょうか。

リモート・モブは、物理的な場所・属人化に伴うサイロという2つの壁を超えて情報格差を減らすことができる方法です。 自身の経験でも、個人作業からリモート・モブへ移行したことで、情報格差やそれに伴う不安が劇的に改善しました。

新メンバーの受け入れに強い

新しいメンバーにはチームへのオンボーディングをして、スムーズにジョインしてもらうことが重要ですが、 リモートチームの場合、その負荷が特定のメンバーに集中したり、あるいはうまく進められなかったりすることがあります。 リモート・モブなら、仮想的に場を共有していることが助けになります。

これは最近の実話なのですが、自分が勤務する大阪オフィスに新たに中途メンバーが入社してくれて、チームメンバーが自分1人から3人に増えました。 このような場合、もしリモート・モブ体制がなければ、新メンバーのガイダンスや教育のために、自分がしばらく休まず出社することが必要でした。 しかし今回、新メンバーには最低限のガイダンスをした後はモブに加わってもらうことで、新メンバーが周りの人に相談しやすい状態を自然と作ることができました。 結果、自分がやむなく休みを取った場合でも、何も問題は起きませんでした。

弱いところ

一方で、物理的に場所を共有していないために「ここは弱いな」という点もあります。

抽象的な議論がしづらい

プログラミングもそうですが、その前の要求の整理や設計などの段階で特に感じることです。 具体的には、「対面で話せばもっとすぐ伝わるのに!」とか「クラス図などをホワイトボードに手書きしたいが出来ない!」といったケースです。

対面よりも伝えづらい、というのはどこまでも付いて回る話ではありますが、議論する相手との信頼関係やコンテキスト共有を高めることで改善できる部分はあります。

また、ホワイトボードについてはツールでの改善が可能です。私たちの場合、電子ホワイトボードなどの導入にはまだ至っていませんが、プレゼンツールで描いた図やテキストエディタを画面共有することで案外なんとかなっています。

チームビルディングの速度が遅い

作業中は常にテレビ会議でつながっているとは言え、拠点が別だとランチや飲み会などはもちろん一緒に行けません。 また実際に顔を合わせて喋っていないため、心理的な距離感も縮まりづらい傾向はあると思います。

これには、意識的に雑談の時間を作ったり、出張して実際に会うことなどがとても効果的で、実際にそのような機会を作るよう心がけています。

過去の悩み

少し余談になりますが、コミュニケーションの円滑さという面で、やはり「テレビ会議は対面に敵わない」という実感は正直言ってあります。 そのため、「頑張ってリモートチームを作り上げなくても、拠点ごとに独立した体制を作った方が良いのでは・・・」と悩んだことが何度かありました。

しかし、昨今の在宅勤務の広まりから、リモートチームとして開発できることはほぼ必須になってきていると思います。 実際に最近、新型コロナウイルスの影響で、メンバーの大半が在宅勤務を選択していますが、プロダクト開発は混乱なく続けることができています。 こうした経験から、拠点が複数に分かれているかどうかによらず、リモートチーム前提で良いチーム体制を作ることは重要で、その一つの解がリモート・モブである、と自信を持って思えるようになりました。

リモート・モブTips集

記事の最後では、私たちがふりかえり等を経て辿り着いたTipsのうち、自分が気に入っているものをいくつか紹介しようと思います。

コミュニケーションの快適さ(ツール)にこだわる

通常のモブと比べたリモート・モブの弱点は、コミュニケーション帯域の狭さです。 経験のある方もおられるかもしれませんが、複数人でテレビ会議を使ってうまく議論するのは単純にスキルが必要で、ある程度時間をかけて上手になっていきます。 もしテレビ会議で会話がスムーズにできないと、ツールのせいでうまくいかないのか、自分たちのスキルのせいでうまくいかないのかが切り分けられません。 なので、ツールにこだわる価値はあると思っています。

実体験としては、あるツールを使ってリモート・モブをしていると、声を発してから相手に伝わるまでのラグが数秒に達することがありました。 その結果、発話の衝突がしばしば起きて、話がしづらい状況となりました。 細かい話のようですが、テレビ会議だと音声がコミュニケーションのほぼ全てなので、そこがギクシャクするのは結構厳しい状態です。 結果的に、ラグが短くなる別ツールに乗り換えて解消しました。当たり前品質大事。

カメラ表示をオンにする

メンバーがシャイでなければ、カメラを用意して顔を見えるようにすると良いです(もちろん見せない自由も尊重します)。 自分が話しているときに、頷きなどのリアクションが見えるか見えないかは、思ったよりも心理的な安心感が違います。 あとは、顔が見えるとより親近感も増しますね。

意識的に休憩する

普通のモブプロよりもリモート・モブの方が、休憩を忘れがちになりました。 他のメンバーが疲れていても気づきづらいからかもしれません。

休憩しないと視野が狭くなって、普段なら気づける解法にも気づけなかったりします(これは個人作業でも同じはず)。 肩も凝るし、強い気持ちで休憩を取るのが良いです。休憩タイミングをルールで決めるのも良いです。

抜けていた人が戻ってきても「一旦共有しますね〜」をやらない

ミーティングなどで離脱していた人が戻ってきたとき、親切心からその間の進捗を共有することがあります。 ですが、意外に共有しなくてもなんとかなることが多いです(少し作業を見ていたり、メモがあればそれを見るだけで十分キャッチアップできる)。 むしろ離脱・合流を気にせずモブの流れを維持する方が、離脱していた人も気を遣わないというか、快適に作業を進められました。 もちろん新メンバーがいる場合など、特定のメンバーが置いてけぼりになっていないか、質問しやすい雰囲気かなどは常に気をつけています。

「モブプロ宣言」を作ってみる

ちょっと変な標題ですが、要は「何のためにリモート・モブをやっているのか」を言語化してみる、ということです。

自分のチームでは、モブプロをしばらく続けていると、「ずっとモブプロやっていて良いのか?」といった意見がメンバーから湧き上がってきました。 これを議論するには、モブプロをやる目的がメンバー間で共有されている必要がありますが、最近までその言語化はしてきませんでした。

そこで、有志メンバーでワークショップをして、「モブプロ宣言」として言語化してみました。その成果物がこちらです:

【kintone開発チーム・モブプロ宣言】
私たちkintone開発チームは、 
 1. チームメンバー間での知識共有・学習の機会を増やす
 2. フロー効率を優先し優先順位の高いPBIから完了する
 3. 必要なときに様々な職能の人にすぐ議論に加わってもらう
 4. リモート・在宅開発体制でも問題なく開発を行う
 5. 会議・休暇・兼務などで抜ける人がいてもチームとしてスムーズに作業を進める
ことによって
 学習・品質・属人化防止・働きやすさ・楽しさ・安心感
というメリットが得られるため、モブプログラミングを実践している。

一度言語化してみることで、自分たちの仕事のやり方への納得感が増した感じがしますし、気づいていなかったメリットに気づくこともできました (例えば自分は「楽しさ」という軸は意識していませんでしたが、言われてみれば確かに、と思わされました)。 逆に、ここに当てはまらないようなタスクであればモブでやらなくても良いよね、という話もできるようになりました。

おわりに

私たちは、仕事時間の多くをリモート・モブで回しています。 そのためリモート・モブは、個々のタスクの結果だけでなく、モチベーションや個人のキャリアにまで、幅広い影響があると感じています。 少し大げさに言えば、リモート・モブは一つのプラクティスである以上に、働き方そのものに思えます。 このやり方がずっとベストかもちろんわからず、常に考え続ける必要はありますが、現時点では多くのメリットがある働き方だと思い実践しています。

この記事が何かの参考になれば幸いです。それでは、Happy remote mob-programming!!

*1:ちょうど、この記事を執筆している2月27日付で、一部拠点は原則在宅勤務とする弊社プレスリリースが出ました。このスクリーンショットは、その社内向け通達が出る数時間前に撮影したものです。

*2:ここでは「リモート」と「モブ」の両方を前提とした事項に絞って書きます。単にモブと個人作業とを比較したメリット・デメリットなども含めると、長くなりすぎてしまうためです。