なぜ、システム開発は必ずモメるのか?

目的

合意したはずの仕様で、納品後に「これでは使えない」と言われた。どちらにも言い分がある。

特殊な案件だったのではなく、揉めごとの型は決まっている。本書を読む目的は、その型を先に知って避けることにある。

論点1 揉めごとは、合意の瞬間にすでに始まっている

「既存システムと連携する」で合意しても、発注側は自動連携、受注側はCSVの手動取り込みを想定していることがある。

合意の瞬間に、何を想定しているかを言葉にしておく。後から確認するより、その場で具体を一つ出すほうが安い。

いちこ

細かく確認すると、話が進まない気がします。

シュン

その場では進まないね。ただ納品後に止まるより、ずっと早いんだ。

論点2 記録は、双方を守るためのもの

記録が無いと「言った」「聞いていない」になり、立場の強い側の主張が通りやすい。

• 当日中に送る / 異議は◯日までと書く
• 返信が無ければ合意とみなす … 後から覆りにくくなる

揉めた案件を第三者が見るとき、最初に探されるのがこれになる。

論点3 どちらか一方だけの責任になる揉めごとは少ない

• 発注側 … 決める人を出す / 期日までに判断する / 現場の情報を渡す
• 受注側 … リスクを先に伝える / 決めるべきことを示す / 遅れを早く報告する

自社が果たせていない側を先に埋めると、交渉の立場が変わる。同じ著者の システムを「外注」するときに読む本 は発注側に寄せた内容になる。

いちこ

相手の落ち度を指摘したくなります。

シュン

気持ちは分かるよ。ただ自分の側に穴があると、そこを突かれて終わるからね。先に埋めるんだ。

この本の限界と、次に読む本

2013年の本で、事例の技術環境は古い。揉めごとの構造は変わっていない。発注側の責任範囲なら システムを「外注」するときに読む本、未決事項の管理なら プロジェクトマネジメントの基本が全部わかる本 が隣に並ぶ。