アジャイルメソッドには大きな成果を生み出すポテンシャルがある。しかしながらその成果は，保証されたものではない – 実際にそのような大きな成果が，アジャイルメソッドを採用し実践したチーム，あるいは組織のごく一部でしか達成されていないことは，その事例証拠からも明らかだ。成功には目に見えない要件がある。そしてそのひとつは，どうやら安全性(Safety)のようなのだ。
最初から話を始めよう。アジャイルメソッドが優れた成果を生み出すのはいつか？ チームが自分たちの知識を深められている時だ。筆者は2007年，共著に次のような内容を書いた。
テストファースト開発や継続的インテグレーションに始まり，イテレーションやレトロスペクティブに至るまで，アジャイルのプラクティスはおよそ，その習得を促進するサイクルで成り立っています。あらゆるプラクティスのサイクルを通じてアジャイルの知識を深めることで，ソフトウェアエンジニアリングのボトルネックに対処するのです。"科学的方法"，"継続的改善"，あるいは "すべてをテストする(test everything)" と言えばいいでしょうか。
このような観点は，その後次第にアジャイルコミュニティ全体へと広まった。そして３年後，ビヘイビア駆動開発(Behavior Driven Development)の中心的提唱者としても有名なDan North氏は，Deliberate Discoveryと題した記事に次のように書いている。
"知識は制約である" Liz Keogh氏は次のような思考実験について，私に話してくれました。あなたのチームが最近完了した重要なプロジェクト，あるいは開発を思い描いてください (数ヶ月間にわたるものが理想的です)。成果が提供できるまで，エンド・ツー・エンドで，どれくらいの期間が必要でしたか？ では次に，そのプロジェクトをもう一度行うことを想像してください。チームは同じ，組織的制約も同じ，すべてが同じです。ただひとつ違うのは，あなたたちのチームがプロジェクトを通じて学んだすべてのことを，もうすでに知っている，という点です。開始から終了まで，２回目はどれくらいの期間が必要でしょう？
ここまでを考えてみます。そうすると，プロジェクトを繰り返せば1/2から1/4になる，という回答が少なくありませんでした。ここから導かれる結論が，"知識は制約である" というものです。
これは2010年のことだ。当時は多くの現場リーダが，プラクティスを越えるものを探し始めていた。人間のダイナミクス，チームや組織の文化といったものが，成功の鍵として注目された頃だ。そして，これらのアイデアの中で定着したと思われるもののひとつが，知識の習得を促進する基本的属性としての安全性であり，安全性それ自体だ。
Scott Belware氏は，2010年のWorkplace Safety for Software Developersというブログ記事に，ソフトウェア開発組織における危険性の悪影響について書いている。
またDaniel Mezick氏は，The Culture Gameという著書で，文化を学ぶ上でも安全性が必要であることを指摘した。InfoQとのインタビューで氏は，次のように述べている。
安全性は社会的学習，あるいは私が部族的学習(Tribal Learning)と呼んでいるものにおける必須条件です。ですから管理者は，この領域にもっと注目しなくてはなりません。もっと慎重な検討が必要なのです。今回の本で私は，安全レベルの低さがなぜ，どのように社会的学習レベルの極端な低さに繋がるのかを説明しています。学習レベルの低さは結果として，変化に直面した場合，その場で適用できる変化の幅を制限することになります。Amy Edmondson博士がハーバード・ビジネススクールで発表した研究によると，心理的安全性と社会学習，関わり合い，生産性のそれぞれのレベルには，すべて相関性があります。このような理由から，人間行動のダイナミクスには細心の注意を払う必要があるのです。
そして今年，Joshua Kerievskyと筆者とは，安全性という観点から見た最新のソフトウェア開発がどのようなものかをブログにして，成功する場合と失敗する場合について改めて考えてみることにした。氏はTech Safetyに次のように書いている。
技術安全性(Tech Safety)は基本的価値として常に存在する，呼吸のようなものです。プロセスやテクニックではありませんし，他の何かによって優先順位が変えられるようなものでもありません。テクノロジの安全性を尊重するということは，プロセスやコードベース，作業場所，人間関係，製品やサービスの安全性を向上させることに他なりません。技術安全性は卓越性への道であって，それ自体が目標ではありません。私たちの関心や仕事，組織の運営に影響を与えるものなのです。
さらに，Is it Safe to Fail?という記事のGuy Nachimson氏は，優れたソフトウェアを生み出す安全性の文化の創造を，Christopher Avery氏の責任プロセスモデル(Responsibility Process Model)や非暴力コミュニケーション(Nonviolent Communication)，Jim McCarthy氏のコアプロトコル(Core Protocols)に結び付けている。
最後にJohn Krewson氏の意見を紹介しよう。技術安全性は崇高な考えではあるが，成功する可能性のない無意味なものだ，というのが氏の考えだ。
概念としては立派で，得るものがあると心から思います。しかしながら，技術的安全性というアイデアの表面下には，ひとつの問題が潜んでいます。それは "リスクホメオスタシス(Risk Homeostasis)" と呼ばれるものです。 Gerald Wilde氏が1994年に提唱した理論であるリスクホメオスタシスは，私たちはリスクを抑制するのではなく消費するのだ，という考え方です。言葉を換えるならば，私たちが生活をより安全にするために何かを実行するとき，私たちはそれを，生活の他の領域におけるリスクのより高い振る舞いの正当化に利用します。つまり全体として見れば，以前に比べて安全になってはいないのです。
安全性のカルチャと環境を理解して作り上げているかどうかは，より効果的なソフトウェア開発チームを作り上げて，これまでにない優れたソフトウェアを開発する方法として，間違いなく認められることになるだろう。しかしそれには調査と実験が必要だ。読者であるあなたは，どのような経験を持っているだろう？