プログラマの思索

PMO観点の教育資料の要望も割と多いと思う。
ラフなメモ。

【参考】
akipiiさんはTwitterを使っています 「それから、PMOの立場でのRedmine資料の問い合わせも受けている。この手の話はそもそも少なくて、 @MadoWindahead さんのブログ記事と発表資料くらいしかない。昨今の導入事例の話を聞くと、Redmineの全社展開が多いのでニーズはあると感じる。アイデアを話すので誰かまとめてくれないかな？笑」 / Twitter

【1】IPA資料：ITプロジェクトの「見える化」総集編のP.78では、IPAの観点で、PMOの類型を紹介している。

ITプロジェクトの「見える化」総集編

当初は、問題プロジェクトの撲滅にある。
すなわち、問題になるPJの事務局を作り、PMOがPL/PMを支援していく。
これは事務局型PMOであり、PMOはPLの世話役みたいな立場である。

そして、PMOは標準化推進型PMOになる。
これは、全社標準でプロジェクトのQCDをコントロールし、安定させるために、進捗・品質・課題・コスト管理の標準ルールを定めて、経営陣に報告させて、プロジェクトをモニタリングする。
こういう役割の仕事が、PMOの主なお仕事。

すると、全社横断的なリスク管理指向の「リスク対応型PMO」プロジェクト管理に進展する。
つまり、全社から見て、早めに問題プロジェクトを検知し、そのリスクを摘み取るようにPMOは動く。
実際は、プロジェクトの各フェーズでゲートを設けて、経営陣や管理部門、技術部門がレビューする運用が多い。
よくある例は、受注前の企画や予算確保、要件定義での開発費用の確定では必ず、経営陣のレビューが入る。
そして、テスト計画やテスト完了、リリース判定のレビューが多いだろう。

ITプロジェクトの「見える化」総集編にある「戦略型PMO」は、たぶん経営企画部みたいな役割だろうか。
このレベルになると、PMOではなく、社長直属の経営企画室みたいな感じだろうか。

こういう類型を踏まえて、それぞれのPMOの役割、期待される機能、実際の活動とRedmineの機能をフィットギャップ分析することになるだろう。

【2】PMOとRedmineに関する資料は、PJ管理の事例に比べるともっと少ない。
門屋さんの資料ぐらいしかないのが現状。

予防型PMOがRedmineでのプロジェクトモニタリング方法を伝授する | マドびっ！ Madosan's View

門屋さんの記事のポイントは2つあると思う。
一つは、PMOがPJの現状を把握する時に、Redmineのどの機能に着目するのか、という点。

注目すべき点は、チケット一覧だけでなく、活動タブを重視している点。
PJの活発度合いから、PJの傾向を定性的に見ている。

（引用開始）
活動
どのくらいの頻度で更新されているか
新規と完了の比率はどのくらいか
利用メンバーはどのくらいいるか

チケット一覧
親子チケットを多数使う管理方法が主です
カスタムクエリ「親チケット別整列」を利用する
（ソート順に親チケット・昇順を追加したもの）

全体像とチケットの設定具合を比較する
何割程度チケット化されているか

次のトラッカーごとの確認において
必要に応じてカスタムクエリを作る

トラッカーごとの確認
「WBS」
チケットの粒度について
大日程レベル・作業まで落とし込まれているか
開始日・期日の登録具合はどの程度か
週あたりの完了数を算出し
進捗に問題がないかを把握できればベスト

「課題・障害」
動きがあるチケットは実施者に任せる
動きがないチケットは問題ないか確認する
動きがありすぎるチケットは話がずれていないかを確認

課題の傾向を確認するときは全件を確認する
類似課題、一部機能に偏っている
などの癖を見つけて
今後の作業において予防できないか考える

収束時期を読むときは、残を確認する
発生数・完了数を日別に追えれば良いが
定点チェックのほうが多い
（週ごとのチェックなど）
作成日や更新日からも判断する

チケットの注記の確認
更新回数が多いチケットについては
注記から話がずれてないか、混乱していないかを確認する
（引用終了）

他に面白い点は、週毎のチケットの完了日数や完了チケット数を元に、PJの進捗度合いを定量的に見ている点。
つまり、リードタイムやベロシティも見ているわけだ。

また、PJの途中の工程で、概要スケジュールを元に、詳細化したWBSがどこまで実現されたのか、その割合も見ている。
実際、PJ計画時に担当者レベルまで落としたWBSまでは作れないから、各工程が始まる時点までには詳細化されているはずだ。
それを元に、全体スケジュールのうちどこまで実現可能なスケジュールに落とせたのか、実際の進捗はどこなのか、を把握することができる。

【3】もう一つは、PMOで長年PJの状況を調査した結果、プロジェクトリーダーが能力を向上させて成長していくパターンに傾向がある事。
PMｘTMマトリクスの考え方が参考になる。

PJ管理のようなマネジメントは経験しないと向上しない。
しかし、誰もが経験できるわけではない。

一方、実際のPJ管理では右往左往しやすい。
そういう時に、PJの状況を把握し、PJをコントロールできるような管理基盤が必要だ。

そんな管理基盤としてRedmineのようなツールが必要となる。
なぜ、そんな管理ツールがあるとメンバーのマネジメント力は上がっていくのか？

理由は2つあると思う。
一つは、管理ツールによってプロジェクトをモニタリングでき、PJで問題が発生しても、その状況や原因を把握しやすく、対応しやすいから。
チケットに状況が最新状態で書かれていれば、問題解決のためにメンバーがどう動くべきか、を的確に指示できる。

もう一つは、特にチケット管理は、PMBOKの言うコミュニケーション計画のイベントやスクラムのようなアジャイル開発のイベントと相性が良いから。
毎日の朝会でチケット状況を共有する。
毎週の課題確認会で、チケットの棚卸しをする。
毎週・毎月のチームふりかえりで、メンバー全員で改善策を上げて、改善活動を実施していく。

つまり、イベントにチケット運用を対応付けて、チケットを見ながらメンバーと状況確認すればいい。
そうすれば、「問題　対　私達」という関係を作れるので、議論しやすくなる。

【4】他にPMOで必要な観点は何だろうか？
PMOは、SEPG（Software Engineering Process Group）の役割もあるので、チケットのデータを元に、PJやソフトウェアのQCDの情報を集計分析したくなる。

プロダクトの品質分析、ゾーン分析、テスト工程ごとのトレンド分析、信頼度成長曲線、プロセスの品質状況の分析とか。
リードタイム、ベロシティ、サイクルタイムなどの進捗や生産性の情報とか。
つまり、プロダクト、プロセスの両方の観点でQCDのデータを分析したくなる。
そして、その情報を元に、PJ側にフィードバックして、PJの改善活動に役立てたい。

すると、メトリクスを得るにはチケットにQCD分析用カスタムフィールドを設定すればいいのか、どんなメトリクスがどの場面で効果的なのか、という問題が出てくる。
この辺りは一般論もあれば、個々の現場では異なってくるだろう。
いろんな知見もあると思う。

そういう内容も整理してみたいと思う。