モブプロで成功記録をつけてみることにしました

こんばんは。沖縄移住組 IT エンジニアの勇大（id:yudy1152）と言います。

2019年1月から3人でスクラムチームを組み、1日中モブプロで開発をしています。それまでモブプロの経験はありませんでした。

スクラムやモブプロについて日々試行錯誤しながらやっていて、モブプロのメリットやチームとしてよくなってきたという実感を得ています。

しかし最近、「成長を実感できていないな。言われれば分かるけれども身に付いてる気がしないな。」という問題点が出てきました。

チーム、個人に関わらず、成長を実感できたり、何かしらの形で可視化できれば、仕事がもっと楽しくなるんだろうな、と思っていました。

そんな中、以下の本を読んで、早速私たちのチームで取り組んでみることにした事について記事にしました。 （と言ってもまだ全部読みきれていません・・・汗）

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

本に書かれていた内容

1.3.2 成功をどのようにして計測するか に書かれていた内容を自分なりにまとめてみます。

• 計測は難しい！

モブプロはフロー効率*1を上げるが、フロー効率が上がった状態になるまでにはある程度時間がかかる。 そのため、チームの短期的な「ベロシティ」を計測してもわからないし、数値で成功を計測するのは難しい。

• 効果が現れる計測方法として以下の4つが挙げられています。

• マージコンフリクトの解決にかかる時間の短縮
• 本番システムに入り込む欠陥の数の減少
• チーム内の経験の浅いメンバーの学習度の上昇
• チームがモブプログラミングの導入を改善と感じているかどうか

これらについて、私たちのチームの現状はどうだろう？と考えてみました。

マージコンフリクトの解決にかかる時間の短縮

モブプロをしていなかった時には、1人1タスクで進めていました。その時はそれぞれでブランチを切り、プルリクを出し、レビューしてもらって、develop ブランチへマージ、という作業が発生していました。 もちろんこの時コンフリクトが発生することもしばしば・・・。

ところがモブプロを始めてからはこれらの作業が一切発生していません。

1日中モブプロをしていて、常にお互いレビューし合っている状態でブランチへコミットしていっているため、この時間の短縮以上に、コンフリクトの解決やレビューのストレスといったものが軽減されていることを実感しています。

本番システムに入り込む欠陥の数の減少

今の開発の流れでは、develop へマージした後は、開発環境にデプロイされ、UI ベースのテストをしてもらっています。

私たちのチームが開発した機能に関してはまだ不具合の報告がありません。（キリッ！）

いや、本当は不具合が出ているけれども、こちらにタスクが回ってきていないだけかも・・・？と若干疑っています（笑）

とはいえ、日々のモブプロで感じたことで、1人でタスクをこなしている時よりも、常に他に2人が目を光らせていることで、すぐに「あれ？そこのカラム更新されてなくない？」、「ん？そのコードだと不具合が起こる可能性あるかも」、「こういう操作した時はどうなるか確認した方がいいね」といった感じで、妥協させてくれません（笑）

もちろん私自身も、自分が1人で操作して確認するよりも、客観的に見ることで視野を広げて確認することができ、きっとそういった積み重ねが 本番システムに入り込む欠陥の数の現象 に繋がるんだろうなと実感しています。

チーム内の経験の浅いメンバーの学習度の上昇

私たちチームは確実に成長していると思っています。 しかし、冒頭でも書きましたが、3人で「成長してきているかな？」という話をたまにするのですが、あまりピンとくる反応がありませんでした。

チームがモブプログラミングの導入を改善と感じているかどうか

これはもうみんな「もちろん！」と答えてくれるでしょう。

---

2019年3月13日　記録開始！

今日がスクラムのふりかえりの日でして、成功記録をつけていこうという話し合いを行いました。

「例えば1ヶ月後、2ヶ月後、ふりかえった時に何があれば成長を時間できるだろう？」といった視点にたち、以下のようなアイデア出し、実行していってみよう！となりました。

1. ポモドーロで作業した際に、気づいたこと、理解できたこと、ハマったこと、分からないことなど、小さいことでも記録する
2. 作成した function、修正した function（たった1行でも！）の数
3. タスク管理（Backlog）のタスク消化数

1. ポモドーロの際の記録に付いて

普段からモブプロを行う際に、ポモドーロ（25分の作業＋5分の休憩）で回していて、Slack に何のタスクをやったかを記録していました。その日の最後に1日をふりかえりしやすくする意図がありました。

なので、その時についでに何かしら思ったことなどを気軽にコメントとして残していってみよう、となりました。 記録する際には、 Slack だと埋もれてしまうので、Google スプレッドシートで記録するようにしました。

こういった小さな積み重ねを後で見返した時に、理解できた事や、できるようになった事が「これだけ増えたんだ！」というのが目で見て分かれば、きっと成長を実感できるんじゃないかと思います。

2. function の数について

以前チームのメンバーが上司と1on1を行った際にアドバイスとしてもらったアイデアです。

新しく作る function だけでなく、例えば100行を超える程の function のリファクタリングをして、適切な意味のある小さい function に切り分けていくだけでもスキルが求められると思いますし、コミット時に差分を見て、今回のタスクでどれくらいの function に携わったか、というのは簡単に数えられるので記録していってみよう、となりました。

3. タスクの消化数

function にも話が通じる部分があると思うのですが、単純にタスクを小さく切って数を伸ばそう、という事はもちろんせず、 タスクを切る際に、同じような粒度で切る、もしくはストーリーポイントのように、何かを基準にして○倍くらいのタスクか、といったように、 比較しやい粒度でタスクをうまく切っていけるようにする、といった狙いがあります。

最後に・・・

「成長を実感したい！」というみんなの想いから、まずはやってみよう！という所から始まりました。

1週間ごとにスクラムのスプリントを回しているので、この記録方法についてもふりかえりを行い、改善できる所は改善して進めたいなと思っています。

そして、この記録の経過や、チームメンバーの実感具合などブログで報告できたらなと思います。

※スプレッドシートに記録したことを定期的に Slack へ投稿したり、集計した結果を投稿したりしてみたら面白いかも？と思ったので、今度挑戦してみようかなとも思います。 その時のこともブログのネタにしようかな、と思ってます。

*1:機能を安く作るのではなく、早く完成させることを目標とし、機能全体を早く市場に送り出すことを重視する考え方。