ぴんぼっくの“分からない連鎖”、どう攻める？：女子ヘルプデスクのプロマネ修行奮戦記（3/3 ページ）

[鐙貴絵，ITmedia]

　プロジェクト全体の青写真がおおざっぱでもいいから描けたら、組織の偉い人（私の場合はAさんか？）から、この計画で“進めましょう”と“認可”されることになる。そうして“認可”された証が、プロジェクト憲章なんじゃないのかしら。プロジェクト憲章には、そうしたプロジェクト全体の青写真を書くんだわ。

青写真：心に描いている将来の姿。未来図。計画。

（広辞苑）

　そんなことはどうでもいいって。

　プロジェクトって、予算やらスケジュールやら人員配置やら、とってもたくさんのことを考えないといけないわけよね。なにせ、10個も知識エリアがあるぐらいなんですもの。いろいろなことについて、ちゃんと計画を立てて、その計画に沿って実行しなきゃいけない。でも、計画は途中で変更されることもあるし、途中で本来の目的を見失なったりすることもありそう。いろいろな計画を立てるために、プロジェクトの背骨をはっきりさせる目的で書くのがプロジェクト憲章、というわけね。

　何となく見えてきたような気がする。この仮説が正しいかどうかは、「プロジェクト憲章作成」プロセスの中のインプットを見たら分かるかもしれない。早速調べてみよう。

---

　見通しが明るくなると、私の手は軽やかになる（ような気がするだけかもしれないけれど）。プロジェクト憲章を作るためのインプット書類は次の5つ。

　1つ目は、「プロジェクト作業範囲記述書（SOW）」。これは、プロジェクトが提供するプロダクトやサービスを記述した文書であると定義されている。つまり、プロジェクトの成果物が何か、を定義したものね。私の場合は、「在宅ヘルプデスク」の組織のあるべき姿、という感じかしら。この書類は、組織内部のプロジェクトの場合、イニシエーターやスポンサーが作成すると書いてある。

　イニシエーターって、発起人、つまり「このプロジェクトをやりましょう」って言い出した人のことよね。スポンサーはお金を出す人、つまり、プロジェクトに対して予算をつけてくれる人のことかな。ということは、今回のイニシエーターやスポンサーはAさんってことになるのかしら。よし、ここはひとつ、そのプロジェクト作業範囲記述書なるものを、Aさんに頼んで書いてもらおう。

　インプットの2つ目は、ビジネス・ケースだって。プロジェクトを投資対象としてとらえて、その効果や価値を明確にするために費用便益分析をして、その結果を評価のために数値化して記載しておくらしい。数値化かぁ。あまり得意じゃないけど、大丈夫かしら、私。あ、でも、効果や価値についても、Aさんに目標値として出してもらえば、私が計算する必要もないか。おお、プロジェクトマネジャー、いいご身分じゃん！　部下が上司をこき使えるなんて。

　3つ目は「合意書」。いわゆる契約のことらしい。ただし、顧客要求によるプロジェクトの場合の契約とある。今回の顧客は社内だから、合意書はないということか。

　4つ目は「組織体の環境要因」。これは、組織内のインフラストラクチャーや文化、市場を取り巻く状況などを指すらしい。社風とか企業理念とかもこの中に含まれるのかな。

　最後は「組織のプロセス資産」。つまり、今までやってきたやり方や過去の事例、ノウハウなどのことらしい。PMBOKを導入するからって、いきなり今までのやり方を捨てることはできないものね。

　これらの5つ、いや、今回は合意書がないから4つ、を準備したら、プロジェクト憲章が書けるのかな？　そもそも、プロジェクト憲章ってどうやって書くんだろう。「ツールと技法」を読めば、何か分かるのか……。

　そのツールとやらに、「専門家の判断」なるものがある。専門家とは、「分野特有の知識を持っているグループや個人、トレーニングを受けたグループや個人」のことらしい。ヘルプデスク業務については私も一応専門家になるし、A子もAさんも専門家になるよね。ここは彼らに相談すればいいとして……。技法は「ファシリテーション技法」っていうのが挙げられているけれど、これはミーティングしろってことかしら。何事も相談して解決することが大切なのね。

　どうやら、これらの作業の結果として、プロジェクト憲章が出来上がるらしい。プロジェクト憲章には「ビジネス・ニーズ」「前提条件」「制約条件」「顧客のニーズの現状での認識とハイレベルな要求事項」、「ニーズを満たすための新しいプロダクト、サービス、あるいは所産」といった5つの内容が記載されていなければならないみたい。顧客のニーズ？　それって、どこに書いてあるんだろう。5つ（4つ）のインプットを消去法で考えていくと、プロジェクト作業範囲記述書かしら。やっぱり、Aさんに聞かなきゃだめね。

　なるほど……。何とか、形になりそうな気がしてきた。プロジェクト憲章を作るってことは、私がこのプロジェクトの決まりごとを作っていいってことよね。なんだか、楽しいことになりそうじゃない。

　もちろん、仕事だから変なものは作れないけれど、「このプロジェクトはこういう方向性で、こんな風にやっていきます」というのが作れれば、自分のプロジェクトに対して思い入れもできそう。ここは、慎重に丁寧に、かつ、速やかに作らなくっちゃ。これがないとちゃんとしたプロジェクト計画なんて立てられそうもない気がしてきた。なにせ、私は聖徳太子のように10人の声を一度に聞けるわけじゃないからね。背骨は必要よ。

　まずはAさんに、リベンジも兼ねたインプット書類の2つをお願いするところから始めよう。

　もちろん、このあと「部下が上司をこき使えるわけじゃない」ってことや、「プロジェクトマネジャーが勝手にプロジェクト憲章を書けるわけではない（スポンサーが主体となって書く）」ということを、いやというほど思い知らされるわけなのだけれど……。