> これに関しては、「相手（顧客）のビジネス」ではなく、「自分の
> ビジネス」として考えると、極端に言ってしまえば『「開発期間が
> 半年ぐらいで、あるものを作ってくれという(曖昧な)要望だけでは、
> コミット(契約)できない』ということですよね？(まあ、この話は
> 妄想というか「理想論」とさせていただきたいので、実際問題こう
> いう状況になったときに、この言い分が許されるかどうかは別と
> して、、、。)
>
> でまあ、たとえば顧客の所へ出向いて、「これだけじゃあよくわから
> ないので、もうちょっと細かくお話をお伺いさせてください。。。」と
> いって、もうちょっと詳細をつめてから、「あ、これは半年でいけそう
> ですから、この内容で開発を行いましょう」とか、「このままでは、
> 絶対半年で開発は無理ですが、ここらあたりの機能を削ってしまえば、
> なんとか半年でいけるとおもいます。この内容で開発させていただいて
> よろしいでしょうか」などと、具体的な「機能」を決めてしまって、
> 作業量を見積もってから『コミット(契約)』する、ってことですよね。
>
> ちょっと視点を変えて「期間」を重要視してコミットすると、こんな
> 感じになるのではないでしょうか？
>
> ) どーせ仕様なんてころころ変わるんだから提示された期間にお互い
> ) 合意した機能を開発することにはコミットしましょう。そのかわり、
> ) 前倒しで開発できたら前倒しした期間分の報奨金をください。
> ) あなたがたの案件ははやければはやいほど価値を増すんですよね。
> ) もちろん、開発が遅延すればその遅れた期間分の罰金をこちらが
> ) 払います。ええ、私の胃なり内臓を売ったりしてでも必ず払います。
それは、計画開始時点では必要な機能やそれを実装する工数が実
用的な精度で予測できない、あるいはプロジェクトの性格として
予測すべきではない場合ですから、多段階に分けて、1段階目の成
果を見て2段階目以降の仕様や期間を決めましょう、ということに
なるのではないでしょうか。
> いいほうにはずれたら、お金ください。悪いほうにはずれたら、お代は
> チャラでいいです、みたいな。これもひとつの「ビジネス戦略」だと考えて
> います。まさに「ビジネス価値」に対価を要求する、ってことになるかと。
>
> # で、もらったお金は開発者に全部還元、と。こりゃーやる気でますよ。
> # もう開発者が体壊すぐらいに。←それじゃあもともこもないけど(^^;。
顧客が評価するのは製品全体の完成時期ですが、個々の開発者が
期待するのは自分の担当した部分の作業期間に対するものだと思
うので、そのギャップを避けてうまく還元できればよいのですけ
れど…
もとの話題に少しふれれば、
結局のところ「ソフトウェアの価値」が何を表し何を評価する数
値かの定義が人それぞれなので不毛な議論になるのではないかと
思います。顧客にとっての価値であったり、企業にとっての価値
であったり、開発者個人にとっての価値であったりと。
他の事柄と合わせなければ売り上げ単体では何の評価にも使えな
いのですが、それを思い思いの事柄を無意識に補って論じるので
かみ合わないのではないかと思います。
--
Michitaro Horiuchi / Access Co.,Ltd.
horiuchi@....jp / horiuti@....jp