たしかに、どうやって決めるの? とか、どういう方法で決めるの? ってのは、結構大事なことだ。それを最初に計画しておくのか。なかなかやるな、PMBOK。おっと、理解できたのがうれしくて、ちょっと上から目線になってしまった。
ん? ということは……
やはり、どの知識エリアの計画プロセス群にも、「計画のための計画」プロセスが含まれている。プロジェクト統合マネジメントだけは「プロジェクトマネジメント計画書作成」という名前になっている。きっと「プロジェクトマネジメント計画」という名前だったら余計に紛らわしいからじゃないかしら。
いずれにしても、明日はプロジェクト憲章などのインプット書類を見ながら、スコープ・マネジメント作業を進めてみよう。「在宅ヘルプデスク業務開設プロジェクト」の要求事項を集めるための方法もたくさんあるようだし、A子やら上司Aさんやらを巻き込んで要求事項をまとめてしまえば、あとは、スコープ定義だな。
ん?
スコープ定義!?
スコープ定義って、スコープの内容を言葉で明確にするってことだよね。
参考書には「プロジェクトの目的や範囲を特定し、必要な作業を洗い出すプロセス」とある。プロジェクトの成果物に何が含まれるのか(何が含まれないのか)、それを作り出すために何をするのか(何をしないのか)、どこまでやるのかという範囲=スコープを明確にするってことなのね。
うーん、不安だぞ。何をどこまでやるのかって、私に定義できるかな。なにせ「在宅ヘルプデスク業務」に何が必要なのか、まるっきり分かってないんだもの。こういうのって、最初はプロジェクト・メンバーとして経験を積んでからマネジャーに昇格するものじゃないの? ああ、愚痴がとまらなくなってきた……いやいや、もう愚痴はよそう。
今回のプロジェクトで“何をどこまでするのか”ってことをまとめるには、このプロジェクトの全体像をつかむだけじゃなく、他の会社の事例なんかも必要になりそうね。やるべきだけど、「予算や時間がないからできない」って部分もありそうだし、そういうのもきっと最初におおまかに決めておくのかな。
それに、プロジェクト憲章に書かれている「本プロジェクトの目的と目標」をしっかりアタマに入れておかないと、スコープ定義自体があやふやになりそうね。「スコープ・マネジメント計画」のインプットの中に「スコープ憲章」が含まれているのもそのせいかしら。
あ、もしかして、目標の達成基準もここで決めておくのかもしれない。なにせ、どこまでやるのかを決めるんだから。となると、プロジェクト・メンバーに分かりやすく数値化できるものは数値化したほうがいいよね。ここまでちゃんと決めないと具体的な作業は洗い出せないような気がする。これは……。
うーん、これ、きっと私1人の手には負えない……。どう考えても力不足。よし、ここはひとつ、ヘルプデスクのみんなに協力を仰ごう。もちろん、上司Aさんにも協力してもらってスコープを定義してみよう。ツールに「専門家の判断」や「会議」ってあるんだから、皆に協力してもらっていいってことだもの。うんうん。
妙に一人で納得。いろいろなことが、ちょっと軽くなったように感じる。やることが少しでも見えてくると、そこに向かって動き出すのが私の特徴なのかもね。
さーて、帰るか。と、すでに空っぽになったコーヒーカップを片付けてていると、私のスマホが鳴りだした。おっと、会社からだ。こんな時間に? なんだかいやな予感……と思いながらも、ヘルプデスクの悲しき習性で手が勝手に電話に出てしまう。我ながらあきれるなぁ……。
電話は後輩からだった。ヘルプデスクスタッフからのヘルプコール。うーん、私としては「スコープ外!」って言いたいんだけど、ダメかしら?
Copyright © ITmedia, Inc. All Rights Reserved.