みなさんこんにちは。かつて火消しばかりやっていた @nullpopopo でございます。昨日twiterを見ていたらこんなツイを発見しまして。

https://twitter.com/nishi1010kawa/status/726385332434833408

↑の絡みでたけさんがフリーランスあるあるなブログをまとめられていてかなり参考になった(というか、「あるあるあるある↓」と頷いた)のですが、フリーランスで仕事していると、たまに、極々たまーになんですが、まるで普通に道を歩いてるだけでいきなり鉈で殴られるかのようにとんでもないクライアントに出くわしたり、最初はうまく回っていた案件(のように見えていた)なのに、だんだん雲行きが怪しくなりデスマーチに・・・という経験は誰しも一度は経験したことがあるのではないでしょうか。

何を血迷ったのか、これからフリーランスのエンジニアになりたい、あるいは非自発的にやむを得ずサラリーマン戦線を離脱してフリーランスとして食っていかざるを得ない方々のご参考になれば、と私の黒歴史をほじくり返してみたいと思います。今回は、上位会社やPL、PMがいてあなたが下請の1メンバーとしてプロジェクトに参画しているという想定で書いています。

試しに「プロジェクト 撤退 方法」でググってみましたが、いわゆるプロジェクトマネジメントや事業計画の観点で語られているものばかりがhitし、フリーランスや中小ソフトハウスの立場で語られているものがなかった、というのも執筆契機の1つです。今回はかなりネガティブなことばかり書きますが、決して来た仕事なんでも断れ、と言っているのではなく、ましてや無責任に仕事を放り出せと言っているわけでもありません。仕事は義務であると同時に、権利も含んでいます。正しい権利の行使をためらう必要はないのです。どうか誤解のなきよう。

本来であればサービス開発は楽しく有意義であるべきにもかかわらず、不幸にも黒塗りのベンツ・・・ではなく不幸にも様々な要因撤退を余儀なくされるケースがあります。プロジェクト撤退は決して恥ずかしいことではありません。自分の人生、主人公はあなた自身なのです。決して誰かの人生や社会、会社の奴隷になってはいけません。この前提で、今回は撤退戦略に最低限守るべき戦術について書いてみようと思います。

■ プロジェクト撤退とは

プロジェクト炎上の理由は様々ですが、だいたいは「予算」「時間」「スキル」のいずれかが不足し、これらが当初の想定をはるかに超えるの(またはこれらの複合要因)に加え、それが鎮火しない理由が「コミュニケーション不足」「決定力不足」であると思っています。ソフトウェア開発の現場で、よくこんな風刺絵にも似た状況が揶揄されることがあるでしょう。

予算の不足や時間の不足は、マネジメントに問題がある場合がほとんどなので、ここでは割愛します。スキル不足については、発注側の過度な期待と受注側の大風呂敷、どちらのケースにも当てはまりますが、いずれにしても事前のコミュニケーションで本来防げるはずなのに、残念なことに一度着手したプロジェクトでスコープが肥大化したり、想定外の難易度でどうにもならないケースは稀によくある話です。

システム開発の方法(根性)論が書いてあるサイトや書籍では、ほぼ例外なく「アラートは早く上げろ」と書いてあります。しかし、プロジェクト(プロダクト)オーナーだって人間、ボトムアップで上がってきたアラートを受けて「はいそうですか」と簡単に軌道修正するわけがありません。ロジカルな理由づけは他のソースをいくらでも当たっていただきたいのですが、「人間的」な理由を挙げると、PMやPLが企業の中間管理職以下の職位であった場合、上席者や経営層への悪い報告は出世に響きます。また、PMが経営層の場合、顧客や株主への説明に大変苦慮します。これが「アラートが握りつぶされる理由」なのです。アラートを上げるだけでプロジェクトが回ったらデスマーチなんておきるわけがありませんよね。

つまり、こうした理由によってアラートへのフォローがなされなかったり無視されたり、というようなケースが続くようであれば、これはもうプロジェクト撤退の立派な理由になると思っています。一番最悪なのは、こちらが都度都度進捗報告や品質報告をしていたにもかかわらず、完成間近になって「こんな機能は望んでいなかった」などと言われてしまうケースです。こうなると、それまでにかけた工数が一瞬で水泡に帰すどころか、要件定義からやり直す工数どっから捻出すんの？となるわけです。

では「お金出すからやり直してよ」とクライアントが言いますか？仮にそう言ってくれたとして、失敗要因をきちんと分析して(できて)やり直せますか？それができると自信を持って言えるならこれ以上読み進める必要はないでしょう。残念ながらクライアントは変わってくれません。しかも、クライアントはベンダーを変える権利を持っています。が、契約というものは双方の合意があってはじめて成立するものなので、片務的であってはならず、こちらからお断りする自由があるのです。受注者たる我々が行使できる最終戦術が「プロジェクト撤退」なのです。

■ プロジェクト撤退を意識するとき

前項で述べた「○○不足」が顕在化し、その改善が見込めないと判断したときが、プロジェクトの撤退どきです。いわゆる見積もりの甘さが仇となるケースがほとんどだと思うのですが、残念なことにプロジェクトの工数やリスク見積もりが受注者側のタスクになっているのが現実です。また、工数やリスクを正確に見積もれるだけの判断材料がクライアントからすべてもたらされるとは限りません。

なので、いわゆる「聞いていた話と違う」が解決されないと、心も身体も財布も健康にはなれません。プロジェクト撤退は、いわば後出しジャンケンに逆転勝利するための戦略と言ってもよいでしょう。いささか乱暴ではありますが。

