著述家でコンサルタントでもある Gerald M. Weinberg 氏は，コンピューティングビジネスに半世紀以上も積極的に関わり続けている人物だ。業界でもっとも影響力の大きな 書籍 の著者として有名であり，尊敬を集めている。
氏は先日，自身のブログ "Secrets of Consulting (コンサルティングの秘密)" に，過去に対する認識のなさを指摘する記事を書き，ソフトウェア開発手法の革新と進歩を巡るハイプ曲線 (hype cycle) が，開発組織や実践者たちが何も学ぶことのないままにどれほど繰り返されているか，ということを説いている。
自身の著書 "Rethinking System Analysis and Design (邦題：システムづくりの人間学)" を電子書籍形式に変換するあたって，氏は "Beyond Structured Programming (構造化プログラミングを超えて)" という名の章 (20年前に書かれたもの) を改訂することにした。そのとき，"structured programming (構造化プログラミング)" を単に "agile (アジャイル)" に置き換えれば，章の内容と意図をそのまま今日の "アジャイルプログラミング革命" に当てはめることができる，と気が付いたのだ。
それによれば，
このエッセイは１世代前 (今回は２世代前) に書かれたものですが，アジャイルプログラミング "革命” がもはや (ほとんどのプログラマにとって) 一時的な熱病と化した今では，その内容の大部分がそのまま当てはまるのです – 次に新たな流行が来ても，その次も，さらにその次でも同じでしょう。今後もずっと当てはまるのなら，もはや新たな章を書く必要はない，と思っているくらいです。なぜって？ 情報処理業界は退屈しないために，10年ごとに新たな流行を必要としているようだからです。これを読んだ時点でコンピュータ出版界を席巻している流行が何であれ，単にこの教訓を当てはめればよいのです。
続いて氏は，口先だけの賛意から新たなプラクティスを適用したり，一連のルールに盲目的に追随したり，さらには実効のある変革に必要な鍛錬を避けて，簡単なプラクティスだけを適用しようとする組織の数がどれほど多いか，ということを論じている。
アジャイルの適用状況を詳細に検討した結果を，氏は次のように書いている。
a. 完全にアジャイルを適用したと認められるのは 5% に過ぎない。
b. 20% は，1990 年代の平均的なコードを改善するのに十分なアジャイルプラクティスを実施した，と判断できる。
c. 50% については，いくつかの "アジャイルルール" をフォローはしても理解できていない。小さな成功を獲得するのが精一杯だ。
d. 残る 25% は，過去20年間のどのようなプログラムに関するアイデア(アジャイルに限らず) を取り入れたとしても，何の成果も残すことはできないだろう。
そして次の理由から，アジャイルプラクティスの適用を注意深く，思慮深く行うように推奨する。
アジャイルプログラミングに約束された恩恵の実現に成功した開発組織や人々に共通するのは，ソフトウェアやハードウェアの宣伝文句を鵜呑みにはしない反面，それらにも耳を傾け，問題解決に必要なものを取り出すことができる，という点です。彼らは自分自身で考え，適応可能ならば他人の考えでも取り入れます。彼らの大部分は，アジャイルプログラミング以前すでに問題解決の最大の成功者でした。今回はアジャイルによって，さらなる成功を手にするのです。
氏はこの章を，熟慮した行動を求めることで結んでいる。
私たちのビジネスには数こそ少ないが，あるとすれば簡単な解決策が存在しています。問題解決の成功は，最新の "魔法" を必要以上に信頼はしないが，そこにあるアイデアを自分自身で試す意志を持つ者に与えられます。仮にそのアイデアが，PR的な戯言のオンパレードの様相であったとしても，です。
この教訓を踏まえて私は，次の箇条を基本とする信条，すなわち "プログラミングの信条" を提案したいと思います。
- 自分の問題の徹底的な理解に対する，完全な代替策は存在しない。時には幸運もあるかもしれないが。
- すべての問題に適用可能な解決策は存在しない。ある状況下で最善であったアプローチが，他ではまったくの最悪であるかも知れない。
- 有用なアプローチの多くは，複数の問題に適用可能である。従って一度成功したことは熟知しておく価値がある。
- 問題解決のトリックは単なる "ノウハウ (know-how)" だけでなく，その解決法を問題に適用する上での "ノウウェン (know-when)" も必要である。逆も同じだ。
- ただし，いくら "ノウハウ" あるいは "ノウウェン"を知っていたとしても，知識が役に立たない問題もあるし，誰も理解できていない問題の側面も存在する。いつも謙虚であることが必要だ。
忘れないでほしい – この書はもともと，構造化プログラミングを題材として 20 年前に書かれたものなのだ。氏が加えた変更は単に "構造化プログラミング" を "アジャイル" に置き換えただけだ – そのメッセージは現在も，1990 年の当時と変わりなく当てはまる。
同じように Elisabeth Hendrickson 氏は，"Agile Backlash? Or Career Wakeup Call" という題の記事で，業界に定着していると思われる "アジャイル適用に関する(アンチ)パターン" について説明している。
最初のパターンは，機能不全に陥った組織の無知なマネージャが押し付けた "アジャイル" の，堕落した香りに焼かれている人々に関するものです。ここで "無知(clueless)" と呼ぶのは，資格を持ったコーチを見つけるには２日間の CSM クラスの証明書を持った人を探せばよい，と考えるような，あるいは以下のようにプロセス資料を大域検索してキーフレーズを置換すれば "アジャイル" な組織への変革が達成できる，と考えるようなマネージャのことです。フェーズ -> イタレーション
プロジェクトマネージャ -> スクラムマスタ
要件 -> ストーリ
見積時間 -> 機能ポイント
状況報告会 -> スタンドアップミーティング残念なことに，このような "アジャイル" という言葉の劣化を防ぐ手立てはありません。これはどのようなバズワードにも起きることです。ISO, CMM，CMMI，RUP，すべてそうなのです。
第２のパターンは，氏にとってさらに深刻なものだ。
ただし私が憂慮と興味をともに持っている，２つめの反応パターンがあります。この種の反応は，アジャイルへの誤解によるものではなく，アジャイルプラクティス – スタンドアップやペアリング，コラボレイティブチーム，オープンチームルームなど – への挑戦的な考え方によるものです。
私はこれらの人々について，水辺のアヒルのようにアジャイルの社会的性質に親しむ外交的なグループの中で作業する，内向的な人々ではないかと想像しています。内向的な人たちには，物事を自分の中で処理するための時間と空間が必要です。そのような時間が十分に勤務時間中に確保できなければ，彼らは燃え尽きてしまいます。これに思い当たるようでしたら，アジャイルプラクティスを悪と見るのではなく，共同の時間と孤独な時間のワークバランスを確保するような方法で，チームと作業してほしいと思います。
さらに氏は，かつては社会的行動と見なされながらアジャイルチームではもはや受け入れられないものがどれほど数多いか，社会的，感情的な円熟度が今日のチームにおいてどれほど重要か，といった話題で議論を続けている。
実際に，それほど複雑ではないソフトウェアシステム開発であっても，それは社会的活動が不可欠なチームスポーツなのです。優秀なだけでは不十分です。これまでもそうでした。効率的なチームメンバとは，社会的スキルを持ったメンバなのです。彼らは耳を傾け，共同作業し，分け合い，チームに貢献します。
InfoQ は先日の記事 ”アジャイルは幻滅の中にいるか?” でも，アジャイルのハイプサイクルについて取り上げている。
結論として – コンピュータ産業は歴史の繰り返しから何かを学ばなくてはならない。あるいは私たちは，これからも新たなアイデアの度にハイプサイクルを繰り返していくのだろうか？