nozayasu

仕事全般/マネージメントで考えたこと

チーム開発とコードレビュー

チーム開発にコードレビューが持たらすものはなんでしょうか?

  • コード品質の向上
  • ナレッジの共有
  • 仕様不備の発見
  • 不具合の発見

コードレビューの成果物として、パッとこのようなものを思い浮かべました。

上記のような成果物を得ることは、望ましい姿と言えます。

しかし同時に、自分にとってこれらの成果物=目的ではありません。

あくまでコード品質の向上等は、コードレビューという体験を通して発生した副次的なものです。

コードレビューの目的は、XPのプラクティスにて示されている、コードの共同所有権 (Collective Code Ownership)の実感と熟成であると自分は捉えています。

今回はなぜコードの共同所有権を必要とするか、コードレビューがそれにどう関係するのかを言葉にしておきたいと思います。

コードを通したプロダクトへの貢献

一般的に業務としてコードを書く場合には、コードの総体であるプロダクトへの貢献が求められます。

コードを通したプロダクト貢献を、定性的・定量的という2軸にわけて考察してみます。

定性的貢献 : プロダクトコードへの責任感、品質への探求心、etc…
定量的貢献 : プロダクトコードの理解範囲、詳細理解の深さ、etc…

ここでいう定性的と定量的とはこのようなものを考えており、さらにそれぞれの貢献度合によって、メンバーのチームにおける立ち位置を四分類として表現すると、以下のようになります。

定性的貢献 小 定性的貢献 大
定量的貢献 大 作業者 自立者
定量的貢献 小 依存者 学習者

この分類を、チーム構成に当てはめて考えを膨らませてみます。

ぎくしゃくしたチーム

作業者と依存者で構成されたチーム

定性的貢献を重視するメンバーが少ないことで、チームとして自己タスク範囲外に興味が薄く、たとえ障害時であっても作業範囲が明確に分離されていることが多い。

学習者と依存者で構成されたチーム

定量的貢献を重視するメンバーが少ないことで、チームとして理想像は掲げるものの実行力が弱く、やりきれず目の前の仕事に追われることが多い。

ぎくしゃくしたチームには、精神的にも実務的にも、余裕が不足しているようにイメージできました。

なめらかなチーム

自立者が主となり構成されたチーム

チームとしての理想を、個人の実行力で支え合っており、チームとしての余裕を作り出し、プロダクト価値探求に時間をとれていることが多い。

なめらかなチームには、精神的にも実務的にも、意図的に余裕を作り出しているようにイメージできました。

チーム開発の課題

ぎくしゃくしたチームと、なめらかなチームとの違いは、変化への対応能力です。

プロダクトを運用をしていくことは、障害・レガシー化・体制変更・ピボット等の大小あれど何かしらの変化に直面します。

価値探求と安定稼働を、変化を受け入れながらこなせなければ、チームはぎくしゃくしだすのだと思います。

そこに健全なプロダクト運営のため、なめらかなチームを目指す必要性と、自立者をいかに育てるのか?というチーム開発の課題がうまれました。

自立者とコード所有感

さて次は、率先してコードでプロダクトへ貢献する、自立者を育てる仕組みの考察をしていきたいと思います。

定性的貢献定量的貢献 の両立をしているメンバーのことを、自立者として分類しました。

  • プロダクトコードへの責任感、品質への探求心、etc…
  • プロダクトコードの理解範囲、詳細理解の深さ、etc…

これらを両立することは、プロダクトに関連するコード*1であるという一点が満たされるのであれば、それを自分のものとして向き合うことではないか。

つまりは自立者に近付くということは、プロダクトに関連するコードの自己所有感を拡大することだと自分では解釈しています。

ならばチームとして取り組むべきは、コードの自己所有感を最大化し、自立者であり続けるための環境整備だとイメージできました。

そしてその環境整備の1つが、コードレビューです。

コードの共同所有権

コードの共同所有権 (Collective Code Ownership)の理解を深めるために、概要を引用します。

チームの誰もがコードを改善するために変更を加える権限を持つ必要があります。全員がすべてのコードを所有する、すなわち全員がコードに対し責任を持つことになります。この技法では、開発者は、個人のコード所有者を気にすることなくコードを変更することができます。全員が責任を持つという事実により、コードが誰にも所有されずに混乱状態が起こることもありません。

XP の真髄 より引用

なるほど、分かりやすい。コードに対してメンバー全員が権限と責任を持つことだと理解しました。

責任について少しだけ突っ込むと、共同所有とした結果、個人の責任感が希薄になりうる危険性を含んでもいると感じています。

実体験として責任が曖昧な状態となり、無視されるようなコードを見てきました。これは望む形ではありません。

そこでチームとして運用責任の比重を、個人的には明確にしたほうが良いと考えています。

具体的にはリーダー・主担当といった役割の表現をすると共に、責任の比重を役割に関連付けて最終防衛ラインを設定するようなことです。

参考: コードの共同所有に弱点はあるか?

コードレビュー

コードの共同所有権を目的とした場合、コードレビューはどのように捉えたらよいでしょうか?

共同所有を前提とすると、以下のようなことが考えられます。

  • 技術レベルやプロダクト理解度の差異による、個人間のコード所有感に違いがあっても、向き合うコードは同じものである
  • 他者が作成したコードを自分も運用することである
  • 運用するということは、メンテナンス、障害対応、概要説明責任を粒度あれど担うことである

共同所有を前提にするということは、現在の状況を考慮しつつも同じ土俵にあがることだなと自分は捉えています。

同じ土俵にあがることで、徐々に個人間の差異を埋められて、自己のコード所有感は広がっていくことでしょう。

徐々にを許されるのであればよいですが、チームや会社からはより早い貢献が求められることも多いと感じています。

コードの共同所有権を目的とした場合のコードレビューとは、自分がこのコードを運用するならばどうするか?を考えるための機会提供と継続性のサポートなのだと思います。

継続的に考え、フィードバックを得ることで、個人間の差異を効果的に埋めていくことに繋げる。

なので自分としては現在の状態(技術レベルやプロダクト理解度)で、自分が運用するのなら?という観点で堂々と疑問を投げかけたり、理解するための行為を推奨したいです。

まとめ

  1. プロダクト運用は変化が伴う、それにうまく対応するのはなめらかなチーム
  2. なめらかなチームであるために、自立者にいかに近付くのかが課題となる
  3. 自立者に近付き、維持するためにコードの自己所有感を拡大していきたい
  4. コードの自己所有感の拡大サポートを、仕組みにしたものがコードレビュー
  5. なのでコードレビューの目的は、コードの共同所有権の実感と熟成と捉えた

このような観点と、思考の流れを整理できました。

とすればコードレビューはメンバーに等しく意味のある仕組みなので、技術レベルが高いといった特定の人だけが担うものではなくなり、チームメンバー全員で担うものとなりますね。

おしまい。

*1:極端に言ってしまうとRuby等の、プログラム言語自体も関連するコードと考えています。とはいえ個人の意欲と程度問題なので、現実的には必ず深い部分までを求めるということではありません。