スクラム、モブプログラミング、リモート。今が旬、もしくはこれからの潮流となっていきそうな開発手法をトリプルで採用している現場がある……。そう聞いて向かったのがサイボウズ。なぜこれらの手法を同時に採用したのか？ どんなメリットとデメリットがあるのか？ 関西在住のサイボウズ西日本開発部エンジニア2人にぶつけてみた。

リモート開発→リモートスクラム→リモートモブプログラミングの順で導入。「リモートは当たり前」という環境と意識が前提にあった

結論から言えば、このトリプルなアプローチは本番の局面で実施されていた。サイボウズのkintone開発チームと、kintoneをアメリカに提供するにあたって、サービスを最適化するための開発を行うチームの両方で「スクラム×モブプログラミング×リモート」が採用されており、前者のチームに榎原氏が、後者のチームに三苫氏が参画しているのだという。

しかし、現状多くの企業の開発現場ではスクラム開発の導入がうまくいかずに悪戦苦闘していたり、リモートを駆使した開発がしたくても環境が伴っていなかったりする。モブプログラミングなどは「試験的にトライしてみた」というところさえ、日本では少数派だ。そんな世の中の実態を尻目に、なぜサイボウズは3つを同時に製品開発の現場で採用しているのだろうか？

「順番からいうと、リモート開発、リモートスクラム開発、リモートモブプログラミングという流れで取り入れていきました。当社はグループウェアを開発・提供する会社ですので、以前からあらゆるデータをクラウドに上げ、仕事でも利用していたんです。システム環境の下地があったことでリモート導入が進み、『リモートは当たり前』という社員の意識が根付いていました」（三苫氏）

世の中では最近になってリモート推進の流れが加速している。地元で働きたい人やオフショアなど遠隔地での開発が増えたことに加え、働き方改革の潮流もあって、取り組みを始めた企業は少なくない。だが、そこでネックとなるのが環境面。その点、サイボウズではリモートに適したシステム環境が整っていたというわけだ。

「部門間のコミュニケーションや作業引き継ぎはもちろん、上長に意志決定を申請するような場面なども、すべてWebサービス上でスピーディに行える環境がそろっています。だからリモート開発がスムーズに実行できる。実際に私も三苫も、関西からリモートで開発業務に携わっています」（榎原氏）

こうしたベースがあったうえで、次に実現したのがリモートスクラムだった。

「リモートスクラムの難易度が高いことは一般的にも言われています。スクラムの代表的な特徴は、チーム内で情報や意見を共有していくやり方にある。しかも、ホワイトボードに付箋をたくさん貼って皆で確認を取り合うような、物理的なタスク管理が推奨されているわけです。リモート参加のメンバーがいるとそういう手法は取れないですが、私はできることなら地元の関西で働きたいし、同じように思っているメンバーは他にもいます。企業やテック系の勉強会は東京に集まっていますが、本来エンジニアの仕事は場所を選ばずにできるはずだという思いもありました」（三苫氏）

「やはり一番の課題は、コミュニケーションをどうやって密に取るのかです。密度の濃いコミュニケーションを画面を通じて実行していかないとうまくいきません。先ほども話した通り、幸い当社のメンバーはこれまでの経験からリモートに親しんでいましたし、画面上でのコミュニケーションにも慣れています。それに加えて、ホワイトボードに付箋を貼る感覚をWebサービス上で再現する工夫を重ねていったことでカバーできました」（榎原氏）　

日本では前例の少ないモブプログラミング、そのメリットとデメリットとは？

残る１つはリモートモブプログラミング。モブプログラミングとは、いわばペアプログラミングの大人数バージョン。誰か１人がドライバとなって手を動かし、残るメンバーたちがナビゲーターとなって画面上のコード等をチェックし、改良点を指摘し、意見を出し合っていくスタイルだ。シリコンバレー界隈では浸透し始めているようだが、まだ日本ではあまり実例を聞かない新しい手法といえる。いったいなぜ、そんな新しいスタイルを本番環境で、しかもリモートで実行することになったのだろう。

「５名のチームに７名の新人が加わったことがきっかけでした。開発拠点がバラバラな中でチームを効率的に回しながら、経験値の少ない新人を育成するためには、蓄積してきた知見や情報をスムーズに共有しながら開発を進めなければいけません。それならば、各自が黙々と任された作業を別々に進めるよりも、思い切ってチーム全体でリモートのモブプログラミングにチャレンジした方が適していると判断したんです」（榎原氏）

「僕のチームでは、アメリカでkintoneを展開するべく、基盤のシステムを作り上げる者、販売管理の機能を開発する者、運用を担う者などが各部署から集い、同時進行で課題を解決し、一気にサービスを構築することが求められます。各々の業務知識の偏りが大きく、全員が多くのことを学ぶ必要があったので、皆で同じ画面を見ながら開発を進めた方がスピードの面でも精度の面でもプラスになるだろう。そんな判断からリモートモブプログラミングを導入しました」（三苫氏）

