ちょっと前に読んだ本ですが、とても興味深い内容でした。
私は、もう１０年程片田舎でWeb周りの技術者をやっておりますが、ぶっちゃけ、一番うまくいかないのが、納品。。それも「要求定義」です。
システム開発とかの基本的な流れは以下のようなものだと思います。
- 依頼を受ける
- 話を聞きながら要求定義をまとめる
- それをもとに見積もりを出す
- OKなら進める。
- 要求定義を満たすものをつくって納品
理論上は、これでうまくいくはずなのですが、大体がうまくいきません。
なぜなら、我々地方のWeb屋のお客様は大体がITの素人さんです。すると、「Webを作って商売に活かしたいけど、実際に何をすればいいのかわからない」という方がほとんどなんです。
だから、いくら最初によく話し合って要求定義をまとめて、設計書を煮詰めても、大体出来上がってから、思っていたのと違った。ということで、修正になったりします。
当然、立場として受注した方が弱いので泣き寝入りで修正するか、強気に追加料金を要求してもめるか？ということになります。
昔は私も、自分の要求定義のまとめ方が悪いのだろう。とか、質の悪いお客さんにあたってしまったのだろう。。と思っていたのですが、最近になって、これはやり方そのものを根本的に変える必要があるのでは・・・と思うようになりました。
この本にあるやり方は、私の理解が不足していることもあるとおもいましたが、このように感じ取りました。
- お客様と「何をやりたいか？」の目標を共有
- その目標について、毎月で予算をきめてもらう。
- 技術者は、その予算内で出来ることを提案＆実施
- すぐに、それを実施して、一緒に結果を見る、よければ「予算内」で、もっと進める。悪ければ違う方法を提案＆実施する。
これは、とても危ない方法のようにも思うかもしれません。
ものを売ってお金をもらう。というのではなく、お客様と担当者の「信頼」のみに頼るやり方です。
でも、思い起こすと、自分が実際に今までお客様と良い関係を築けたときって、これに近い事ができているんですよね。
お客さんが自分を信頼してくれて、お金の範囲内で自由にやってくれ。と言われ、こちらは、細かなことでいちいち許可や見積もり承認を求めずに、成果だけを共有して、好き勝手やらせてもらう。
人種にもよるとおもいますが、この関係が築けたら、燃えるエンジニアって結構いるんじゃないかと思うんです。
今までは、こういう関係って、フリーランスと事業主の個人対個人での信頼の上にしか成り立たないと思っていたのですが、この本では、これを企業対企業として成り立たせるための、やり方やヒントが書かれています。
そういう意味で、とても興味深く、今後の自分の方向性に大きなヒントをくれた本だと思っています。