前回、撤退戦略を取るに至るまでの経緯と契約書の重要性について書きました。今回は撤退戦略に舵を切った後の撤退戦術について書いてみたいと思います。そもそもプロジェクト撤退とは、戦いです。撤退戦なのです。撤退戦の勝利条件も含め、撤退戦術について詳しく紐解いてみましょう。

■ 撤退戦略 (1) 契約締結前 編

前回から重ねて言いますが、撤退ありきで仕事することを勧めてるわけではありません。が・・・中には「おっ、こいつはヤバいぞ」という臭いがするプロジェクトやクライアント、時には共同作業者(社)がいるのも事実です。悲しいことですが。さて、こうした事態は非常に残念ですが、これが契約締結前で、かつ作業着手前であればラッキーです。何の義務もへったくれもなく撤退することが可能です。何ら悪びれることもありません、おめでとうございます。

もしよんどころのない事情で契約書締結前に作業着手してしまったら・・・こうなると少し話は厄介です。そもそも案件から撤退するということは、何らかのキナ臭い煙が立ち込めている(か、誰よりも先にそれに気づいている)ので、すんなり撤退できればもうそれだけでめっけもん、着手した分の請求ができて入金されたらそのクライアントに対して「あれ？実はいい奴なんじゃね？」とプラスの評価をしてしまうかもしれません(それはない)。

まず、撤退戦の勝利条件を決めておきます。これは契約締結後の撤退にも言えることですが、撤退戦で重要なのは、相手を打ち負かすことではなく、こちらが負けないこと、これ以上のダメージを負わないことこそが最重要なのです。欲をかいて少しでも取れるものは取ろう、というように戦線を広げようとすると大抵失敗します。勿論、正当な権利として請求すべきものは請求しないと、それはそれで「ああ、こういうケースだと払わなくていいんだ」と勘違いさせてしまうことにも繋がりかねません。が、こればかりは回収コスト見合いというのが現実でもあります。

契約締結前にまったく作業着手していなければラッキーですが、もし何らかの作業を行った場合、以下の確認を文書で取り交わしましょう。

1. これまでに行った作業の一覧を提示し、その内容に齟齬がないこと
2. これまでに行った作業は本来契約締結を前提とした作業であるが、契約締結前に着手した作業であること
3. これ以上の業務遂行責任を負わないこと

これまでの作業分について請求できるかどうか、という請求根拠にもなり得るので、上記3つは最低限確認しましょう。勿論、一度手を上げた案件を降りようとするわけですから、発注者側の心象は当然悪いはずです。仮にこちらに非がない場合であっても、撤退するという判断をするからには事実をありのまま説明し、理解してもらわなければなりません。撤退戦の勝利条件、についてもう少しハッキリとした書き方をすると、これは「そもそも何故撤退するという判断をしたのか」にも繋がってきますが、だいたい以下のケースに収斂されるのではないでしょうか。

1. 求められる成果に対して契約条件が著しく受注側に不利
2. 契約締結あるいは作業開始前と条件が変更された
3. 時間、コスト、裁量権のいずれかが不足している
4. 上位会社や共同作業者(社)がボトルネックとなりプロジェクト遂行が不可能

■ 撤退戦略 (2) 契約締結後 編

晴れて契約締結、順調に作業をしていたにもかかわらず、それでもプロジェクトの撤退を余儀なくされる場合があります。私の経験則では、契約締結前の撤退ケースに加えて、以下の条件が当てはまるのではないかと。

1. PLやPMが進捗や品質を適切に管理できていない
2. 事前に想定していなかった追加要求が膨らんでいくにもかかわらず、プロジェクトのスコープや契約条件の見直しがない
3. 検収条件が明記されていないにもかかわらず、あるいは不当な理由で検収を拒まれた

