はじめに
モブプログラミングは、各自がソロで分業するよりも、少ない機能を早くリリースすることに適しており、楽しい上に、知見も共有できると思います。
本稿は、社内向けのWebサイトを開発する際のモブプログラミングでの会話を公開することで、その魅力を感じてもらうことが目的です。
モブプログラミングとは
1つのディスプレイの前で3人以上で議論しながら開発することです。ドライバー役(キーボードを打つ人)が1人に対して、ナビゲーター役(指示する人)が2人以上になります。詳細は以下の記事を参照ください。
明日からできる働き方改革「モブプログラミング」
モブプログラミングのよくある誤解
対象プログラム
私の社内には、技術記事を投稿する社内版Qiitaのようなシステムがあります。
ただ、そのシステムには、いいねの数でランキング表示する機能がありませんでした。
そこで私は「いいねランキングがあった方が投稿者のモチベーションが上がる」と考え、「月間いいねランキング」を表示するWebサイトを有志で作成することにしました。
イメージとして下図のような感じです（記事タイトル、投稿者名、投稿日時、いいね数を表示）。
上記Webサイトを作るにあたって、以下のReact記事のプログラムをベースにさせていただきました。この記事のプログラムで呼び出しているWeb APIを変更して、アニメ一覧の代わりに記事一覧を表示すれば、リリースできるだろうと考えました。
Reactで誰もがやりたかった10の機能。アプリ構想はあるけど作れない人の壁をぶっ壊す。
しかし、集まったメンバーは全員__JavascriptもReactも初心者__であり、知識レベルとしてはReactのチュートリアルをやって上記のReact記事を読んだだけの状態でした。
そんな貧相な知識レベルでしたが、__モブプログラミングでたった2時間__でリリースできるプログラムが作成できました。
以下にモブプログラミングの実際の様子を紹介します。
モブプログラミングの実施
以下はモブプログラミングを実施した3人での会話です(一部脚色していますが概ね事実です)。
「よし、まずは今回使うWeb API(社内システムに投稿された記事一覧を取得するAPI)がどんなレスポンスを返すか知りたいね」
「じゃあ、Web APIを実行してレスポンスを確認しよう(Web APIのヘルプが見つからないため)。」
「実行できたよ、あっ、レスポンスに投稿者のIdはあるけど名前がない。」
「これじゃあ、投稿者の名前が表示できないね」
「投稿者の名前を表示するには、投稿者一覧のAPIも実行する必要があるから、作る難易度が上がるよ」
「じゃあ、投稿者を表示する機能は無くそう！それがなくてもリリースはできるよ」
「それだ！」
「おっと、APIのパラメータで、投稿日時でフィルタする機能がない。投稿日時の降順に記事を取得する機能しか提供されていないよ。」
「ええっ！？それがないと、月間ランキングを表示できないよ」
「じゃあ月間ランキングはやめて、直近の投稿記事30件のランキングにしよう。1ヶ月当たりの投稿数は30件くらいなので、それでも十分価値は提供できるよ」
「それだ！」
（その後、ベースプログラムでWeb APIを呼び出しているURLを、記事一覧を取得するAPIに変更）
「あとは、APIで取得した記事一覧を画面に表示する所だね」
「ベースプログラムでも、別のAPIを取得して、別の一覧を表示しているから、それを変えればできそう」
「ちょっと待って。APIのレスポンスを格納した変数名が、ベースプログラムの変数名のままだと、混乱しやすいね。変更する関数内の変数名は、適切な名前に直そう」
「それだ！・・・・こんな感じ？」
「うん、これで何をやっているか分かりやすくなったね」
（その後、APIで取得したデータを画面に表示させることに成功）
「とりあえず、Web APIで取得した記事のタイトルを画面に表示できたね」
「でも、これをいいねの多い順にソートしないといけない」
「Javascriptで、連想配列をソートする方法なんて知らないよね」
「じゃあ、検索だ！キーワードは？」
「Javascript 連想配列 ソート」
「あった！これでソートできる！」
「できた！記事をいいね順に表示できたぞー！」
「やったー！」(一同、喜ぶ)
モブプログラミングの効果
上記会話の太字部分が重要な部分です。以下に解説します。
スピーディーな仕様変更
仕様を決定できる人が一緒に取り組むことで、プログラミング中の仕様変更を随時決定できます。MVP(Minimum Viable Product)でリリースする場合、この恩恵はとても大きく、とにかく価値が享受できる最小機能を素早くリリースするためには、スピーディーに仕様変更を決定することが重要になります。
今回作ったプログラムに色々問題はありますが「いいねランキングができることで、投稿者のモチベーションを上げる」という目的を達成するために、最小機能でリリースしました。今後、社内からのフィードバックを元に改善していけば良いと思っています。
俯瞰した視点からの提案
ナビゲーターは、手を動かしているドライバーと違って、余裕があるため、俯瞰した視点に立てます。
そのため「ちょっと待って、変数名を直そう」と提案するなど、1人だと気付きにくい問題を見つけやすい立場になります。
暗黙知の共有
一緒に作業をすることで、考え方や思考過程の暗黙知を共有できます。
以下に暗黙知の例を記します。
- 分からないことがあった場合の調査方法(ググり方を含む)
- 設計・実装する時の思考過程
- 何から優先して行うかなどの判断過程
- 各種ツールの便利な使い方などの小ネタ
機能ができた時の達成感
とても大事なこととして、一緒にワイワイ会話しながら物ができていくことは、とても楽しく感じます。
そして、機能が動作した時の達成感を、メンバー皆で共感できます。
「楽しい」というのは、とても大事なことで、楽しい時間はとても集中して取り組むため、高い生産性で開発できます。
また、モブプログラミングで開発しているチームは、開発中の議論でお互いの考え方の理解が深まることで、心理的安全性も高くなる傾向があると思います。
まとめ
モブプログラミングは、早く楽しく開発できるプラクティスです。
本稿と同じ日に↓こちらも投稿しました。
仕事の進め方の良し悪しを見える化したら、各自が自分で行動を改善してくれた話
私は上記手法を用いて こちらのツール を作ったりしています。
Twitterでも開発に役立つ情報を発信しています → @kojimadev