１．「成功」の連続なんてあり得ない
よくマネージメントの失敗談とそれをベースにした、改善策が語られます。その事自体は何も問題ないと思います。そうして問題を修正していくのが通常だと思います。
たとえば、ウォーターフォールではなく、アジャイルでやろう。また、アジャイルでも、こういうケースはだめだから、こうしたほうが良いと。
では、そこで得られた「うまくいく方法」をしたら、すぐに成功の連続が起こるでしょうか？
実際、そんなにきれいに物事が運びますか？
２．「失敗しないアジャイル」という"表現"はおかしい
日本人に多いのかもしれないですが、「完璧」でないと物事を進められないというのは、仕事ではあんまりよいことではないと思います。
実際、物事は思い通りにならないし、途中で調整もします。
アジャイルとは失敗しそうな状況を調整するための「掛け声、視点」の集大成だと思います。
思い通り、計画通りになんてなかなかいかない。だからこそ、「Agile（機敏・臨機応変）」に対応する。
でも、アジャイルを使っていてさえ、失敗が起きると、「アジャイルではないから、失敗が起きている」と言われることもあります。
そもそも、アジャイルとは失敗しないことではなく、失敗があっても調整することな気がします。
「失敗するアジャイル」という考え方が自体が間違っている気もします。失敗してるから、調整することこそ、「アジャイル」だと思います。
３．「ゴールとしての成功」に行き着くまでに「失敗」はいろいろある
いろいろなプロジェクトに参加していると、「私はプロジェクトを成功に導くことができる」という人がいます。そういう人もいるでしょう。
でも、だからといって、その過程すべてが成功の連続ではない気がします。
私も失敗も成功もしたことはあります。特に、成功したプロジェクトですら、失敗がなかったかといえば、そんなことはありません。
ゴールに行くまでにいくらでも失敗しました。その都度、早めに失敗に気付き対策を立てました。
そして、結果的に成功を手にしたように思います。
「成功」とは、成功の連続ではないと思います。そして、それを調整する指標、掛け声が「アジャイル」というものではないでしょうか。
４．完璧主義者こそ失敗を招きかねない
完璧主義者は、プロジェクトの最初から、失敗がみえると喚き散らします。もちろん、それは調整できるものであれば、調整すべきでしょう。
でも、昨今のソフトウェア業界では、人それぞれプロジェクトそのものに専念できない事情もあります。つまり、いろいろ立場や状況によって、失敗してしまうこともあります。
それをつかまえて、「失敗する！！！」とわめいて、あるべき論をかざしてチームを撹乱しても意味がありません。
人それぞれ、「理想的な状況」ではない人もいます。それすらも受け入れて、調整し、みんなが支えるのが「アジャイル」ではないでしょうか？
完璧主義はいいことだと思いますが、それをどう実現するかが問題だと思います。人それぞれの状況を配慮し、そこに即した対処方法をしていかないと、チームメンバーの生産性が下がるばかりです。コミュニケーションが大切なのに、完璧主義をかざして喚いていると、コミュニケーションが取りにくくなります。
仮にあるプロジェクトがなんとか成功しても、そのチームから離脱する人がでるという、もっと大きな意味での「失敗」を引き起こしかねません。
５．「最終的な成功」のために、過程の失敗は喚くことではない
繰り返しになりますが、結果的な成功に至るまでに、いろいろな失敗はあります。そして、都度調整は必要です。
また、人によっては、理想的な状況になれない人もいます。だからこそ、一見、ムダや失敗と見られるような状況でも、受け入れざるを得ない状況があります。
「完璧主義」を最初からゴールまで貫徹する考えこそ、「アジャイル」に反するものだと私は思います。
そして、過程による失敗はつきものです。それをチーム全体で「機動的」、「早い段階」で修正することこそ、アジャイルな動きだと思います。
６．塗り重ね、支え合い、最終的な成功
過程はいろいろあるのがプロジェクトです。アジャイルは、ウォーターフォールのような「決められたプロセス」を提供するものではありません。個々の状況に応じたものを受けて、早めに調整が利くように促す「掛け声、視点」の集大成だと思っています。
なので、過程で失敗が起きたからと言ってそれは即失敗ではないと思います。失敗だと思えるなら、みんなで意識共有をして、みんなの状況に合わせて修正していくべきな気がします。
そうした、いろいろな対応の「塗り重ね」と「支え合い」の結果がとして、「成功」があるのではないでしょうか？
備考：「手続き主義・教条主義」をアジャイルに持ち込むことは本質からずれている
アジャイルというか、スクラム開発ではある決まったやり方があります。それを実行することで早めに物事を明確に把握していくことができたり、色々とメリットはあります。
ただ、「アジャイル」がそうした「手続きをすること」だと思っている現場があったりします。これは形式だけをみて、その本質をみていない感じがいつもします。その手続ですら状況によってはできないこともあります。そうしたときに、目的が何かを認識したうえで、臨機応変に調整して動くことこそ、アジャイルの本質な気がします。
また逆に、スクラム開発の手法をすればアジャイルであり、物ごとが成功するのかというとそうでもありません。いくらスプリントを細かくわけてタスクを見積もり、こなそうと、コミュニケーションがなかったり、問題に早く気付け無いような状況では結局、無駄なことをスクラム開発の手法で流しているだけということにもなりかねません。
もちろん、こうした失敗に気づいて修正していけばいいと思いますが、本質からずれているマネージメントをしていると、そこに気付きにくいことがあります。そして、短絡的に「アジャイルはだめだ」ということになりかねません。
「アジャイル」で語られるものはやや曖昧な事が多く、なかなか実践するのは難しいようにも見えます。ですが、一つ言えるのは、「決められた手続きをいかなる時も実行すること」でないことは確かです。
失敗はつきもの、臨機応変に動く。コミュニケーションをして、そうした問題に早く気付き、対応をすること。この失敗と変化を積極的に受け入れて、絶えず変化していくことこそ、アジャイルな状態だと個人的には思います。
また、もっといえば、「アジャイル」、「スクラム」、「ウォーターフォール」などどのような手法を採用しようと、プロジェクト遂行をする本質は変わらないと思います。「アジャイル」はすべての手法の根底にあるべき考え方な気もしています。