■プロジェクトマネジメントの応用 １５（ソフトウェア開発編）
◆変化に対応する
①計画通りにはなかなか進まない
プロジェクトを実際に進めたことのある人は経験済みであるが，当初計画した通りにプロジェクトがその通り進んだと云うことは殆ど無いのが多いのではないだろうか。即ち，短ければ半年，長ければ１年を超えるプロジェクトにおいて，半年前，１年前の計画が全く変更もなく，計画通りに進むことは殆ど無いのである。それは計画がいい加減に立てられたからではなく，当初予測したことから，内部的な，或いは外部的な変化が必ずあり，それによって計画を余儀なく修正せざるを得ないことが起こるからである。
だからプロジェクト・マネジメントの重要な一つに，変化に如何に対応できるか，があるのである。もちろん，計画立てた段階で，いずれ修正せざるを得ないと思って計画を立てる訳ではない。最善策を十分検討し，リスクも予め抽出し，そうしたことに対して余裕も持たせて計画を立てているのである。また，これまでの経験から学んだことも十分取り込んでいる。
計画を十分錬ることは非常に大切なことではあるが，計画通りに進められないとプロジェクトが上手く行かないと，がんじがらめの計画を立てることよりも，プロジェクトに変化は付きものと，変化に如何に対応すべきかを検討しておくことの方が実際的で且つ，有効な方法である。
②内なる変化
内部的な変化の一つは，当初計画した仕様に対して，プロジェクトが進んでいくと今まで判らなかった，或いは曖昧なままで進んで行って初めて決定できる仕様もあり，こうした仕様の変更（修正）が生じることがある。単に検討不足とは言い難い内容で，目標と出来映えを比較して，変更せざるを得ない内容も出てくる。こうした仕様変更に対しては，当初仕様に固執するのではなく，結果的に良いものにする必要がある。殆どのプロジェクトにおいて，その影響の度合いは大小様々であるが，発生することである。
同じように仕様変更でも，当初の見込み違い，検討不足と云う部分ある。特に，仕様がこれまでの経験では十分見極めができない新規の部分がある場合などである。こうした未知の部分があれば，予め計画段階で多少の時間的余裕，バッファーなどを取っておき，対処する方法などが考えられる。
もちろん，予想外の問題発生が皆無とは云えない。よく云われる想定外（東日本の大震災ではよく聞いた言葉である）の問題が発生することである。これは経験則から予測して立てた計画が狂うことで，これには予め余裕も，バッファーも取るわけにはいかない。こうした問題，課題には，素早く対応することで，先延ばしすることは得策ではない。後になればなるほど，その影響度合いが大きくなることが殆どである。リーダ，サブリーダの素早い判断，対応がカギを握っている。
これもよくあることだが，メンバーが体調不良を起こしてプロジェクトから離脱することが起こる。これも予測できない。しかし，ノルマが厳しすぎてダウンするなど，その兆候は事前に必ずあるので，リーダはメンバーの健康管理などには気を割かなければならない。特に，キーになるメンバーの離脱はプロジェクトにとって致命傷になりかねない。
さらには，メンバーのスキル不足もある。これは当初予定したメンバーが実際にやり始めると，実力が伴っていないことで，特に，初めてプロジェクトに参加するメンバーなどには十分注意を払うことが必要で，新規のメンバーの比率を余り高くしないなど，リスク管理が必要である。特に，取り返しが難しいのは，外部委託で，スキルの実態把握がなかなか難しい。かといって，内部にバックアップ部隊を持つような余裕のあるプロジェクトは先ず無い。こうしたリスクは，事を徐々に，状況を素早くフィードバックを掛けながら進める堅実さが必要で，これもプロジェクト・マネジメントとしては基本的なやり方である。
③外の変化
内部だけでなく，プロジェクトは外的変化の影響を受けることがよくある。一番大きなものは，景気変動など経済のマクロ的な大きな変化の影響を受ける場合がある。ものによっては，プロジェクトを中断せざるを得ないケースだって起こりうる。プロジェクトとは，何か新たなことをやろうとするもので，組織的な定期的オペレーションと違うので，経済変動などに左右されることが起こる。要は，周りの経済活動にとって，当該のプロジェクトが結果として効果が薄い，或いはタイミングを逸してしまっているなど判断される場合がある。
通常のプロジェクト，例えば新製品開発など，市場での競争であり，競合の台頭如何で，プロジェクトが大きく左右されることがある。競合の進み具合が早ければ，それに打ち勝つ早さを目指して，メンバー増強など，勝つ手段を求めなければならない。或いは，競合の情報を元に，市場で勝てるものへの変更が必要なことも起こってくる。
ステークフォルダーは勝手気ままなことが多く，途中から新たな仕様追加をすることも良くある。プロジェクトの途中からステークフォルダーが増えるなどすると厄介で，その意見を追加して取り込む必要性が出てくることさえある。こうした仕様変更に伴うような事態の発生には，変更履歴などを明確に，プロジェクトとしての正しい評価ができるよう心掛けるべきである。プロジェクトを受ける側は受け身であることが殆どだが，メリハリはつけるべきである。
組織変更が発生して，プロジェクトに影響を及ぼす場合もある。通常はプロジェクトの状況を見て，影響が無いように取り計らわれることが多いが，昨今はいつ何時，会社そのものが吸収合併する事態が起きないとは言えない。また，予め組織変更が予測されるような場合には，プロジェクトとしての成果を明確にさせたり，開発のスピードアップを図ったり，要するに，ムダな活動にならないようにしなければならない。
[Reported by H.Nishimura 2011.10.02]
Copyright (C)2011 Hitoshi Nishimura
