教えて! 最新技術―テックコミュニティの現場から

第5回 リモート化で加速するモブプログラミングとアジャイルの精神

この記事を読むのに必要な時間:およそ 4 分

テックコミュニティの運営側で,その技術分野を常に追いかけているエンジニアの方々にお話をうかがうインタビュー企画。ホストは関満徳が務めます。コロナ禍のさなか対面での取材を避け,リモートで行います。第5回目のゲストとしてお迎えしたのは,シニアアジャイルコーチとして活躍する川口恭伸氏です。

川口氏は,現職にアジャイルコーチとして従事するかたわら,一般社団法人スクラムギャザリング東京実行委員会 代表理事,一般社団法人DevOpsDaysTokyo代表理事などの活動を精力的にされています。

画像

川口 恭伸(KAWAGUCHI Yasunobu)さん

得意とするIT分野は,アジャイル開発のプロセスやチームマネジメント,プロダクトオーナーシップ(要件定義や絞り込み⁠⁠,モブプログラミング。現在は,なにかするときにJavaScriptを選択することが多い。

Twitter:@kawaguti
URL:https://kawaguti.hateblo.jp/

関:川口さんがWEB+DB PRESS Vol.102の特集1「はじめてのペアプロ/モブプロ ―メキメキと人が育ち,プロダクトの質を高める」に寄稿されたのが2017年12月でした。あれから3年経ち,ペアプログラミング/モブプログラミング(以降,ペアプロ/モブプロと省略)を取り巻く状況はどのように変わったのでしょうか?

川口:もう3年も経ったんですね。モブプロというのは,米国のHunter Industriesで生まれた,数名のチーム全員で同じコンピュータで仕事をするスタイルのことです。あるチームが,XPExtreme Programmingを中心にBDDBehavior Driven Developmentふるまい駆動開発)などのアジャイルの技術プラクティスを実践しながら,さらなる実験と改善を積み重ねて行きついた一つの型です。良い効果が数多く見つかったので,そこにモブプログラミングという名前を付けました注1⁠。現在も実験を繰り返して変化しています。

記事を書いた当時,モブプロはリモートではなく同席のほうがベターだと考えていました。コロナ禍以前のビデオ会議といえば,機材が十分ではない,打ち合わせ時間になっても人がそろわない,ネットワーク接続の状態が悪く遅延がたびたび発生する,など,たくさんの問題を抱えていました。

最近はコロナ禍で在宅での仕事が推奨されたこともあり,多くの方々が,在宅環境のカメラやマイク,ネットワーク環境,椅子,机,モニターなどに投資するようになりました。加えてZoomやMicrosoft Teams,Google Meetなどのオンラインビデオ会議サービスの品質が格段に上がり,前述した問題が起きにくくなっています。それだけではなく,画面共有の技術がここ数年でかなり向上したことも大きいでしょう。Visual Studio Live Shareによるリアルタイムのコード共有や,GoogleドキュメントやOffice 365のようなリアルタイムドキュメント共有,MiroMURALGoogle Jamboardのようなオンラインホワイトボードを含め,たくさんのソリューションが広く使われるようになりました。

これらのソリューションに共通するのは,オンラインで共同編集している全員のカーソルの場所(注視点)がリアルタイムでわかる,ということですね。リアルでのモブプロだと,指やマウスカーソルで見てほしい場所を指したりしていましたが,リモートでもどこを見ればよいかわかるようになり,迷子にならなくなったのです。逆に,オンラインによる共有が不慣れな人との打ち合わせだと,⁠注視点がわからず)ストレスを感じることがあります。⁠とりあえず画面共有しませんか?」と切り出すことも多いです。

ここでの本質は,みんなで同じ場所を見て,同じ状況下で議論をする,ということです。これは,モブプロをしている様子を外から見ているだけじゃ,わかりにくいかもしれません。実は,あらゆる仕事において重要なポイントなんです。アイデアはその場で付箋ふせんに書いておき,OKなら次に進める。全員で議事録を見ながら打ち合わせを行い,議事録はみんなでその場でなおしていく。だれも打ち合わせが終わったあとに,議事録をまとめたりしません。これまでは会議で概要を決めて,会議が終わったら作業をしていたかもしれませんが,モブプロでは会議中に作業をしてしまい,会議をしながら作業を終わらせるのです。会議かつ実装。会議が終わったら実装が終わっているのが理想ですね。プログラミングに限らず,あらゆる仕事で,モブプロのようなやり方が,生産性向上に非常に貢献することがわかってきました。

注1)
参考:モブプロの起源についての川口氏による翻訳文章。
https://kawaguti.hateblo.jp/entry/2021/03/30/082537

本の共同執筆もモブプロで

関:ここ最近は,本の共同執筆もモブプロのようなやり方で行われるようになってきましたね。実はこの記事も,完全オンラインで執筆しています。

川口:はい,本の執筆も基本同じですね。GoogleドキュメントやVisual Studio Live Shareなどで編集,GitHubへpush。フィードバックが返ってきたら,修正してGitHubに再度反映,という形で進めるようになりました。以前だと,PDFに手書きで赤入れするなどしていましたが,あちこち回覧されている間に,手もとでも修正していたりするとコンフリクトするんですよね。バージョン管理ができていないので,データがずれたりする。みんな良くないなぁとは気が付きながらも,それが業界のやり方だと黙認してきました。著者,編集者,組版制作者と関係者が多いなか,手渡しと修正を繰り返し,組版まで進んだときには,誰がどんな修正したのかわからない伝言ゲームになっている状態です。伝言ゲームの難しいところは,誰もが三段先を見越して動かないといけない,という点です。 著者がなんでこう考えたのか想像して,別の人が動くわけです。一次校正,二次校正,最終校正と進んでいく中で,だんだん引き返せなくなります。最終的には,⁠これはどういう意味なんだろう?」と疑問を持っても相談する時間がなく,想像しながら進めることになります。まるでウォーターフォールのようです。

ところが,GitHubで管理するようになると,戻せるんですよね。1つ1つの指摘や修正などの動きが,あとからトレースできるんです。誰が,どの観点で,どの箇所に働きかけたのかがわかるようになりました。残念ながら,まだ組版のツールに直接連携するところまでは難しいところがありますが,とある編集会社では組版まで一気につなげているところもあるようです。こうなってくると,立場に関係なく,フラットな議論ができるようになってきます。校正担当の方がどこをどんな観点で校正したのかについて,著者があとから見なおして,なるほどこういう書き方だと校正されるのかと学習し,次に文章を書くときには内容が良くなっていったりするわけです。

著者プロフィール

関満徳(せきみつのり)

プロジェクトマネージャー・スクラムマスターとして組織・プロダクトオーナー・チームを支援しながら後進人材の育成に従事。アジャイルやプロダクトマネジメントのコミュニティ活動多数。

GitHub:fullvirtue
Twitter:@fullvirtue
URL:https://fullvirtue.com/