開発中システムをレビューしてもらう技術

浪川 舞(まいどる)

それなりの規模を持つソフトウェア開発をする上で、レビューは欠かせないイベントである。

日々のコードレビューはもちろん、開発方針や仕様策定、受入れテスト基準など、さまざまなフェーズ・粒度で発生するレビュー会は、最終的にそれなりのメンバーのそれなりの工数を使うことになる重要なタスクだ。

ただし、レビュー会で周囲から良いアドバイスをもらうのには少しコツがいる。

もちろんレビュー会はレビューイ(レビューしてもらう人)が責任を負うものではないが、これを無駄な時間にするのか、有意義な時間にするのかはレビューイにかかっているという事実はあるのではないか。

レビューを制するものはシステムを制する!(言いたいだけ)という心意気で臨みたい。

こんなレビュー会は嫌だ

1から10までただ説明を聞かされる

某巨大システムに関わっていたときに実際にあった要件定義レビュー会を思い出す。自分にとっては初の上流レビュー会で、参加人数も20名と大規模!まずは偉い(偉そうなというべきか)PMの皆様から学ばせてもらおう!という気持ちで参加した。

開始から1時間…2時間…もっと経っただろうか。
Wordファイルに記載された文字をただただ読み上げるだけの時間が続いていた。

「なんだこの無駄な時間は…」

そう思ったのは私ではなかったのか、このたった1回きりでレビュー会は廃止された。(後にこのシステム開発プロジェクトは大炎上する。)

判断材料のない問題を宙に放たれる

「設計Aか設計Bか設計Cを考えてみたんですが、どうですかねぇ?」

「・・・(知らんがな! )」と周りが無言になる場面はよくある。

特にステークホルダーを巻き込んだレビュー会では、その設計内容を初めて耳にする参加者も多いわけで、いきなり数パターンの細かな設計を説明されても具体的なアドバイスができない場合が多い。

こういうレビュー会は、誰もが発言しにくい空気になり、だんだん「嫌な時間」認識されていく。そうなるとレビューイもレビュワーもボールを持ちたくないために、レビュー会自体を嫌煙してしまう。

謎の空白時間が多い

レビュワーからの指摘や質問に対し、その場で何か調べ始めてしまったり、わからないことを言えずに黙り込んでしまうレビュー会にも遭遇したことがある。

その場にいる全員の頭上に「???」が浮かんで見えてくるようだ。

もちろんモブワークやペアプロであれば作業時間も込みで考えて良いが、時間に限りのあるレビュー会の中で無言の時間を作ってタイムアップしてしまうのではもったいない。

レビュー会で良いアドバイスを募るコツ

レビュー会では、いかに現状のシステムの懸念をクリアにし、ネクストアクションを明確にできるかが肝になる。

そのためには、レビューイはここまで何を考え、何に悩み、何の判断に困っているのか、ポイントを抑えてレビュー依頼したい。

ゴールを明確にする

今日この場で解決すべき項目を理解せずにレビュー会をするのは全く無意味である。問題がどこにあるのか把握できず、闇雲に説明を聞いていたら私なら聞き流してしまう。

通常の打ち合わせと同様、そのレビュー会のゴール(最低限以下)を最初に共有しておくことは必須だ。

  • 本レビュー会の議題
  • 重要となるチェックポイント
  • 各チェックポイントの目的は、報告か相談か合意形成か

前提情報と判断材料を渡す

集まったレビュワーは全能の神ではないので、レビューイがこれまで取り組んだ全ての情報を共有できているわけではない。可能な限り資料は事前に共有し、レビュー会で取り上げる議題を伝えておく必要がある。

また、判断軸のわからない相談事を宙に放り投げるのは避けたい。そのボールは誰も拾いたがらない。

  • 本レビュー会でのレビュー範囲(何を決める必要があり、何を決めなくていいのか)
  • 全体の概要と取り上げる議題
  • 相談項目の判断軸(それぞれのメリットデメリット等の判断材料)

これらの前提を揃えておくだけでも、レビュー会はスムーズに進行する。

話の切り上げ時を見極める

限られた時間内で効率的にレビュー会を進めるには、この場で話す必要のない議題は潔く切り上げなければいけない。

  • 調べなければ回答できない質問
  • 想定していなかった問題への指摘

想定外の問題がここで発覚するのはレビュー会に期待していることなわけで、とても良いことではあるが、レビューイは緊張もある中で周囲から上記のようなフィードバックを受け、萎縮してしまう場面も多い。(だからこそ別途ファシリテーターがいるのが望ましい)

誰も知見のあるレビュワーもおらず考え込んでしまうようであれば、「この議題は持ち帰って改めて共有しましょう」で後回しにしたっていい。レビューしたいことは他にもあるのだから。

レビュー会を有効活用してより良いシステムをつくる

後に完成したシステムに不具合があった時、「あの時◯◯さんにレビューしてもらったのに」などと誰かのせいにしている場面を時々見る。

レビュー会をしたという事実に満足して責任転嫁してしまうようでは、良いシステムを世に届けられているとは言えない。レビュー会は、レビュワーだけに責任があるわけでも、レビューイだけが重荷を背負わなければいけないわけでもないし、参加者全員が当事者としてシステムと向き合える時間にすることが大切である。

参考

いいね!
この記事を書いたPM
浪川 舞(まいどる)
@maidol
  • Twitter
  • facebook
  • github
  • コーポレートサイト

武蔵野音楽大学卒業後、ヤマハ特約楽器店にて音楽教室の運営企画に従事。2014年にSIer企業への転職でエンジニアへ転向し、証券システム、IoT事業など複数プロジェクトの開発を経験。その後、自社サービス立ち上げや法人向けJava研修サポート講師を経て同社のマーケティングマネージャーを歴任。
データ分析・マーケティングの知見を活かしたITサービスの企画・要件整理支援のほか、プロジェクトチーム構築や情報整理を得意とする。
現在は合同会社PeerQuest代表兼PMアドバイザーとしてプロダクト開発組織の内製化を支援している。認定スクラムプロダクトオーナー(CSPO)取得。