エンジニアリング組織論への招待

目的

顧客に期日を約束した。開発に伝えたら「できません」と返ってきた。押し問答の末に無理を通したが、結局間に合わなかった。

この構図は、どちらかが悪いわけではない。見えているものが違うだけだ。本書を読む目的は、開発側の論理を理解して、交渉の前提を揃えることにある。

論点1 開発とは、分からないことを減らす作業

本書はエンジニアリングを「不確実性を削減する活動」と定義する。この一文で、見積もりの見え方が変わる。

着手前の見積もりは、正確な予言ではなく、その時点での幅の表明になる。「3か月」という答えは本来「2〜5か月」であり、進むにつれて幅が縮んでいく。

• 幅が広い段階で確定を迫る → 大きめの数字か、守れない約束が返ってくる
• 幅が縮むのを待って確定する → 精度は上がるが、商談は待ってくれない

見積もりを点ではなく幅で扱う考え方は、営業の目標設定とも共通している(来季の目標をどう置くか)。

いちこ

「結局いつですか」と聞いていました…。

シュン

気持ちは分かるよ。ただ幅で答えてもらったほうが、実は商談で使える情報が多いんだ。

論点2 「話が通じない」の正体は、情報の非対称性

営業は顧客の期限と失注リスクを見ている。開発は既存の作りの制約と手戻りの可能性を見ている。どちらも事実だが、相手には見えていない。

ここで起きるのが、相手が事情を分かってくれないという感覚だ。実際には分かっていないのではなく、情報が渡っていない。

論点3 急がせた結果は、あとから速度として返ってくる

技術的負債という言葉を、本書は比喩でなく負債として扱う。急いで作った部分は、後の開発を少しずつ遅くする形で返済を求めてくる。

営業が意識しておきたいのは、いま押し込んだ分が、半年後の自分の案件を遅くするという点だ。毎回の交渉は目の前の1案件の話に見えるが、積み上がると開発速度そのものが落ちる。

• 短期 … 押し込んだほうが速い。だから押し込みたくなる
• 長期 … 押し込み続けた組織のほうが遅くなる

いちこ

目の前の案件だけ見ていると分からないですね。

シュン

そう。だから「今回は急ぐ、代わりにこの部分は後で直す」と合意しておくといい。借りたと分かっていれば返せるからね。

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

技術書ではなく、不確実性をどう扱うかという思考の本なので、コードが読めなくても通読できる。発注者としての立ち回りを具体的に知りたいなら、細川義洋『システムを「外注」するときに読む本』のほうが実務寄りだ。