MENU
そらいろ
SEとして7年の経験があるそこそこのエンジニア。
スキルセット:C#/VB.net/HTML/CSS/JavaScript/PHP
DB:Oracle/SQLServer他etc
専門はWebアプリケーション。データ分析やRPAにも精通。
当ブログのおすすめテーマはこちら!

モブプログラミングで開発が流行り!メリットとデメリットを紹介!【リモートで開発】

最近はコロナウイルスによりリモートワークが話題ですね。

リモートで働いている皆さんの開発業務は順調に進んでいますでしょうか。

僕の職場ではチームメンバーと話す機会が減っていて、誰が何をやっているのか分からない時が多々あります。笑

IT系はリモートワークを行いやすい環境がすぐ準備できるメリットがありましたが、仕事の方式を変えるのにはもう少し時間がかかりそうですよね。

 

そんなリモートワークを効率的に行えるように、様々な開発手法を試している企業が増えてきています。

その開発手法の一つに「モブプログラミング」というものがあります。

今回はリモートワークでも使える、「モブプログラミング」という開発手法についてお話したいと思います。

目次

モブプログラミングとは

モブプログラミング」とは、一人の「タイピスト」とその他大勢の「モブ」でプログラミングを進めていく開発手法です。

それぞれの役割として、「タイピスト」は実際にコーディングを行う人で「モブ」は「タイピスト」に指示を出す人になります。

基本的に「タイピスト」は自分の意志でコーディングを行うのではなく、「モブ」から言われた通りに開発していきます。

例えとしては「ペアプログラミング」の教える人が多いバージョンを想像すると分かりやすいかもしれません。

 

「ペアプログラミング」との違いは、「タイピスト」が時間経過で入れ替わっていく点でしょうか。

「タイピスト」は教えてもらっている人ではなくコーディングに集中している人になります。

一般的に「タイピスト」は15分や30分ほどで入れ替えていくことが多いようです。

 

リモートワークで注目されている点としては、チームの人間が一つの機能に集中することでチームワークの向上を狙える点にあると思います。

全員が別々の場所で働くことによってチーム力が下がってきているという問題は多くの職場で存在しているのではないでしょうか。

生産性にもかかわってくるので、全員が同じ方向を向いて仕事ができるようにしたいですよね。

モブプログラミングのメリット

意思決定/情報共有の速度

意思決定や情報共有のスピードは格段に早くなります

通常であれば、

通常
  1. 開発者が仕様等の壁に当たる。
  2. 設計書の熟読や他の機能のコーディングを参考に改善策を考える。
  3. 二進も三進もいかなくなって初めて設計者に確認する。
  4. 設計に不備があれば、設計者が修正する。
  5. 他の機能への影響や類似仕様がある場合は、チームメンバーに共有する。
  6. 開発者がコードを修正する。

となるケースが「モブプログラミング」だと下記のようになります。

モブプログラミング
  1. 「モブ」が仕様の誤りに気付く。
  2. その場で仕様の確認と決定を行う。
  3. 「タイピスト」に指示を出す。

設計者やチームリーダーが同席していることが基本になるため、当然「意思決定」や「情報共有」は速くなるわけです。

設計側の分からなかったら早く聞いてくれという気持ちと、開発側のよくわからずに時間を浪費する行動が解消されますね。

レビューの省略

各区切りでレビューを行うと思いますが、それを省略することができます。

開発段階であればコードレビューが主になると思いますが、全員がその機能のコーディングを見ているわけですからコードレビューを行ってもほとんどフィードバックが発生しません。

開発とレビューが同時にできてしまうので一石二鳥といったところですね。

コーディングだけで見れば複数人で1機能を作っているので効率が悪くなりますが、このように他の作業も同時に行えていれば作業効率が落ちない状況を作れます。

全体のレベルの底上げ

新人などの技術力が低いプログラマーが参加していれば、その人たちのレベルアップが行えます。

業務の進め方やツールの効果的な使い方を参加メンバーで同時に共有できるからですね。

また他の人が作業する様子を見て、業務効率化の方法を発見できる場合もあります。

複数人で作業を進めることで自分の知らなかった知識を得ることができるので、勉強会のような形で開催するのもありかもしれません。

モブプログラミングのデメリット

複数人で一つの機能を作るので時間がかかる

うまくやれば業務効率を高めることができるようですが、僕の環境では時間がかかりすぎてしまいました。

やはり全員が一つの機能に集中してしまっているため、他の作業がストップしてしまうのがネックになります。

「モブプログラミング」を行う部分を限定的にするなど、対策が必要になるかと思います。

一回で完璧な「モブプログラミング」を行うのは難しいので改善を行っていく必要がありそうです。

メンバーに積極性がないと意味がない

やはり3人4人と増えていくと、会話に参加できないメンバーが出てきてしまいます

ひどい場合は、「モブ」側の一人が延々と「タイピスト」に指示を出すという構図が出来上がってしまいます。

初めのうちは、リーダーが発言できていない人にボールを投げてあげるような工夫をし、会話に参加しやすい雰囲気を作っていくことが大切になりそうです。

コードや資料の共有に時間がかかる(リモート限定)

通常は「タイピスト」用のパソコンが用意されており持ち回りで使用するのですが、リモート時においては各自のパソコンで作業するようになります。

※社内のサーバーに共有の開発スペースが準備できるということであれば問題ないかと思います。

僕がやった際には各自のパソコンで進めたので、ソースコードをリポジトリにコミットし次の人がチェックアウトするというのを繰り返していました。

細かいところですが、「タイピスト」の交代がスムーズにいかないと作業効率も落ちてしまうので注意が必要です。

まとめ

以上がモブプログラミングのメリットデメリットでした。

これから試してみようという方の参考になれば幸いです。

もし本格的にチャレンジするようであれば、下記の本も参考になるかと思いますので一読されることをお勧めします。

よかったらシェアしてね!
目次
閉じる