プロジェクトマネジメント知識をライトノベル感覚でお伝えする小説です。
初めからご覧になりたい方は、こちら↓から
異世界✕プロジェクトマネジメント カテゴリーの記事一覧 - 凡人が成果を出すための習慣
リーガルの説得に成功し、設計フェーズの承認が下りた。
兵器を含む、ゾーム対策の仕組みを本格的に作り始める。
プロジェクトとは往々にして、いろいろな問題が発生する。
設計フェーズに入ると、物事が具体化してくるので問題が増える。
既に、多くの問題が見え、ヒロは対応に日々忙しくしていた。
次の満月まで2か月弱。
その短期間で、ゾームを倒す仕組みを構築し、実際にゾーム討伐で試験的に使う必要がある。
スケジュールはとてもタイトだ。
そのため、プロジェクトメンバーで毎日15分の定例会議をしている。
「では、定例を始めましょうか。
いつも通り管理表にそって話をしましょう」
そんな感じで会議をはじめ、進捗管理表・課題管理表・リスク管理表を確認する。
それぞれの管理表は、プロジェクトがうまく進んでいるか？問題はあるか？ということを日々チェックするものだ。
進捗管理は、フェーズの開始時にタスク化したタスクが、予定通りに実行されているかを確認することだ。
兵器の設計においては、魔道具の選定、魔力の動力配線の設計など、こまかなタスクがある。
それら一つ一つのタスクについて、いつまでに誰が実施するかを決めておき、進捗管理表に記載する。
元の世界では、WBS（Work Breakdown Structure）なんて呼ばれていた。
定例では、その進捗管理表にあるタスクが、本日時点で遅れているのか、順調なのかを確認する。
課題管理表は、タスクが進捗通り進んでいない場合に、その遅れの要因となっている解決すべきことを記載する表だ。
このプロジェクトの例で言えば、兵器に使うゾームの糸を防ぐシールドの設計が、進捗管理上では遅延している。
原因は、現在検討しているシールドでは重量が予想よりも重く、兵器全体の重量が重くなってしまうという問題。
そのせいで、設計が遅れている。
それを解決するために、シールドの素材変更を検討している。
課題管理表には、課題として『兵器全体の重量を下げるために、シールドの素材変更を行う』と記載している。
そして、シールドのより軽量な素材を、予算内で探すことが次のアクションとしてマーテルにあてがわれている。
進捗が思わしくない場合には、何か問題があり、それを解決せねばならない。
課題管理表は、そんな問題解決を行うための管理表である。
リスク管理表は、進捗を脅かしそうな要素を予め考え、対策を決めておくための管理表である。
リスクや課題で影響が大きそうなものがあれば、スケジュールやコストを見直す必要も出てくる。
早めにそういった要因を見つけるためにも、管理表が必要なのだ。
定例会議の終わりに、レインがヒロに話しかける。
「ヒロさんの作った、課題管理表とリスク管理表。
すごいですね。
これまでギルドで数か月の期間になる仕事をしたとき、こんな管理表は用意していませんでした…。
何か問題が起きても、みんな忘れてしまったり、うやむやになったり」
「何か、苦労した経験があるんですか？」
「そうなんですよ…。
希少価値の高いヒカリキノコを50個調達、なんて依頼の時、冒険者で手分けして調達となったんです。
ただ、近くではもう探せなくてどうしても10個足りなかったんで、対策案を話し合ったんですよ。
で、ヒカリキノコを繁殖させて、成長を促す魔法で早いこと増やそう！ってなったんです。
ですが…その魔法が使える魔導士って案外少ないので探すのが面倒なんです。
で、誰もやりたがらなくて、え？俺の仕事だったの？お前の仕事と思ってたわ、みたいなやり取りが起きちゃったんですよ…」
「なるほど…
私の元居た場所でも、良くありましたよ」
管理表での管理が無いと、メンバー内での認識合わせができない。
人間の記憶なんて、曖昧なものだ。
自分の都合よく解釈してしまうこともある。
だから、管理表で文字にしておかなければならない。
①課題はどうなれば完了するのか？
②誰が担当しているのか？
③次にいつまでに何をするのか？
上の三つが明確になっていないと、課題の解決は進まないのだ。
レインが愚痴ったヒカリキノコで言えば、次のようになる。
①課題はどうなれば完了するのか？
→ヒカリキノコが後10個足りないので、魔法で繁殖させる
②誰が担当しているのか？
→冒険者A
③次にいつまでに何をするのか？
→7日以内にキノコを成長させる魔法を使える魔導士をギルドの台帳で調べる
これなら冒険者Aはギルドの台帳を調べるという具体的な行為をすればよいと認識合わせできる。
ギルド台帳調べた？と定例で確認していけば、課題として解決に向かっているかの確認もできる。
こういった台帳が無ければどうなるか。
レインが言ったように、誰も課題解決に向けて行動しない。
課題が何であるか、どうなれば解決するのか？がみな良く分からないからだ。
そして、似たようなものとしてリスク管理台帳がある。
これは、起きるかもしれない悪いこと、を認識合わせするための台帳だ。
起きるかもしれない悪いこと。
”リスク”とは本来良いことも悪いことも含めた、将来起きるかもしれない物事のこと。
だが、プロジェクトにおいては悪いことの影響の方が多く、最小限に管理するなら悪いことに焦点を当てるべきとヒロは考えている。
ゾームは現時点で、次の満月には15体程度で襲ってくると想定している。
一度目の満月が15体だったからだ。
だが、リスクとしてはもっと多くのゾームが襲ってくる、という可能性がある。
リスク管理台帳では、次のことを明確にする。
①起きるかもしれない悪いことを明確に書く
②それによる最悪の場合の影響
③最悪の場合に備えた対策
ようは、リスクが顕在化すると最悪どうなるの？ということを明確にして、それにどう対応するの？を考えておくのだ。
リスクへの対策は、4種類ある。
回避
リスクが現実にならないように回避する方法をとる
転嫁
第三者にリスクを請け負ってもらう
軽減
最悪の状況を、ましにする
受容
リスクを受け入れる
ゾームの数が多いかも、という例では、リスク管理台帳に記載すべき項目は次のようになる。
①起きるかもしれない悪いことを明確に書く
→ゾームが次の満月に20体襲ってくる
（サムソン村は10体程度、1度目の満月は15体程度、という増え幅から想定）
②それによる最悪の場合の影響
→兵器の不足と討伐隊の不足による犠牲者の増加
③最悪の場合に備えた対策
→討伐隊のメンバーを増やす
（費用調整が必要なので、他の費用を減らせないか検討）
リスクへの対策においては、まじめに考えると次の4種類があることになる。
回避
洞窟に攻め入ってゾームを根絶やしにする
（遠征は兵力が必要で、これは取れない）
転嫁
錬金術ギルドに協力を仰ぎ、ゴーレムで対応する
（費用的に折り合わない）
軽減
討伐隊のメンバーを増やす
（費用調整が必要）
受容
犠牲者の増加を受け入れる
（プロジェクト目的に反する）
現実的にとれる案が”軽減”であるため、対策は討伐隊のメンバー増加となった。
進捗管理、課題管理、リスク管理。
プロジェクトマネジメントは文字通りマネジメント、管理である。
よって、いろいろなものを管理する必要がある。
その中でもヒロはこの三つの管理がプロジェクトを順調に進ませるには重要だと考えている。
あれこれ管理しすぎると大変だ。
レインというプロジェクト初心者にプロジェクトマネジメントを理解してもらうため、あえてこの三つの管理に限定してプロジェクトを進めている。
★つづく★
