IT業界でプロとして活躍するには何が必要か。ダメな“システム屋”にならないためにはどうするべきか。“システム屋”歴30年を自任する筆者が経験者の立場から、ダメな“システム屋”の行動様式を辛口で指摘しつつ、そこからの脱却法を分かりやすく解説する。（毎週月曜日更新、編集：日経情報ストラテジー）
先輩“システム屋” 「プロジェクトマネジャー就任おめでとう。このプロジェクトにおける最悪、ワーストの事態って何だと思う？」後輩“システム屋” 「私が初めて責任者を務めるプロジェクトですから、一生懸命やりますので、最悪なんてことは起きません」
先輩 「その意気込みは大切だけど、起こりうる最悪の事態をあらかじめ考えておかないとダメだよ」
後輩 「どうしてですか？」
先輩 「プロジェクトだから、納期、コスト、品質、顧客との信頼関係のいずれも重要だ。まずは、それぞれで最悪の事態を考え、それが起きないように手を打っておくといいよ」
後輩 「その意味では、今回は新規顧客のプロジェクトなので、信頼関係を作れなければ最悪ですね」
先輩 「そうそう、そのためにコミュニケーションに留意するなどの手を打つ。その次の最悪は何かな？」
若手 「要件定義ですね。顧客企業からの要求はどうも抽象的で、精神論みたいなところがあって、要件があいまいなまま設計に突入する恐れがあります」
先輩 「それならどういう施策が必要だろうか・・・というように最悪の事態を1つひとつ潰していく。それがプロジェクトマネジャーの仕事だ」
若手 「なるほど」
先輩 「逆に、最良、つまりベストシナリオは何だと思う？」
若手 「それはもちろん、プロジェクトがうまく行くことでしょうか」
先輩 「それだけ？」
若手 「いや、これで信頼関係ができ次のプロジェクトも任せてもらえるようになる」
先輩 「それだけ？」
若手 「いやいや、この案件でノウハウが蓄積して、他のプロジェクトにも“横展開”する」
先輩 「それだけ？」
若手 「え、まだありますか？」
先輩 「ベストシナリオが小粒だと思うよ。もっとワクワクしながらプロジェクトに取り組めるようにしないと」
（前回に戻る）
ダメな理由：最悪をイメージできない
以前、この連載の第13回で“システム屋”の営業担当者は、「最悪と最良」「ベストとワースト」の両方を描くべきだだと指摘しました。これは、プロジェクトマネジャーでも同じことです。
“システム屋”が情報システム構築プロジェクトに取り組む時に、プロジェクトが失敗する、あるいは大きなトラブルが発生するケースをイメージしてみてください。当事者たちは「想定外」の事象が発生したと感じるかもしれません。
しかし、そもそも想定外の事象が起きるということは、想定の範囲が狭すぎるのです。あるいは想像力が弱いのかもしれません。想像力を働かせて、「このプロジェクトが最悪の事態になるとしたら、それはどういうことだろうか」と突き詰めて考える必要があります。（関連記事）
要件をきちんと定義できない、入出力仕様がなかなか決まらない、初めて使うソフトウエア製品の扱いに苦労をする、2人のサブリーダーの意見が衝突する、データ移行時に人海戦術を取らなければならなくなる、顧客企業側のテストケース設定が甘く本番データでそれこそ「想定外」が続出する、新人プログラマーのスキルが低い、などなど。様々な事態が考えられます。
最悪のシナリオを想定し、その兆候はどうやって知ることができるかを押さえ、そして対策の方向性を考える。さらに、最悪のシナリオまでは至らなくても悪いことが起きる「セカンド・ワースト」を考える。これについても兆候発見方法と対策をあらかじめ考えておく。こうして、最悪のシナリオを1段階ずつ、より問題が小さく発生確率の低い方向へ持っていく。これがプロジェクトマネジャーの仕事です。
