開発チームのチーム力の向上について

iCAREでVPoEをしております安田と申します。
今日は弊社開発部での出来事を通して自分が開発手法について考えたことを書いてみたいと思います。

チームメンバーから否定された意見

先日、iCAREの二つの開発チーム内でモブプロもしくはコードレビューミーティングの推進(もしくは導入)の提案をしました。片方のチームでは非常に乗り気で全く問題なかった(すでに自発的に行われているという事情もあります)のですが、もう一つのチームでは、全員ではないにしろ導入に否定的なメンバーがいました

否定的な意見を持つメンバーの主張は、主に「それらをやることにメリットを感じない」というものでした。
様々な状況があるので、モブプロもしくはコードレビューミーティングがいつでもメリットを持つとまではさすがに考えてはいません。
ただ、iCAREの開発の状況を踏まえると、それらを実践することでメリットが生まれると考えたので提案したのですが、提案の中でそれらのメリットについて十分な説明ができなかったので、ここでそのメリットについて考察してみたいと思います。

もちろん、モブプロとコードレビューミーティングは相互に関係ない技法なので別々に考察してみたいと思います(ただ、弊社開発部のニーズからそれらが一緒に検討されているというだけの話です。)

なお、ここで考察するのは「意義」についてであって、その方法論とかやり方については考察しません。

モブプロ

さて、モブプロの方の意義についてですが、

モブプロにやりづらさを感じて改善した話

にまとめられている通り、
- チーム内で知識の共有ができた
- チームワークが良くなった
といった具合に、「チーム」「チーム開発」へのメリットが大きいと思われます。

もし、これらのことに意義が感じられないとすると、それは
- チームが非常にうまく機能していて、そこに問題が生じていない
- メンバーが「チーム開発」がうまく機能している、機能していないに関心がない(「チーム」としての質が、「個々人のエンジニア」に与えるインパクトがよく理解されていない)
のどちらかではないかと思います。
弊社iCAREの場合、課題がないほどにチームがうまく機能しているとは到底言えないと思いますので、後者の問題になるのではないかと思われます。

チームとしての質とは何かについては後述したいと思います。

もう一つ、注意するべきことは、

実践して分かったモブプログラミングのメリット・デメリット

上記サイトにも記されている通り、メリット・デメリットがあり、生産的にモブプロをするのは簡単ではないということです。
モブプロに意義を感じる感じないとは別に、モブプロの「困難さ」が原因となって、それに対する否定的な姿勢につながる可能性もあると推測されます。
もしそうだとすると、モブプロに対して否定的になるケースは、「自分のチームではこうした困難さを乗り越えられないのではないか」と考える場合、もしくは感じる場合なのかもしれません。

コードレビューミーティング

残念ながらこれについては参考にできそうな日本語サイトを上手く見つけられなかったので、英語のサイトを参考にします。

Do Code Review Meetings Still Make Sense in 2019?

この記事は、コードレビューの歴史(1976年の IBMの研究〜GitHub, Visual Studioの登場等)をたどりつつ、GithubのPRのようなピアレビューが全盛の時代においてコードレビューミーティングに意義があるのか?を問うています。

この記事での答えはYesです。

ただ、この記事で最良のアプローチとして挙げているレビューミーティングのやり方はいきなりグループでコードをレビューすることではなく、ピアレビューされたものを再度グループで取り上げる、というものです。

Fostering Collective Ownership and Learning
のセクションになぜレビューミーティングが有益かが詳しく記されていますが、その一部を紹介します。

直近のレビューで学んだことをコードレビューミーティングでメンバーに共有してください。そうすることで、少人数でなら容易に起こりうるスキルの共有、チームを越えての学習の共有ができます。このプラクティスは協力的で学習する文化を強化します。
学習、メンターシップを重要な価値として最優先化することで、あなたのチームは、新しいスキルと技術を毎週毎週身につけ、アクティブであり続けることができます。
[ Fostering Collective Ownership and Learningの一部の筆者訳 ]

ここで言われていることでも、キーになっているのは、このコードレビューミーティングがエンジニア個人に「直接」強い影響を持つということではなく、チームに対して、もしくは組織やカルチャーに対して大きな影響を持つということです。

チームとしての質の向上

ここまで読んでいただければ、なぜ自分がモブプロとグループレビュー(or コードレビューミーティング)をひとくくりにして話題に挙げているか理解いただけるかと思います。
単なるピアレビューやペアプロを越えて、これらを実施したいという意図は、開発メンバーに「シングルプレイヤー」として成長することを期待するためなのではなく、「チームプレイヤー」として成長することを期待するためです。

単にテクニカルな意味で質の高いシングルプレイヤーが集合すれば、組織として高い生産性を挙げられるかというと、そうではないはずです。テクニカルな能力だけでなく、チームプレイヤーとしての能力も備えていない限り、組織の中で価値を発揮することはできないはずです。その能力はモブプロやコードレビューミーティングのようなコミュニケーションにおいてより効率的に伸ばすことができると思います。

メンバーひとりひとりがチームプレイヤーとして成長すれば、チームおよび組織もそれにともない高い生産性を発揮できるようになり、メンバーひとりひとりもそのチームの一員として開発することがより楽しく充実したものになる。そのような好循環が生まれるのではないかと思います。

上記のような施策を通して、iCAREのVPoEとして、開発チームのチーム力向上、またメンバーのチームプレイヤーとしての能力向上を図って行きたいと思います。

この記事が気に入ったらサポートをしてみませんか?