では、実際にやってみて、どうだったのだろうか？ 「リモートは関係なく、モブプログラミング自体の話ですが……」という前置きの後、２人は次のように話した。

「私は周りの人に自分の考えをどんどん話して、ワイワイしながら仕事をしたいタイプ。ですから、ワーっと自分の意見を言えるモブプログラミングは、そりゃあもう楽しいですよ（笑）。それに、やってみて実感したのは、物事を共有しながら仕事をする局面で、モブプログラミングは非常に有効だということ。チームのコミュニケーションが重要になる面ではスクラムとの親和性も高いですし、何より私のチームのように一度に多くの若手を育成する場合には最適だと感じました」（榎原氏）

一方の三苫氏は“非ワイワイ派”。１人でこつこつとやるのが好きなタイプだ。案の定、モブプログラミングは「慣れるまでしんどかった」という。ただ、やっていくうちにメリットも感じたという。

「１人でやっていたら思いつかなかったアイデアが他の人の引き出しにあったり、自分では気付かなかった問題点を他の人が指摘してくれたりと、皆で一つの画面で同じタスクに取り組む利点を体験していったんです。あまりやる気が出ない場合に、周りの仲間が引き上げてくれるのも、予想外の収穫でした。皆で仕事を共有しているからこそ、休みが取りやすいというのも大きなメリットですね」（三苫氏）

ただ、新しいチャレンジだけに、全てが簡単にうまくいったわけではない。やっていく中でデメリットも見えてきた。

「誰をドライバにして、どのくらいの時間を任せるのかという面は注意が必要でした。技術力の高い人間がドライバになって長時間手を動かしてしまうと、経験値の低いナビゲーターが置き去りにされかねない。特定の誰かをドライバとして固定するよりは、複数の人間で回すような運営は必要でした」（榎原氏）

「モブプログラミングは皆でやるものだから、全員参加の意識は必須です。でもあまりいき過ぎると、しんどくなった時に休憩を取りづらくなるんですよ。そろそろ休みたいけど、今みんなが乗ってるし、言い出しづらいなあ……っていう。計画性をもって休憩を提案しないと、チーム全員がボロボロになりかねないというのは注意点ですね」（三苫氏）

また、「モブプログラミングの良さはある程度継続しなければ分からない」と２人は口をそろえる。

「モブプログラミング自体はやろうと思えばすぐにできますし、リモートでやる場合も画面を共有するツール自体は世の中にいろいろあります。ただ、複数人で同じタスクをやるわけですから、個人の目線で生産性や効率を考えると、１人でプログラミングをした方が速いように感じてしまいがち。長期スパンで“チーム全体としての効率”を意識してみた時に、モブプログラミングが有効かどうか、初めて分かると思います」（三苫氏）

「モブプログラミングに関する勉強会のイベントはあると思いますが、継続的にトライしなければ、本当の価値は見えてきません。短時間試しただけで判断するのは、お薦めできませんね」（榎原氏）

「スクラム×モブプログラミング×リモート」はどの会社でもうまくいく手法ではない。
ただ、開発手法を知ることは技術者の成長につながる

リモートでのスクラム開発やモブプログラミングについて、「手応えは感じている」と２人。今後新たなプロジェクトを立ち上げる際、開発手法の一つとして選択肢に入るという。ただその一方で、「どの会社でもうまくいく手法ではない」と話す。

「スクラムもモブプログラミングも、原則的にリモートとの相性は悪いです。大前提として当社のように全てのデータがクラウド上になければ、リモートスクラムもリモートモブプログラミングもうまくいかないと思います」（榎原氏）

「誰と誰がリモートでつながるのか、という部分も要注意ですね。直接対面したことがなく、相手の人となりが分からないままではコミュニケーションを取るのは難しいと思います。人柄も重要で、特にモブプログラミングは全員参加で行う開発手法。リモートであればなおさら、引っ込み思案な人には向かない手法かもしれません」（三苫氏）

かつて、アジャイル開発が脚光を浴びた時には、「何でもかんでもアジャイルが良い」という間違った幻想が広がったケースもあった。リモートスクラムもリモートモブプログラミングもそれぞれ長所と短所があり、導入できるかは自社の開発環境に左右される。やってみようと思ってすぐにできるものではなさそうだが、最後に両氏はこう話した。

「仮に自社で試すのが難しくても、こういった開発手法や働き方の選択肢を知っておくことは重要だと思っています。人手不足の世の中で、エンジニアは選べる立場にある。でも選択肢を知らなければ、そもそも選ぶことができないですよね。アンテナを張っておくことは、自分が望む働き方をかなえることに繋がるのではないでしょうか」（三苫氏）

「僕は“やりたいことを実現する”のがエンジニアの仕事だと思っています。そのためには、一つでも多くの言語やツール、開発手法や働き方を知っていた方がいい。選択肢を持つことは、技術者の成長には不可欠だと思います」（榎原氏）

取材・文／森川直樹・天野夏海　撮影／吉永和久