ソフトウェアの標準と部品化 4 /アジャイル開発

前回につづいて、ソフトウェア開発に関連した話題です。

アジャイル開発

XP手法やアジャイル開発が注目されていることはご存知の通りです。

従来の手法でコードを開発しているだけでは要求にこたえられないと感じている人が多いことが、アジャイル開発の注目度が上がる要員の１つであると思いますが、もう１つには、アジャイル開発を唄って、ノンドキュメント、設計行為なくただコードを作るという方法が取られている場合もあるようです。

アジャイル開発はドキュメンテーションをなくすということを主張しているものではありません。

　　▼XP(エクストリームプログラミング)
　　　　IT用語辞典 e-Words
　　　　http://e-words.jp/w/XP.html

単に工数を削減するという名目のもとにドキュメントを作成しなかったり、リファクタリングの名のもとに未設計のままコードが作られて、スパイラル開発の名のもとに改版するという行為をアジャイル開発といっている人がいるというに過ぎないのだと思います。

XPなどアジャイル開発手法で語られるモデルは、多分に設計能力の高いSEがコーディングと教育、テストまで分担することになるためボトムアップ開発も可能、スキルアップも可能、品質も安定、となるわけですが……手法による成功するモデルというより能力の高いSEの個人能力への依存度が高い手法ともいえます。

権限を与えているので、最初に上げたような『自分がルール』という人は、モデルに適合しているかのようにも見えますが、相当に能力が高く、プロジェクト運営や教育的行為に積極的な技術者を確実に割り当てないとうまく機能しない可能性があることを示唆しているかもしれません。

ウォーターフォールと対極？

ウォーターフォール開発モデルと比較されることが多いわけですが、ウォーターフォールでも、必要であればリファクタリングもペア・プログラミングも採用されます。

　　▼ウォーターフォール・モデル
　　　　@IT情報マネジメント用語事典
　　　　http://www.atmarkit.co.jp/aig/04biz/waterfall.html

アジャイル手法が強調している点に反論する人は少なく、ただ、組織的に全面採用するには、個人依存度とスキルが問題になるという点において、全面的に賛成とはいえないということが多いのではないかと思います。

ペア・プログラミングなどを採用しても、コミュニケーションや教育を苦手とする人では、手法のみ採用しても効果が上がるわけではないことは自明です。

以前のペースの開発であれば、ペア・プログラミングにしなくても、ライブラリ・コードから学んだりプログラム部品の仕様設計から学ぶ、あるいは、議論するということで済んでいたところが、開発サイクルの短縮と対象範囲の拡大などによって、ソースコードや設計書などによって伝播することが難しくなったことも、ペア・プログラミングなどが必要とされる一因なのでしょう。

ウォーターフォール開発モデルでは、設計から基本部分の生産というように流れますから、早期段階での高い設計能力や技術が要求され、また、早期に実装される基本的なライブラリやコード標準は後まで、正しく品質が高いものとして計画が立てられています。

この前提がしばしば崩れることでデスマーチに陥るため、アジャイル開発などでは、見直しや変更、テストと再テストを強調されています。

……でも、アジャイルで語られている変更に柔軟な設計と実装、品質安定のために詳細仕様を意識した再テストの仕組みを取り入れることは、ウォーターフォール的な開発体制でも軽視されていたわけではないと思います。

それでは、次回もよろしくお付き合いください。