##前書き##
__「2020年アジャイル状態報告」__によると、現在では多くの組織がアジャイルの実施を検討しています。
回答者は約半数の人は自分のチームが半分未満のメンバーがアジャイル開発を使用していると返事します。更にその中で自分の組織がアジャイル開発のレベルに足りない能力不足という現状を認識してる人は84％もいます。

一部の会社やチームがアジャイルさを実践した後、大きな成功を得た実績を見て、多くの人がそれを真似して、次々とアジャイル開発の行列に入ることになりました。
しかし、アジャイル開発に変更することは決して容易なことではありません。この変更の過程で最もよく見られる問題は、チームがアジャイルな原則やコアである価値観を理解しておらず、ただの猿真似をしていることです。
その結果はもちろん失敗です。そして失敗したチームメンバーがアンチ発言をばらまいて、アジャイル開発に人力と財力を無駄に消費して、時間のコストも増やしたのに何のいい効果も出来ていないという汚名を被らせて、そう宣伝しました。
果たして悪いのはアジャイル開発ですか？
勝手に勘違いをしたやつのせいではありませんか？

アジャイル宣言の主な内容は：

道具より人
文書より産物
契約より協力
計画に忠実より変化に対応

しかし多くの会社で、チームは“アジャイル”を笠に着て実際の行動はありえないほどにアジャイル開発宣言とその価値観から離れています。その結果はもちろん失敗です。
「どんなツールやプロセスと関係ない。**もし人々が自分の作業環境に苦しめられるなら、アジャイルとは言えない。**だから、このような“アジャイル”の皮を被ったチームは、偽物だ。」と、アジャイル宣言共著者のRobert C.Martinはインタビューに応じてそう言いました。

チームや会社が“偽アジャイル”に足を踏み入れそうなとき、どうやって一刻も早くこの問題を発見し、解決するのは我々アジャイル開発者の課題です。

##偽アジャイルさとは何ですか？##
###1. 極端なアジャイル###
####1) アジャイルはスピードだけではありません####
アジャイルといえば，軽量級の方法として，「とにかく速い」と勘違いしている人が多い。そのため、チームメンバーに「忙しい」錯覚を与えて、最後はスピードのために質を落とすオチになります。この状況でできたプロジェクトはお客様の要望を果たすところかテストも合格できないでしょう？
####2) アジャイルはシンプルだけではありません####
アジャイル十二原則の第10条に**“簡潔さをもとに、不要な仕事量を極力減らす芸術”**であると書かれています。
「不要なプロセスは省略ですよね。じゃ毎日の立ち会議も省略しよう」と、一部の人はそう考えるでしょう。そしてスプリントレビューも意味ないので省略、変化を応じるこそアジャイルだから企画会議も不要。
絶対主義者は、変革ならば徹底的にと思って本当に価値あることを全部省略しました。
その結果は、まだ何も理解していない開発者の負担になることになりました。
###2. 硬くなった　アジャイル###
####1) 立ち会議####
毎日の立ち会議はアジャイルチームのコミュニケーションにとって不可欠な架け橋です。毎日の立つ会議はチームメンバーが自分の仕事内容を詳細かつ明確に報告する必要がなく、2分で簡単な陳述を行うだけで、総時間は一般的に15分程度です。そして具体的な時間はチームごとのメンバ数や作業の性質によって変化する。15分を死守して時間以外の大事なことを無視してはいけません！

会議時間が硬くなると、チームメンバーに大きな負担を与えます。時間死守したらメンバーがどうでもいい話を無理やりして、もうコミュニケーションにならない状態になって、チーム内コミュニケーションを促進するという目的ももちろんできなくなります。
####2) 看板####
アジャイルチームの中で、看板を利用して任務の可視化、作業状態の透明化を実現し、チームメンバーを激励して、仕事の集中力と効率を高めることができます。
しかし、看板を設置すると、半分飾りになったり、タイムリーな更新が得られないなったり、チームメンバが看板から情報を得られないことになる問題がよくあります。
その結果、看板はアジャイルさを代表する飾りとなった。
担当者が仕事を報告するとき、壁の看板を指さして：ほら、私たちのチームはアジャイルです。
しかし実際には、アジャイルな観念が貫徹されているかどうかは、チーム内部のメンバー以外誰もわかりません。
####3) 伝統型リーダーのアジャイル####
以前に規模化のアジャイルな変革についての文章を書いたが、その中でチームが規模化するアジャイルに転換する前に、まずリーダーの思想はアジャイルに変更することを強調しました。
同様に、伝統的なチームがアジャイルに転換する過程にでも、指導者が率先して転換し、アジャイルな思考を備えている必要がある。アジャイルなリーダーになってから、チームや個人の長所を発掘し、利用することでチームのアジャイル化を推進することができます。
リーダーの考え方が伝統的なウォーターフォール式開発モデルを続けている会社をみました。チーム全体がアジャイルに変化し始めたとき、リーダーは開発プロセスの前後関係をたちきることができませんでした。そのためにチームはアジャイル開発の小周期スプリントを実施する際に大きな問題にあって、チーム全体が中途半端な状態に見られていました。
社内で統一的なアジャイル転換体勢が達成していなければ、そのときのアジャイルチームは難航する。
ということで、アジャイルに転換の効果が悪いの“呪詛”を祓うためには、チームの現制度の縛りを破り、チーム中の“偽アジャイル”現象を見破って、チームの実態に応じて適切に策略を変え、本当にアジャイルに“生きる”ことができるようにしなければなりません。
##最後に##
もっと知識を知る必要があれば、以下のリンクにアクセスすることができます。これは私が使っている__Zentao__開発ツールで、より専門的な人が問題を解決してくれます。
オープンソースのプロジェクト管理ソフトウェア-スクラムツール - ZENTAO