プロジェクトマネージャー(PM)のお仕事内容
こんにちは はしと です。
現在、会社ではWebアプリケーションのプロジェクトマネージャー(PM)業務を進めさせていただいています。
私のやっている仕事をざっくり説明してみようという思います。
今回は「概要編」なので、ざっくり何をやっているかを説明します。
超基本
この部分が最も重要なのですが、プロジェクトでは「品質」「機能」「作業時間」はどれかが上がればどれかを下げないと絶対に成り立ちません。
例えば、下記のような例があると思います
・品質を上げる必要があるのであればスケジュールを伸ばす必要があります
(「品質↑」「作業時間↑」)
・機能を増やす必要があるのであれば作業員を増やす必要があります
(「機能↑」「作業時間↑」)
・スケジュールを短くする場合、未検証のα版として出す必要があります。
(「作業時間↓」「品質↓」)
根性論について
例えば、「そんなことは残業させれば問題ないはずだ」などと精神論を考える方がいるようですが、残業をさせてもプロジェクトは早く進捗しません。
残業は個人の精神的な負荷が上がりますし、モチベーションや翌日の仕事量にも影響を与えます。
1日単位で考えれば得をするかもしれないですが、連続できないため意味がありません。
精神的な負荷が上がると判断がおかしくなり、出戻りが多くなり結局別の部分で問題が起きるので、人は8時間しか働けないと心に刻みましょう。
品質
完成物の品質です。
例えば、これを最低まで下げれば開発速度は上る可能性があります。
しかし、品質が下がることをお客様などに伝えるのは非常に難しいです。
「ボタンを押しても動かない場合があるかもしれません」
「個人情報が流出する可能性があります」
実際にそうなる可能性がある品質まで落とさなければならないのであればその通りに伝えましょう。
それが難しいのであれば次に書く2種類を可変させるしかありません
機能
アプリケーションの機能です。
例えば、これを増やすと作業時間は増大します。
プログラマ的な思想だと、「1機能を付けるのは数時間程度で完了する」的に考えてしまいがちですが、PM的に考えると1つの機能は非常に大きな作業時間を生んでしまいます。
例えば機能を1つ新規に追加する場合でも、下記のようなタスクが必要になります。
1.仕様定義
2.レビュー
3.実装(開発)
4.検証
5.メンバー共有
プログラマは完成形が頭の中にあるのですが、非エンジニアにはそれがありません、最悪の場合はメンバー共有時に差し戻しが発生してしまい再開発になる場合も少なくはありません。
単純な機能でも1つ減らすだけで大きく作業時間を削減する事が可能です。
作業時間
実際に作業者が作業を行う時間です。
これはスケジュールと作業人数、作業者のスキルによって大きく異なります。
特に新しいメンバーなどは想定したタスク量ができるかどうかを前半に見極めて、問題が起きそうであれば早めに報告するように気をつけましょう。
また、メンバーが足りずに増やす場合は管理コストが増大することに気をつけましょう。
自分で管理する場合は自分の作業できる時間が減りますし、他のメンバーに間接的に管理させる場合も、そのメンバーの作業時間が減ります。
なんにしろ100%の時間が使えるわけではない場合が多いので、多めに見積もっておくことを考えておきましょう。
主な業務
1.調整
上長や他部(営業やサポートなど)のメンバーとお話をして各種調整を行います。
例えば、お客様から障害の連絡が来た場合に誰が1次対応を行ってどこまで責任を取るかを明確にして、1次対応を行うメンバーと打ち合わせを行います。
下記にあるスケジュールについても上層部のメンバーと相談を行い、「問題ないかどうか」などの認識を合わせておきます。
2.スケジュール
問題を改修する場合や、開発を開始する場合のスケジュールを組み立てます。
個人的にはプロジェクト開始時はメンバースキルや何時間稼働できるかが不明な場合があるため数週間は観察期間的に準備しておきます。
ある程度、進捗が見えてきた場合にどの程度他のタスクやメンバーの管理にプラスアルファで開発文化がよくなる仕組みを組み込む組み込むように計画を組みます。(これは場合によりますが…)
3.タスク管理
メンバーに具体的なタスクにして依頼を出します。
渡しの場合は、このタイミングでしてほしいという依頼を出しますが、完了タイミングは基本的にメンバーに依存させます。
自身の想定していたタイミングで終わるか、それよりも長くかかるか?どのようなタスクが得意か?なんかをざっくり確認します。
先程お話していた観察期間でその程度を理解して、スキルが足りないメンバーにはタスクを小さくして渡してコミュニケーションを多めに取ります。
逆にスキルが高いメンバーであればある程度大雑把に依頼して、完成時にコミュニケーションを取ります。
想定していたものができていない場合や時間がかかりすぎている場合は「タスクを小分けにして依頼をし直す」か、「別のメンバーにタスクを割り振り」を行います。
進捗を優先しますが、メンバーの交代が期待できない場合が多いので、十分に注意してメンバーのモチベーションを優先してタスクで調整します。
4.溢れたタスク全て
上記で溢れてしまったタスクややる人が居ないタスクをすべて行います。
自分でできない場合は、すぐに上に申告を行い、メンバーを増やす事や変えることを検討しましょう
特に「0→1ベースタスク」や「調査タスク」はスキルが不足したり認識が共通化されていないと時間が異常にかかってしまう場合があるため、自身で解決したほうがいいでしょう。
この2つのタスクは、他人に頼む場合は2倍から10倍程度の時間とコミュニケーション量を見込んでおいたほうがいいですし、教育1回でなんとかなるものではないのでなかなか難しい問題です。
まとめ
プログラム以外でどんな仕事があるのだと思ってた人もいるかも知れないですが、意外に業務量は多く責任も重たいです。
また、ピンチヒッター俺的な動きも求められるため、最終的に全体を最も理解して実装できる人である必要もあります。
このバッファ的な動きができない場合はメンバー内でバッファを多く保つ必要があるので1名空くくらいの人数感で余裕を持つ必要があると思います。