こんにちは！一人カラオケ、一人ファミレス、なんでも一人で行ってしまいます。中薗と申します_(:3」∠)_
わりと考え事をするのが好きなので、一人でご飯を食べに行くと落ちつけて良いのです。友人に「一人焼き肉も普通に行く」みたいな話をしたら、「えっ、一人焼き肉はちょっとどうなの」みたいなリアクションをされて悲しい気持ちになりました_(:3」∠)_
しかし！一人焼き肉は最高です！　←_(:3」∠)_

さて、前回の記事では「スケジュールを立てていくプロセスの中で、各作業を実施するうえでの制約や前提上の問題が洗い出せていなければ駄目なんだよ」という話をしていました。
「それじゃあどうやってそれらを洗い出していくの？具体的な方法あるの？」
そういうふうに感じる方が多いかと思います。

制約や前提上の問題は頭で漠然と考えてもよく理解が出来ません。
実際にスケジュールをシミュレーションする過程の中で、初めて客観化出来るものです。

例えば、「プロジェクトを進行する上で、現在獲得している要員数では足りない」という状況を仮定しましょう。
つまり、要因を増やすか、作業のスケジュールを引き直さなければいけない状況です。
このような場合には、次のような問いかけをする必要があります。

1. 必要な要員数をプランした時点での制約や前提は何だったのか
2. スキル要件を緩和すると、要員は入手しやすくなるのか
3. 要員を増加するためのコスト増が認められるのか
4. 要員確保を困難にしている条件はあるか
5. 要員確保が困難な場合、スケジュールを引き伸ばせるか
6. 制約を外せない場合、スケジュールの弾力性はどの程度あるのか。作業を移動させることが出来るのか
7. 移動した場合、他の作業にどのような影響が出るのか
8. 7で発生する影響を避けるためにはどうすればよいか

変化を先読みし、「この行動を取れば結果はこうなる」という試行錯誤のプロセスを経る。
それを行うことで、初めてコストやリソース、スケジュール上の各制約間の無理・矛盾を客観化することが出来ます。

このように、前提条件がどこまで現実的であるかを検証し、問題解決を行うプロセスをスケジュールに組み込まなくては、プランの実効性は上がらないものなのです。

【関連記事】
サーバの冗長化について①
サーバの冗長化について②
ロードバランサについて
負荷試験について
プロトコルについて①
OSI参照モデル①
OSI参照モデル②
OSI参照モデル③
プロジェクトマネジメントの手法①
プロジェクトマネジメントの手法②
プロジェクトマネジメントの手法③
プロジェクトマネジメントの手法④
プロジェクトマネジメントの手法⑤
プロジェクトマネジメントの手法⑥
JavaScriptのテストフレームワーク
プロジェクトマネジメントの手法⑦