Pocket

システム開発の仕事に携わっていれば、設計書やテスト仕様書などの成果物を作成し
レビューをして頂くということが多いと思います。

今回は、レビューにおける失敗事例を通して得た教訓をお伝えいたします。

レビューの目的とは?

前提として、今回は

成果物の内容が正しく伝わり、適切な指摘を得ることで、成果物の質を向上する

ということを、レビューの目的の定義とさせていただきたいと思います。

レビューの事例

本日は、私、伊東の作成した設計書の社内レビューの日です。

参加メンバーは、私とレビュアーの2人です。

この直前に、顧客から要件変更依頼があり、 設計書に要件を取り込みましたが レビュアーは不在であった為、まだ内容を報告していません。 …図1

図1

説明を始めました。

伊東「早速ですが、○○設計書のXページをご覧ください。」

伊東「当ページに記載のある、xxという処理を改修しております。」

と、いきなり設計書の説明に入りました。

伊東「…以上がxxの処理の説明になります。」

レビュアー「要件と食い違っている気がしますが?」

伊東「すみません。顧客から要件の変更がありました為、このようにしております。後で説明しようと思っていたのですが。」

レビュアー「先に言ってくれないと困るよ!」

と、このように、議題の順が不適切であった為、レビュアー側が混乱してしましました。

伊東「○○設計書の説明を終えたので、△△設計書の説明に移ります。」

伊東「yyという処理についてですが…」

伊東、黙々と自分のペースで進めています。

レビュアーは意見を言いたそうな雰囲気ですが、話が途切れないので、言い出せないでいます。…図2

図2

問題点

2つ、問題点がありました。

1つ目は、レビューの目的と、目的を達成する為の進め方を明確にせず進めていたことです。

2つ目は、相手に理解頂いているかを確認せずに、独りよがりに進めた点です。

改善点

改善に当たり、下記を達成できるよう進めてみました。

・レビューの目的と、目的に応じた進め方を参加者で共有する

・参加者に伝えたい内容を理解して頂けるよう配慮する

改善後の事例

伊東「本日のレビューの目的と進め方について、以下の通りでよろしいでしょうか?」…図3

・目的

  • ○○システムの設計書について要件を満たせている仕様になっているかをご確認いただく。

・進め方

  • 1.要件変更依頼についてのご説明(5分)
  • 2.○○設計書のご確認(20分)
  • 3.××設計書のご確認(20分)

図3

レビュアー「良いです。進めてください。」

伊東「では、まず、要件変更の内容からご説明いたします。」

伊東「設計書のご説明に入ってよろしいでしょうか?」

レビュアー「お願いします。」

伊東「では、○○設計書のXページをご覧ください。」

伊東「○○設計書の説明を終わります。説明を続けてよろしいでしょうか?」

レビュアー「ちょっとまって…□□チェックが必要では?」

伊東「…はい、必要になります。追加しておきます。」

伊東「他、問題なければ△△設計書の説明に移ります。」

結果、レビューにおいて適切な指摘を得ることができ、レビューの目的を達成することができました。

指摘を得られたおかげで、当機能については、問題なく稼働まで進められております。

教訓

レビューの目的を達成させる為のポイントは、下記の2点です。

・レビューの目的と、目的に応じた進め方を参加者で共有できているか?

・参加者に伝えたい内容を理解して頂けるよう配慮しているか?