２回目の投稿になります。
中村です。
今回は研修系のネタを記載しようとしましたがまだまだ方針が固まってないので
10月からプロジェクトリーダーをやっての感想的なのをダラダラ書こうと思います。
リーダーポジションやってみて改めて大変ですしどうしようと思っている方も多いと思います。
この記事を見ている皆様のお役に少しでもお役に立てればなと思います。
しかしあくまでほとんどが中村の視点からみた感想や見解ですので参考にするかは記事を見る人に委ねます・・・・w
※以降はプロジェクトリーダーは長いのでPLと略します。
プロジェクトリーダーとは？
実はというと私自身PLはどんな仕事をするのかわかっていませんでした。
ですので調べてみると以下が主なPLの仕事と言われています。
・スケジュール管理
・メンバー管理
・問題解決
・他部門・他チームとの連携
参考https://products.sint.co.jp/obpm/blog/project-leader
実際着手して上記が主な仕事だと私自身も感じます。
では早速それぞれやってみての感想を１つずつ記載したいと思います。
スケジュール管理
誰もがPLの仕事として思いつくのがこの仕事だと思います。
着任早々前任がどのように管理しているかメンバーに聞くとあんまりわからないと聞き頭を悩ませました・・。
そして着任早々現在進行案件が重くかつ進捗が良くないということでスケジュールを細分化し作業全体を見える化しました。
私自身も実装側だったのでよくあったのがこの先どのような規模感で作業するのかというのが理解してないと全体が遅れるイメージが強かったのでこちらを真っ先に行いました。
どれくらい細分化したというとまずは実装機能に応じて以下の分け方をしました。
・基本設計
・詳細設計
・実装
・単体テスト仕様書作成
・単体テスト
ここまでは当たり前かと思いますがさらに以下の入力を行うようにしました。
・開始予定、実績
・実作業終了予定、実績
・終了予定、実績
作業開始終了のみでは成果物の手戻り修正込みの完了をコントロールするのが不可能と考えました。
作業者としても作業完了を目標に作業をしてしまうためスケジュール遅延の要因ができると考えこのような形で管理を始めました。
それぞれ未着手、着手中、レビュー待ち、レビュー指摘修正中、完了のステータスを用意し管理側も一目で分かるように進捗管理表を作成し現在も業務を行っています。
そしてスケジュールも本当は作業員に最短と最長のかかる日数まで割り出してほしいとお願いしたのですがそこはきついと言われ断念。
まあここまでやるとやりすぎというところありますし作業者負担をかけすぎると本末転倒ですので時には折れることも大事かと思います。
メンバー管理
まず柔軟に対応できる人と作業に集中する人を確認しました。
この分け方をする理由は緊急対応が入った際にいかに作業効率をおとさずスケジュールを進行できるかが大事と考えるからです。
ですので柔軟に動ける人をできるだけ差し込みで入る仕事を投げないと上手く仕事が回らないですし作業集中する人にそれを任せるのは酷かなと思います。
全員が柔軟に動ければベストですが人間ですのでそれぞれの長所を活かすのを前提で動くのが個人的に大事なことなのかと思います。
とは言え最終的に作業員全員に緊急対応できるようにしないと作業員の負担は増えるのでスケジュールと相談して作業に集中する人にも時には振ったりもします。
開発言語が複数ある場合の配置は誰でもできると思うので自分の意識は上記が多いです。
問題解決
自分自身あまりここはまだまだできているとは言えませんができるだけ作業者には常にわからないことは悩む前に聞くようにという指導をしています。
ありがちなのがスケジュール管理を意識するあまりなぜこれができてないのとか遅れているのはなぜ？みたいな詰め寄りをする人もいますがそれを未然に防ぐのがこの項目だと考えています。
特にPLは実作業を行うのは厳しいですが設計フェーズでは調査がないか作業員に聞いて回ることでコミュニケーションを取りかつ進捗把握ができる気がします。
あとは受け身ではなくこちらからアプローチをかけるのがいい気はします。
みんながみんな自発的に動けるわけではないですし・・w
他部門・他チームとの連携
非常に頭を悩ませます。
他部署のこの機能がないと先に進まない、うちの管轄ではないので調査をお願いしないといけない等々他の部署にヒアリング、お願いをするのが一番しんどい気がします。
とにかく頭を低く低くお願いしかつ伝え漏れないように文章を確認等々大変です。
こればかりは意識するというよりはいかに相手に伝わるかや書いたメールの文章を自分で読んで変なところがないかを確認する意外にやりようがない気もします・・。
その他
PLの仕事かまではわからないですがスケジュール遅延や決めることについてはPM、お客様と会議することが多いですがここが一番神経を使います。
無理なスケジュールを呑むとそれが常態化するため避けなければなりません。
できるだけ丁寧にお断りしますが時には少し具体的工数と作業を説明しはっきりと厳しいと申すこともありました。
やはりお客様との交渉はいかに理論武装をもつに限ると思います。
この理論武装というのは具体的な作業工数、どのような作業を行うなどをあらかじめ持っておくのが大事かと思います。
例えば追加機能を実装してほしいという話ですがスケジュールに余裕がない場合を例にします。
まずは追加作業にはこれだけの工数がかかります。と提示します。
から必ずなぜ？というツッコミがワンセットですので〇〇の調査に何人日そしてそれを実装するのに何人日と説明から入れば大体は相手はこれ以上のツッコミは起きません。
ここのなぜの後にいかに具体的な作業と根拠が述べれるかが重要かなと常々思います。
こういうことがやりたくなくてPLはやりませんって人もいるだろうなぁと思います。
やってみて思ったこと
ざっとこんな形で１ヶ月やりました。
スケジュールとその他以外は具体性のない話ばかりですね・・・。
こんな感じにやってきましたが最近PLの役割ができていると思われるゴールはなんだろうかと考えています。
スケジュール通りいけばPLとしてゴールだと思いますが個人的には「全員の残業時間をいかに減らせるか」がゴールでは？とぼんやり思ってます。
スケジュール管理と一緒では？と思われますが個人的な意見を述べると
無理なスケジュールを遂行してスケジュール通り上手くいったというのはPLとしては全く機能していないと考えているからです。
作業員を守るためにはやはりPM（プロジェクトマネージャ）やお客様を説得できるかが一番求められているのでは？と私は思います。
自分自身いろんな案件を回りましたがやはり業界全体が人材不足のため作業員の作業時間はどうしても多くなります。
しかしながらPLがお客様やPMの無理なスケジュールを鵜呑みにすることが多くそのしわ寄せが作業員かPL自身に降りかかることがほとんどです。
そしてなぜ「全員の」という表現をしたかというとスケジュールを遅らせないかつ作業員の残業をさせないためにPLが無理するパターンがあるからです。
自分が頑張ればいい。
これはある意味マネジメントを放棄していると考えているからです。
自分自身の管理ができないのに他人の管理するのは正直無理のではと私は思います。
最後に・・・
いかがだったでしょうか？
長々と記載しましたがやはりこのポジションはただマネジメントするだけではなくリーダーシップも必要のため色々と難しいです。
マネジメントだけしてても方向性が１つにならないので上手くいかない。
リーダーシップがあっても管理がずさんだと上手くいかない。
両方あって初めて仕事になる。
悩みが絶えない毎日です。
とはいえ始め１ヶ月まだまだ新しい課題等々出てくると思います。
そして何よりここから自分のマネジメントに問題が出てくると思うと胃が痛い・・・。
しかしながら２０代でこのポジションができることになったのはある意味幸運だと思っているので引き続き自身のアップデートをして頑張りたいと思います。
そしてこの記事を読んでいる皆様のPLとはというのも聞いてみたいですね。
求められているものを把握せずに動いては意味もない気がするのでPL初心者として今後も一生懸命頑張りたいと思います。
あとここは違うぞというご意見もお待ちしています。
次回はもっとライトな話題の記事を書けるように頑張ります・・。
それでは！
