不具合の発見コードレビューの成果物として、パッとこのようなものを思い浮かべました。上記のような成果物を得ることは、望ましい姿と言えます。同時に、自分にとってこれらの成果物=目的ではありません。コード品質の向上等は、コードレビューという体験を通して発生した副次的なものです。Ownership)の実感と熟成であると自分は捉えています。今回はなぜコードの共同所有権を必要とするか、コードレビューがそれにどう関係するのかを言葉にしておきたいと思います。一般的に業務としてコードを書く場合には、コードの総体であるプロダクトへの貢献が求められます。コードを通したプロダクト貢献を、定性的・定量的という2軸にわけて考察してみます。深さ、etc...ここでいう定性的と定量的とはこのようなものを考えており、さらにそれぞれの貢献度合によって、メンバーのチームにおける立ち位置を四分類として表現すると、以下のようになります。学習者この分類を、チーム構成に当てはめて考えを膨らませてみます。したチーム作業者と依存者で構成されたチーム定性的貢献を重視するメンバーが少ないことで、チームとして自己タスク範囲外に興味が薄く、たとえ障害時であっても作業範囲が明確に分離されていることが多い。学習者と依存者で構成されたチーム定量的貢献を重視するメンバーが少ないことで、チームとして理想像は掲げるものの実行力が弱く、やりきれず目の前の仕事に追われることが多い。したチームには、精神的にも実務的にも、余裕が不足しているようにイメージできました。なめらかなチーム自立者が主となり構成されたチームチームとしての理想を、個人の実行力で支え合っており、チームとしての余裕を作り出し、プロダクト価値探求に時間をとれていることが多い。なめらかなチームには、精神的にも実務的にも、意図的に余裕を作り出しているようにイメージできました。チーム開発の課題ぎくしゃくしたチームと、なめらかなチームとの違いは、変化への対応能力です。プロダクトを運用をしていくことは、障害・レガシー化・体制変更・ピボット等の大小あれど何かしらの変化に直面します。価値探求と安定稼働を、変化を受け入れながらこなせなければ、チームはぎくしゃくしだすのだと思います。そこに健全なプロダクト運営のため、なめらかなチームを目指す必要性と、自立者をいかに育てるのか?というチーム開発の課題がうまれました。自立者とコード所有感さて次は、率先してコードでプロダクトへ貢献する、自立者を育てる仕組みの考察をしていきたいと思います。両立をしているメンバーのことを、自立者として分類しました。深さ、etc...これらを両立することは、プロダクトに関連するコード*1であるという一点が満たされるのであれば、それを自分のものとして向き合うことではないか。自立者に近付くということは、プロダクトに関連するコードの自己所有感を拡大することだと自分では解釈しています。チームとして取り組むべきは、コードの自己所有感を最大化し、自立者であり続けるための環境整備だとイメージできました。その環境整備の1つが、コードレビューです。Ownership)の理解を深めるために、概要を引用します。チームの誰もがコードを改善するために変更を加える権限を持つ必要があります。全員がすべてのコードを所有する、すなわち全員がコードに対し責任を持つことになります。この技法では、開発者は、個人のコード所有者を気にすることなくコードを変更することができます。全員が責任を持つという事実により、コードが誰にも所有されずに混乱状態が起こることもありません。引用なるほど、分かりやすい。コードに対してメンバー全員が権限と責任を持つことだと理解しました。責任について少しだけ突っ込むと、共同所有とした結果、個人の責任感が希薄になりうる危険性を含んでもいると感じています。実体験として責任が曖昧な状態となり、無視されるようなコードを見てきました。これは望む形ではありません。そこでチームとして運用責任の比重を、個人的には明確にしたほうが良いと考えています。具体的にはリーダー・主担当といった役割の表現をすると共に、責任の比重を役割に関連付けて最終防衛ラインを設定するようなことです。コードの共同所有に弱点はあるか?コードレビューコードの共同所有権を目的とした場合、コードレビューはどのように捉えたらよいでしょうか?共同所有を前提とすると、以下のようなことが考えられます。粒度あれど担うことである共同所有を前提にするということは、現在の状況を考慮しつつも同じ土俵にあがることだなと自分は捉えています。同じ土俵にあがることで、徐々に個人間の差異を埋められて、自己のコード所有感は広がっていくことでしょう。徐々にを許されるのであればよいですが、チームや会社からはより早い貢献が求められることも多いと感じています。コードの共同所有権を目的とした場合のコードレビューとは、自分がこのコードを運用するならばどうするか?を考えるための機会提供と継続性のサポートなのだと思います。継続的に考え、フィードバックを得ることで、個人間の差異を効果的に埋めていくことに繋げる。自分としては現在の状態(技術レベルやプロダクト理解度)で、自分が運用するのなら?という観点で堂々と疑問を投げかけたり、理解するための行為を推奨したいです。まとめプロダクト運用は変化が伴う、それにうまく対応するのはなめらかなチームなめらかなチームであるために、自立者にいかに近付くのかが課題となる自立者に近付き、維持するためにコードの自己所有感を拡大していきたいコードの自己所有感の拡大サポートを、仕組みにしたものがコードレビューなのでコードレビューの目的は、コードの共同所有権の実感と熟成と捉えたこのような観点と、思考の流れを整理できました。すればコードレビューはメンバーに等しく意味のある仕組みなので、技術レベルが高いといった特定の人だけが担うものではなくなり、チームメンバー全員で担うものとなりますね。*1:極端に言ってしまうとRuby等の、プログラム言語自体も関連するコードと考えています。いえ個人の意欲と程度問題なので、現実的には必ず深い部分までを求めるということではありません。とい...2017-02-03チームの文化とは何なのか?チームの文化は何を与えてくれるのでしょう。情報を共有するということ月別アーカイブはてなブログをはじめよう!nozayasuさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。