システムを「外注」するときに読む本

目的

顧客の要望は全部聞いた。できる限り応えた。それでも納品後に「これでは使えない」と言われる。

技術の問題ではなく、業務をどうしたいかを誰も決めていなかったことが多い。本書を読む目的は、発注側が手放せない仕事の範囲を理解することにある。

論点1 業務のあるべき姿は、外に出せない

本書は紛争の調停に携わった立場から、揉める案件の構図を示す。多くは発注側が業務の正解までベンダーに決めさせている。

• 任せきる … ベンダーが業務も決める。揉めるのは納品後
• 範囲を持つ … 何を優先するか、誰が決めるかは発注側

営業の立場では、ここを顧客に持たせられるかが効く。全部こちらで決めますと引き受けた案件は、あとで必ず戻ってくる。

いちこ

「お任せします」と言われたら、嬉しく感じていました。

シュン

嬉しいけど危ないんだ。決める人がいない状態を預かったことになるからね。

論点2 断るのではなく、交換条件にする

追加要望をその場で飲むと、期日も金額も変わらないままどこかが削られる。本書が勧めるのは影響を示して相手の判断に戻すことだ。

• その場で飲む … 品質かスコープが静かに落ちる
• 影響を示す … 期日+2週か、別の機能を後倒しか。顧客が選ぶ

論点3 記録は、決まっていないことを可視化する道具

口頭の合意は「そうは聞いていない」で崩れ、立場の強い側の記憶が通る。だが本書の記録の使い方は守りではない。

• 決めたこと / 決めていないこと
• 次に誰が何をするか … 送って返信がない論点が、次に揉める場所

未決事項を一覧で扱う手順は プロジェクトマネジメントの基本が全部わかる本 のほうが詳しい。

いちこ

議事録は、書いて送って終わりにしていました。

シュン

返信が来ない項目を見るのが本番だよ。そこが合意できていない場所なんだ。

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

発注者向けに書かれているため、受注側の読者は立場を置き換えて読む必要がある。それが逆に、顧客が何を気にしているかの地図として使える。開発側の論理なら エンジニアリング組織論への招待 が補いになる。