頭脳一式

人の記憶なんて曖昧なもの。すべての情報を頭に記憶するなんてナンセンス。困ったらここに来ればいいじゃん?というスタンスで最強のナレッジベースを目指すブログ

【SIer向け】自己レビューチェック観点(草案)

はじめに

プロジェクトによっては「自己レビューチェックシート」なるものが用意されていると思いますが、 中にはそういったものが用意されていないプロジェクトもあります。

プロジェクトとして用意されているかどうかに係わらず、自分が作成した成果物は自己レビューを行うべきです。

ベテランSEの方はこういったものが用意されてなくても、長年の経験と勘から無意識にチェックされていると思います。
一方、経験の浅いSEや新人は、どういった観点で成果物を自己レビューしたら良いのか分からないこともあると思います。

この記事では、どこのプロジェクトでも通用するであろう、最低限の自己レビューチェック観点をまとめていきます。
最低限、ここら辺が守られていないと、レビュアにボロクソ言われます。
ボロクソに言われたくないのであれば、自分の身を守るためにもしっかり自己レビューをしましょう。

自己レビュー時の心構え

自分が作った成果物に文句を付けさせないぞ!という意識でレビューに臨むこと。
上記をベースとし、一度受けた指摘を二度繰り返さないようにするための対策を考え、実行すること。

レビュアがどういう目線でレビューしているかを考える

レビュアは、ドキュメントの内容が仕様どおりか、書かれている内容に誤りがないのかを確認したいのであって、 誤字脱字等の体裁的なところに突っ込みを入れたくはないのです。

エビデンスも同様です。
レビュアは、作業者がテスト条件どおりにテストを行ったのか、予想結果どおりであることをどのように検証したのかを確認したいのであって、作業者が検証した形跡がないエビデンスを見たくはないのです。

レビュア等の第三者にとって分かりにくい、読みにくい成果物を作ってしまうと、内容を理解するのに時間がかかります。

内容を理解したいのに、誤字脱字があったり、表記ゆれがあると、レビュアと作業者間で成果物に対する認識のズレが生まれる可能性があります。 (作業者は○○のつもりで書いているのに、レビュアは△△のつもりで受け取ってしまう)

こういった自己レビューの甘い成果物がレビューに回ってくると、
レビュアは「内容を理解するためには先に認識のズレを解消する必要がある」と判断するので、
仕様的な部分に突っ込みを入れたくても、先に体裁的なところに突っ込みを入れざるを得ないのです。

本来、体裁的なところは自己レビューで潰せるのに、そこを怠ってレビューに出すと、 レビュー回数は増えるし、工数も要してしまいます。
「相手の時間を奪うことは罪なのだ。」という意識を持ってください。
レビュアはレビュー以外にもタスクを抱えています。自分が作った成果物をレビューするために時間を割いているわけです。レビューが迅速に終わるよう、自己レビューで潰せるところは潰しておきましょう。

レビュー形式を意識する

対面レビューと机上(回覧)レビューの違いを意識する。

机上(回覧)レビューの場合、レビュアは作業者の声は聞けないわけなので、成果物だけでレビューしないといけいないのです。
つまり、成果物に漏れていることはレビュアには伝わらないのです。

ドキュメント編

対象は、設計書/テスト仕様書/レビュー記録票/障害票などなど…
業務で作成するすべてのドキュメント類を指します。

  • 誤字脱字が無いことを確認する。
  • 表記ゆれが無いことを確認する。(例:スーパークラスと書くのか親クラスと書くのか。)
  • 二重否定文を使わないこと。
  • 条件や境界値に関する記述は、以下のキーワードなどを使い、誰が読んでも一意の解釈となるように記述していることを確認する。
    すべて/かつ/または/いずれか/のみ/以上/以下/含む
  • ファイル指定   フルパスなのか、ファイル名だけで良いのか。ディレクトリ名だけで良いのか。
  • 文体を統一していることを確認する。
  • 文字の見切れ等が無いことを確認する。
  • ドキュメント間の整合性が取れていることを確認する。 (ドキュメントを複数開いて並行してチェックを行う事。)
  • 何を以って正常/異常かを明記していることを確認する。

エビデンス

  • テスト条件と予想結果を満たす箇所が分かるようにマークを付けていること。