はじめに
エンジニア歴がずいぶん長くなってきました。
望んだわけではないですが、PL/PM的なポジション(というかグループか・・・?)をもう5年以上続けており 作っているときの苦悩とは別のものが降りかかってくるものです。
昨今PL·PM・PMOを募集します! という求人も多く見られ、経験してみたい!と思う方もいるでしょう。
その反面、そもそも何するの?というのがわからない・・・と思われるでしょう。
少しでもそのもやもやの解消になればなと思い記事にしてみました。
お仕事の内容
組織によってまちまちだとは思いますが、私の経験談として。
- 要件定義
- コスト試算および見積の作成
- 基本設計
- 関係部署に対する依頼 (インフラなど)
- プロジェクト開始に向けたプランニング、アサインの検討
- 各種レビュー対応
- 進捗確認及び遅滞の解消の検討
- デリバリ方法の検討
- プロジェクトクローズに向けたドキュメントのとりまとめ
- 各種社内書類等対応
こんなところでしょうか。
わたしも他の組織でリーダー・マネジメントを行ったことがないので、多いのか少ないのかよくわかりませんが、幅広く対応が必要です。
社内ルールの理解が必要
開発者である内もある程度自分の作業範囲では理解が必要ではありますが、基本的には指示に従うものでしょう。
指示を出すためにルールがどのようになっているのか?という理解が必要となります。
例えば、
- 設計書は何を残すのか?様式はなにか?
- レビューの承認は誰が行うことができるのか?
- レビューの観点などはどのようになっているか?
- それぞれ成果物のインプットなどはどのように追跡させるのか?
- 各種決裁は誰が行うのか?
などルール・規定を理解しないとお仕事を進められません。
コスト試算はメンバーを意識して行う
ここでは人とどのくらいの期間の開発となるか?についてとなります。
まず定量的な基準を私は作ります。
データ数・画面数・コントロールの難易度などそれぞれ基準を設けて積み上げていきます。
人によって得手不得手もあり、同じことをさせても同じ日数では終わりません。
基準となる値に対してどのくらいで完成させたか?を前もって確認しておきます。
基準の1.5倍かかる人なら1.5倍の期間を見積もるなどすることで、おおむね予実が一致してきました。
同じメンバーで開発をしていたことがある場合にのみ使えますが、人毎の生産性は記録が取っておいた方が良いです。
問題はこの基準をなににするか?です。
場合によっては、3倍も4倍もかかる場合もあります。
その為、前はどうであったか?を参考としています。
進捗確認
何か静的に見ることができるプロジェクト管理ツールがあるとよいです。
進捗率などを必ず入れるよう周知徹底しないと、いつまでも進んでいないな・・・などということに陥ります。
また、経験が浅い場合、そもそも今どのくらいの進捗なのかがわかっていない人もいます。
そのような場合は、一度全体の作業を細かく分け、それぞれどのくらいのエネルギーがかかってくるか? など考えてあげましょう。
レビュー対応
規模が大きければ大きいほど大変ですが、一つ一つ必ず実施します。
意識しなければならないのは、通してあげるところと、絶対に通さないところはメリハリつけた方が良いです。
わたしも最初は細かく全て指摘・差し戻ししていましたが、いつまでたっても終わりません笑
絶対に通しちゃいけないところ(ルールを守っていない、現実的にバグにつながる) ところは差し戻して、それ以外は認識を共有するにとどめることにしています。
プロジェクトクローズに向けたドキュメントのとりまとめ
プロジェクト管理ツールで何とかなりそうではありますが、ここも社内ルールに従うところです。
- 各自で行った設計書やテスト仕様書など取りまとめ
- 設計書根拠となっているのは何なのか?
- デリバリ方法はどのようにすることになったのか?
- 運用監視体制はどのようになったのか?
- 本番稼働時の手順はどうすればよいのか?
- データの移行が必要な場合などその手段はどうするのか?
など取りまとめます。
決裁方法などはそれぞれの組織によりますが、承認者がこのシステムはルールに沿って作られたものなのか?
今後どのように運用・監視されていくのか?など安心して承認してもらえるようにまとめる必要があります。
上司にここに全部入ってますから〜！というわけにはいきませんよね笑？
終わりに
開発だけをやっていたころは、納期に追われてヒィヒィ言っていましたが、PL/PMとなるとルールとメンバー・対外との均衡にヒィヒィ言うようになります。
正直開発だけやっていたころが楽だったなぁ〜と思いますが(これもPL/PM次第でしょう)、 歳をとると致し方ないところでしょう。