Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか

KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。

ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。

リモートワークとアジャイル開発

HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team での情報共有はチームビルディングにおいて重要な一幕だった･･･という話も Rebuild でしたっけかな。

ただ、アジャイル開発という文脈でいったときに「どうするべ?」ということが幾つかあった。

その際たるものが「全員同席」。まあ全員同席はアジャイルで必ずやらなければいけないこと (･･･そもそも必ずやらなきゃいけないことなんてないとは思うんだけど)、ではないのだけど、リモートワークだとどうしてもその辺りのコミュニケーションが希薄になりがちで、チームビルディングという観点では課題だなと思っていた。

例えば、ちょっとした仕様の確認とか、あるいは雑談のために Google Hangout を使ってオンラインミーティングしようとすると HipChat で以下の様なやりとりが行われたりする。

naoya 「@ngs ちょっと確認したいことあるんだけど Hangout いい?」
ngs「なんでしょう」
naoya「あのモジュールのあそこの実装なんだけど」
ngs「あー、あそこは @funami がよく知ってます」
naoya「なるほど、じゃあ @funami も Hangout」
naoya「@funami さんーん」
naoya「･･･いないね」
ngs「いないですね」
funami 「あ、ごめん、チャットみてなかった」
naoya 「おうおう、じゃ Hangout はじめましょ」
ngs 「url どこですかー」
naoya 「ちょっと待ってね･･･はいこれ」
funami 「なんか You're not allowed っていわれる」
naoya 「あれれ」

これで 10分かかる。経験がある人はわかると思うが、これ、実際はなかなかにイライラする。誰が悪いわけでもないのでそのイライラをぶつける先もない。

これがリモートワークでなければ、その場でいるかどうか確認してその場でちゃちゃっと話合って終われるんだけど、リモートだとなかなかそうもいかない。そしてこの 10 分がめんどくさいので、チャット上でやりとりして実際には10分話せば終わることを30分も1時間もかけてやりとりしたりする、なんてことになりがちである。(結果的にテキストで記録が残る、というところはよいのだけど)

Sqwiggle

そんな折り、たまたま 8 Helpful Online Tools To Keep Your Company On Track という記事を読んだ。これは Buffer を作ってる人たちがどうやってリモートワークしてるかという話。Buffer はなかなか面白い働き方をしているらしい。

この中で紹介されていた Sqwiggle というツールが、まさに先の問題解決をしてくれた。あるいは、今後してくれそう。

Sqwiggle を起動すると、カメラが有効になってこんな感じで Sqwiggle を立ち上げてるチームメンバーが一覧になる。

Sqwiggle は常にストリームをしてるわけじゃなくて、定期的に画像のスナップショットをサーバーに送ってる。そのスナップショットがときどき更新されて、この一覧がでる。

この一覧にいるメンバーと口頭で何か話したいことがあると思ったらどうするか。相手の写真をタップするだけ。すると、その瞬間からセッションが始まる。セッションをはじめるよという呼びかけみたいなのは一切なくって、タップしたら音がなって、いきなり相手と会話が始められる状態になる。

常時カメラで相手の状況が映し出されてるので、相手がいる/いないの確認がいらないし、Hangout を始める時の招待とか url のやりとりとかそういうのも一切必要ない。会話の途中で、その会話にもう一人追加したいとおもったらその人もタップすれば3人での会話になる。

使用感としては Hangout でのミーティングは会議室に移動してよいしょで会議を始める感じで、Sqwiggle は隣にいる同僚にちょっとちょっと、と話しかけるような感じに近い。

最初 Sqwiggle を使い始めたときは、常時カメラで写されてるということでプライバシーのこととか、割り込みしやすいというのでリモートワークの利点がとかいろいろ心配していたけどその辺は実際やってみると普段はほとんど気にならない。まあ、自分は Sqwiggle を ON にしてるのを忘れて画面の前で着替えをしたことがあるが、致命傷にはならなかったｗそのうち放送事故が起こるかも知れないが、まあそれはそうなったらそのときだ。

どちらかといえば、リモートワークにありがちな、自己管理できなくてついついさぼってしまうみたいな問題をも Sqwiggle は解決してくれるところが非常によい。周りに誰かいる、というような感覚でリモートワークに望めるので適度な緊張感が得られる。怠惰な自分には、それがとてもありがたい。

Daily Standup やスプリント計画、KPT

こんな感じで全員同席で進めていってるときのチーム感は Sqwiggle によって結構解消されつつある。

KAIZEN のワークフローだとリリースデプロイの直前 QA なんかで頻繁にエンジニア同士でも確認事項が発生するのだけど、普段チャットでやってるところ、次回はその辺も Sqwiggle を駆使してコミュニケーションを厚めにやってみようかなんて話をしている。

ちなみにアジャイル開発、というかスクラムでいくと他のプラクティスをどう実践してるかというと、以下の感じである。

