Pascal Van Cauwenberghe氏によれば、プロジェクトも製品開発も困難な意思決定の連続だ。そして、リアルオプションは正しい決定を正しいときにすることを支援してくれる、という。Agile Tour Brusselsカンファレンスで、Pascal氏はリアルオプションを使った意思決定のついて自身の経験を発表した。
InfoQは以前、Chris Matts氏とOlav Maassen氏によるリアルオプションについての記事を公開し、リアルオプションの原則を説明している。
リアルオプションは文脈にそった、最適な意思決定ができるようにします。これは難しいように思えますが、どのように意思決定をするかということに対する考え方のひとつです。
リアルオプションは積極的なリスクマネジメント戦略です。定期的に選択肢のポートフィリオを監視して、壊れかけていないか確認する必要があります。加えて、情報を積極的に摂取する必要のある方法でもあります。また、何もしないことも選択肢のひとつだということを忘れてはなりません。何もしないことも積極的な意思決定のひとつなのです。リアルオプションはぐずぐずするための言い訳ではありません。
Pascal氏のプレゼンはアジャイルコーチングツールで確認できる。
Pascal氏がまず紹介したのは、ビデオゲームのウェブサイトの再設計のプロジェクトだ。このプロジェクトでは、ルックアンドフィールについて多くの意思決定がなされた。これらの決定はプロジェクトが進むにつれ、変更され、新しい決定によってさらに多くの再設計が必要になった。しかし、プロジェクトには納期があり、1日でも遅れれば、セールスに深刻な影響を与えてしまう。素早く頻繁に決断しすぎてしまい、納期に間に合わない可能性が大きくなるようなやり直しが増えてしまっていた。何かを変えなければならなかった。
チームは選択肢のコスト、金銭的な価値、有効期間を記述することで再設計のための選択肢を精査した。そして、いつ決定をしなければならないかも確認した。マネージャは今日決断したがったが、選択肢を吟味したところ、納期を守ったまま、決断をもっと送らせることができることがわかった。品質に応じて再設計したインターフェースを組み込んでも組み込まなくても、決定を送らせることができるという点で関係者は合意した。意思決定を送らせることで開発に費やせる時間が増え、ルックアンドフィールを変えるような意思決定で混乱がおきることがなくなった。また、開発チームは開発サイクル時間を短縮する方法を見つけ、意思決定するまでの時間が増えた。リアルオプションはチームが意思決定を送らせ、開発に使える時間を増やすことを支援したのだ。
二つ目の事例は銀行のプロジェクト。新しいネットバンキングサービスのプロジェクトだ。バックエンドの開発プロジェクトはプラットフォームについて設計上の選択をする必要があった。検討した結果、"セットベースデザイン"を採用し、プラットフォームAとプラットフォームBの両方を開発し始めた。プロジェクトが進んである時点でプラットフォームAを採用することになった。しかし、プラットフォームAを作っていた企業がプラットフォームBを作っていた企業に買収されて、プラットフォームAは開発が中止になってしまった。したがって、プラットフォームBへ意向をしなければならなくなった。プラットフォームBが必要になったということはプラットフォームAに対する投資はもう無関係だということだ。プラットフォームAにいくら投資したかは関係ない。プラットフォームAはもはや可能な選択肢ではないからだ。
また、ヨーロッパ法が変更される前までに納品しなければならなかったシステムの事例も紹介された。ベンダに1000ユーロを投じて、現行のシステムを新しいシステムと互換性のあるようにできるかどうかを調べてもらうという選択肢もあったが、そうはしなかった。しかし、新しいシステムの納品が数ヶ月遅れてしまい、毎月10.000-100.000ユーロの損失を出してしまった。既存のシステムの顧客に案内ができなかったからだ。ここから彼らは、選択肢の価値をしっかりと吟味すれば、大きな出費を回避できることを学んだ。
Pascal氏のプレゼンはcommitment – a novel about managing project risksという本に書かれているリアルオプションの使い方に基づいている。