レビューという仕事

何気に見出しをそのままにしてしまってたんですねorz
さて、id:gothedistanceさまにwktkされてしまいgkbrですが、頑張って書いてみますです。

id:gothedistanceさまのエントリにあった、「第三者の視点でのレビュー」がどうにも有効なアクションに思えないです。というのも、私はレビューというイベントには２つの役割があると思っているからなんです。

１つは品質保全。
ただ、内容を熟知していない第三者が見る以上、どうやっても「書類の顔ぶれ」「誤字脱字」といった表面上の品質しか分からないんじゃないかな、と。これがコードなら、IDEと同じ程度のバグは見つけてもらえるかも知れませんが、コンパイル・エラーの出ない設計書や提案書になるとどれがベストか、なんて誰にも分からない訳です。

これを第三者が見て検知できる、と思う方が間違ってます。

また、ここでいう「品質」というのも問題です。

お客様のニーズに対する品質を問うのであれば、検査をする第三者もお客様とのヒアリングに同席するなどしないと、適正なニーズを見極めるのは不可能でしょう。しかも第三者から当事者になってしまいます。

プログラムの安定性に対する品質であれば、まだ第三者的な立場から見ることが出来るかも知れませんが、全ての要件や当初の仕様と現在の仕様の差分を把握して、と適切なレビューにしようとすればするほど、監査そのものにコストがかかりすぎてしまい、監査者は知らないうちにプロジェクトメンバーになっているんじゃないかな、と思ったりもします。

以上が、レビューというアクションの１つの側面です。
で、もう１つはid:gothedistanceさまにコメントとして書かせていただいたのと同じなのですが、「リスクを監視する為のレビュー」です。

「このリスクをそのままにしておくと、どれくらいのコストを持った問題になるか分からない」
こういったリスクが発生して、埋没して、問題に化ける前に発見しなくてはならず、またそのリスクを解消する為の方策も妥当かどうか検討して、対策を施したら完全にリスクが解消されたかを確認して、検証して、とリスクを本気で管理しようとすると相当な手間と労力が必要のなります。

目先の仕事に追われてしまうプロジェクトチームでは、もしかしたらリスクを継続的に管理し続けるリソースはもう残されていないかも知れません。その為に、第三者であるPMOがそのリスク管理を請け負いますよ、というのであればこれほど心強くありがたい存在はありません。

けど、現実的にはリスクを見極めるにはプロジェクト固有の事情があって、プロジェクトのクライアントの事情があって、メンバーそれぞれの事情があって、顕在化するかどうか分からないという不確定性がある訳です。

これらを全て考慮した上で適切にプロジェクトを監督していける人材がいるなら、その人はPMOなんていう１企業の部署にいるより、コンサルタントとして独立しちゃった方がその人にも業界にも良いんじゃないでしょうか。（少なくとも、レビューの指摘事項を文書にまとめるより、リスク・マネジメントの本でも一冊書いてくれた方が私は嬉しいですｗ）

こう考えていくと、PMOという試みはとても良いのですがこと品質について稼動中のプロジェクトを外部からコンサルティングしようとしても、結局どこか不十分にしかならないんじゃないですかね。

ややバタバタし始めたプロジェクトに急に首を突っ込んでアレコレ言い始めるマネージャみたいな、そんな不十分さｗを感じます。あとはこれが「鬱陶しさ」にならないことを祈る次第でアリマス。