仕事をしていると、業種を問わず「プロジェクト」という言葉に出会うことがあります。
プロジェクトとは、何らかの目的や計画に対して、期限を区切って取り組む仕事のことです。
新しいサービスの立ち上げ、システムの導入、業務改善の取り組みなど、形は違っても最も大事な要素であることに違いはありません。
そして多くのプロジェクトでは、役割分担をしながらチームで進めていきます。
この記事では、システム導入に関するプロジェクトに焦点をあてて、実際にプロジェクトを実現するために作業を行う人（メンバー）、プロジェクトを現場で引っ張るプロジェクトリーダー（略して、PL）、そしてプロジェクト全体の進捗を管理する（略して、PM）それぞれの役割と関係性について書いていきます。
僕は今、以下のような状況でメンバーとして働いています。
- プロジェクトマネージャー（PM）はいる
- しかし技術出身ではない
- プロジェクトリーダー（PL）はいない
- メンバーは黙々と作業を振られるだけ
「これって一般的にどうなの？」そう感じたことが、この文章を書くきっかけです。
PLがいないプロジェクトの一般的な構造
本来、ITプロジェクトの人員構造は次のようになることが多いです。
PM（全体管理・調整）
↑
PL（技術判断・現場リード）
↑
メンバー（実装・テスト）しかし、PLがいない場合はこうなります。
PM
↑
メンバーこのとき、PMがPLの役割も兼ねるのが理想です。
理想：PMは技術者出身が望ましい
PMが技術者出身だと、以下の点で助かります。
- 工数感覚が分かる
- 技術的に実現可能な範囲内で要求する
- メンバーの相談を理解できる
「この仕様、実装的に危ないな」
「このスケジュールは無理だな」
そういった判断ができるPMがいると、現場はかなり健全になります。
現実：PMが非技術者のケースも多い
一方で、現実はこういうケースも少なくありません。
- PMは進捗管理・調整役
- プログラムは書けない
- 技術の話になると判断できない
その結果、
- 作業を無機質に振られる
- 目的や背景が共有されない
- 技術的な判断はメンバー任せ
という状態になります。
「これ、なぜやってるんだろう？」
そう思いながら作業する人も多いのではないでしょうか。
では、この状態は「詰み」なのか？
結論から言うと、即詰みではありません。
ただし、分岐点ではあります。
危険な状態になるのはこんなとき
- 無理な期限を押し付けられる
- 技術的な指摘をしても聞いてもらえない
- 失敗の責任だけメンバーに来る
- 改善提案をすると煙たがられる
この状態が続くと、人が消耗していくプロジェクトになります。
メンバーとして取れる現実的な立ち回り
① 依頼内容は必ず言語化して確認する
無機質な依頼ほど危険です。
念のため確認ですが、今回の作業は〇〇を△△まで、という理解で合っていますか？
これだけで、後からのトラブルをかなり防げます。
実際には、ひとつのプロジェクトだけに専念できるケースは稀で、多くの場合、複数の作業を同時に進めながら対応しているのが現状です。
そのため、認識のズレを防ぐ意味でも、事前に内容を確認しておく方が無難だと言えるでしょう。
② スキルを棚卸しし、より良い環境を選ぶ
PLが不在で、PMも技術に詳しくない環境では、メンバーがいくら頑張っても、
構造そのものが変わらないケースも少なくありません。
その場合に大切なのは、自分のスキルを客観的に棚卸しをして、必要な知識を貪欲に吸収したうえで計画を立て、より良い環境を選べる状態を作っておくことも戦略の一つです。
最後に：僕が思うこと
野球に例えると、
・プロジェクトマネージャー（PM）は監督（指導者）、
・プロジェクトリーダー（PL）はキャプテン
・メンバーは部員
のような存在です。
メンバーの立場からすると、監督（指導者）がイチローさんや新庄剛志さんのような人物であれば、「この人のもとで貢献したい」と感じるのが自然でしょう。
なぜなら、彼らは現役を引退した後も自ら技術を披露しながら、その経験や考え方を言葉と行動で伝え続けているからです。
しかし、現実にはそのようなPMは決して多くありません。
理想を待っているだけでは、環境はなかなか変わらないのが実情です。
だからこそ、受け身でいるのではなく、自分から動き、自己研鑽を続けていくことの大切さを強く感じています。