プロジェクトメンバに品質を確保しなければならないことを理解してもらうために


トラブっているプロジェクトが実はそこそこの人数がいるのにもかかわらず、たとえば肝心の所で出てくるのはいつも同じ人で負荷もかかるから人的リソースのリスクの観点でも心配になってくる。


一方、他の人達は何やっているの?って言う人もいて、周りに「何やっているの?」って聞くとドキュメントを直しています、とか。一体何時までどんだけ時間を掛けて「何をどう直しているのか報告があってもいいのではないだろうか。」と思うんだけどさっぱり要領を得ない報告しか上がってこない。


もう、いい加減いままでのやり方は前任者のやり方でしかなく、ワタシとしては耐えられないのでdeliverableの品質を確保するためにいろいろ変えることにした。


モードを切り替えるためにロールを見直す
仕事を組織だってするわけで、そしたら、役割があるものです。ワタシのプロジェクトでは、ただ人の作るもの、作ったものを管理するだけの管理屋は置かない、です。必ず何かを生み出す、付加のある仕事で役割を分担させることにしています。


それは役割を与え、責任を持たせるということです。リーダ、サブリーダが人の作ったものを管理するなんてそんな楽な仕事のさせ方はさせないです。リーダは対外的な、サブリーダはブロックのdeliverableを作るために自ら手を出してもらうくらいに責任を分担してもらいます。リーダがものつくりに関与しないと“タスクの隅々まで観ないと自分の作業に影響するということを意識しなくなるから”と言う点もあると思っているからです。


大体、責任を曖昧にしておくから曖昧な点を都合の良いように時間を浪費してやらないといけないことをやっていない状況を作っちゃうんじゃないかなって思うんだけど。そういう環境を作る方がバカというか。


品質要求レベルを示すことは作業プロセスを変えさせるため
ロールを見直せば、それであとはうまくいくかと言えば、残念ながらそうはいかないもので。いくらロールを見直しても、それをやる人のマインドセットが変わらなければ、一向に期限になってもdeliverableが揃わない、欲しい要求レベルになっていないなんて安易に想像できるものです。
#実際、出てこない。


あと2つアクションが必要で。一つは、振る舞いを変えさせること。こういった手順でやれ、とか。もう、エンタープライズウォーターフォールの作業の標準化そのものなんだけど。このプロセス(=手続き)を踏ませないと一切評価しない、と言うくらいに行動様式を変えさせる決意がやってもらう側に必要です。変えてもらうんだけど、それは真逆にやってもらう側の決意も必要だったり。


二つ目はプロセスを変えないと出来ない要求品質レベルを具体的に示すことです。単体試験でバグ発生をいくつまで、とか。ケアレスミスなんて絶対に許さない。それをしないための仕組みに時間をコストを掛けることはやってもよい、と。


要求レベルを先に示さないから一人ひとりのメンバが好き勝手に「(こんくらいでいいや。)」って思うんですよ。裁量があるのは限られた時間の中での時間の配分やデザインの仕方だけ、です。それ以外に裁量は与えない。実際、要求品質レベルを提示されたらそれを実現するためのアクティビティを優先することになるだけなので。そういった思考になってもらいたいから。そうしないとモグラたたきの品質を向上させるというバカげたことになるので。


品質はそれを実現するためにアクティビティするものであって、そのアクティビティの結果=要求品質なのであって、作ってみたら出来が悪いので要求品質に追いつくようなアクションを取ろうなんて言っている人を見ると「(死ねばいいのに。)」って思うよ。そんなことするくらいなら、出来るようになるまで何もさせない方が良い。時間が許せば、だろうけれど。