経営に関する名著「 High Output Management （邦題：ハイアウトプット・マネジメント（＝高い成果を可能にするマネジメント））」の中でAndy Groveは、”トレーニング（訓練・教育）はマネージャーの仕事”であり、組織の成果を向上させるためにマネージャー（経営者・管理者）が実践できる最高のレバレッジ活動だと述べています。

多くの組織のマネージャーにとって、この言葉は現在においても参考にできる素晴らしいアドバイスでしょう。しかし、現代のソフトウェア開発チームのマネージャーに関して言うと、その中心となる考え方はシフトしています。

> エンジニアリングチームの成果向上にとっては、GitHubのプルリクエストなどで実行するコードレビューが、今では最大のレバレッジポイント（レバレッジの作用点）である。

品質管理以上の役割

従来、コードレビューのプロセスは品質管理のツールと見なされてきました。初期におけるその手法の実証的検証が重きを置いていたのは、圧倒的に不具合の防止という点です。 プルリクエストが主流になってから およそ10年になりますが、コードレビューはますますそのような形で進化し続けています。

コードの不具合発見に関して、コードレビュー（プルリクエストであれ他の手段であれ）は依然として作業対効果が大きい方法の1つと言えるでしょう。通常の”最優先”事項である品質（＝コードの稼働性）の他、”二次的”な品質（＝コードベースの保守性の不具合）の管理にも非常に適しています。

プルリクエストは、仲間同士で（マネージャーをトレーナー（指導者）として部分的に組み込みながら）互いに訓練する機会をチームに与えてくれる他、チーム文化が発展する主要な場にもなります。チームのメンバーが分散した状況にあるような時には特にその意味合いが強いでしょう。また、開発チームにとって、実質的な情報ラジエーターの役割も果たします。時間の経過とともに製品とコードベースがどのように変化しているかを知る最良の方法は、コードレビューの輪の中に入ることです。

> 優れたコードレビュープロセスを実践するチームは、コードベースもメンバーも改善する。劣悪なコードレビュープロセスを実践するチームは、良くてその場に立ち往生、普通であればコードの品質が低下し、メンバー同士が互いに傷つけ合うようになる可能性が高い。

このようにコードレビューが大きな利害に関わるプロセスである以上、優れたリーダーであればそれを無視するわけにはいきません。このプロセスを純粋にエンジニアだけの問題領域と見なすことは可能ですが、この領域にマネージャーが参加すべきでないと考えることは、 how (and why) should managers code （マネージャーはどのように（そしてなぜ）コーディングすべきなのか？）でも書いたように、見通しと取り組み方の失敗だと私は考えます。

品質

注釈：誰が監視者を監視するのか？
実際ところ、誰なのか？（画像：Paramount Pictures）

プログラミングの歴史において、コードレビューの最大の推進力となってきたのは、組織が設定した品質目標にソフトウェアを準拠させるような時です。Jeff Atwoodは 2006年のコードレビューの投稿 で、エンジニアは例外なく自分の書いたコードをレビューすべきだと述べており、彼の議論はそのすべてが品質をベースにしています。

しかし近年、開発者コミュニティの論調はその枠組みから離れつつあります。Derek Priorは、RailsConf 2015で行った講演、 Implementing a Strong Code-Review Culture （強力なコードレビュー文化の実践）において、”コードレビューの目的はバグを見つけることではない。現代のコードレビューとは社会化であり、学ぶことであり、教えることである”と述べました。これについて二者択一で答えを選ぶ必要があるのかどうか、それは私には定かではありません。しかし、皆さんが同意するにせよしないにせよ、重要なのはレビュープロセスにかかわるすべての利害関係者が、レビューの目的において一貫した視点を持つということです。

そして1つ注意すべき極めて重要な点があります。それはQAやセキュリティチームなどの下流部門が、プロセスとの間に依存関係を持ち、不具合検出の少なくともある範囲においてコードレビューの適用を前提とすべきということです。これに関して頭に思い浮かぶのは、監査またはセキュリティベンダの質問に回答する際、チームがピアレビューのプロセスをしばしば使用して”効果的な変更管理”を示すといったようなことでしょう。

