リモートワークをしながら「全員同席」するためのツール

KAIZENのようなスタートアップ企業で、かつリモートワークをする社員もいる環境で、どんなふうにアジャイル開発を進めていくか。
それが最近の僕の重要な関心事です。

ちょっとKAIZENのリモートワーク風景を見てほしいんですけれど……（Sqwiggleというオンラインミーティング・ツールで自宅で仕事をしているエンジニアを呼び出し、会話を始める）。

Sqwiggleを起動すると、カメラが有効になっていて、こんな感じで Sqwiggleを立ち上げてるチームメンバーが写真で一覧表示されます。いま誰がPCに向かっているか、すぐわかる。話しかけるときは、その人の写真をタップするだけ。

「これからビデオ会議を始めますよ～」という呼びかけのようなものが要らなくて、タップしたら音が鳴って、いきなり相手と会話を始められます。まるで隣の席の人に話しかけるような感じで、ネットワークの向こうの人と会話できる。

アジャイル開発では、「全員同席」という条件が不可欠だと言われているんですが、リモートワークだとこの条件を満たすのが難しい。もちろん、オンラインミーティングのためのツールはこれまでにもいろいろあって。

例えば「Google Hangout」などもそうですが、これの最大の問題は、「話そうぜ」と別のツールで同期を促さないといけなかったこと。ちょっとした仕様の確認や雑談なのに、会話する前に「いる？いない？」「チャット見てなかった？」「URLどこだっけ？」みたいな手続きで何分も時間が取られてしまう。

このあたりを改善したのが、Sqwiggleなんですね。自宅で一人で仕事をしていると、どうしても孤独感にさいなまれる。今日一日誰とも話さなかったなあとか。人間やはり社会との接点が必要だなあとか(笑)。はてなのときも、週に１回はリモートワークOKという制度があったんだけれど、みんななぜかオフィスに来るようになってしまった。

この点、Sqwiggleだと、画面に誰かがいつも映っているから、みんなと一緒にやっている感覚を共有できる。また、リモートワークにありがちな、自己管理できなくてついついさぼってしまうみたいな問題もSqwiggleだと、周囲の視線による適度な緊張感が得られるので、勝手にサボれない。怠惰な人にも向いているんじゃないかな。

Sqwiggleを知ったのは、SNSの予約投稿ツール「Buffer」を開発しているエンジニアたちがリモートワークをしていて、そこのブログを読んでいたら、最近これが良いよ、ということで、試したんです。

ただまあ今後ほかにも似たようなものもたくさん出てくると思うし、道具自体が進化している。だからこれがいいからずっとこれを使うというより、いろいろ試して、乗り換え続けるというのがいいと思う。

自分たちの環境整備のために継続的に改善を図る──ということが、エンジニアとしては正しい態度だろうと思うんです。

GitHub活用で僕らの仕事はどう変わったか

KAIZENではリモートワークの人も含めてスクラム開発をしているんですが、ここでもう一つ重要なのは、GitHubの活用です。GitHubをPull Requestベースで使いながらスクラムで開発する、というのがKAIZENの流儀になっています。

ソースコードの変更は基本的にPull Requestを通す。本体にマージする前のPull Requestのコードレビューも必ず行うようにしています。Pull Requestはレビューが間に挟まることが前提になっているので、Pull Requestベースで開発すると自然にレビューすることになるんです。

GitHubは単にトレンドだから使っているわけじゃなくて、立ち上がったばかりのスタートアップで、スピード感は求められるのに、エンジニアが足りていない。そこでどうするかということを考えて、必然的にたどり着いたのがこのやり方だったんです。

最終的には、誰が作っても同じようにコードが書けるようにしたいわけです。GitHubが僕らの仕事に与えた影響というのはとても大きなものです。GitHubは単にコードを共有化できる便利な環境というだけじゃなくて、オープンソースの開発のお作法を機能化したもの、とも言える。つまり、ソフトウェアをオープンソースプロジェクトがやるように作るための道具なんです。

10年前に、「Googleにはコードレビューやテストをみんながやるすごい体制がある」「Google はオープンソースのようにソフトウェアを作っている」と聞いて、やり方を聞いてみんな真似をしたけれど、その頃はうまくいかなかった。それは今思うと、開発用の道具が足りなかったから。テストやコードレビューを継続するための手段がなくて、エンジニアの気合と根性だけでやっていたから、みんな途中で息切れしてしまった。

10年経ってそれと同じような環境が誰にも使えるようになった。それがGitHubだったと思います。きっと、Googleには「Google版GitHub」のようなものがあったんじゃないかと、僕は勝手に想像しているんですけれど。

だから自分たちの感覚ではGitHubを使わない手はないし、オープンソースやWebの世界では今や当たり前のプラクティスになっていると思います。けれども、そうじゃない世界があることは知っています。IT企業にいても、GitHub知らないエンジニアもまだまだたくさんいる。

僕らはある意味「その方が楽しいから」とか「その方が正しい作法な気がするから」という主観的な理由でGitHub を使うんだけど、一方で「コードレビューをすると人事評価が上がるんでしょうか」とか「コードレビューを定量化して、それを給料に反映する仕組みが必要じゃないか」と質問されることがあって、文化の断絶を感じます。

オープンソースのようにソフトウェアを作る人とそうでない人、アジャイル開発をやる人とそうでない人。この文化の差はますます広がっているなと感じることがあるのです。

伊藤 直也氏
ニフティ、はてな取締役CTO、グリー統括部長を経てフリーランスとして活動。ブログやソーシャルブックマークなど10年間、ソーシャルメディアの開発と運営に携わる。
著書に『入門Chef Solo』(達人出版会)『サーバ/インフラを支える技術』『大規模サービス技術入門』　(技術評論社) など多数。2013年9月よりKAIZEN platfrom Inc. 技術顧問。
GitHub：@naoya Twitter:@naoya_ito

CodeIQコード銀行にあなたのコードを預けてみませんか？

• CodeIQコード銀行ではあなたのコードを財産と考えます。
• お預かりいただいたコードは、CodeIQコード銀行がしっかり評価し、フィードバックいたします。
• 当コード銀行にお預けいただいたコードは、企業がみてスカウトをかける可能性があります。
• 転職したい方や将来転職することを考えている方で、今の自分のスキルレベルを知りたい方はぜひ挑戦してみてください。
• 企業からスカウトがきたら困る人は挑戦しないでください。

興味を持った方はこちらからチャレンジを！