ペアプロ・モブプロを広めるのに役立ったControl Chartの使い方
この記事はAttlassianAdventCalendar2018の8日目の記事です。
こんにちは！ この記事では以前発表した資料（モブプログラミングという開発スタイル、あるいは生産性について）を参照しながら、ペアプロ・モブプロとはどんなものか、なぜ有効な開発スタイルなのかを説明するとともに、株式会社エウレカ内でペアプロ・モブプロを広める際に役立ったJiraのReportの1つであるControl Chartについて紹介します！Control Chartの説明だけ見たいんじゃい！という方は目次から飛んで飛ばして読んでいただくこともできます。
目次
- ペアプロとは
- モブプロとは
- ペアプロ・モブプロの経験がない人からよくある質問
- 複数人で同じことをしていては生産性が下がるのでは？
- 参加者にスキル差があるとうまくいかないのでは？
- JiraのControl Chartとは
- 新しいことを始めて運用に乗せる時の勘所
- 定量と定性で示す
- 繰り返し示す
- おわりに
ペアプロとは
ペアプログラミング（英: pair programming）は、2人のプログラマが1台のワークステーションを使って共同でソフトウェア開発を行う手法である。
wikipediaによると上記のように定義されています。 ペアプログラミング - Wikipedia
もう少し具体的に噛み砕くと同じ仕事を同じ場所で同じ時間に同じコンピュータを使って作業するのがペアプログラミングです。この条件はモブプログラミングでも同じです。
モブプロとは
ペアプロを2人から人数を増やして3人以上で作業することをモブプログラミングといいます。手を動かしてコードを書いている人以外の人数が増えることになります。 下記はモブプログラミングを複数のチームで行っている様子を動画に収めたものです。
ペアプロ・モブプロの経験がない人からよくある質問
複数人で同じことをしていては生産性が下がるのでは？
生産性とはなにか？というところでも議論が分かれそうですが、ここではある開発タスクに着手しfeatureブランチを切ったところからmasterブランチにマージされるまでの時間とします。
2つの開発タスクがある場合に、ペアプロやモブプロで複数人で1つずつ片付ける場合と2つの開発タスクを同時に別々の人が進める場合にどちらのほうが時間が短くなるでしょうか。
それぞれの開発を1人でやった場合とペアプロで片付けた場合、かなり単純化していますが下記のようにペアプロでやったほうが時間が短くなります。
参加者にスキル差があるとうまくいかないのでは？
経験豊富でスキルを持ってる人からするとペアとなった相手に知識を伝えることが多くなり、退屈だなーと感じる人も中にはいるかも知れません。 しかしペアの相手が知識をつけて成長していくことで中長期的に見ればチームの総合力が上がっていくことになります。 そうすれば将来の自分が助けてもらえるようになることもあるかもしれません。 以前ペアプロ・モブプロについて発表した時の感想でも良かったという声が届いていました。
.@futabooo さんのこの発表に影響を受けて社内でモブプロ試してみたけどとても良かった！いつも以上に考えてコーディングしたし細かいノウハウも伝授できてメリットありまくりだったので継続します！ / モブプログラミングという開発スタイル、あるいは生産性について / https://t.co/QNNOho80fg
— setoh (@seto_hi) 2018年7月11日
やったことがないことに対してやらない理由を探すよりも、まずはやってみてアリかナシか判断してみても良いのではないでしょうか。 （AttlassianAdventCalendarなのにここまでペアプロ・モブプロの話しかしてない）
JiraのControl Chartとは
ここからが今回の本題です！ Control Chartとは特定の期間において、あるProjectのチケットがそれぞれどのぐらいの時間で完了したのかとその平均を見ることができる図です。
これまで説明してきたようにペアプロ・モブプロはチームに取って良いことがたくさんあります。 チームがやる気になってもステークホルダーや関係者からは疑問の声が上がるかもしれません。
今では複数のチームでペアプロ・モブプロが当たり前になってきたエウレカ社ではありますが、導入に際して役に立ったのがJiraのControl Chartです。実際に触って見てもらうことが一番の理解の近道だと思いますが、ここでそれぞれの表示の説明をしたいと思います。
全体としての図の見方は右上を読むとわかります。
緑の円や点はJiraのチケットを表しています。点になっている場合は同じぐらいのサイクルタイム1のチケットがまとまりとして表示されている状態です。
赤い線はこの緑の円や点が表しているサイクルタイムの平均、青い線が直近数チケット分の移動平均となります。
サイクルタイムを測りたい期間を設定するのは画面中央下にあるRefineReportの部分を調整します。画像ではTodoに入ってからInprogressを出ていくまでの期間を指定している状態です。
以前モブプロについて発表した時点での私達のチームでは下記のような状況でした。 少し見づらいのですが4月からモブプロを導入し、青い戦の移動平均が小さくなっていることが見て取れます。モブプロによってチケットの完了までのサイクルタイムが短くなったということです。
このあとのスライドにもありますがGithubのCode Frequencyはモブプロ開始後のほうがむしろ上がっており、作業量自体も向上しています。
このように定量的にモブプロの有用性を示すのにJiraのControl Chartが大変役立ってくれました。
新しいことを始めて運用に乗せる時の勘所
モブプロに関わらずチームになにか新しい仕組みややり方を導入する場合に以下の2点を意識するようにしています。
- 定量と定性で示す
- 繰り返し示す
定量と定性で示す
今回のモブプロ導入にあたってはControl Chartを使った定量的な説明と、実際にモブプロしているチームに体感でどう思ったか？というのを聞いたりした上で社内でもモブプロのススメとして話をしたりしていました。 今ではたくさんのチームがコーディングをペアプロやモブプロでやっています。最近ではバックオフィスチームやプロダクトマネージャチームでナレッジを持った意図と一緒にペア作業している姿も見かけます。
繰り返し示す
モブプロ導入においては私達のチームよりも前に実践していたチームがいました。彼らも社内へ発信してくれていました。 個人の習慣を作るのと似たように、チームに新しいことを初めて定着させるためにはめんどくさいやつだと思われても繰り返しなぜやるのか・なにが良いのかを示し続ける必要があります。
おわりに
社内にペアプロ・モブプロを広めるのに役立ったControl Chartの話をしました。 ControlChat以外にもJiraのReportsにはチームがうまくやれているか？を定量的に見せてくれるものがたくさんあります。 メトリクスを取る目的をはっきりさせた上で、今後もいい感じに使っていきたいと思います。
