「モブプログラミング超入門ライブ !」を企画して伝えたかったこと

私は AWS Developer Live Show で、2022 年 8 月と2022 年 10 月に「モブプログラミング超入門ライブ !」という企画を担当しました。皆さん観ていただきましたか ?

企画自体はじめて知った ! という方もいらっしゃるでしょうし、企画は知ってるけど 1 時間の動画を観る時間が取れてなくまだ観れてないよ ! という方もいらっしゃると思います。企画としては「モブプログラミング」という開発スタイルがあり、“モブプログラミングって何だろう” や “モブプログラミングに興味がある” という方に向けて、実際にモブプログラミングをしている姿をライブ配信しちゃおう ! という内容です。普段から一緒に仕事をしている、テクニカルトレーナーの仲良し 3 人組でワイワイとモブプログラミングをしました。

なお、モブプログラミングをするお題（アルゴリズム）としては FizzBuzz と FizzBuzzPlus を使いました。これは「プログラミング初学者でも理解しやすいお題」の代表例として選んでいます。皆さんのチームでモブプログラミングを体験するときにも使えます。

しかし、これじゃ簡単すぎるよ ! と感じることもあると思います。その場合には、他にもよく知られたお題があるため、調べながら使ってみるのも良いと思いますし、あまり難しすぎないものであれば、皆さんのチームで次に着手する予定の機能開発でモブプログラミングをしてみるのも良いのではないでしょうか。

また、今回のライブ配信で深くは紹介していませんが、テストコードを書きながら FizzBuzz と FizzBuzzPlus コードを書き進めるというテスト駆動開発 (TDD: Test-Driven Development) のエッセンスも取り入れました。特に歩幅を小さく進めたり (仮実装と明白な実装)、テスト項目をいくつか用意する (三角測量) などは、書籍「テスト駆動開発」に詳しく載っています。本当に素晴らしい1冊です。

そして、テストコードを実行する前に「実行結果予測 (どういう結果になると思う ?)」を行うことも今回意識していました。何となく “勢いで” 実行するのではなく、実行結果を予測することで、コードの理解度と納得感が高まります。私自身とても好きなプラクティスで、よく使っています。

本企画で伝えたかったことは多くあるのですが、大きく分類すると以下の 3 点でしょうか。

1. モブプログラミングという開発スタイルがあることを伝えたい
2. 全員参加型の雰囲気の良さを伝えたい
3. モブワークという働き方があることを伝えたい

順番にまとめていきましょう。

モブプログラミングは A Whole Team Approach と言われることもある「チーム全員で取り組む」開発スタイルです。モブプログラミングにはよく知られた 4 つの原則があり、以下に英語で箇条書きをしてみました。これは「同じ仕事を、同じ時間に、同じ場所で、同じコンピューターを使って」行うということです !

• on the same thing ...
• at the same time ...
• in the same space ...
• on the same computer ...

それでは非効率では ? と感じられる方もいるのではないでしょうか。しかし、チーム全員で開発に取り組むことにより、開発の流れそのものを共有しやすくなったり、判断に迷ったときにすぐに合意を得やすくもなります。結果的にリードタイム (開発に着手してからリリースされるまでの期間) を短くできる可能性があります。

特に「開発の流れそのもの」を共有できるのはメリットを感じやすい部分です。プログラムを書きながら何を考えているのか、どんな命名規則にするべきなのか、どのようにエディタやショートカットを活用しているのか、などなど。変数名の命名などは、後々コードレビューで指摘を受けて修正することになった、という経験もあるのではないでしょうか。モブプログラミングではチーム全員が同席しているため “リアルタイムに” コードレビューを行っているとも言えますね !

モブプログラミング超入門ライブ ! で実際に会話した内容をいくつか抜粋してみました。チーム全員で助け合ったことにより、ノウハウを共有しながら、効率的に進められました。もし、1 人でプログラミングをしていたら、もっと時間がかかったり、後々コードレビューで指摘を受けるコードになってしまうかもしれませんね。

