全部入りで見積もると高い・遅い・事故る。機能を絞って受注した話
打ち合わせの席で、相手が「あれもできたら」「これも欲しい」と要望を挙げていく。
自分はそれをメモに書き取りながら、頭の片隅で、見積もりの数字がじわじわ膨らんでいくのを感じていました。
機能がひとつ増えるたびに、作る量が増えて、期間が延びて、金額が上がる。
以前の自分なら、その要望を全部そのまま積んだ見積もりを出していました。
挙がったものに全部応えるのが誠実だと思っていたし、たくさん作れるほうが価値がある、と思い込んでいたからです。
でも、あるときから逆のことをするようになりました。
要望を一度ぜんぶ受け取ったうえで、そこから削る。
今日はその話をします。
何を作って、何を作らないかを、自分がどう決めているか、という考え方だけです。
「あれもこれも」で、見積もりは膨らむ
要望を全部積むと、見積もりは一気に膨らみます。
機能がひとつ増えるだけなら大したことなく見えても、それが十、二十と重なると、作る量も、動作を確かめる量も、後で直す量も、まとめて増えていく。
AIでコーディングするから工数もあまり変わらないのでつい足してしまう。
足し算のつもりが、実際は掛け算で効いてきます。
前に受けた相談でも、最初に出ていた見積もりは数百万円規模でした。
あれもこれもと機能を盛った結果、そういう数字になっていた。
でも、挙がった要望を一つずつ見ていくと、毎日使うのはそのうちのごく一部で、残りの多くは「あったら便利かもしれない」くらいのものでした。
そこで、本当に毎日効く部分だけに機能を絞って、削った見積もりを出し直したら、数十万円で受けることになりました。
金額はぐっと下がったのに、相手はむしろ乗り気でした。
安くなったからというより、「これなら決められる」と思えたからだと思います。
このとき自分は、価値の出しどころを勘違いしていたことに気づきました。
全部作れることが価値なんじゃなくて、要望の山から「これだけでいい」を選び出せることのほうが、よっぽど相手の役に立っていた。
全部作ると、たいてい事故る
なぜ全部入りを避けるようになったかというと、単に高いからではありません。全部作ろうとすると、たいてい事故るからです。
事故る理由は、だいたい3つあります。
ひとつは、作る量に比例して、リスクも期間も費用も増えること。機能が増えれば、その分だけ壊れる場所が増える。
動作を確かめる箇所も、後で保守する箇所も増える。
ひとつの便利機能の裏で、見えないコストが静かに積み上がっていきます。
もうひとつは、盛った機能の大半が、結局使われないこと。
「あったら便利」で足したものは、たいてい最初の数回で触られなくなる。
作るのには時間もお金もかかったのに、動いていない機能だけが残る。これがいちばんもったいない。
最後は、相手が判断できなくなること。
機能が多い見積もりほど、相手は「本当にこれ全部いるのか」を自分で確かめられない。
金額も大きいから、社内で決裁も通りにくい。
結果、話がずっと止まったままになる。
高くて、遅くて、事故りやすくて、しかも使われない。
全部入りは、良かれと思って盛るほど、この方向に転がっていきます。
逆に、思いきって絞ると、安くて、早くて、効いたかどうかがすぐ分かる形になる。
価値は「何を削れるか」のほうにある
だから自分は、何を削るかを決めることこそ、仕事のいちばん大事な部分だと思うようになりました。
作れる人は、探せばそれなりにいます。
でも、相手の要望を聞いて「これは要らないですね」と削れる人は、意外と少ない。
要望を減らす提案は、一見すると手を抜いているように見えるので、言い出しにくいんです。
でも、そこを引き受けるのが、たぶんいちばん価値のある部分でした。
削るためには、まず要望を分解して、どの機能がどれだけ効くのかを見えるようにする必要があります。
ここは前に、業務をいくつかの工程に割って「本当に効く工程」を見極める、という話を書きました。
要件を削るときも、やっていることは同じです。
ひとかたまりの「やりたいこと」を、小さな機能に割ってからでないと、どれを残すかは決められません。
割ってみると、たいてい気づきます。
相手が本当に困っているのは一点で、それ以外は「ついでに」挙がってきたものだった、と。
その一点さえ動けば、相手の毎日は変わる。
逆に、その一点を外して周りだけ作り込んでも、何も変わりません。
要る／後でいい／要らない、に仕分ける
具体的に、自分がどう削っているか。挙がった要望を、3つの箱に仕分けています。
本当に要る：それが無いと、毎日の困りごとが解決しない機能
後でいい：あると便利だけど、無くても今日は困らない機能
要らない：挙がったけど、実は誰も毎日は使わない機能
仕分けの物差しは、シンプルに3つです。
毎日使うか。
その1つで、目に見える効果が出るか。
無くても困らないか。
この問いに通すと、「あったら便利かも」の多くは、後でいい／要らない、のほうに静かに落ちていきます。
最初に作るのは、本当に要るの箱に残ったものだけ。
「後でいい」は、いったん脇に置く。捨てるわけじゃなくて、順番を後ろにするだけです。
まず一点を動かして、効くのを確かめてから、必要なら足していけばいい。
ここ、ハマりやすいんですけど、相手も自分も、つい「後でいい」を最初の一回に入れたくなります。
同時に頼んだほうが得な気がするから。
でも、最初にあれこれ足すほど、動き出すのは遅くなる。自分の場合は、初回は「本当に要る」だけ、と決めておくくらいでちょうどよかったです。
絞ったほうが、相手も得をする
絞るというと、相手に我慢させているように聞こえるかもしれません。
でも実際は、逆でした。
機能を絞ると、まず安くなる。作る量が減るから、当然です。
次に、早く動き出す。
作るものが少ないほど、完成も早い。そして、確実に効く。
一点に絞っているぶん、そこがちゃんと効いているかを、すぐ確かめられる。
安くて、早くて、効いたかどうかがはっきりする。相手にとって、悪い話はひとつもありません。
使われない機能をいくつも抱えている状態と、毎日回る機能をひとつ持っている状態。
並べてみると、後者のほうが、明らかに役に立っています。
数の多さは、価値とは関係ない。
毎日効いているかどうか、だけです。
そして、一点が効くと分かってからのほうが、次の相談はしやすくなります。
「あれが効いたから、次はこれも」と、相手のほうから出てくる。
最初に全部を約束して重くするより、まず一点効かせて信頼を作ってから足していくほうが、自分の場合は結局うまく進みました。
まず、1つだけ効かせてみる
要望を全部積むと、見積もりは膨らみ、開発は重くなり、しかも大半は使われない。
だから自分は、要望を一度ぜんぶ受け取ったうえで、本当に要る／後でいい／要らないに仕分けて、最初は「本当に要る」だけを作るようにしています。
これは受注の話に聞こえるかもしれませんが、自分用の仕組みを作るときも、まったく同じです。
あれもこれも自動化したくなったら、いったん全部書き出して、そのうち毎日効く一点だけを最初に作る。
残りは、それが効いてから考えれば間に合います。
価値は、全部作れることじゃなくて、何を削るかを決められること。
少なくとも自分の場合は、そう考えるようになってから、仕事がずいぶん軽くなりました。
最後まで読んでくれて、ありがとうございます。
実際に作った仕組みの実装メモと、つまずきの記録を書いています。
今後の投稿が気になる人はフォローしておいてください。
