プロダクト開発におけるレビューの場：レビューアーとしての観点と心構え

はじめに

こんにちは、システム開発部の奥野です。
今回は製品開発を行う上で欠かせない レビュー について、レビュー実施時にどのような事を意識しているかをご紹介します。

私は LANSCOPE エンドポイントマネージャーオンプレミス版開発のテックリードの立場・役割でレビューを行っています。入社以来、開発者として設計・開発を経て、マネージャーとしての業務を行っていました。
5 年程前からテックリードとして、製品について他仕様との整合性や今後の拡張性など、技術的な責任を持つ立場として業務を行っています。

本記事は、これまでの経験と見解を整理し、言語化したものです。私と異なる役割や立場の方にも、レビューに参加する際の一助となる気づきを提供できればと考えています。

はじめに
レビュー
レビューアーとしてどのようなことを考えているのか
- 観点の出発点
- 心構え
おわりに

レビュー

私たちの開発現場では、実施方法が異なるレビューを日々行っています。
メンバー同士で簡易的に行うものから、設計やコーディングなどの開発工程ごとに定められたものなどです。
レビューの目的も、次の工程へ進むかの合意形成や、チームメンバーの教育など様々です。

レビューの取り組み方は、何を目的としてレビューを行うのかによって変わります。
今回は私が主に行っている 重大な課題を早い段階で検知することでの品質向上 を目的としたレビューをメインでお話します。

また、成果物などに対してレビューを行う側をレビューアー、レビューを受ける側をレビューイとして記載します。

レビューアーとしてどのようなことを考えているのか

レビューアーはどのような観点でレビューしているのか、とメンバーに聞かれることがあります。
いくつも課題を指摘される現状を、今後なくしたいという気持ちからの質問だと捉えています。成長意欲が素晴らしいですね。
ですが、具体的な観点は製品機能や開発工程などのレビュー対象によって変わるため、どう答えたら良いのか正直困ってしまいます。

そこで、レビューに際して考えていることの中で、共通していそうなものを列挙しました。
観点出しの出発点みたいなものや心構えです。

観点の出発点

時間をかければ他にも候補は出てきそうですが、思いついた順で並べました。
ここに記載したものは、私自身が考える機会の多い出発点なのだと思います。

要件
- 定義された要件と設計に抜けやズレが生じていないか
  - 要求内容もあわせて「要求 - 要件 - 設計」という地続きで確認する
時間軸
- 現在・過去・未来、短期・中期・長期で考える
  - 今は良くても未来はどうなるのか
    - 開発者なら改良のしやすさや、セキュリティや技術面の陳腐化など
    - 利用者なら数年単位で運用できるのか、など
  - 過去から利用しているひとにはどう影響与えるのか
規模や数
- 大量と少量、単独と複数、最大値と最小値、ゼロやマイナスなど
  - 増減数といった変化していく値や、異常値などの単独では測れない値など
立場
- 開発者、利用者など誰にとってどう嬉しいのか、どう変化をもたらすのか
  - 善者だけでなく悪意を持った利用者がいた場合、という視点もある
- 複数人のレビューアーがいるなら、役割分担してもよい
  - 担当部分以外を見ないわけではなく、グラデーションで注力部分を分担するという意味
影響範囲
- 変更箇所にばかり注目してしまっていないか
  - Git などを用いたコードレビューでは、変更箇所がわかりやすいため陥りやすい
- 課題解決はできても副次的な作用がないのか
  - その変更によって影響を受ける箇所はないか
  - 同様の変更がほかでも必要ではないか
命名
- 明確な名前、誤解を生まない名前にしたつもりになっている
  - "check" などの曖昧な言葉に逃げがち
  - 社内用語に慣れすぎてうっかり利用しがち
- 設計が進むにつれて、最初につけた名前と内容が乖離しはじめる
  - 要件や目的をあらためて確認したい

これらの出発点は適宜組み合わせて考えています。
ただ、レビューしていると、改良内容や発見した課題に集中しすぎてしまうことがよくあります。
時折、これらの出発点に立ち返って、別の角度から物事を見ることを繰り返す事が大事だと考えています。

心構え

観点の出発点だけでなく、レビューアーとして心がけていることも洗い出しました。
こちらも思いついた順です。

早めに対応する
- 遅くなるほどレビューイ側の開発速度に影響する
  - コードレビュー依頼などの非同期なレビューはできるだけ早く着手する
  - レビューの事前資料確認は、その規模感を捉えるための概要把握とスケジューリングをまず行う
  - 遅くなる場合はその旨をすぐ伝える
コミュニケーションである
- 伝えたいことがすべて完璧に伝わるとは限らない前提で動く
  - 理解している部分と理解していない部分を伝えて、認識確認をこまめにする
  - あたり前のことであっても、できるだけ言葉にする
  - 文面での指摘では、受け取り方で誤解されるような文言がないかを確認する
- 些細な疑問や指摘から新たな課題発見につながる
  - ひとりでレビューしていた際には気づかなかったのに、他レビューアーによる指摘から気づきを得ることがしばしば起こる
- 指摘するのは課題
  - 人格攻撃や皮肉、吊し上げにならないように配慮する
  - 強い言葉や不快にさせる表現はしない
- 違う意見が出るのは当たり前
  - 意見の対立の先は、意地を張ってのケンカではなく、落とし所を見つけること
  - 主観的な感覚ではなく、納得できる客観的な情報を根拠として提示する
第一印象を軽視しない
- ドキュメントやコードを読むのに詰まる場合、そこにはなにか原因があると捉える
  - 文章構成やコードの保守性が悪くて読みづらくなっている
  - レビューイ側との間で認識や理解に差がある
  - まだ具体的に気づけていない課題の匂いを感じている
わからない、で終わらない
- 調べやすい環境づくり
  - 過去の仕様書やソースコード、ガイドラインや使用技術の公式ドキュメントへのリンクなどはすぐに取り出せるようにしておく
- 納得する
  - 公式ドキュメントやそれに則った動作確認などから納得する
  - 個人ブログなどの体験記事は、貴重な情報としてあくまで参考資料とする
  - 経験豊かなチームで対応しているから大丈夫だろうで終わらせず、納得するまで調べるなり聞くなりする
やらないことを決める
- 指摘によってやることは簡単に増えるが、同時に減らすことがないかも考える
  - 感覚で減らすのではなく、十分な根拠が必要になる
時間は有限
- 時間をかけた分だけ良いレビューになるわけではない
  - 限られた時間で効率よく行える、自分にあった方法を見つけたい
    - 個人的には午前中に集中時間を設けたり、期限が許すなら一晩寝かせたりなど