Bula!

前回に引き続き、亀のようにスロウで平和なフィジーの職場に導入した簡易版PMBOKについてお話します。
集中力が続かないトロピカルな環境です。PMBOKが云々と講義したところで、全員が爆睡することは火を見るより明らかです。
そこで、記入式のドリルを用意して講義を実施することにしました。

PMforms

では、このドリルからポイントを抜粋します。

１－１．ステークホルダの識別
自分の上司だけではなく、ユーザ、顧客、視聴者、出資者、スポンサー、取引先・・・、プロジェクトに何らかの利害関係を持つ人や組織を羅列します。
あとで「ひっくり返された」「後ろから撃たれた」と泣かないように、
各ステークホルダのプロジェクトに対する要望と影響力を考えてみます。

１－２．スコープ定義
プロジェクトの目標と成果物を明文化するわけですが、こういうのは偉い人とか仕事ができる人の独りよがりになりがちです。なので、必ず上記のステークホルダーに関する記述を参照させます。
「出資者はああ言ってるけど、この目標でいいの？」みたいな質問を繰り返しながら記述を推敲していきます。

１－３．Work Breakdown Structure の作成
いわゆるWBSですね。目標や成果物に辿り着くまでに必要な作業を洗い出します。「この前に何か作業必要じゃない？」というように作業を細かく分解し、それぞれにかかる期間を見積もります。
最終的には費用、納期、実装する機能を決定しなくてはなりませんが、まずはチームメンバーに自由にWBSのドラフトを書いてもらうと、PMにとってよい参照資料になりますよ。

１－５．品質計画
昔は「欠陥がない＝品質がいい」でしたが、今は「ユーザの満足度＝品質」と考えるのですよ、という話です。
さらに満足とは何かを「計測できる」指標を設けて定義します。どうやって計測するかも具体的に書きます。アンケートするとかシステムのログを使うとか。

１－６．人員計画
組織図を書きながら必要な役割や人材を明らかにします。ついでに「この作業領域の品質や納期をモニターしながらコントロールするのはおまえだからな。失敗したら部下じゃなくてあんたの責任だぜ」とプレッシャーをかける場合にも使えます。

１－７．コミュニケーション計画
前回の記事で出てきたホウレンソウですね。まずは定例ミーティングの参加者と日時を決定しましょう。
さらに、みんなが集まって何となく課題が共有されてプロジェクトが前進した気持ちになる日本企業的な会議にならないように、毎回会議でチェックする項目や会議自体の目的を明文化します。

以上が計画フェーズです。
私の職場のトロピカルな面々は、こんなに緻密な計画を立てたことはないらしく、この時点でかなり満足した表情をしています。
ただ、計画はあくまで計画なので、実行フェーズではしっかりモニタリングしないといけません。

２－１．情報の配布
上記のコミュニケーション計画を実践するのはもちろん、誰かから報告が上がってくるのを待つのではなく、積極的というか攻撃的なくらいに自分から情報を収集しに行け！ということです。
講義のなかで参加者ひとりひとりに「積極的に情報集する」の意味を自分の言葉で説明してもらいました。
またRedmineを導入し、課題やリスクが放置されないようにしました。

２－３．スケジュール管理
WBSによる予実管理はもちろんですが、コミュニケーションが上手に機能していれば納期の遅延やコストオーバーのリスクを早期に発見できます。
日本でもよく見かけるシーンですが、締め切り間際になって「間に合いません！」と言われるより、遅延の事実や原因を随時クライアントと共有（小出し）していくほうが、最終的なダメージが少なくて済むでしょう。

・・・という感じです。
この講義は予想に反してとても好評で、いくつかの学校や組織でも実施することになりました。
かなり省略されているとはいえPMBOKに基づいたものなので、曖昧で掴みどころのないプロジェクトというものを体系的に捉えることができたのかもしれません。

それでは次回は「のんびりフィジーでシステム開発　最終回」をお届けします。

MOCE！

 

【関連記事】
のんびりフィジーでシステム開発①
のんびりフィジーでシステム開発②
のんびりフィジーでシステム開発③
のんびりフィジーでシステム開発④
のんびりフィジーでシステム開発⑤
のんびりフィジーでシステム開発⑥
のんびりフィジーでシステム開発（最終回）