PMだとかSEだとかPGだとか

所詮役割に過ぎないわけですよ。

役割の前に仕事があり、仕事の先に目的があるはず。とすれば目的から仕事を定義出来るはず。というか、本来は目的から仕事を定義すべきです。役割からではなく。

今回はシステム開発という狭い世界の話になりそうです。別の業界の人には伝わらない予感。

ええと気を取り直して先に進みます。つまり、PMがコードを書いたっていいし、PGが進捗資料を作ったっていい。先にあるべきは仕事であって、役割ではない。

何が言いたいか。悔しかったらコーディングしてみやがれ。どうだ。なんてことを言いたいのではありません。もちろんPMがコードを書くのは、現場の作業を理解するためにはいいことだとは思います。でも恐らくは必須ではない。

仕事の目的と人の役割が合致しているプロジェクトは幸福だと思います。しかし、必ずしも全てのプロジェクトが幸福なわけではない。別にむつかしいことを言っているわけではありません。例えばPMOという役割があります。PMのためにEXCELの資料を作ったり、メタ資料（コーディングについての資料やテストについての資料。何とか方針とか。大規模プロジェクトに必要な煙幕）を作ったりする、要はPMのパシリです。ハッキリ言って10人未満のプロジェクトには無用の存在。ところが、あるメンバがプロジェクトに入って、私はPMOだから、と自分の仕事を勝手に役割から定義してしまうという、もうどうしようもないことが現実化にあるわけです。10人未満の現場ではPMO的仕事なんてものすごい優先度が低いか恐らくは必要とすらされていない。そんな仕事やられても困る。でも私はPMO。意味のない仕事をする使命がある。勘弁してくださいよ。本当に。

それから、PMがいるがためにほとんど不要な仕事が発生することもありますね。つまりPMの思いつきってやつです。別にお客さんは求めてなかった。その仕事をしなくても済んだ可能性はあった。でもPMが思いついちゃったからやらざるを得ない。「なんかこんな感じのものを作らなくちゃダメじゃないのか」という曖昧なPMの思いつきに苦しむ現場。ホントご苦労さまです。

要はいいものを皆で作るためには、自分は何をしなければならないのか。役割だとか一般論はさておいて、そこを真摯に考える力と、遂行するスキルが必要だと私は思うのでありました。形式とか役割とか一般論から入るのではなく、今プロジェクトが必要としているのは何なのか。その目極めができないとダメじゃん。

しかし考えてみたら下流と上流という言葉ってプログラマをバカにした定義だよな。

以上。