前者2つはいわゆるデスマーチ、後者はヘタすると発注側が訴えられてもしゃあない的な事件ですね。契約締結後に撤退すべきと判断する基準はいずれも「後出しジャンケン」になるのかと思っています。勿論、発注者だって人間ですから、事前にデスマることが完璧に予想できるわけではありません。しかし、ここでは炎上そのものではなく、炎上してしまったにもかかわらず何のケアもないことを問題視しています。

こうしたケースで撤退を検討する場合は、非常に慎重な判断が求められます。これは撤退そのものに及び腰になる、という意味ではなく、できるだけ手駒を用意した上で撤退戦を戦うということを意味します。つまり、クライアントへ撤退の意思を告知する段階で丸腰ではダメなのです。

■■ 撤退戦で用意する武器 (1) タスクの棚卸し

まず、これまでにクライアントがどれだけの要求をし、どれだけ応えることができたかをリストにまとめます。このリストは粒度が細ければ細かいほど理想的です。言い換えれば、プロジェクトの大きな単位で「未成 進捗N%」では単なる契約不履行、敵前逃亡と変わらないとみなされてしまいます。

また、終了したタスクだけでなく、未成のタスクについても正直に書き出しましょう。それをクライアントにどう見せるかは別の話として、ボールは誰が持っている(た)のか、そのタスクが今の時点で未成なのはスケジュール通りなのか、それともスケジュールを過ぎているのか、これは最低限書き出しておきます。可能であれば、どれだけのINPUTがあれば、そのタスクをOUTPUTできたのか、足りないリソースは何だったのかも書き出しておくとよいでしょう。

もう1つ大事なのは、タスクは終了させればよいというわけではありません。言い換えれば、本来、昨日までに終了予定のタスクがあったにもかかわらず、クライアントからの割り込みタスクなどの理由で優先度が変わってしまったためにそれが終了できなかったら・・・なので、タスクの終了本数だけでなく、割り込みの発生数も考慮に入れなければなりません。

ここで1つ気づいたあなた、鋭いです。これ、本来PLやPMが管理すべき項目なんですよね。つまり、こうした武器を用意しなければならないということはもうこの時点でプロジェクトマネジメントが破綻しているのです。

■■ 撤退戦で用意する武器 (2) 課題整理

あなたがオペレータであれば別ですが、少なくとも「エンジニア」と名乗っている以上は課題解決が存在価値と言っても過言ではありません(というのが私の持論です)。コードやインフラはその手段です。言い換えれば、コードが書けるだけ、ネットワークやサーバの構築ができるだけ、というのは、それは高度なオペレータでしかありません。

PLやPMから常にタスクが降りてくるだけであれば楽なのですが(それってオペレータだよねw)、何かしら手を動かすうちに可視化される課題というものがどうしても発生します。これはもうエンジニアがボトムアップで問題提起するしかないのですが、どれだけ問題提起したのか、そしてどれだけそのチケットがクローズできたのか、そしてここが重要なのですが、自分の職責を超えた判断が必要でエスカレーションした問題提起のうち、どれだけ解決されたのか、されなかったのか、についても課題リストにまとめておきましょう。

---

さて、契約締結後のプロジェクトからどう撤退するか、についてですが、先ほど2つの武器を用意しろと書きました。タスクの棚卸しと課題リストの取りまとめですね。これら2つの武器を用意する目的は次の通りです。

1. 責任分界点を明確にする
2. 分割納品交渉の材料にする

プロジェクト撤退の戦術は、交渉力が肝要です。交渉材料がなければこちらの要求を通すにも相手の不当な要求をRejectするにも根拠を欠くことになりかねません。声が大きい方が勝つ喧嘩というのが許されるのは小学生まで、大人の喧嘩はスマートに、です。

■ プロジェクト撤退交渉 基本戦術

