資産価値の不確実性とそれがもたらすリスクを管理する金融的な概念が，活用の道を再びソフトウェア開発に見出そうとしている。金融の世界では従来から，資産価値の変動に対して一定レベルの保障を提供する手段として，さまざまな種類のデリバティブが用いられてきた。
Alistair Cockburn 氏は先日，アジャイルで言われる "Last Responsible Moment (可能な限り決定を遅らせること)" の根拠について 疑問を呈した。それによって氏は，ソフトウェア開発がリスクと不確実性に対処する最善の方法についての議論の口火を切ったのだ。
その後のフォローアップでは Chris Matts, Olav Maassen, Kerl Scotland の３氏が，アジャイルとリーンコミュニティ間の論争に対して第４の 現実的選択肢 を提示する，という貢献を行っている。この話題は，ソフトウェア開発では必ずしも新しいものではない。それは Amazon や Google を少し検索すれば分かることだ。しかしながら，アジャイルのスケール性を向上する潜在的方法として，新たな注目を集める可能性もある。Chris Matts, Olav Massen 両氏は 2007年に，これに関する記事を InfoQ に残している。
アジャイルおよびリーンコミュニティの現実的選択肢として再燃した関心に対して我々は，ソフトウェア開発のリスク管理技術のさらなる進化を期待すべきだろうか？ 前例はそう示しているようにも思える。この ブログ記事 が示唆しているように，アジャイル手法はそもそもアプリケーション開発における主要分野のひとつである要件定義において，そのリスクに対処するための対応策であり，必然的な結果であったのだ。
要件リスクは，ソフトウェアおよびアプリケーション開発における一貫したテーマである。かく言う筆者も，収集技術の改善による要件リスク軽減の価値について，これまで いくつか記事 を書いている
しかしながら，これらすべての中心には根本的な仮定がある。それはつまり，ソフトウェア開発はより予測可能で無駄のないものにすることができる，というものだ。本当だろうか？
リーン方法論者たちはそう信じている。Jack Milunsky 氏は 2009 年に，リーン生産方式でいう「７つの無駄」に寄せたソフトウェア開発の７つの無駄 (7 Software Development Wastes) に関して，ブログ記事をいくつか書いている。ソフトウェア開発のばらつきの多くを引き起こしているものがここにある，というのが氏の見解だ。
- 部分的に完了している作業
- 過剰な機能
- 再学習
- 引継ぎ
- タスクの切替え
- 遅延
- バグ
しかしソフトウェア開発には，クラフトあるいは創造的活動という側面もある。この面を重視する人たちはしばしば，製造業との比較を行うリーン派に反対の立場を取る。Gary Police 氏は，ソフトウェアのアートとクラフトマンシップ についての記事を書いている。氏の見解では – 偉大な仕事 (ソフトウェアであれ何であれ) とは経験と失敗，さらには最善を尽くすという意欲と情熱が生み出すものである。この考え方によれば，無駄とは創造性であり，ひいてはソフトウェア開発の本質的部分である，ということになる。
あなたの考えはどうだろう？ ソフトウェア開発にさらなる予測可能性を実現することは可能だろうか，それとも，それはソフトウェア開発の価値である創造性を破壊する行為なのだろうか？