システム開発プロジェクトにおいて何かを決める際、PM（プロジェクトマネジャー）が「みんなで決めよう」と言うようでは問題である。古来より和を重んじる日本人的な発言と言えばそれまでだが、それではうまくいかないのがプロジェクトの持つ独特の性質である。

みんなで決めることにこだわったAさん

　Aさんは情報システム部門の経験年数が10年になる中堅社員である。彼の上司Yさんは業務部門の現場叩き上げのベテラン社員で、数年前に情報システム部門へ異動してきた。長年少しのミスが大事故につながる現場で過ごしてきたYさんは、常々情報システム部門の仕事の仕方に疑問を抱いていた。そんなYさんに、Aさんはなかなかなじめずにいた。Yさんに対するAさんの思いは「少し厳しすぎるよ。みんな仲間なんだから楽しくやらないと」というものだった。

　Aさんが、ある社内システムの開発プロジェクトでPMを任されたときの話である。そのプロジェクトは、設計フェーズまでは社員と数人の協力企業の社員で実施し、実装フェーズ以降はその協力企業にお願いすることになっていた。

　プロジェクトは、基本設計フェーズで立ち止まってしまった。社内をヒアリングしてまとめた要件定義書の内容を実現するには、「コストは少なくて済むが、ある程度のリスクが存在する方法」（案1）と、「リスクは少ないと予測されるが、それなりのコストが掛かる方法」（案2）の二つの案があった。どちらの案にすべきかまとまらないのである。

　Aさんは、できる限りみんなの意見を聞きたいとして何度も検討会を開いた。他の社員もAさんとは長年仕事を一緒にしており気心も知れている。そこで意見を出すことに積極的に協力してくれた。また協力企業の社員もAさんの会社とは長年のつきあいがあり、今回のシステム化を行う業務についても良く知っていた。そのため彼らも積極的に議論に参加したのだった。

　議論が活発なのは良いが、問題はどこへ着地させるべきか結論が出ないことだった。会議では案1で概ね決まりかけているのだが、どうしても残るリスクを受け入れきれず、最後の最後で決めかねていた。

　そこでAさんは、「ではみんなで決めよう」と会議に出席したメンバーの多数決を取ることにした。多数決の結果、1人のメンバーを除いて案1を支持した。そこでAさんは「みんなで決めるのだから」とばかり、案1を支持しなかったメンバーを説得し、プロジェクトメンバーの総意として案1にすることを決めた。

　目標が決まった組織は動きが速い。案1に決まったことでプロジェクトは一気に加速した。単体テストも無事に終了し、このまま順調にいくかと思えたその時である。心配されていたリスクが顕在化したのだった。しかもそのリスクは設計時に想定したリスクではなく、検討から落ち抜けていたリスクであった。案1には別の問題があったということだ。

　Aさんは上司のYさんに報告した。

Yさん：「いったい誰がこの案で行くことを決めたのだ」
Aさん：「みんなで決めた案です」
Yさん：「この案にするための具体的な検討は誰がやったのだ？」
Aさん：「みんなで議論し、みんなで考えて決めました」
Yさん：「プロジェクトの方向性を決めるのはPMの仕事じゃないのか？」
Aさん：「確かにそうですが、今回はみんなで協力して決めたのです」
Yさん：「では失敗の責任は誰が取るのだ？」
Aさん：「責任と言われましても…みんなで協力して何とか乗り越えます」
　　　「そもそもみんなで決めたのですから、私一人の責任ではありません」

　これにはYさんも、これを伝え聞いたプロジェクトメンバーも言葉を失ってしまった。結果的にこのプロジェクトは状況を見かねたYさんの的確なアドバイスのおかげで、何とか2週間の納期遅延で完了させることができた。当初の予算はオーバーしてしまった。

　計画した納期と予算を守れなかったことについて、Yさんは「全ては自分の責任であり、PMに対する指導力不足、監督不行き届きだった」とPMO（Project Management Office）に報告した。一方Aさんは、最後まで「自分は間違っていない」と思っていたらしい。プロジェクトに参加していた社員や協力企業の社員の心は、既にAさんから離れてしまっていたのだった。