レビューの指摘には自分の言葉で


レビューアとしての心構え
見積仕様書やプロジェクト計画書をレビューを対面でレビューするとき、ワタシはレビューアでレビューを受ける方はレビューイになる。レビューするドキュメントの種類やレビューイのレビュー方針により、レビューアは見方を変える。全般的に見て欲しいのであれば、“てにをは”から見るし、特定のテーマにフォーカスしたいと要望があればそれを中心に見ることになる。
どのようなリクエストであっても、レビューアとしてはそのドキュメントの用途で引き起こされる将来を予見することに重きを置く。
見積仕様書でもプロジェクト計画書のいづれであっても、これからの仕事に対しての作業と前提を書くものだから、その作業で届ける品質、コスト、納期というQCDとスケジュールの4つの軸を基本に、レビューイがどのようにdeliveryするつもりなのか、ストーリを何処まで考えているのか、どこまでリスクを識別し、今取れる対策を打っているのかを見る。


指摘に「はい」は信じない
よくよく考え込まれていない見積仕様書やプロジェクト計画書は、綻びが多い。deliverableを作る作業の関連性がなかったり、アブストれべるでも何をするかがイメージ的でいなかったりする。このようなドキュメントの場合、それらを指摘するとレビューイはシドロモドロになるか、ただ「はい」と言うか、若しくは、指摘と違うことを答える。それは、レビューイが指摘自体理解できていないことの証左であり、とくに「はい」と答えるときは、理解度を心配するものだ。
そこには、レビューアがレビューという場に飲み込まれ、自分の頭で思考せず、集団のなかの思考に引っ張られてしまっているのである。

なぜなら、自分が作りこんだドキュメントへの指摘に対し、期待する答えを返すことがなく、また、指摘に対して、何が問題で何をすれば解決するのかを自分の頭で理解した上で、自分の言葉で応えないからだ。
自分の頭で理解していれば、例えば、
「あぁ、それは、○○ということですね。それは△△としてもよいですね。」
というような会話に流れるからだ。




  • 道具室(アプリとか)
  • 音楽室(PCからリンクをクリックするとき、PCにiTunesが入っているとアプリケーションが起動します)

  • 視聴覚室
  • 調達室