18:45 見出しの位置が狂ってたので修正
Project Management Officeっていう組織体/委員会のことで、第三者の目線でプロジェクトがこの予算・スケジュール・体制でちゃんとカットオーバーできるのかどうかを判断・アドバイスをしてくれるありがたい存在。
(中略)
中身についての勘所が現場で頑張っている人より理解が浅い人がレビューするのですからレビューする内容はヌケモレの確認と資料の書き方がメインになります。
(中略)
こんなのやってもやらなくても同じじゃないか、ただ現場に負担増えただけだろって思っている戦友の方々。
PMO(Project Management Office) って単語はコレで初めて知ったけど。QA 部門がイチレビュアーとして参加するのは価値あるんじゃないかな…と思った。
トラックバック先で述べている文脈とはちょっと―予算とかスケジュールの話じゃないから―ズレた内容になるけど読んでいて思い出したことがある。それは、QA 部門はプロジェクトの開始段階から関わったほうがいいんじゃないかなぁ？といったモノ。*1
俺が QA 部門に抱いている印象は、仕様のバグ発見のプロ。横から見てると QA 部門の仕事はウォーターフォールでいう検査とかテスト工程とかの段階担当で、制作されたソフトウェアが仕様に沿っているかどうかチェックするもの、に見える。それはそれで真実なんだけど、実際やっている仕事はそれだけに留まっていないと感じている。
仕様の矛盾を実装で回避しているようだが仕様か？○○と××機能に重複が見られるが仕様か？○○に××機能が無いのはユーザにとっては不親切に思えるが仕様か？といった内容のバグレポートを、そんなに多くはないけどそれなりの頻度で提出してくる。*2 いわゆる、我々下請プログラマにはどーしょーもない、イマサラ言われても仕様書いたヤツに言ってくれよ、的な「仕様のバグ」と愚痴られるアレである。*3
でまぁ。俺が思ったのは、この愚痴は裏返せば QA 部門が早い段階でプロジェクトに関わり、仕様の査読に加わって口出しすれば、仕様のクオリティ上がるんでないの？と。
QA 部門は、仕様等のドキュメントと出来上がったソフトウェア（内部構造は一切見ない）を見てアレコレ口出しをする。その口出し能力は、仕様策定段階においても十分発揮される代物なのではないか、と思ったわけです。プログラマですら見落とす仕様の矛盾・重複・漏れの発見、ユーザ視点からの意見提出、が出来るわけで。
また、この前 QA 部門と飲んだときに「もっと早くテスト対象のソフトウェアの規模がわかればなぁ」とボヤいていた人がいた。様々な情報が降りてこないので適切なテスト工数の見積もりがしにくいんだそうです。もちろん、動的にテスト工数は見積もり直されてしかるべきだし、実際そうしているけど、あまりに頻繁だと QA 部門の人員育成計画などに影響が出てしまうのでなんとかなればなぁ…と言った口調でした。
そういった観点からも QA 部門がプロジェクトの早期から関わるのはアリなんじゃないかな…と思ったのでした。上手く回ればウチらプログラマにとってもワケノワカラン代物の実装をする確率が減らせるという恩恵があるわけですよ。
このエントリの主旨からは外れるんだけど
やっぱりプロジェクトで飯を食ってる組織に横断的な横串を刺すのは限界があると最近よく思う。業界と技術によって考慮すべき点が各々違うんだし、中身が分かっているものが最大限努力して中身の議論を深めていくのが本来あるべき姿で、それが困難な場合に議論をリードする、会社としての判断を下す場をセットアップする等がPMOとしての本分だと思う。
ウチら下請企業からすると、単独で企画・営業してスケジュール引いてエンジニア集めてインフラ構築してテストして運用して…と一社だけで全工程請け負える SIer は体力あっていいなぁ、と思っちゃうんだけどねｗ
ただ、社内に分散してる技術者を適時一人ずつ引っこ抜いてチーム編成する、なんていう動的な組織編制が非常に難しいのもわかる。俺が居たことのある SIer はナントカ部とかドコソコ課とかに「所属すること」が重要な価値観を持っていたから、環境に応じて常に組織のカタチがウニョウニョ変化するようなやり方は中々ね…。
でもまぁ ヒトデはクモよりなぜ強い 読んでると、我々のような知的生産を行う組織にとってそういう分権型組織の強みは明らかだし、そういった組織形態へシフトしていくやり方も必ずあると思うんだけど…俺にはそこまでの知見はナッシング。
