はじめに
最近プロジェクトリーダーという役割について考えることが多くて、自分なりに整理してみました。
新しくプロジェクトリーダー(以降PL)をすることになった人に役立つ内容になっていると思いますので、使える部分はぜひ参考にして頂ければと思います。
※私はスクラムマスターの資格を持っているわけでも、PMBOKの資格を持っているわけでもないのであしからず。
※プロジェクトマネージャー(以降PM)が担当する内容もPLが含んでいる可能性があります。
PLの役割って何？
QCD+Rについて責任を持つこと
- Q(品質)
- C(価格)
- D(納期)
- R(リスク)
では、順番に詳しく見ていきましょう。
Q(品質)について責任を持つ、とは
以下の画像はITシステムを作る際に陥りがちな問題についての風刺画像です。
(出典：顧客が本当に必要だったもの)
簡単に説明すると、顧客も自分が本当に必要なものについて理解しているケースは多くなく、システムが複雑に、関係者が多くなればなるほど、最終的なアウトプットは当初予定していたものとは全然違うものが出来上がる、という内容です。
もちろん、出来上がったものが想定通りだけれども、システムがバグだらけで使いものにならない、というのもダメです。
品質について責任を持つ、とはコンサルで言うところの、期待値管理の考え方と通ずるものがあります。
出来もしないのに、話を盛って顧客の期待値を上げて、納品時にがっかりされる、というのは論外ですので、要件定義の段階でしっかりと顧客とゴールの認識合わせを行っておく必要があります。
また、プロジェクトの途中でも適宜認識合わせを行い、最終成果物の認識合わせを行いましょう。
これによって、成果物が顧客が思っている内容と全然違う、といったトラブルは避けることができます。
品質について責任を持つ、とは、「納品物が顧客の期待するものと同じorそれを上回っている」状態にするように管理する、ということです。
C(価格)について責任を持つ、とは
システム開発はまず見積もりを出して、受注後にシステムを開発する、という流れを取ります。
なので、当然見積金額以上の工数を使うと赤字になります。
当然工数を使えば品質の高いシステムが作れますが、工数には限りがあります。
なので、工数が見積もり段階以上にならないように調整する必要があります。
例えばタスクをそれぞれのメンバーに割り当てる際に、「このタスクの見積もり工数は約4時間なので、それを意識して作業してくださいね」などを伝えておき、それぞれのメンバーが工数を意識しやすい環境を作る、などです。
期待されている品質に対してかけることができる工数とのバランスをどう調整するのか、これを考えるのが「C(価格)について責任を持つ」ということだと思っています。
D(納期)について責任を持つ、とは
これはスケジュール管理についてです。
ITシステム作成ではいろいろなトラブルが起きます。
想定外の落とし穴が見つかってタスクが見積もり工数以内に終わらないことも、メンバーが体調不良で休むことも、突発的なトラブル対応が入ってタスクに着手できないことも、、、、
そんな状況でもあなたはスケジュールについて責任を持たなければなりません。
つまり、顧客と約束した納期は必ず守らないといけません。
一般的にはWBS(Work Breakdown Structure)とガントチャートを利用してプロジェクトのスケジュールを管理することが多いと思います。
※ガントチャートの例
メンバーのタスク調整
メンバーが複数の案件を担当している場合もよくあります。
その場合、他の案件の管理をしている人と調整する必要があります。
例えば、「想定外のトラブルが起きたのでAさんのタスク完了が遅れそうです。
Aさんは12月下旬からプロジェクトBへの参画が決まっていたと思いますが、そのあたりについて調整させてください、」といったやり取りが必要になります。
自分のプロジェクトだけを見ていればよいのではなく、他のプロジェクトと調整が必要な場合は、適宜調整しましょう。
スケジュール確認ポイント1: タスクが開始時期になっても着手されていない
例えば、12月1日からAさんが着手予定のタスクが、12月1日になっても着手されていない、という場合です。
この場合、何らかの問題が起きている可能性が高いです。
Aさんが別のタスクに手を取られている可能性もありますし、単純にAさんがタスクの処理の更新を忘れているだけかもしれません。
そんな時にあなたがすべきことは、Aさんの状況を確認し、12月1日開始のタスクをどうするのか判断すること、です。
このタスクが優先度が低く、Aさんの作業にバッファを持たせている状況の場合、このタスクの開始時期を後ろにずらす、という判断ができる可能性もありますし、このタスクがとても重要でAさんが対応できないのであれば、別のメンバーにお願いする、という判断もありです。
いずれにしても、スケジュールに責任を持つ立場のあなたは、最終的に納期に間に合わせるためにはどうすればいいのかを考えて動く必要があります。
スケジュール確認ポイント2: タスクの完了時期になってもタスクが完了になっていない
これもポイント1と考え方は同じです。
見積もり工数が甘く想定以上の時間がかかっている可能性もあるので、全体のスケジュールに影響しないように調整する必要があります。
R(リスク)について責任を持つ、とは
これは例えば顧客との打ち合わせで「この部分はこういう仕様にしてください」というやり取りはよく起きると思います。
そこで、何も考えず「分かりました」と答えていませんか？
その仕様を受け入れることのリスクを考えてください。
その仕様は簡単に修正できるものですか？その仕様を受け入れることでスケジュールに影響しませんか？
不確定要素は当然ですがリスクを含んでいますので、顧客が要求する内容とこちらが許容できるリスクのバランスを理解して判断を下す必要があります。
モチベーション管理について
この項目を入れるか悩んだのですが、必要だと思ったので追加しました。
メンバーに仕事をお願いする際に、当然給料が発生しているのでタスクをお願いすること自体はできます。
しかし、信頼関係がゼロ、モチベーションがゼロの状態でお願いして、満足するアウトプットが出てくると思いますか？
モチベーション云々の前に、信頼関係の構築は絶対必要です。
信頼関係とは1日で構築できるものではないので難しいのですが、日ごろから気を付ける必要はあります。
ぱっと思いつく感じだと、個人的には以下についてはしないように気を付けています。
- 自分の意見をころころ変える
- 昨日はこう言っていたが今日は違うことを言っている、そんなPLは信用できない
- 自分主体でメンバーのことを考えていない
- メンバーをただの作業者としか見ておらず、作業が遅れていると残業を強要してくる
- 意見に否定しかしない
- 何らかの提案をしても、否定しかされなかったら改善の機会自体が失われる
- 相談しても自分で考えて、と言われる
- 自分で考えて答えが出ないので相談している、以降は相談自体されなくなる
また、良好なコミュニケーションがとりやすい雰囲気を作ることも気を付けています。
メンバーのやりたいこと、自分がお願いしたいことの共通点を見つけて、少しでもモチベーションを上げることができれば、WIN WINの関係が築けると思っています。
例えば、ドキュメント整理をお願いする場合に、「前にプロジェクト管理したいって言っていたよね？今後このプロジェクトのリーダーをお願いしたいと思っています。ただ、いきなりリーダーをするのは荷が重いと思うので、まずはこのあたりのドキュメント整理からお願いしてもいい？プロジェクト整理する中で、背景やプロジェクトの詳細を理解できるんじゃないかなと思ってるんだ。雑用的な仕事で申し訳ないんだけど、最初のステップとしてはちょうどいいのかなって思ったんだけどどうかな」、的な感じで伝えるといいんじゃないかなと。
最後に
マネジメントのタスクはいろいろな要因があるので、そんなに簡単な作業ではないことは皆さん思うところだと思います。
少しでも新人リーダーの役に立つ記事になっていればいいな。