■ プロジェクト撤退方法そもそも論 契約書はちゃんと取り交わそうぜ

言うのは簡単ですがなかなか実行できないのが、「案件着手前にちゃんと契約書を取り交わす」というタスクではないでしょうか。契約書の必要性についてダラダラ書いても釈迦に説法だったり「そんなのできりゃとっくにやっとるわい」となるので割愛しますが、契約書を取り交わす究極の目的は

1. 役割(義務の)分担と責任分界点の明確化
2. 契約主体のうちどちらかが義務を行使できなかった場合どこまで責任を負うか

の文書化だと思っています。なので、相手方がどんなに急いでいても、また、こちらが「こんなのすぐ終わらせられるぜ」と思っていても、初めての取引であれば絶対相手方のオフィスまで出向いて、危険な香りがしないか確認する習慣をつけましょう。それを怠るとほんと痛い目にあいます(経験者 匿名希望:サーバーエンジニア 40歳男性 談) 。

初めての裁判所 – 不払いクライアントに少額訴訟をおこしてみたよ – 1/2 | (っ´∀｀)っ ゃー | nullpopopo

初めての裁判所 – 不払いクライアントに少額訴訟をおこしてみたよ – 2/2 | (っ´∀｀)っ ゃー | nullpopopo

つまり、契約書をちゃんと取り交わすことが、正しい撤退戦略の第一歩、とも言えます。

■ 契約書の読み方

こちらがベンダー、相手方がクライアントという立場の場合、こちらが契約書を書いてクライアントに提示して承認をもらうというフローがイメージしやすいかと思いますが、クライアントがある業務を定常的にアウトソースする場合、すでに契約書が用意されているケースもあります。冒頭に挙げたケースがまさにそれなのかと思いますが、こうしたケースでは大抵

クライアントに有利なように契約書が書かれているケース

だと思いましょう。それが法や商習慣に照らしあわせて合理的なものであればまだしも、さらっととんでもないことが書いてあったにもかかわらず、すぐにサインしてしまうと本当に痛い目を見ます。

■■ 契約書を提示されたら

まず、相手方から契約書を提示されたら、その場ですべてを確認するのは不可能なので、必ず持ち帰り検討する旨を伝えましょう。その際、いつまでに返事をすればよいかも合わせて確認するのはマナーでもあるので必須です。

もし、その場で確認できるくらいにペラペラなボリュームの契約内容だとしても、それで安心してはいけません。これには2つの意味があります。

1. 契約書に謳われている内容の無双無限なる拡大解釈に気をつけろ
2. 契約書の行内に書いていない内容が行間という亜空間にいくらでも書かれているので全部書き出せよオラ

世の中悪意の塊みたいに書いているようですが、実はこれ、なーんも考えていないケースで往々にしてあり得るのです。契約というのは情で交わすものではなく、ましてや白紙委任でもありません。つまり、相手の善意にのみ依存するのは非常に危険ということでもあります。

よく海外かぶれの「これだから日本人は」と言いたがる連中は、とかく「決められない」ことに対してバンバン斧を投げてきますが、その場でサインをしないことは決して「決められない」のではなく、次の「契約書の確認ポイント」に示すように、確認すべき項目が山のようにあるからなのです。初見の契約書にその場でサインを求めるようなクライアントは、今後の付き合いも含めて要注意いや要警戒です。また、契約締結前であれば、何の義務も権利も発生していないので、撤退戦というよりも国交断絶というフェーズです。

■■ 契約書の確認ポイント

極論「5w1h」を曖昧にするな、になるのですが、これだとあまりにも大味すぎるので、最低限以下のことを確認しましょう。以下の例は、何がしかの納品物を納めたり環境構築を行ったりする契約を前提としています。いわゆるSES契約や派遣契約については対象としていません。

• 受注側が契約上何をしなければいけないのか、義務の範囲はどこまでか
  • 作業範囲
  • 案件(契約)の目的 (さすがに品質にまで踏み込むのは双方にとって酷か)
  • 完成責任の有無
  • 共同作業者がいる場合に義務や権利の線引きはあるか
• 発注側の義務が謳われているか
  • 検収基準が明確か
  • 品質や進捗についての監督責任を明記しているか
• 納品物の権利と義務について
  • ソースコードやconfigなどの納品物を納める契約の場合、これらの著作権が誰に帰属するのか
  • 納品物の権利は、まるっと買い上げなのか、使用権なのか
  • 納品物の保守を行う義務について
    • いわゆる瑕疵担保義務(期間、内容)
    • 保守の義務を負う者以外が納品物を変更したらどうする？
• 有償プロダクトやインフラのサポートについて
  • これらのサポート契約は締結されている(これからする)のか
  • 契約主体は誰か
  • 受注者がチケットを起票することができるか
• 支払いについて
  • いつの時点で請求できるのか
  • 開発が長期にわたる場合、分割納品などが可能か
  • 締め日や入金期限などの日付が明記されているか(検収後N日、でも可)
• 紛争発生時の処理について
  • 紛争解決手段が明記されているか
  • 双方の権利義務について明記されているか

もう1つ大事なことについて明記しますと

• 契約書に謳っていない内容については、一切の義務を負わないことが明記されているか

についても確認することをおすすめします。つまり、素人考えでざっと思いつくだけでもこれだけ確認することがあるのに、その場でポンポンはんこを押すなんて怖くてできないことがお解りいただけたかと思います。

さて、撤退戦略の戦術についての詳細は・・・と言いたいところですが、ここまででかなり長くなってしまいました。次回は撤退戦術についてフェーズごとに分けて述べてみたいと思います。