Daily Standup は、毎朝時間を決めて固定の Hangout URL に集まるようにしている。Sqwiggle は残念ながら大人数でのリモートチャットをサポートしてないのと、議事録用のスクリーンシェアができないため。時間になると Hangout にみんな集まってきてちゃちゃっとその日のやることを共有して、議事メモがすぐに Qiita Team に上がる。
スプリント計画は、実は厳密にはあまりやってない。やってるのはタイムボックスを決めて、2週間毎に前後のプロジェクト進行をスプリント単位で確認するくらい。自分の経験上、受託開発とかもうちょっとカチっとした開発では QCD における Delivery ･･･つまりはスケジュールの優先度が非常に高いので見積もり精度を上げるためにもスプリント計画を厚めにやるんだけど、365日開発し続ける SaaS 系サービスだとこの辺はゆるくやってるくらいが丁度いいと思ってる。がっつりやりすぎて疲れてしまうことより、ゆるくても長く続けて常にタイムボックスを意識して進められるくらいが良いかなと思う。
一方、KPT は日時を決めてしっかりやっている。スクラムマスターがその日までにオンライン上で KPT を集めておいて、その時間帯に Hangout で集まってミーティングをする。アジャイル開発においては、定期的に開発プロジェクトを見直し自分たちのやり方が間違っていないか、おかしなところがあったらそこをどう直していくかということが何よりも大切で、KPT はそのための良い機会になっている。

人の問題と、技術の問題

顧問として携わりはじめた昨年夏ぐらいから時間が経って、改めてみてみるといろんなプロセスが改善されて (KAIZEN だけに。) 安定した開発ができるようになってきたと思う。

当初は、まずはいろいろ教科書通りにやってみようということでスプリント計画そのほかをみっちりやったりもしてたが、やっぱりこれは違うねと感じたところは KPT で Problem にあげて、やらないことはやらない、緩く崩すところは崩すということをしながら今のスタイルに落ち着いている。

ところで昨晩から「ピープルウェア」という本を読んでいる。ソフトウェア開発の名著なんだけど、今ままで読んだことがなくて、たまたま知り合いのブログで感想があがってたのをきっかけに読み始めた。これの第一章から早速なかなか面白いことが書いてある。

実際のところ、ソフトウェア開発上の問題の多くは、技術的というよりは社会学的なものである

さもありなん。

技術の問題というのは、案外正解を導きやすい。コンピュータは、こうしたらこうなるというのにちゃんと答えを出してくれるし、どちらのやり方が良いかというのに結論を出しやすい。

一方、人間の問題は、そのやり方が本当に正しいのかどうかが見極めにくい。ものによっては半年とか一年後くらいになってようやく結果がわかることなんていうのも多い。時間が経過しすぎてどのアクションがその結果に繋がったのかという因果関係がはっきりしないことも多い。

だから、ソフトウェア開発の人間はついつい (解決の道筋が見えやすい) 技術的な問題にばかりフォーカスしがち、というようなことがピープルウェアには書いてあって、そうだよねえと思いながら読んでいる。

Daily Standup をリモートでどうやるかとか、リモートでも気軽に雑談できるような環境を整えることにリソースを割き続けるとか、そういうことは社会学的な問題だと思っている。一方、先日書いたような GitHub を使ったデプロイフローなんかは社会学的側面もありつつ基本は技術的な問題である。

人の問題が解決されてチームが良い状態になると、今度は技術の問題がボトルネックになる。せっかく迅速に開発してるのにリリース作業や QA に時間がかかりすぎる、とか。実際 KAIZEN では一時期リリースの品質に問題があったのでコミュニケーションを取って QA をしっかりやるようになったのだが、そうしたところ今度は人手での作業が多すぎてつらい感じになったので、E2E テストを書いて全部自動化することによってそのボトルネックを解消した、なんて典型例があった。

逆に技術的な問題ばかりを解決しても、コミュニケーションがボトルネックになって、だれそれの了解が得られないからリリースできないとかそういうことが起こる。

人と技術の問題を両面からバランスよく解きほぐしていくのが、昨今のソフトウェア開発におけるチームビルディングのコツなんではないか、と思っている。

追記

ちなみにリモートワークと書くと時折誤解を招くので、捕捉しておく。

リモートとはいっても、100% リモートワークしましょうということではなくて写真にも映ってる通りオフィスはある。オフィスに行くか行かないかは自分で決めるようになっている。対面でしたほうがよいミーティングがある日はオフィスにいくしそうでないなら自宅、あるいはカフェかどこかでやる。いい大人なんで、その辺は自分たちで判断しましょうね、お互い信頼してれば大丈夫だよね、ってな感じの仕組みになっている。

もちろん対面でやった方が早いと思うことはたくさんあるけど、本当にそれは対面じゃないとできないのかというところをまずは疑ってみないことには、新しい働き方を追求するということはできない。結果的にそれで会議を減らす、非同期に作業することができれば全体の効率が上がるわけで、そこで思考停止しない･･･ということが大切だと思う。