• モブプログラミング超入門ライブ ! ~ FizzBuzz 編
  • Python の unittest ではテストコードの関数名は test ではじめるよ !
  • FizzBuzz 計算をする関数名の名前は何にしようか？
  • 期待値は assertEqual 関数の第一引数と第二引数のどっちに実装しようか ?
  • Python で数値を文字列に変換するのってどう実装しようか ?
  • 3 の倍数ってどう実装しようか ?
  • “if/elif” と “if で早期リターン” のどっちを使おうか ?

• モブプログラミング超入門ライブ ! ~ モブプロのポイントを総まとめ
  • Python で文字列の中に特定の文字が含まれているかを調べるのってどう実装しようか ?
  • if で早期リターンを使う実装だと実現できないから文字列連結をする実装にリファクタリングするのはどうだろうか ?
  • “上の方” とか “その辺” だとわからないので行数で指示するのはどうだろうか ?
  • Python で文字列連結ってどう実装しようか ?
  • Python で変数に値が入っているかをどう判定 しようか ?
  • Python の unittest で例外のテストコードってどう実装しようか ?

ツイートや参加ブログなどで “とても楽しそう !” や “常にポジティブ !” や “小さく合意を得ていてイイ !” といったようなコメントをいただきました。モブプログラミングはこうあるべき ! という唯一の正解があるわけではないため、最終的には皆さんのチームで 1 番やりやすい形を模索することが重要ですが、今回のライブ配信では、私自身が好きなスタイルを紹介したいと思っていました。どんなに些細なことでもチーム全員で合意を得て、もし反対意見が出たとしても、積極的に意見交換をすることで納得感を高めることが重要だと考えています。そして、全員で参加していると感じやすくなるのではないでしょうか。

また、楽しそう ! というコメントは本当に多く、きっと 1 番印象に残ったのは「やったー🙌」ではないでしょうか。モブプログラミングをしながら、どんなに些細なことでも前に進んでいることを喜ぼう ! という雰囲気を作るように意識していました。テストコードの実行が成功したら、本当に嬉しいことですし、もしテストコードの実行が失敗したとしても “失敗すると予想して実際に失敗した” のであれば、それは期待通りの挙動で嬉しいことなんです ! 今回のライブ配信では、ある程度「やったー🙌」を強調したため、もしかしたら “多すぎでは ?” と思われた方もいらっしゃるかもしれません。皆さんのチームでそこまでやらなくても良いとは思いますが、どんなに些細なことでも喜ぶという気持ちは忘れないで欲しいと思っています。

なお、チーム全員で開発をするときに、コード管理をどうするべき ? という質問もありました。そのときに、Git リポジトリを使って、ドライバーは git push をして、次のドライバーは git pull をする「Git Handover」という Tips も紹介しました。Git コマンドで交代 (バトンタッチ) できるため、区切りを記録しやすく、とても便利です。特にリモートモブプログラミングでは Git Handover を使うことが多いと思います。Remote Mob Programming という書籍でも重要な原則の 1 つとして「Git Handover」が紹介されています。

チーム全員で取り組むことは、何もプログラミングだけではありません。「モブワーク」とも言いますが、どんなことにも応用できます。よって、最終的には「モブは働き方である」と言えるのではないでしょうか。

例えば、皆さんが運用をしているサービスで障害対応をする場合を想像してみましょう。特に号令をかけなくても、気付いたらチーム全員が同じ場所に集まって “あーでもないこーでもない” と話し合っているのではないでしょうか。このように、実は皆さんも意識せずとも「モブワーク」をされていることがあるのです。よって、作業を効率的に、品質も高く、ノウハウを共有しながら目の前の課題に取り組むときにはモブワークがおすすめです。

皆さんはどんな作業にモブワークを適用できそうですか ? 以下に思い付くものを列挙しておきたいと思います。ちなみに私は昔に “経費精算” をチーム全員で取り込んだことすらあります (笑) ほら経費精算って結構フォームが複雑で難しいじゃないですか〜 !

• 障害対応をする
• 営業資料を作る
• プロジェクト計画を策定する
• アーキテクチャを考える
• AWS ドキュメントを読む
• 業務メールの読み書きをする
• ブログ記事を書く
• 企画を考える
• 新メンバーのオンボーディングを進める
• etc