役割にこだわり過ぎるの、意味なくない？あるいは責任と役割と評価と。

プロジェクト中に議論していて、他の人（主に社外の方、お客さん）と感覚が噛み合わないな、と思うことはいくつもある。恐らく僕自身が「プロジェクトを成功しやすくするために」という観点から全てのことをゼロベースで考えているのに対して、普通の人はもちろんそうではないから、ギャップがあるのだろう。

体制図に代表される役割分担もその一つだ。
プロジェクトはふわふわした活動だ（何をやるか、何にどれくらい工数がかかるかを見通しにくいし、やっていくにつれ変わっていく）。だから役割が安定しない。
定常業務（例えば販売管理の仕事で請求書を作るとか）の場合、急に社員が辞めたりしない限りは、不安定ということはない。請求書1枚あたりの生産性が想定より5倍低かった、ということは起こらない。先月に比べて発行枚数が5倍に増えることもほとんど起こらない。そもそも請求書が不要になることもない。
だがプロジェクトでの仕事は上記が全部、普通にあり得る。

そしてもっと重要な変動要素がある。それは「決めた通りの役割を果たせるとは限らない」ということだ。
例えば「Aさんに在庫管理領域の要件定義を担当してもらおう」と決めても、全然書けないことがある。マジで。「あー、これに赤入れをして直してもらうくらいなら、自分で書き直したほうが3倍速いな・・」「でも書き直してもらった方が修行にはなるしな・・その余裕あるかな？」みたいな感じで。

しかもこれは1年生だからできない、10年目の社員ならできる、みたいな感じではなく、できない人はできない。多少アドバイスしたり教えてもできない。管理職だからといって、成果物レビューができるとも限らない。PM（プロジェクトマネージャー）という肩書が付いているからといって、業務テスト計画書が作れるとも限らない。
要件定義に限らず、プロジェクトワーク全般でこういうことが起きる。

請求書作成ならば、最初はできないのが当然で、教えればできるようになっていく。多少ミスが多いとか、速い/遅いの個人差はあれども、「全然貢献できない」ということは考えにくい。
だからプロジェクトワークに慣れていない人は
・役割を決めたらやれる（多少の生産性の違いがあれども）
・というか組織なんだからやってもらわないと困る
という考えが強いみたいだ。どれだけ時間割いても出来ないんだから、「やってもらうべき」とか言ってても仕方ないのだが。

こういう考えの人は、役割分担を事前にかなり厳密に決めようとする。例えば「リードするのはコンサルタントで、実際には御社のメンバーに手を動かしてもらおうと思います」みたいな話をすると「リードとは何をどこまでやるのか、明確に文書化してください」みたいなことを言われることもある。
別に文書化してもいいけど、実際にどうするかは、あなたの部下の活躍次第なんですよね、こちらのコミットメントではなくて、と思うことも多い（だから一生懸命そういう説明をする）。


実際には、プロジェクトで決めた役割は柔軟にならざるを得ない。
誰かが出来なければ、代わりの仕事をしてもらって、できる人が代わりにやる。
誰かが思わぬ高パフォーマンスを発揮したら、どんどん仕事を受け持ってもらう。
誰かが心身の調子を崩したりご家族の事情であまり仕事ができなかったらよってたかって助ける。
全て、走り始めてから調整するしかない。
もちろん、効率よく分担するために、事前に役割分担は決める。だが囚われすぎてはいけない、という話だ。

ちなみに新著「プロジェクトを失敗させる55の罠」には「メンバーの力量不足≒自分の責任を果たせない」みたいな罠を選定していない。それは罠ではなく、ただの日常であり前提だ。
そういうモノだと思って計画し、起きたら対応しなければならない。むしろ「メンバーが責任を果たすことを当然と考えすぎる。それを強いる」が罠になりうる。


※この様に事前に役割分担を決めても機能しにくいので、プロジェクト活動と請負契約は本質的に相性が悪い。請負は「事前にかっちり決めた成果物を作る責任を購入する」という契約なので。とはいえちょっと脱線気味なので、その話はいつかどこかで。

ここまではプロジェクト全体の話。
次に、このような状況で個々人はどの様に振る舞うべきなのか？を考えるために、僕自身がやってきたことを紹介してみよう。

右も左も分からない1,2年生の時を除くと、僕はキャリアのごく初期から、
・他の人々と協調するために、体制図とかWBSはもちろん見て、最初はそれに従う。
・でも上記のような事情で、どんどんそれが現実的ではなくなってくる。
・そうしたら、周りを見渡して、必要なことをやる。
という感じでやってきた。実にシンプルな話だ。

これは「メンバーなので、自分が担当している仕事のことだけ考えればいい」とは真逆の姿勢だ。
自分の肩書がPM（プロジェクトマネージャー）だろうがなかろうが、プロジェクト全体を見渡して、必要なことをやる。
必要なこととは、言い換えると「これをやらないと前に進まないだろうな、と思うこと」だし、それはたいてい、他の人にはできないが、自分が頑張ればなんとかできるようなことだったりする。


※もちろんPMが上司として機能している時は「コレ必要ですよね。やっときますね」と、事前に相談する。そうしないと二度手間が発生する。なにより上司も人間だから、部下が勝手なことをやっていると気分が悪い。

この行動のベースにあるのは「1人のプロジェクトメンバーでしかなくても、PMの立場でプロジェクト全体を常に考える」という姿勢だ。こういう姿勢だと仕事の質は上がるし、視座は高くなる。自然にPMの能力が身につく。
「PMじゃないから顧客との交渉窓口に立たない」とかはなし。
「PMじゃないから他のメンバーに指示出さない」とかもなし。
肩書としての「PM」は後から付いてくる。だって誰から見てもそれにふさわしい仕事を続けているのだから。
もし事実上PMの仕事をしていても、それにふさわしい待遇と肩書が付いてこないなら、それは組織の問題。待遇改善を主張してもいいし、きちんと評価してくれる他社に転職してもいい。

なお、ここで書いてきたことは他人に対しても同じだ。
「AさんはPMだから〇〇やるべき」みたいなことはほとんど考えない。それを言い過ぎると、Aさんが潰れてしまうこともあるから。
もちろんスタート地点では体制図や肩書を尊重する。でもできないならできる人がやるしかない。
上の人が手を差し伸べてもいい。下の人が代わりにやっちゃう時もある。仕事が進むならどっちでもいい。

プロジェクトは難しい。プロジェクトで必要となる1つ1つの仕事も、かなり難しいものがある。だから事前に決めた体制図とか責任分担のままでは機能不全になることが多い、という話でした。