そりゃそやろ！ - 「アジャイルがダメだと思う7つの理由」について議論して -

「アジャイルがダメだと思う7つの理由」について議論する会を大阪でに参加しました。3年前の元ネタと最近の様子に関する鈴木雄介さんの講演のあと、グループ毎に議論しました。

元ネタについてはすでに書いています（アジャイルがダメだと思う7つの理由を前向きに考えてみる）が、今回はこれまでの経験を踏まえて議論をしてきました。

講演内容

まず、「アジャイルがダメだと思う7つの理由」についてのお話がありました。そして、当時はアーキテクチャとアジャイルのコミュニティが対立していたことからアーキテクトである鈴木さんがアジャイルをあまり良く思っていない事、最近はアジャイル風の繰り返し開発をされている事、をお話しされました。

私も、アジャイル開発の「考え方」と「やり方」を学べや[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -で同じような開発方法を書いてます。

ウォーターフォール開発をベースにアジャイル開発を参考にすると言う話は昔から書いてますが、最近はウォーターフォールがベースに開発する多くの人が工夫しているのでしょうね。

変化ヲ抱擁スルために固定化している

講演の後は７つの理由のグループに分かれて2回の議論しました。というか、賛成と反対の意見に分かれてディベートをしました。1回目は「 変化ヲ抱擁スルために固定化している」です。

元記事では暗黙知の事を書かれていますが、アジャイル宣言の背後にある原則

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

を取り上げて、プロセスを固定化として、最適化できないとの議論を展開しました。関連するシステムがあり、期限が限られているので、定期的なリリースにあわせる事はできません。

反対意見では、スプリント中にリリースするタスクを作って実施しているとのお話がありました。実務的にはそうでしょうけど、それは原則に従っているのか、1週間ごとのリリースや1日に何度もリリースして、アジャイルというのと同じではないかと言いました。

この他にも2ヶ月ほどの短期開発では、タイムボックスごとのふりかえりなどもあまり効果的でなく、期間内で最適化する方がうまくいくのではというお話をしました。

どこまで原則を守らないとアジャイルと言えないかとの議論はありましたが、それ以外の反論はありませんでした。

なお、そういったシステム間の連携があったり、短期間のプロジェクトが一部の例外と呼べる組織なら、アジャイル開発を標準とすることもアリだと思います。

アジリティはアジャイルだけのものではない

2回目の議論ではグループの全員が「そりゃそうだ」と賛同しましたので、議論というよりは意見交換になりました。

アジャイル開発はアダプティブ（適応型）であるのが基本で、アジャイル（機敏）というのは風呂敷が大きすぎるのではないかと言いました。機敏を実現するには高速開発等の環境やツールなどもあるからです。

ただ、アジャイル開発があったからリーンスタートアップが生まれたんだよね。という意見には賛同しました。そういう意味では、「 アジリティはアジャイルだけのものではないが、アジリティの本家だ」ということだと思います。

おわりに

この記事を書き出してからゆっくり考えました。

私自身はアジャイルに反対している訳でなく、向いている所で実施すべきものだと思っています。

そもそもアジャイルソフトウェア開発宣言は、当時のソフトウェア開発の解決すべき問題点を示しており、誰もが考慮すべき事であると思っています。

しかし、厳密な定義を元せずアジャイル開発の議論をすると、きちんとした技術論にならず、いつもながら不毛になりがちだと思いました。

アジャイル開発であるかどうかは開発者の関心事ではなく、顧客に価値を提供するより良いソフトウェアの実現が関心事です。アジャイル開発に対する議論はもう終わりにして、どのような現場の問題をどのように改善したかを議論したい思いました。