アジャイルソフトウェア開発手法について

アジャイルソフトウェア開発手法の調査をしたので、少し検討してみます。
 ２００１年の発案者はその道を極めたすごい人々なのでしょう、私はマーティン・ファウラー氏 しか知りませんが。

手法の概要を確認すると、「開発での文書化よりも直接の会話重視」、「実際に動くシステムを作ることが一番大事」、「開発の反復を重視し最適化する」の3つでしょうか、どれも問題がない実に本質的で合理的な考え方であると思われます。

それではこの技術が生まれた背景を推察してみることにします。

一つ目の要素：
私はかねがねシステム開発の洋書の翻訳の内容から、米国の技術者はシステム開発 の自動化が得意で且つ普通のことと考えます。
特に感心したのは、本の著者自らが書いている書籍に掲載されるソースコードを自動検証 可能なツールを構築して、検証をしてから本の推敲をしていたことです。

もう一つの要素：
通信系のシステムではごく普通の自動検証でしょうが、作業自体ではなく考え方が進んでいると 思いました。 この他にポイントとなっているのは、WEBが現れるまでは通信系技術で標準化が進んでいました。 OSI参照モデルのプロトコルの７層を技術者同志でよく議論していました。今ではHTTPプロトコル １つで大体話題は済んでしまうので、非常にシンプルです。
WEB関連では色々な標準化が進みました。
HTML５、XML、DI、JavaScript、C#等々今までベンダーが抱えていた分野までも標準化されています。システム開発を実施している技術者は覚えることが増えましたが、標準化が進めば技術が当然管理する分野へと変化します。MOTとかPMBOKをよく目にすることは世の中全体が標準化していけば自然の流れであると考えられます。

従ってウォータフォール型開発が主流な時期から確実に環境や技術基盤がステップアップしたところで、 アジャイルソフトウェア開発手法は時代的な背景が生んだ考え方だと思います。
特にリーマンショック以降は経済的にも時間的にも、アジャイルソフトウェア開発手法を育てた時期であると思います。

 「アジャイルソフトウェア開発手法は自動化が進んだ状況で実施するべきである。」
と考えています。
自動化すれば、開発での文書化が少なくても自動でドキュメントをいつでも参照できるので問題がなくなります。少し違うことは美術的に綺麗な図を観れなくなることぐらいでしょうか。
反復でも自動化することによりデメリットはなさそうです。

---

最後に私が開発手法でもう一つ付け加えたいのは、
「オントロジーとタクソノミーの意識的適用です。」
これがこのブログのテーマです。