プロジェクトマネージャが抱えるプロジェクト管理の問題

プロジェクトマネージャが抱えるプロジェクト管理の課題について考えことをメモ。

現場リーダーやプロジェクトマネージャの立場になると、単なる開発者の役割だけでなく、チーム全体を鳥瞰する役割も担う。
更に重要な役割が、自分一人の責任だけでなく、チーム全体の責任、更には売上やコストの責任まで背負うようになることだ。

数年前に、別の会社の部長さんから、プロジェクトマネージャに必要なスキルは何か？と質問を受けた時がある。
その時の僕は、進捗管理とチームビルディングが大切です、と答えて笑われた。
その部長さんからは、進捗管理は全体の3割、チームビルディングは1割に過ぎない、リスク管理やコスト管理がそれぞれ3割は必要だ、と言われた時があった。

プロジェクトリーダーやマネージャに問われる能力は何か？: プログラマの思索

今になってその言葉がようやく腑に落ちる。
それらを一つずつまとめてみる。

【1】チームビルディング
現在のソフトウェア開発では、3～6ヶ月の短期間に開発者をかき集めてチームを形成し、アウトプットを出すという開発サイクルが多い。
しかし、優秀な開発者を揃えたからと言って、翌日からチームとして有機的に機能するわけではない。
タックマンモデルが示すように、メンバー同士が本音を出し合って混乱期を経なければ、チームとして機能しないのだ。
そして、プロジェクトマネージャはコミュニケーション計画をプロジェクト立上げ段階に作り、定期的にコミュニケーションを行う場を設けて、チーム全体のコミュニケーションが円滑に行われるようにする。
開発チームが一つの場所に集中しているならば、朝会や定期的なふりかえりの会議がそのような場になるだろう。
チケット駆動開発は朝会やふりかえりと相性がとても良い。
朝会やふりかえりに必要な情報はチケット駆動開発が提供するし、その情報を元にチームの見える化が促進される。
何よりも開発のリズムが生まれるので、メンバー自身がそのリズムに合わせて作業し始めるようになる利点がある。

プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ: プログラマの思索

TiDDを実践して気付いたことpart1～解ける問題であれば人は自然に解決する方向へ動き出す: プログラマの思索

遠隔地にある開発チームや設計チームと協力して開発する場合は、意図的に報告や課題をやり取りする場を朝会やふりかえり以外に設定する事が必要になってくる。
特にオフショア開発はそうだ。
TV会議やSkype、GoogleDocsなどのツールが必要になってくるだろう。
オフショア開発チームとのチームビルディングは、今後のプロジェクトファシリテーションの課題であると思っている。

現代のAgile開発が抱える課題: プログラマの思索

プロジェクトファシリテーションに足りないもの: プログラマの思索

ペア作業やミーティングをクラウド化する: プログラマの思索

【2】進捗管理
ウォーターフォール型開発ならば、外部設計完了時に開発対象が確定するので、詳細なWBSを作るのが可能になる。
そのWBSを線表に引いて、詳細設計や開発やテスト工程のスケジュール管理を実施していく。
だが、ソフトウェア開発の進捗管理は当初の計画通りに進まないことが大半であり、計画外の作業が大量に発生しやすい特徴がある。
だからこそ、アジャイル開発のように変化に強い開発スタイルが必要になってくるし、アジャイル開発の実装例の一つであるチケット駆動開発が現場に適用しやすい。

【3】リスク管理(課題管理)
チームで発生する課題、遠い将来に発生しそうなリスクもチケットに登録して管理できるインフラがチケット駆動開発にはある。
進捗管理はチケット駆動開発がもたらす見える化によって作業そのものが不要になる。
むしろ、プロジェクトリーダーの仕事の大半は、メンバーが解決できない課題やチームに出てきた予兆のリスクに対して対応することだ。
次々に現れる課題やリスクをいち早く潰して、メンバーの作業の進捗が滞らないように、メンバーの環境を守る役割に変化する。
つまり、プロジェクトリーダーの役割は管理者よりもファシリテーターのように変わっていく。

XPのトラッカーの役割はTiDDがサポートする: プログラマの思索

【4】コスト管理
プロジェクトリーダーよりもマネージャレベルになると、プロジェクトの実際のコスト管理も逐一追跡していなかければならない。
当初の計画通りに進捗が進まなければ、人員を投入するか、納期を延長するか、開発対象を削るか、という判断を迫られる。
チケット駆動開発ではメンバーに担当チケットへ予定・実績工数を入力してもらう運用ができていれば、日々のコストを計測することが可能になる。
コスト管理で使われる指標はWF型開発ならPMBOKのEVM、Agile開発ならVelocityになるだろう。
つまり、WF型開発の場合、達成価値(EV)の変化に注目するし、Agile開発の場合、開発規模(ストーリーポイント)に着目する。

PMBOKのEVMの計測方法は下記に書いた。

RedmineからPMBOKのEVMを計測する方法: プログラマの思索

チケット駆動開発にEVMの概念を導入してみる: プログラマの思索

Velocityの計測方法は下記に書いた。

アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索

チームは加速するのか～Velocityの使い方 #agilesamurai: プログラマの思索

ソフトウェア開発の工数見積もりが混乱しやすい理由: プログラマの思索

工数見積もりで陥りやすい罠: プログラマの思索

現時点では、EVMを集計表示してくれるRedmineプラグインはないので、元ネタとなるPV・EV・ACをCSV出力した後、Excelのマクロで集計する必要はある。
IPAが開発中のプラグインの中にEVMを出力してくれる機能があるので、公開されたら楽しみだ。

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

VelocityはRedmineのバーンダウンチャートプラグインやBacklogsプラグインで計測可能だ。
いずれにしても、チケット駆動開発で収集した工数から計測可能だし、将来のコストを予測することも原理的に可能だ。

プロジェクトマネージャが抱えるプロジェクト管理の上記の問題はチケット駆動開発を徹底的に運用できれば、解決できるだろうと考えている。