テックコミュニティの運営側で、その技術分野を常に追いかけているエンジニアの方々にお話をうかがうインタビュー企画。ホストは関満徳が務めます。コロナ禍のさなか対面での取材を避け、リモートで行います。第5回目のゲストとしてお迎えしたのは、シニアアジャイルコーチとして活躍する川口恭伸氏です。
川口氏は、現職にアジャイルコーチとして従事する傍（ かたわ ） ら、一般社団法人スクラムギャザリング東京実行委員会 代表理事、一般社団法人DevOpsDaysTokyo代表理事などの活動を精力的にされています。
関： 川口さんがWEB+DB PRESS Vol.102 の特集1「はじめてのペアプロ／モブプロ ―メキメキと人が育ち、プロダクトの質を高める」に寄稿されたのが2017年12月でした。あれから3年経ち、ペアプログラミング／モブプログラミング（以降、ペアプロ／モブプロと省略）を取り巻く状況はどのように変わったのでしょうか？
川口： もう3年も経ったんですね。モブプロというのは、米国のHunter Industriesで生まれた、数名のチーム全員で同じコンピュータで仕事をするスタイルのことです。あるチームが、XP（Extreme Programming ）を中心にBDD（Behavior Driven Development 、ふるまい駆動開発）などのアジャイルの技術プラクティスを実践しながら、さらなる実験と改善を積み重ねて行きついた一つの型です。良い効果が数多く見つかったので、そこにモブプログラミングという名前を付けました[1] 。現在も実験を繰り返して変化しています。
記事を書いた当時、モブプロはリモートではなく同席のほうがベターだと考えていました。コロナ禍以前のビデオ会議といえば、機材が十分ではない、打ち合わせ時間になっても人がそろわない、ネットワーク接続の状態が悪く遅延がたびたび発生する、など、たくさんの問題を抱えていました。
最近はコロナ禍で在宅での仕事が推奨されたこともあり、多くの方々が、在宅環境のカメラやマイク、ネットワーク環境、椅子、机、モニターなどに投資するようになりました。加えてZoomやMicrosoft Teams、Google Meetなどのオンラインビデオ会議サービスの品質が格段に上がり、前述した問題が起きにくくなっています。それだけではなく、画面共有の技術がここ数年でかなり向上したことも大きいでしょう。Visual Studio Live Share によるリアルタイムのコード共有や、GoogleドキュメントやOffice 365のようなリアルタイムドキュメント共有、Miro やMURAL 、Google Jamboardのようなオンラインホワイトボード を含め、たくさんのソリューションが広く使われるようになりました。
これらのソリューションに共通するのは、オンラインで共同編集している全員のカーソルの場所（注視点）がリアルタイムでわかる、ということですね。リアルでのモブプロだと、指やマウスカーソルで見てほしい場所を指したりしていましたが、リモートでもどこを見ればよいかわかるようになり、迷子にならなくなったのです。逆に、オンラインによる共有が不慣れな人との打ち合わせだと、（ 注視点がわからず）ストレスを感じることがあります。「 とりあえず画面共有しませんか？」と切り出すことも多いです。
ここでの本質は、みんなで同じ場所を見て、同じ状況下で議論をする、ということです。これは、モブプロをしている様子を外から見ているだけじゃ、わかりにくいかもしれません。実は、あらゆる仕事において重要なポイントなんです。アイデアはその場で付箋（ ふせん ） に書いておき、OKなら次に進める。全員で議事録を見ながら打ち合わせを行い、議事録はみんなでその場でなおしていく。だれも打ち合わせが終わったあとに、議事録をまとめたりしません。これまでは会議で概要を決めて、会議が終わったら作業をしていたかもしれませんが、モブプロでは会議中に作業をしてしまい、会議をしながら作業を終わらせるのです。会議かつ実装。会議が終わったら実装が終わっているのが理想ですね。プログラミングに限らず、あらゆる仕事で、モブプロのようなやり方が、生産性向上に非常に貢献することがわかってきました。
本の共同執筆もモブプロで
関： ここ最近は、本の共同執筆もモブプロのようなやり方で行われるようになってきましたね。実はこの記事も、完全オンラインで執筆しています。
川口： はい、本の執筆も基本同じですね。GoogleドキュメントやVisual Studio Live Shareなどで編集、GitHubへpush。フィードバックが返ってきたら、修正してGitHubに再度反映、という形で進めるようになりました。以前だと、PDFに手書きで赤入れするなどしていましたが、あちこち回覧されている間に、手もとでも修正していたりするとコンフリクトするんですよね。バージョン管理ができていないので、データがずれたりする。みんな良くないなぁとは気が付きながらも、それが業界のやり方だと黙認してきました。著者、編集者、組版制作者と関係者が多いなか、手渡しと修正を繰り返し、組版まで進んだときには、誰がどんな修正したのかわからない伝言ゲームになっている状態です。伝言ゲームの難しいところは、誰もが三段先を見越して動かないといけない、という点です。
著者がなんでこう考えたのか想像して、別の人が動くわけです。一次校正、二次校正、最終校正と進んでいく中で、だんだん引き返せなくなります。最終的には、「 これはどういう意味なんだろう？」と疑問を持っても相談する時間がなく、想像しながら進めることになります。まるでウォーターフォールのようです。
ところが、GitHubで管理するようになると、戻せるんですよね。1つ1つの指摘や修正などの動きが、あとからトレースできるんです。誰が、どの観点で、どの箇所に働きかけたのかがわかるようになりました。残念ながら、まだ組版のツールに直接連携するところまでは難しいところがありますが、とある編集会社では組版まで一気につなげているところもあるようです。こうなってくると、立場に関係なく、フラットな議論ができるようになってきます。校正担当の方がどこをどんな観点で校正したのかについて、著者があとから見なおして、なるほどこういう書き方だと校正されるのかと学習し、次に文章を書くときには内容が良くなっていったりするわけです。
開催困難なカンファレンスをアジャイル精神で乗り越える
関満徳 氏
関： 川口さんは、オンラインカンファレンスとオフラインカンファレンスの併催、いわゆるハイブリッド開催のカンファレンスをこれまで何度か開催してきましたね。
川口： はい、ありがたいことに毎回たくさんの方々に応援いただき、無事に開催することができました。コロナ禍でたくさんのカンファレンスが開催中止を余儀なくされている状況で、Scrum Fest Osakaというカンファレンスは、初めてオンラインで開催しました。せっかくオンラインで開催・集客するのであれば、全国各地のいろんなコミュニティと一緒にやったらおもしろいんじゃないか、ということで、たくさんのコミュニティにお声がけし、全部で19トラックを終日開催、しかも同じくカンファレンスであるところのAgile Japanも1トラック持っているという、謎のオンラインカンファレンスになりました。Discord というチャットツールをそこで初めて使いましたが、今ではオンライン開催イベントのデファクトスタンダードになりつつあります。
このときに開催したScrum Fest Osakaの基調講演で、アジャイルコーチの永瀬美穂さんが、オンライン開催と聞いて「うっ」と思ったっていう話をしたんですよね[2] 。「 うっ」ていうのは、やったことのないことを頼まれると、ちょっと気が引ける、という反応のことです。それでもやっぱりやってみると、すごく学びが多いんですよね。私たちのようなアジャイルでやっている人たちは、常日頃から「学びが大事、実験が大事」と言っています。そんな私たちが、「 うっ」って思ったぐらいで止まっちゃだめだなぁと。オンラインカンファレンスにも同じことが言えました。
ハイブリッド開催のカンファレンスでは、放送関係のプロの方から見たら、びっくりされるくらいに機材を減らして対応しています。プロに依頼すると、どうしても専用の機材と、それを扱える人をそろえて、念のためのバックアップ機材も、となりがちなんですが、実際はZoomがあれば十分だったりするんですよね。最近は講演者もZoomがいちばん慣れていたりしますし。スタッフさんをたくさん雇うより、機材をなるべく減らしてシンプルにし、安定運用を目指しています。関わる人がなるべく楽になるようにしています。
こうしたことをやっていると、あぁ、私たちってエンジニア気質だったんだなって思います。もっと楽になるために、ここはこう工夫しよう、みたいな考え方、改善のサイクルが染み付いているんですよね。エンジニア時代に学んだことを、ほかのことで役に立てているともいえるかもしれません。
エンジニアリングで学んだことをほかに活かす
関： もともとエンジニアをやっていた人が、なかなかIT化が進まない現場で活躍している例は、ほかにもありそうですね。
川口： エンジニアだったら何ができるのか、と考えながら、エンジニア以外の人たちとコラボレーションするのは、とても大事だと考えています。どの分野でもそうですが、価値をどうやってお金に変えるか、って難しいですよね。ソリューションを出しても、期待を超えるものでないとなかなか継続発注がもらえません。リターンオーダーがもらえないということは、失敗なんです。
会社員エンジニアとして働いていると、そういうことを考える機会はあまりないですよね。しかし実際は、作ったソフトウェアやサービスにバグがあったら、次から発注が来ないんですよ。つまり、仕事の依頼が来ないってことです。品質が良くて、コンパクトで、ほかの人より仕事が早く終わる人は、社内の評価をすぐには得にくいかもしれません。ただ、継続的に仕事の依頼が来ることで、結果的に業績が上がる、というループがあります。
信頼貯金やヒューマンキャピタルを使って、仕事をお金に変えていく。そうすることで、おもしろい仕事もやってくる。自分の知的好奇心を満たしながら、さらにお金がもらえるようになり、巡り会えるチャンスも増やしていく。そんなサイクルをまわしていかないといけません。会社員だろうが、独立していようが、コンサルタントとして活躍していようが、みんな同じですよね。種をまいて、信頼を得ておくわけです。もう一緒にやりたくないな、って思われたら終わりですから。そのためには、エンジニアももっといろんなことを学び、実践していくとよさそうです。
もっと学ぶ時間をとろう
関： 学びといえば、これまでのオフラインでの学びの場に加えて、最近ではオンラインによる学習環境も充実してきましたね。
川口： 大学ではコンピュータサイエンスの講座を公開していますし、Udemy やUdacity 、Pluralsight のようなオンラインの学習サービスも増えてきていますね。日本語のコンテンツも徐々に増えていますが、英語だとびっくりするぐらいいろんなことを安く学べたりします。アジャイルでは、自らやってみる、学んでみることが大事と考えています。どんどん学んで、動くものを作っていこうぜ、と。
残念なことに、日本の会社では、いまだに開発者が学ぶというと「勉強ばかりしてないで仕事をしろよ」って言われることが多いようです。スクラムの研修をしていて思うのが、チームが学ぶ時間を意識的に確保しないと、改善が進まなくなり、新しいものに追いつけないんですよね。手もとの改善はもしかしたらできるかもしれませんが、ブレイクスルーにつなげるのは難しいです。やはり、やってみる、という時間が必要です。継続的に学習に投資したいのに、チームが成果を出せていないと投資を許してくれない、という相談をよく受けます。期待された仕事を80％の力でできるようにし、20％はチームが学ぶ時間に投資してはどうか、とアドバイスします。企業における内部留保と同じです。株主からは、そんなことをせずに還元しろよ、と言われちゃったりするんですけどね。
写真1 川口さん（左）にはリモート＋エフェクト盛りで対応いただきました チームは、役に立ちそうにないことを学ぶわけではなく、今の自分たちに役に立ちそうなことを学ぶものです。たとえば、テストを自動化し、CI/CDを実現していけるようにすれば、ビジネスジャッジをしてからリリースするまでの時間、いわゆるリードタイムを短くすることができますよね。DevOpsを導入する前はリリースまでに6ヵ月かかっていたものが、DevOpsのトレーニングを受けて、基盤を入れ替えたら4日でできるようになったとします。ビジネスジャッジしてから4日で世の中に出せるということは、ビジネスの人たちにとって良い話ですよね。開発者にとって、ではなく。なぜなら、それはお金になるからです。
読者へのメッセージ
関： 最後に、本誌読者のみなさんへのメッセージをいただいてもよいでしょうか。
川口： あなたのチームにいる、もっと学びたい、という人たちを、もっと大事にしてあげてください。全員が学ばないと、良くなっていきません。今、足りないのは、スキルです。そのためには、学ぶ時間をとることが大事です。まずは自分が学んでいき、それを自分の周りにいるみなさんにも広げていってください。自分が今できていることの一歩先を、一歩横の新しいことを、実験し、やってみてください。
エンジニアが勉強すると、めっちゃ元がとれます。たとえば本誌を毎号読んで、いろんな技術を見知っておき、これどうやろうってなったときに3ヵ月前の本誌を読み返して、実際にやってみて、やれるようにしていく。あらかじめいろんな情報を調べていた人しか、結局のところひらめかないんですよね。最後まで読んでいただき、ありがとうございました。
特集1 イミュータブルデータモデルで始める 業務の複雑さをシンプルに表現！ 特集2 いまはじめるFlutter iOS/Android両対応アプリを開発してみよう 特集3 作って学ぶWeb3 ブロックチェーン、スマートコントラクト、NFT
