概要
初めてPL(プロジェクトリーダー)の業務を経験して得られた教訓をまとめました。
経歴
- テスター3〜5年
- アプリ開発3〜5年(詳細設計・開発・単体テスト、Java / JavaScript 中心)
プロジェクト概要
- 画面系システムの再構築案件
- 体制: PMO + 複数の開発チーム(以下、同格の他チームとする)
会議体は朝会(PMO + 各開発チームPL)が中心。
PLとして実際にやったこと
- 進捗管理・報告
- タスクの割り振り
- 作業の巻き取り
- チーム内外からの質問対応
- バックログ上での顧客対応
得た教訓
1. 自分で判断しない
チーム内部で結論が出ない問題が出たとして、他チームやPMに相談せずに過去のPJ経験や根拠に乏しい推論で判断してしまう。
→後で発覚してお叱りを受ける。
2. ネガティブな話は伝え方に気をつける
「進捗が思わしくない」「間に合うように作業を削る」のようなネガティブ方向の報告は、伝え方を慎重に考える。
上の立場で考えれば「許容する前例を作ってはいけない」と詰めモードに入らざるを得ない。
PMへの相談は、どうにかしてください、と泣きつくことではない。何とかするのはこちら側であり、PMは判断しか行えない。
どうにかしてください(ルール見直し等)は最終手段と肝に銘じる。
3. いきなり相手が知っている前提で話さない
PMOにトラブルの相談をした際に、「○○の件ですが現在XXという状況で…」と話し始めたところ、前提をまず話すよう注意を受けた。
頭が伝えるべきことでいっぱいで、内容に早く入りたいという焦りがあった。しかし、同じPJでも距離感が遠い相手には、議題が既知であっても、会議を設けた(設けられた)経緯から話すべきだった。
4. 多人数の会議で即断不可能な議題を出さない
特に複雑な課題の相談をする際、相手の認知負荷を考えずに資料も事前相談もなしに判断を求めると、判断相手がすぐに理解できず、時間を無駄にする、心象を悪くする等のリスクが生じる。
5. 予実を常に出せる状態にしておく
進捗報告で詰められる場面では、聞かれることはほぼ以下のパターンだった。
- いつまでに終わるのか?
- 残タスクは何か?
- 予実がわかる資料を出してほしい
詰められる前にこれらに対する答えを用意しておくと、管理側への見え方が良くなると感じた。
6. 他チームは「仲間」ではない
同格の他チームに質問する際に、同じPJの仲間なので何でも相談してよいと勘違いしていた。実際は他チームは仲間ではない。相談していいこととダメなことが存在する。
すでに関係値を築いている、PJ初期なので判断できない等の正当な理由がなければ、以下を守るべきだった。
| 質問の種類 | 他チームに聞いてよいか |
|---|---|
| 単純な質問(資料の格納場所、参考実装のコード共有 など) | OK |
| 判断が必要な質問(仕様の正否、実装方式の妥当性 など) | NG(上位チームへ) |
7. 知らないことは話さない
質問に対して、憶測や不確定な情報を頼りに回答してはいけない。わからないことは素直にわからないと言う、もしくは確実に分かる部分だけ回答することが大切。
8. 悪目立ちすると、味方が減る
リーダーのミスが目立つと、上位のチームは当然のこと、同格のチームとの関係も悪化する。
ミスを犯しても誰も助けてくれない、足並みを揃えたいという前向きな提案すらうやむやにされる、など。
各作業を慎重に進めることでミスを少なくする、プレゼンスが発生する場所において準備を怠らないことが重要。
おわりに
結果としてPJ後半は上司のヘルプが入りましたが、決められた担当期間はPLとして業務を全うできました。
書きながら当時の記憶が蘇り何度も書く手を止めましたが、今回の経験は「形」として残したいとずっと思っており、モヤモヤの解消と気持ちの整理、また今後PLとして業務することがあったら同じ轍を踏まないためにという使命感(?)で書きあげました。
辛いこともありますが、PLとしての業務は作業者としての枠を超えるという大きな意味を持つものだと思います。この記事が未来の自分、または同じようにPL経験の豊富でない方のお役に立てれば幸いです。