はじめまして、はだ＠日本ユニシスです。
上手さんのコメントに、コメントしようとしましたが、断念し、
元のメールにそって、意見を書きます。
ここでの、オプションは、明らかに金融派生商品である、オプションにかけています
から、
オプションと訳すのが、いいと思います。
＃ オプションが何ものかは、Fowler の Analysis Pattern も参照してください。
オプションは、「金融商品の売買権利」を売買する、取り引きです。
金融派生商品は、皆、リスクを回避する（他人にまわす？）のが目的です。
リスクは、ボラティリティに依存します、これが”不確実性”に相当するでしょう。
＃
ボラティリティは、収益率の標準偏差の関数です。つまり、儲けが大きくなる、小さ
くなる
＃ その不確実性の幅です。
オプションには、オプションスタイルと言うのがあって、普通は、call(買う)/put
（売る）ですが、
ここでは、abandon,switch,defer,grow
をする、しないを、オプションスタイルとして、設定している
のでしょう。
＃ kinds of options が、オプションスタイルに相当するのでしょう。
five factor は、通常の金融オプションでの計算モデルのファクターです。
実は、オプションには、アメリカン・スタイルと、ヨーロピアン・タイプがあり、ア
メリカン・タイプの
計算公式は、決まっていないようです。
＃
ヨーロピアン・タイプのプレミアム計算公式の代表が、今話題のブラック・ショール
ズ・モデルです。
＃ 権利行使日が、満期日のみが、ヨーロピアン・タイプです。
ちなみに、"exercise" は、"行使する"、がその分野での訳として定着しています。
この辺については、（手前?味噌ですが）例えば、
< http://www.unisys.co.jp/tec_info/tr61/61abs.htm#6104 >
をご覧ください。
で、five factor 以降の展開ですが、
five factors のうち、不確実性が、オプションの価格を決めます。
＃ そうでなければ、無リスク利子である、普通の貯金をすればいいわけです。
リスクがあるから儲かる、というのが、オプションで儲ける方法です。
ソフトウェアにおける、リスク＝不確実性を列挙しているのが、その下の4点です。
結局、不確実性が高まると、危なくなる、従来の手法にくらべ、
xp は、不確実性が高まると、より力を発揮する、と言っている、と思います。
＃ ちょうど、オプション取引のように。
さて、計算方法ですが、変動する確率を積み重ねるため、先ほどの five factors
を含む、
偏微分方程式を、解かなければなりません。
解き方を知るには、本屋に積まれている、金融工学本のいずれかを読むことになりま
す。:-)
ボラティリティが無いときは、上手さんがおっしゃるように、いわゆる現在価値への
割り戻し、でいいでしょう。
で、Kent Beck 氏も、おそらく自分で計算したのではないのでは？と思えるのが、
p.11 の注： Thanks to John Favaro for the analysis of XP with options
pricing です。
それでは。
---
Akihiro Hada
Akihiro.Hada@....jp
---
At 午後 03:09 00/03/25 +0900, Kaoru Hosokawa wrote:
>Chapter 3 Economics of Software Development
>===========================================
>
>次の要因を考慮してソフトウェア開発プロジェクトの経済価値を最大にする戦略を立
>てることができます。
>
>・現金資金の流出入
>・金利
>・プロジェクトの失敗率
>
>この戦略とは、
>
>・「支出を抑えること」ですが、だれもみなほとんど同じツールとスキルで始めるの
>で難しいです。
>・「収入を増やすこと」ですが、すぐれたマーケティングとセールスの組織によって
>可能になります。
>・「支出を遅らせ、収入を早めること」です。支出に伴う金利を抑えて収入による金
>利を増やします。
>・「プロジェクトが生き残る確率を高めること」です。後で大きな支払いをもらう可
>能性を高めます。
>
>[「しかし、これらの戦略はなかな達成できない。」と言いたいのでしょう。]
>
>Options
>-------
>
>ソフトウェア開発の経済状態を違った方法で見る事ができます。それは、一連の選択
>として見る事です。ソフトウエアプロジェクト管理には次の４つの選択枠があると考
>える事ができます。
>
>・断念すること−プロジェクトをキャンセルしてもなにか得るものがあります。得る
>ものが大きければ大きい程いいです。
>
>・変更すること−プロジェクトの方向性を変えることができます。頻繁にそしてより
>激しく要求を変えることができるほどいいです。
>
>・延期すること−問題が自然に解決することを待つことができます。待つ期間が長け
>れば長いほど無駄遣いをしないのでいいです。
>
>・成長すること−マーケットが伸びそうであれば、すぐに成長して、それを利用して
>いくことができます。プロジェクトがより速くより長い期間成長できるほどいいです。
>
>これらの選択枠の価値を計算する時に考慮する要因は次のとおりです。
>
>・選択を得るために必要な投資
>・選択を実行することによって得られる報酬（prize）の価値
>・報酬の現在価値
>・選択の実行にかかる時間
>・報酬の最終価値の不確実性
>
>これらの要因のうち、選択の価値は最後の要因「不確実性」にもっとも左右
>（dominate）されます。この不確実性から具体的な予測をすることができます。[
>「From this we can make a concrete prediction.」を訳したのですが、「this」は、
>「不確実性」のことですよね？]仮に選択枠の分析を行って、プロジェクトの価値を
>最大にするプロジェクト管理の戦略は、以下を提供します。
>
>・正確かつ頻繁な進捗状況のフィードバック
>・劇的に要求の変更が行える多数の機会
>・[以前に比べて]小さい初期投資
>・より速く進むする機会
>
>不確実性が高ければ高いほどこの戦略の価値は増します。（これは、「いつXPを使う
>べきか？」という質問の理論的な答えを提供しています。要求が曖昧または変化して
>いる時、XPを使いましょう。）
>
>Example
>-------
>
>あなたは楽しくプログラムを書いているとしましょう。あなたはある機能を$10で加
>えることができることに気付きます。あなたはこの機能に対する収益は約$15と考え
>ました。ですから、この機能追加の現在価値は$5です。
>
>この新機能が本当に$15の価値があるかどうか、わからないと仮定しましょう。実は、
>この価値は100%変動してもおかしくないと思っています。さらにこの機能を一年後に
>追加しても$10かかると仮定しましょう。金利が5%として計算すると$7.87になります。
>
>[
>「7.87」という値はどのように計算したのでしょうか？
>
> 現在価値=支払い時における価値/POWER(1+金利,年数)
>
>を使ってみましたが、
>
> 15/POWER(1+0.05, 1)=14.29
>
>となってしまいます。:-(
>]
>
>待つ選択（$7.87）が現在機能を追加する（$5）より価値があることになります。不
>確実性の作用によって、ユーザーにとってもっと価値がある場合は、待っていても
>今実装することとひけめはない。また、価値がまったくない場合は、実装していない
>ので手間が省けました。
>
>[コメント：
>この章は、大変でした。「option」は、ストックオプションに引っ掛けているのでしょ
>うか？「There are five factors ...」の要因とその後の戦略との関係がよく理解で
>きませんでした。まあ、言いたかったことは、「曖昧でいつも変わる要求に対応する
>にはいつでも状況／環境とともに変化できるようなプロジェクトにしましょう。」で
>しょうか？
>
>「7.87」の出し方教えて下さい！
>]
>
>--
>Kaoru Hosokawa
>khosokawa@....com