もしあなたの配下のチームが、そうした文脈においてコードレビューの実践に不具合検出を組み入れないような流れにある時は、エンジニアリングマネージャーとしてそれが修正されるようそっと導くか、利害関係者の考え方をコントロールするようにしてください。

トレーニング

ここで、 Ian TienがまとめたAndy Groveの本（High Output Management）の優れた概説 から、トレーニングに関するAndy Groveの議論の要旨を借用したいと思います。

> トレーニング（訓練・教育）は、組織の成果を向上させるためにマネージャーが実践できる最高のレバレッジ活動である。仮にマネージャーが12時間を費やし、10人のチームメンバーに対して平均1％の割合で成果を向上させるようなトレーニングを準備した場合、（10人のメンバーは、それぞれ年に2000時間程度働くので）結果的には200時間の成果向上につながることになる。この時、トレーニングはマネージャー自身が行うべきであり外部に任せてはいけない。

コードレビューのプロセス内にチームメンバー間による良好なトレーニング文化を組み込むことができれば、チームを改善できる優れたレバレッジポイントを獲得したことになり、チームのレベルを次の段階へと引き上げることが可能になります。トップダウンによるトレーニングの取り組みをボトムアップの実践を通じて強化することができれば、なお強力です。例えば昼食会を開くなどして特定のコーディング方法を学んだりするのもいいでしょう。2名のエンジニアを選んでメッセージに対応させ、テーマに関してその週の彼らのレビューコメントに着目することで2倍の成果を狙ってもいいかもしれません。

配下のチーム内にトレーニングという発想がない場合、リーダーとしてのあなたの最優先事項はそうした文化を養うことです。時にはそれが度を超してしまい、レビューを遂行するというよりも自己反省に重きを置きすぎるような学問的形式に陥る可能性もありますが、どちらかというと教育的な部分への投資が少なすぎて失敗する方がはるかに一般的だと思います。斧の刃を研ぐことと木に対して振りかざすことのバランスが適切になるよう慎重を期しましょう。

コードレビューにおけるトレーニングの考え方を具体的にどうやって開発するかというのは大きなテーマですが、最初の取りかかりとして Awesome Code Review （優れたコードレビュー）に掲載された講演のリンクは非常に参考になるのでお勧めです。

行動と文化

メンバー間の物理的な距離が離れているかどうかにかかわらず、多くのチームにとってGitHubは仕事に関する文化が育まれる”場”として機能します。プルリクエストを掘り下げることで、チームのダイナミクス（動き）について多くのことを知ることが可能です。ただし、プルリクエストのディスカッションでは専門家と個人の区別がしばしば曖昧になります。コメントの内容が、行ごとの詳細なコード分析からその時話題のミームの共有、はたまた別の開発者に対する応援や批評メッセージまで刻々と推移するためです。

企業文化の形成を委託することはできません 。配下のチームにおける文化形成について責任を負うのは、マネージャーであるあなた自身です。

> GitHubの周りにボックスを描き、”ここがエンジニアリングの作業スペースだ”と言うだけでその場に一切関心を払わないようなマネージャーは、エンジニアリンググループの文化を形成するという職務を放棄しているのと同じである。

この話題について私の論調が強いと思われるかもしれませんが、実際に私は痛切にそう感じています。私がHecateを創設した理由の1つに、Coraline Ada Ehmkeが書いた My Year at GitHub （GitHubでの私の1年）という記事を読んだことが挙げられます。プルリクエストのプロセス内において、1人のエンジニアが特別視され異なる扱いを受けていたという事実はまったくひどいもので、100％マネジメントの失敗と言うほかありません。

開発者たちはコードレビュー後、こうした表情になるべきではない

マネージャーとしてのあなたの役割は、影響力の範囲内で対人関係のダイナミクスが健全かつ生産的であるようにすることです。チーム内の社会的規範を知り、規範からの逸脱があった時にはそれを調査できるようレビュープロセス全体を支える必要があります。規範が健全でない場合、それが健全な方に向かうようそっと助け船を出してあげましょう。それでもうまくいかない場合、単なる助言ではなくもっと思い切った対策を探ってみてください。

