事例から学ぶ 「旭川医科大学・NTT東日本事件」
感覚的にはもう上告まで進んでいたんだ、です。エンジニアがそうそう仕事で裁判所に呼ばれることはないので、呼ばれたときに困ってしまうプロジェクトマネジメントのアンチパターンを事例から整理しましょう。
＃できるかな
基礎知識
最初に「スルガ銀行対IBM事件」（東京高判平成25年9月26日）で出されたシステム開発におけるベンダのプロジェクトマネジメント義務とユーザの協力義務の内容、関係を理解しておく必要があります。
ベンダはシステムの専門家なのであり、ユーザの業務や要望について詳しいわけではありません。そのため、ユーザが求めるシステムを作るためには、ユーザとベンダとの共同作業が不可欠になります。この共同作業において、ベンダが負う義務がプロジェクトマネジメント義務、ユーザが負う義務が協力義務だといわれています。
ざっくり言えば、システム開発のプロなんだからやること全部やっておきなさい、ということです。あれこれ理由をつけてプロジェクトマネジメントのやることをネグるならそれはオウンリスクだよ、と。
このやらなかった後始末にどのくらいコストと時間が掛かるかはプロマネ、エンジニアそしてマネージャでも見極められる人は少ないです。ほぼほぼ、ろくに考えず目の前の仕事を片付けるために考えもせずにやっています。最悪なケースは自分にはおきないなんてどうして思えるのか不思議です。ほんと。
あと、基礎知識として顧客側とベンダ側のSOWの線引きをしておきなさい、ということです。顧客には顧客の仕事をさせなさい。ベンダはプロなんだから顧客のマネージもリスク対策としてやっておけ、ということです。
例えば、受け入れテストの進捗が悪いからといって契約にないテスト実施をベンダから無償でやってはいけないです。本契約とは別に、派遣で顧客の指示下で社員代替としてやるのが正解です。本来は別の業者を紹介するのが良いかもしれないです。
事例から学ぶ
さて事例から改めてプロマネの勘所を学びましょう。でも、これって基礎の基礎ですよ。
工程を終了させる
「仕様凍結」の定義とそれを必ず行いなさい。つまり、工程を終了させなさい。
ウォーターフォールなら局面で行程終了を宣言し、顧客の承認を得る。局面を中間納品に設定し、検収させることが望ましいです。
局面を切ることはベンダ側も行程内の進捗が露わになり、痛みを伴う（遅れていれば）ことが想定されますが、それはそれで何が遅れて、何が課題で、それぞれの対処を行程終了の中で合意しておくことが必要です。
そうそう、必ず、営業を同席させて検収書の手続きを確認させましょう。
議事録を残す
会議体を設定し、会議体ごとに議事録を各回分残しなさい。
全てがエビデンスです。担当者同士で仕様変更要望やそれの回答をさせないで、課題管理で一元的に受付後、変更管理プロセスで採否をプロジェクトとして決定しなければなりません。
つまり、仕様変更の意思決定は最終的にQCDに影響するので顧客判断が必要だということです。現場でエンジニアが勝手に受けてホイホイやらせては統制が取れませんし裁判で揚げ足を取られます。また顧客をプロとしてマネジメントしなければならいのですから仕変をやったらQCDがどうなるかを専門家として顧客に理解させ、予算と時間を確保できたら計画変更をして着手させる必要があります。
この変更管理プロセスを回すためにもボトムの会議体の議事録が起因となるので議事録を残す必要があるのです。もちろん、議事録もオーソライズさせなければなりません。
SOWを曖昧にしない
（上述しましたが）ベンダ側と顧客側の仕事の線引きをしなさい。
契約書にSOWを書き、その通りに役割分担してプロジェクトを進める必要があります。作業の分担がなし崩し的になり、ひいてはそういう状況を受け入れていたと誤認させることになりかねないので。
嫌な役割なんですよ。契約どおりに進まないので。そこに変にブリゲーションを感じてしまいがちですが、書いてあることをまずはやらなければ、結果的に最悪なことが起きればプロジェクトチームを守れないし、顧客の実現したいシステムも頓挫するんですよと言い続けなければならないのです。
そういう役回りです、プロマネは。
このように、ベンダは、プロジェクトマネジメント義務の履⾏として、追加開発要望に応じた場合は納期を守ることができないことを明らかにした上で、追加開発要望の拒否（本件仕様凍結合意）を含めた然るべき対応をしたものと認められる。これを越えて、ベンダにおいて、納期を守るためには更なる追加開発要望をしないよう注⽂者（ユーザ）を説得したり、ユーザによる不当な追加開発要望を毅然と拒否したりする義務があったということはできず、ベンダにプロジェクトマネジメント義務の違反があったとは認められない。
下線1は、変更管理ですし、下線2も変更管理です。そうした変更管理もその前のスコープ管理が統合的にコントロールできていないとどうしようもないのですけど。
変更管理の本ってあまりないんだなー。
