SI事業部の中村です。
研修系の記事にしようと思いましたが、まだまだ方針が定まっていないため、今回はプロジェクトリーダーを担当してみての感想を書こうと思います。はじめてプロジェクトリーダーになるエンジニアのみなさんのご参考になれば幸いです。
※以降はプロジェクトリーダーは長いのでPLと略します。
Table of Contents
プロジェクトリーダーとは？
私はエンジニア未経験で入社し、3年ほどWebシステムの開発に従事してきましたが、正直なところ、PLが具体的にどんな仕事をするのか知りませんでした。ひょんなことからPLを任せて頂き、実務の中で経験したPL業務を挙げると以下のようなものがあります。
- スケジュール管理
- メンバー管理
- 問題解決
- 他部門・他チームとの連携
- わかりやすい根拠提示
上記の業務の概要と観点、要点などを以下にまとめてみました。
1. スケジュール管理
まずはじめにPLの仕事として思いつくのがこれでした。
私がPLとして着任して早々、「前任のPLがどのようにスケジュール管理をしていたか」を参画メンバーに確認してみましたが、「よくわからない」と返ってきたため、正直頭を悩ませました。
私はそれまで開発メンバーとして設計や開発に当たっている立場だったのですが、「この先どのような規模感で作業するのか」ということが理解できていないと、全体のスケジュールが遅延する傾向が多いように感じていたため、スケジュールを細分化した上で作業全体を見える化しました。
具体的には、開発対象の機能ごとに工程で細分化する手法をとりました。
- 基本設計
- 詳細設計
- 実装
- 単体テスト仕様書作成
- 単体テスト
上記に加え、さらに以下の日付を収集するようメンバーにお願いしました。
- 開始予定、実績
- 実作業終了予定、実績
- 終了予定、実績
実際の作業の開始日と終了日を把握するのみでは、メンバーが「手戻りを含めない状態」を目標に作業をしてしまうため、手戻り修正も含めての「完全な作業完了」をコントロールするのが不可能だと考えました。それがスケジュール遅延の要因になると考え、このような手法で管理を始めました。
また、それぞれのタスクには未着手着手中レビュー待ちレビュー指摘修正中完了のステータスのようなステータスを用意し、管理側も一目で分かるように進捗管理表を作成しました。
さらにメンバーの方々には、最短と最長の工数を割り出してほしいとお願いしたのですが、諸事情から難しいと回答があり、断念しました。作業者負担をかけすぎると本末転倒ですので、時には柔軟性を持つことがPL業務にあたる上で重要だと思います。
2. メンバー管理
プロジェクトは、生き物のように刻々と変化しています。そうした場面において、「柔軟に対応できるメンバー」と「作業に集中することが得意なメンバー」に分類しました。なぜなら緊急対応が入った際に、いかに作業効率をおとさずスケジュールを進行できるかがとても大事だと考えたからです。
現実問題として、両者を同じように考えていてはプロジェクトが回りません。作業に集中することが得意なメンバーに緊急対応を任せるのは酷です。それぞれの長所と短所を把握し、長所を活かす前提でプロジェクトをハンドリングする上でとても重要なことだと思います。
しかしながら、最終的にはメンバー全員が緊急対応できる状態を目指さなければ、いっぽうのメンバーの負担は増えますので、スケジュールと相談しながら徐々に理想的な状態を目指します。
3. 問題解決
メンバーの悩みごと・考えごとの解決をサポートすることもPLの重要な仕事です。そのため、私はメンバーに対して「わからないことは常に聞いてください」とお願いしています。
スケジュール管理を意識するあまり、「なぜこれができてないの」とか「なぜ遅れているのか」と言いだすPLが多いですが、それを未然に防ぐのがPLの力の見せどころです。
PLが実作業をバリバリと進めるのは難しい状況が多いため、とくに設計フェーズにおいては、「調査がないか」ということをメンバーに意識的に聞いて回ることで、積極的にコミュニケーションを取りながら、同時に進捗の把握をしています。受け身ではなくPLからアプローチをかける方がいいと思います。みんながみんな自発的に動けるわけではないですし・・w
4. 他部門・他チームとの連携
これは非常に頭を悩ませる問題です。
「他部署が担当している機能がないとプロジェクトが先に進まない」
「自分の管轄ではないので、他部署に調査をお願いしないといけない」
など、他部署に依頼やヒアリングをする時は気を遣います。
先方の利害と一致しない場合もあり、その場合には平身低頭で依頼し、かつ伝え漏れないように文章を確認するなど、もっとも気遣いが必要とされます。これはPL業務というより、人間性と言いますか、「いかに相手を害さないようにお願いするか」だったり、「いかに伝えるか」だったりします。
5. わかりやすい根拠提示
プロジェクトによってはPLの担当範囲でない場合もありますが、PM（プロジェクトマネージャー）やお客様との会議において、スケジュールの遅延時や意思決定について根拠を説明することがあります。
タイトなスケジュールの依頼を二つ返事で受けてしまうと、スケジュール遅延が常態化するため、お客様にご理解を頂きながら、はっきりと避けなければなりません。
その際には、ロジカルかつわかりやすく根拠を説明するということを心がけるようにしています。具体的な作業工数を伝えることは当然ですが、その上でわかりやすい説明をするための準備を事前にしておくことが大事です。
たとえば、お客様から「追加機能を実装してほしい」と要望されたけど、スケジュールに余裕がない状況はしばしば起こります。
その際にはまず「追加作業には○時間の工数がかかります」と説明しますが、お客様からは「なぜそんなに時間がかかるのか？」と聞かれることが多いため、「〇〇の調査に○人日、そしてそれを実装するのに○人日」などと具体的かつ詳細でわかりやすい（ここ大事）根拠を示すことでお客様やPMから納得を得やすいと思います。
番外編 PLを担当しての所感
最近、PLのゴールはなんだろうか、と考えています。
スケジュール通りにいけばPLとしてうまくやれている証拠だと思いますが、個人的には「全員の残業時間をいかに減らせるか」がゴールでは？などとぼんやり思ってます。
個人的な意見に留めておきますが、無理なスケジュールを物量でこなしたというのは、PLとしては機能していないと考えているからです。
時と場合によりますが、お客様やPMからタイトなスケジュールを依頼された時にしっかりと根拠を持って説得できるか、ということがメンバーを守るために大事なことであり、それがPLとしてメンバーから求められていることだと私は思います。
いわずもがな、IT業界は深刻な人材不足に喘いでおり、エンジニア一人あたりの作業時間は意図せずして多くなりがちです。そんな中にあって、タイトなスケジュールを安請合いしてしまうPLをよく見かけますが、そのしわ寄せを食うのはメンバーかPL自身であることがほとんどです。
自分が頑張ればいいというのはある意味マネジメントを放棄していると私は考えます。自分の管理ができない人が他人の管理するのは難しいですよね。
最後に
今回はマネジメントにフォーカスして書きましたが、実際にはPLはマネジメント業務だけではなく、リーダーシップも求められます。マネジメントだけしてても方向性が定まらず、リーダーシップだけがあっても管理がずさんになりがち。リーダーシップとマネージャーシップのどちらもが必要なのだと思います。
私もまだまだ未熟者ですが、20代でPLのポジションを経験できたことは、とてもラッキーでした。この幸運に慢心せずに身を引き締めて精進したいと思います。
See you next time👉
