はじめに
- プロジェクトを成功させるためにプロジェクトリーダーがとるべき行動とは何か、について議論します
- ネットワークエンジニアが関わるインフラ構築プロジェクトを対象としています
- 筆者のエンジニアとしての経験をもとに議論します
プロジェクトの成功とは
- 納期を守ること
- 先方から要求されている以上の品質をアウトプットすること
- コストを見積以内に抑えること
- プロジェクトメンバーが健全な精神状態で業務を行えること
- 筆者としてはこれを重視します
プロジェクトリーダーのアンチパターン
プロジェクトリーダーとしては不適切と考える対応（アンチパターン）を以下に記載します。
いつまでにできるかをメンバーに決めさせる
プロジェクトリーダーからメンバーへ何かタスクを依頼する際に、メンバーに対して「いつまでにできる？」と聞くという手法を採るリーダーがいます。
この手法の意図としては、メンバー自身に期限を決めさせて、期限内にタスクを終わらせることをメンバー自身の責任にすることでメンバーのパフォーマンスを上げる、ということだといえます。
しかし、以下の理由からリーダーとしてこの手法を採るべきではありません。
- メンバーとしてはプレッシャーを与えられるため、精神的に不健康になる可能性が高くなり、メンバーを不幸にする可能性があるため
- これによりメンバーのパフォーマンスが低下する可能性がある
- 情報をより多く持っているリーダーの方が、より正確な所要時間の見積もりができるため
実際に、私もメンバーとして参加したプロジェクトでこの手法をリーダーから採られたことがありましたが、以下のように感じました。
- リーダーから問い詰められている印象がある
- スケジュールがタイトになっているのは自分の責任にされている気がする（プロジェクトが期限に追われている状況だったので）
- リーダーが責任放棄しているように見える
- タスク内容を言われてすぐにこちらで正確な所要時間を見積もれというのは無茶
プロジェクトのスケジュール管理に関しては、メンバーとしても協力するのが得策ですが、責任の所在としてはリーダー（or マネージャー）です。リーダーがメンバーへタスクを依頼する際は期限も含めてリーダーから依頼するのが筋であり、またそれがプロジェクト全体のパフォーマンスを高めることにもつながります。
最低限、メンバーに丸投げするのではなく、一緒に考える必要があります。
メンバーに対して感情や弱みを一切見せない
- リーダーの感情が見えないと、メンバーは不安になる
- メンバーに迷いが生じ、パフォーマンスが低下する
- ある程度リーダーの感情や弱みが見えたほうがリーダーに対して共感しやすくなる
- 共感すると、ファンになり、協力的になり、パフォーマンスが上がる
メンバーを試そうとする
例えば、リーダー側ではハマりポイントや問題になりそうなポイントがあらかじめわかっていてもメンバーにそれをあえて伝えないという状況があります。これはプロジェクトの進捗を遅らせるだけなのでリーダーの行動としては不適切です。
メンバーの成長のためにあえて完全な情報を与えないという考えもありますが、結局はメンバーからリーダーに不明点を確認することになるので、これは実態としてはリーダーが優越感に浸りたいというだけです。
プロジェクトの成功のためには、必要な情報は必要なタイミングでにチーム内で共有すべきです。
プロジェクトリーダーのあるべき姿とは
- チームのパフォーマンスを最大化させる
- 目標をチーム内で共有する
- 目指すべきゴール地点を明確にすることで迷いを無くす
- チーム全体で協力関係を構築する
- チーム内での情報共有を適切に行う
- 目標をチーム内で共有する
- 責任をメンバーに押し付けない
- メンバーには常に仕事に対する感謝を伝える
- メンバーには作業に集中してもらい、パフォーマンスを最大化する
- あらゆる事態を想定しリスク管理を行う
- 起こり得る事態を想定し、顕在化した場合の対応策を立てておく
- プロジェクトの状況を常に注視し、問題の兆候を見つける
- 問題が顕在化しないように予防策を講じる
技術的ナレッジは資料化すべき
- IT のプロジェクトにおいては、メンバー間で技術の差がある
- 技術が不足しているメンバーに対して毎回技術的内容を口頭で説明するのは非効率
- 技術的なナレッジは資料化して、いつでも、だれでも、自由にアクセスできるようにしておくべき
- リーダーの工数減にもつながる
- 不足する情報だけ個別に説明する
おわりに
筆者がエンジニアとして業務を行うなかで感じたことをまとめてみました。何かしら参考になれば幸いです。