「契約書の確認ポイント」にも書きましたが、契約書に紛争発生時の処理について明記されているか再確認しましょう(もちろん契約前にちゃんと確認するのがベターですが)。完成前のプロジェクトから撤退する、ということは、何かしらの紛争材料があるか、プロジェクトの継続が困難なほどにモチベーションが下がっているかのどちらかですし、これらのうちいずれか(あるいは両方)が受忍限度を超えたときが、プロジェクト撤退を意識する契機であるとも思っています。こちらが相手方によろしくない感情を持っているときは、恐らく相手方もそれなりにこちらに対してネガティブな感情を持っているはずです。なので、感情論のぶつけ合いになるともう泥沼です。これを防ぐためにも、2つの武器は用法用量を守って正しく使用しましょう。

■■ プロジェクト撤退の切り出し方

双方が感情的にもつれているか、それが予見される場合において、プロジェクト撤退の切り出し方を間違えると余計にこじれかねません。何度だって言いますが、発注者だって人間です。感情を抜きにして理屈だけが通る世界であれば、「これだけの理由でもう継続は無理」「うんわかった」がすんなり通るでしょう。しかし、プロジェクトが上手く回らない状況において、これ以上ダメージを負いたくない、という感情に発注者も受注者もありません。

恐らく、前項で述べたタスクの棚卸しと課題整理をした時点で、「つらい」という感情の言語化がしやすくなったのではないでしょうか。しかし一方で正論で殴れば良いというわけでもないのが人間相手の難しいところ、こればかりは相手を見ろとしか言えないのですが、こちらが言いたいことをコンパクトにまとめられなければ始まる話も始まりません。プロジェクト撤退を決意し、クライアントへそれを伝える時点でそれなりの覚悟が必要ですが、要約すると以下の内容を淡々と伝えるのがよいでしょう。

• プロジェクト途中離脱したい、という意思表示
• プロジェクト撤退という判断に至るまでの経緯(感情的にはならない)
• 発生事実のうち、争点になるであろう箇所について、意識のすり合わせ

■■ それでも何がなんでも完成させろと言われたら

今のリソースでどうにもならず、環境改善の見込みがないから撤退したいと言っているのにこんなことを言われたら、これはもう契約としてどうなんだい、という方向に持って行くしかないです。完成責任のある契約なのか、完成責任があるとしてそれが無条件に無限責任として負うべきものなのか、契約条項で謳っているかを確認しましょう。残念なことに契約条項では判断できない、あるいはこちらが有利になるという確証が持てない、という場合は、弁護士さんに相談するしかないかと。

とまあ、話がこじれにこじれる前提だとどこまで考えても追いつかないので、戦術としては以下の順序で相手の反応を見るのがよいでしょう。

1. 事実で戦う

2. 契約で戦う

3. 法律で戦う

■ プロジェクト撤退 勝利条件のおさらい

冒頭にも書きましたが、プロジェクト撤退戦の勝利条件は「こちらが負けない」ことです。なので、以下の項目をどこまで認めてもらうか、最低ラインは決めておきましょう。

1. 撤退に伴う義務や権利の整理
   1. どの時点での納品(検収)とするか
   2. 検収後の瑕疵担保責任について
      1. 瑕疵担保期間
      2. クライアントや他の協力会社が手を入れた際の保守について
2. 分割納品(部分入金)の可否
   1. 分割納品(部分検収)の可否
   2. 完成率の算定

武田信玄も「戦に勝つということは、五分を上とし、七分を中とし、十分を下とする」と言っています。あまり欲をかいて交渉が長期化しても疲弊するだけです。勝利条件と最低限譲れないラインはよく考えましょう。

 

---

さて、2回にわたってプロジェクト撤退について書いてみましたが、理想論を言えば、撤退戦略は本来クライアントと良い関係を築ければまったく不要なスキルです。しかしながら、システム開発にはトラブルがつきもので、特に元請<–>下請のビジネスモデルでは様々な利害関係により、プロジェクトはすんなり回らないということもよくある事実です。

勇ましい掛け声で、やるぞ勝つぞ大勝利！と叫ぶばかりが戦いではありません。周囲の声に押されて勝ちにこだわりすぎると正しい戦況判断ができずに大負けするリスクを孕みます。「負けないこと」の大事さを今いちど噛みしめたいものです。