> オーストラリア陸軍元本部長のDavid Morrisonによると、 “あなたが通り過ぎてきた基準が、あなたが受け入れた基準だ” という。もしあなたがレビュープロセスから身を引けば、現在の基準がどんなにひどくても、あなたは実質的にそこを通り過ぎることになる。

では、方法は？

プルリクエストプロセスとチーム文化について、その全体的な健全性を管理することが重要だということには同意いただけたかと思います。ではその次の質問です。そのプロセスにどう関わればいいのでしょうか。

プルリクエストプロセスの管理とマイクロマネジメントは紙一重の差です。特定のプルリクエスト内で発生することはチームの領分であるため、マネージャーはプロセス自体に頻繁に介入しようとする衝動を抑えなければなりません。一方、プロセスの動き・作用の傾向に関してはマネージャーの領分です。メタレビュープロセスがうまく実行されていれば、マネージャーの仕事はほとんど目立つことはないでしょう。

ステップ1：プルリクエスト自体への関与は続けること。チームの規模が小さければ、さほど難しいことではありません。定期的なGitHubのメールやSlackの統合などをフォローし続けることができると思います。しかしチームが大きくなり会議の負担が増えてくるに従って、これは難しくなってきます。4時間の会議の後に100通のGitHubのメールに目を通すのはさすがに骨が折れるでしょう。以下に紹介するのは、私が作成した最初のHecate製品、 Dispatch（マネージャー用のバッチPR通知） のユースケースです。

ステップ2：フィードバックのパターンを構築すること。内容を確認する場合は良いレビューを発信するようにしましょう。また、コードにコントリビュートする機会がある時は、レビュー担当者としてコードレビュー作法の輝かしい模範を示してください。

“パブリック（公の場）では褒め、批評する時にはプライベート（個人的）に行う”ということの落とし穴に気をつけましょう。これは、ほとんどの場合において良いアドバイスと言えます。しかし、プルリクエストのコメントは、実質的には永続的な（組織の文脈内における）パブリックの記録です。従ってパブリックで批評しない場合、悪い行いが指摘されないまま残ってしまうことになり、結果的にそうした行いがOKであるという印象を与えてしまいかねません。

私が推奨するのは、まずは問題があるメンバーに対してプライベートな形でそっと指摘をすることです。もしかするとここで意思の疎通がうまくいかずそれっきりになる場合もありますが、うまくいけば、そのメンバーに行いの誤りを自覚させ、それを正すことができるようになるでしょう。余談ですが、最悪のコメントを除いてすべてを編集せずに残しておき、履歴を書き換えるのではなく、後で説明的または弁解的なコメントを追加することを私はお勧めします。人を傷つけるようなコメントを取り消せないことになりますが、履歴からそれらを抹消すればレビュー担当者はデータの正否を疑ってしまうかもしれませんし、グループの学習の機会を減らすことにもなってしまいます。問題があるメンバーが謝罪を拒絶する場合は、パブリックにおいて、ただし穏やかに叱責コメントを残してください。

コードレビューに関する行動規範のパブリックにおける報酬と処罰は、グループの価値基準と一致することが重要です。

ステップ3：チームの動向を追跡すること。私が初めてマネジメントした時は、チーム活動の週日記をつけ、特に良かった（または悪かった）その週のプルリクエストなどを書き込んでいました。そして、その記録を定期的（月ごと、四半期ごとなど）に振り返り、チームのプロセスがどのように進化しているかを質的に理解するよう努めいていました。なお、私たちは現在、 コードレビューの実践を質的に追跡するHeartbeat という製品に取り組んでいます。試用に興味のある方は、ぜひ登録してください。

最後に

コードレビューの実践とツールはチームのパフォーマンスを多くの次元で改善するための軸となるものなので、放置したままにするのはよくありません。マネージャーの仕事については、日常的にコードレビューをする必要はありませんが、プロセスには積極的に関わるようにしましょう。