お客さん側の問題

8時半まで仕事して、それから飲みに行ってきた。皆さん、当たり前のように9時10時まで残業しているそうで。なんだかなー。

発注側にも問題がある

今日の現場をみていて思ったのは、開発を発注する側の体質。お客さんのせいにするのは申し訳ないけど、もうちょっと戦略的に発注するべきじゃないかな。問題点は以下のとおり。

• やたらと値切る
• 細かい
• 散々粘って発注しない
• 朝令暮改

「やたらと値切る」ってのは、とにかく「高い〜　安くしろ〜　高い〜　安くしろ〜」と文句をいうお客さん。費用対効果の観点がばっさりと欠如している。そのシステムでいくら儲けるのかを考えていない。同様に、いくらまで損したら中止するかという撤退戦略もない。[*1] 「○○億円投資して、N年かけてα%で回収する。損失が××万円になったら撤退する。」という基本戦略があれば、無理して値切る必要はないんだよ。そこを無理して値切るから、開発する側は開発資源配分とかで無理を強いられて、結果として納期が延びたり品質が落ちたりするわけ。これがお客さん側にベンダ不信感を生む原因の一つだろう。

「細かい」ってのは上記「やたらと値切る」の親戚。「この機能はいくらなの？」「これはいくらなの？」と細かく聞いてくる。もちろん、この段階では綿密な見積りは無理だから、答える方は概算にならざるを得ないのだけど、「機能Aと機能Bが同じ値段なんて変じゃないの？」みたいに異様に細かいツッコミをいれてくるから、答える側も「精査します」と応じるしかない。結果、この見積りにかかるコストが最終費用に上乗せされる。→「高い〜　安くしろ〜」に

「散々粘って発注しない」ってのは、発注期限ぎりぎりまで（あるいは過ぎても）「ど〜しようかな〜」と迷うお客。建前論では正式発注をもらうまで人員配置をやってはいけないことになっている。でもこのご時世、そんな建前を真面目に実行したら、人手不足になるのは確実だから、実際は見切りで人員を配置せざるをえない。で、ドタキャンくらったら、何か適当な勘定項目を立てて損失を計上する羽目になる。そして、その損失は次回プロジェクトで上乗せ請求せざるをえない。→「高い〜　安くしろ〜」に

「朝令暮改」は発注後に言うことをころころ変えてくること。もはやAgileでも無理でしょ、というくらい変えてくる。そして、真面目な開発現場ほど、真剣に対応しちゃうけど、当然原価はかかる。その原価はなんらかの形で上乗せ請求せざるを得ない。→「高い〜　安くしろ〜」に

これは開発側のいうことを丸飲みしろ、といってるのではないよ。開発側が言ってくる数字を妥当かどうかと見極める「目」と「戦略」を持っておけ、ということ。

どうでも良いこと　寿司屋に例える

自分の実家は寿司屋だったんだけど、カウンターに座って食べるお客さんにも通じるものがある。いちいち「あれいくら？　これいくら？」と聞くのは損する典型。お好みで上限金額を指定するのが一番お得。作る側からすると、「この大トロを余らせて原価1000円損するくらいなら、500円で売っておこう」みたいな細工ができるのがお好み。そこをいちいち価格聞いてくるお客さんには、堂々と「大トロ2000円です」と言えちゃう。それで注文受けたらラッキー。だめでも、そのあたりの仕掛けを理解しているお得意さんに売れば損はしない。

もちろん、お得意さんと店との間には信頼関係が築かれている必要がある。お好み注文でぼったくりをするようなことをすれば、そのお客さんは二度とこないであろう。お好みで食べたお客さんも、その内容は価格に見合ったものかどうかを見極める目が必要。

システム開発も似たようなものがあるのかも。

新人時代の話。入社先の偉い人の訓話で印象に残っているのは「システム開発は料亭」説。当時は「このおっさん、何いってるんだろう」とびっくりしたけど、そこそこ経験を積んだ今は理解できるようになった。

*1:撤退条件のない戦略は戦略とは呼べない、が正しい表現かも