アジャイルサムライ

目的

顧客に「いつ使えるようになりますか」と聞かれる。開発に確認すると「やってみないと分からない」と返る。板挟みのまま、適当な日付を答えてしまう。

本書を読む目的は、開発がなぜそう答えるのかを理解して、顧客との約束の仕方を変えることにある。

論点1 全部決めてから作ると、間違いに気づくのが遅れる

本書が前提にするのは、要件は最初には分からないという立場だ。だから小さく作って見せ、違っていれば直す、という進め方をとる。

• 最初に全部決める … 完成してから「思っていたのと違う」が判明する
• 小さく作って見せる … 早く間違えて、早く直せる

速いというのは作業が速いことではなく、間違いに気づくのが早いという意味になる。

いちこ

仕様が固まらないまま始めて大丈夫なんですか?

シュン

固めたつもりでも、動くものを見ると必ず変わるんだ。それなら早く見せたほうが早いよね。

論点2 期日・予算・範囲は、同時に固定できない

営業にとって最も使えるのがこの考え方になる。期日、予算と人数、機能の範囲。この3つを同時に約束することはできない。

期日も予算も動かせないなら、調整できるのは範囲だけになる。「全部を期日どおりに」と約束した時点で、どこかが必ず破綻する。

論点3 始める前に、関係者で答えを揃える

本書が勧めるのは、着手前に関係者を集めて同じ問いに答えておくことだ。あとで揉める論点は、たいていここが揃っていない。

• なぜやるのか / やらないことは何か
• うまくいった状態とは / 最大の不安は何か

営業の立場では、この場に顧客側の期待を持ち込む役が回ってくる。商談で聞いた「本当は何を解決したいのか」を、ここで開発に渡すことになる。

見積もりを幅で扱う考え方は エンジニアリング組織論への招待 に。

いちこ

開発の人と話す前に、聞いておくことがありますね。

シュン

そう。「なぜ今なのか」を持っていけると、開発側も優先順位を決めやすいんだ。

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

2011年の本で、扱う技術の記述は古い。ただ期日と範囲の考え方は今も変わらない。開発組織そのものの論理を知りたいなら、広木大地『エンジニアリング組織論への招待』のほうが射程が広い。