それはアジャイルの問題なのかな? -2-
話題はこれ。乗り遅れた感があるけれども…。 (^^;
アジャイルとしての反論はこちらをご覧頂くとして…。
アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog
私としては、そもそもアジャイルがどうこうって前に…と思ったので、別の視点を提供してみる。七つも反論する文章力がないので、"1.全体スケジュールにコミットできない" についてだけなんだけどね。
…と思っていたけど、"2.アーキテクチャ上の無駄が生じる" についても書いてみる。(^^;
ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。
うん。トーゼンだね。
なんとなく流行の技術を使って作ってないか？そうやって作られた物は負債になる。
うん。トーゼンだね。
プロセスがどうあれ、アーキテクチャはちゃんと考えるべきなんだ。
うん。トーゼンだね。
でも、アジャイルだから全体が決まらないとか言って、
問題はここ。"アジャイルだから" なの? ホントに???
確かに "アジャイルだから" 的な理由を付けて、ヘンテコリンな設計で暴走したプロジェクトがあったりもしたんだけど、それは "アジャイルだからヘンテコリンな設計になった" のではなくって、"アジャイルを理由にしてヘンテコリンな設計を提案した人がいた" とか、"ヘンテコリンな設計で暴走したのを止められなかった" という問題であって、"アジャイルの問題ではない" だろう。特に前者の "アジャイルを理由にして変なことをする人がいる" のは問題で「だったらアジャイルなんていらねぇ!」と、私は何度かケンカしたことがある。これはアジャイルコミュニティーにとっても損なことだろう。
システムを作る以上、アーキテクトは必要。これはスキルだ。スキルのない人にアーキテクチャ設計は任せられない。そして、アーキテクチャのレビューや承認フローも必要だと思う。
また、費用対効果の問題という側面もある。手戻りコストが大きいものは、なるべく手戻りしたくない。手戻りしないために時間をかける価値はある。でも、手戻りしない ("アーキテクチャ上の無駄" を避ける) ために 10 年かけて完璧なアーキテクチャを設計するのは本末転倒だ。費用対効果の妥当性のあるどこかで折り合いをつけなければならない。論理的な正解はなく、どのぐらいの時間とお金を使うかは、最後は経営判断ということになるだろう。Twitter は 2006 年にサービスを開始し、2009 年に Scala に移行したらしい。3 年間運営した 2009 年時点で 250万回/日を支えるところまで育った RoR だった訳だけど、"アーキテクチャ上の無駄" だったという結論は、妥当ではないのではないように思う。
アーキテクチャについて私が教わったのは、「完璧な未来なんて予測できない。変更は必ず発生する。その時にコストが抑えられるように、シンプルなアーキテクチャには徹底的に拘ること。」だったよ。
