概要
普段はバックエンドのエンジニアをしているが、最近ヘルプでプロジェクトマネージャー（PjM）としてサポートする機会があった。実践的なPjMとしてこなすべきアクションが具体化されているのをあまり見たことがなかったので自分がやっていることを書き出してみた。
PjM何して良いか分からんという人の手助けになればと思う。
背景
自分はNTTデータグループのSIerから現職のWeb系自社開発に転職したので、古き良きSIerにおけるウォーターフォールの上流工程と、アジャイル、スクラムな開発のどちらも経験したことがある。ただPMとしての資格（PMPなど）を取っているわけではないのであくまで自己流であるが、実践的にやってきて良かったことなので大きく間違ってはいないと思っている。
前提
後述するアクションはアジャイルな開発と言いながらも多数のステークホルダーや大規模システムを開発することを想定している。逆にスモールな開発ではtoo muchな作業であるものもあるので良い塩梅で必要なアクションをこなす必要がある。
アクション
大きく分けてプロセスとタスクに関するアクションがある。プロセスは見える化と改善が主な作業でタスクは優先度づけを行う必要がある。
プロセス
(1) WBSを作成する
大規模な開発だったりステークホルダーが多い開発では誰が何をいつまでにやる必要があるのかを見えるようにしておく必要がある。そのためWBS(Work Breakdown Structure)を作成しておく必要がある。これを作成してwatchすることで現状が遅れているのか進んでいるのかプロジェクトが今どういった状況なのかを把握することができる。詳細なタスクはチケット化して管理しても良い。
(2) 進捗は毎日確認する
WBSを作成しても更新されなければ意味がない。進捗は毎日朝会、夕会、デイリースクラムなどで確認すると良い。特に進捗が遅れているときはなぜ遅れているかを早期に発見するために必要になる。
(3) 情報は常に整理して最新化する
更新するのは進捗だけではない。仕様や外部調整など最新のものが常にどこにあるかわかる状態にしておく必要がある。情報はwikiなどに雑に配置するのではなく、例えば次のように情報の階層構造を意識して整理する必要がある。認識齟齬や情報の不明瞭さによる手戻りを防ぐ。
プロジェクトDir
- Product Core
- コンセプト
- KGI/KPI
- リーンキャンバス
- ユーザーインサイト/ペルソナ
- ドメイン知識
- Development
- ...
- Operation
- Security
- Meeting
(4) PDCAを回す
プロジェクトにこれをやれば100%成功するのはないと思っている。それはメンバーの成熟度も毎回変わるしステークホルダーも変わるからだ。ただ失敗の確率を下げることはできる。悪いところがあれば振り返り改善していくと良い。手法はKPTでもSSSでも良いし、タイミングはプロジェクトが未成熟なうちは週次で振り返り、レトロスペクティブなどのタイミングで行うと良い。問題点についてはNext Actionを決めて改善していく。
タスク
タスクは優先度を決め、誰が担当しているかを明確にし、いかにdone状態に持っていくかが重要になる。
優先度
まずは優先度を決める必要がある。優先度は下記のような項目をこなすことで明確になってくる。
(5)全てのタスクの内容を把握しておく
タスクの内容は開発者に丸投げするのではなく概要でも良いので何をやっているかを把握するようにする。分からないところは開発者に確認する。そうすることでタスク間の依存関係を把握することに繋がってくる。
(6) ステークホルダーの多いタスクは優先度を高くする
特に外部との連携が必要なタスクなど外部依存でボトルネックが発生しそうなタスクは優先的に対応し、早めにタスクのボールを渡しておく必要がある。これはギリギリでタスクを消化しようとしても外部リソースの状況に依存してどうやっても消化できないような状況が発生しうるためである。
(7) タスクの依存関係を把握する
どのタスクを消化することができればどのタスクに着手できるといったタスク間の依存関係を把握しておく。依存関係を把握しておくことができれば並行してタスクが消化できるかどうかを考慮することができるようになる。
(8) ボトルネックタスクは早く消化する
これも依存関係とほぼ同じだが、ボトルネックタスクを消化できないと後続のタスクも消化が遅れてしまうため、タスク消化の障害となるようなタスクは優先度をあげて着手、完了する必要がある。
(9) 不確実性の高いタスクは早めに検証する
hogehogeの調査や外部要因で完了できるか分からないような不確実性の高いタスクは早めに調査や事前実施を行う。例えば新しい技術を導入するときのアーキテクチャ検証や新規アプリの申請などは早めに実施して不確実性を下げておく必要がある。フィジビリティをあげておくことでスケジュール不安を解消することができる。
ステータス
優先度を決めたタスクはdoneになるまでステータスをおう必要がある。
(10) タスクのボールが誰か明確にする
タスクの実行者は誰なのかを明確にすることで進捗を正確に把握することができる。複数の人が担当してやっとdone条件を満たすようなタスクの場合はタスクを細分化することも必要である。
(11) タスクはin progressを増やすのではなくdoneにしていく
in progressのものが大量にある状況は注意が必要である。進捗中となっていてもそのタスクが何パーセント完了しているか把握することが難しいからだ。またタスクは進捗中のものを増やすのではなく着実に完了していったほうが精神的にも健全な状態を保つことができる。
その他
(12) メンバーに責務を押し付けない
プロセス、タスクに関するもの以外で重要なことがある。各タスクは実行者が担当するにせよ最終的な責務はPjMにある。単純に開発者のマンパワーに頼って「頑張ってください」というのはPjMとして無能である。PjMは代替手段がないかスコープ調整、スケジュール調整、アサイン調整などを行い進捗が健全に回る状態を保つように努力する責務がある。進捗が遅れているものについては適宜メンバーに声をかけて一緒に解決し、不安を取り除いていく必要がある。
まとめ
記載したもの以外にも細々としたものはあるが、結局PjMはプロジェクトの状態を把握していかに不確実な状態を排除していくことに責任をもち、開発者オネシャスではなく健全な状態でプロジェクトが回るように最大限努力する必要があると思う。そうすることで高いQCDを保ち継続可能な開発を行いユーザーに良いものを提供することに繋がるのではないかと思う。