だからアジャイル開発は失敗する
アジャイル開発を現場に取り入れる事例が増えてきているようだ。もちろん、アジャイル開発により成功したという事例も多いのだけど、これも「銀の弾丸」ではないから必ず成功するという保証は何も無い。ソフトウェア開発のボトルネックがウォーターフォールに起因するのであれば、アジャイル開発へ変更することで成功率は上がるかも知れないけど、プロジェクト失敗の原因が他にあるのなら、どのようなプロセスでも成功は難しいだろう。
例えば、このような課題は、どのような開発プロセスを採用しようと本質的に変わらないはずだ。
- 開発者のスキル（それはスキルの問題）
- 開発者のコミュニケーション（それはコミュニケーションではない）
それなのに、アジャイルへ移行すれば全ての問題が解決できるかのような誤解（幻想）を抱いている人が多いのは残念なことだと思う。
そもそもアジャイルでドキュメントがいらないと誤解する開発者が多いのではないでしょうか。確かに欧米では、ドキュメントを全く作らない事例がある。ただしこれは、長年自社のシステムを担当してきた熟練エンジニアがそろっていて、ソースコードを読めばドキュメントの代わりになるからです。
［覆面座談会］はびこる失敗アジャイル（2ページ目） | 日経 xTECH（クロステック）
開発対象やドメインによって「設計書が必要な理由」は異なるかも知れないけど、基本的に「仕様書は作成過程が大切」であって、仕様書が存在しないのはまともな設計が行われていないことに等しいと思う。ドキュメントと言うと「嫌われる作業のナンバーワン」「削減される工数の筆頭」であることが多く、確かにムダなものがあるとは言え、何でもかんでも省略して良いものでは無いはずだ。「仕様書をTracのWikiに記載する」のは作業効率化の一つの方法だし、「Tracのwikiに図面を入れる」工夫だって出来るはずだ。カットできるものはカットする、減らせるものは減らす等「技術者はもっと手を抜く方法を考えるべきではないか？」と思う。
現場のメンバーが何を作業しているのか今ひとつつかめないというのです。メンバーに聞いても問題ないのひと言。ガントチャートやWBS（Work Breakdown Structure）といった管理ツールがないので、うまく進んでいるのか判断できなかったようです。
［覆面座談会］はびこる失敗アジャイル（3ページ目） | 日経 xTECH（クロステック）
ある程度の経験を積むと「失敗プロジェクトの予感」を敏感に感じられるようになる。例えば、「進捗状況を聞いても誰も答えられない」「リーダーが外部の調整に追われ、チーム内の状況を把握できていない」「不具合が見つかって初めて仕様が分かる」という状況が発生していると、それはデスマーチへ向かって一直線という証拠だろう。「重要な情報はメールの中に埋もれる」ことが多いので、それらの情報を全てオープンにして誰もが同じ問題意識を持てる環境を用意することが必須だろう*1。「開発プロジェクトの見える化」は不可欠なのだ。また、TracやRedmineのような環境を用意することで、プロジェクト全体の見通しが良くなり、進捗管理も用意になるケースが多い。Excelでのタスク管理を好む人に限って、そのようなツールの欠点を指摘して自己正当化を図りがちなのは嘆かわしいと思う。
ウォーターフォールにはウォーターフォール特有の課題が有ったのように、アジャイルでもアジャイル特有の問題が存在するのだ。その問題の存在を正しく認識した上で、アジャイルに取り組むという前向きな姿勢が必要だろうと思っている。
ただし、本に書いてある通りにやってもうまくいかないことがあるので注意が必要ですよ。現場で実践して改善していく。それがアジャイルの本質ですから。
［覆面座談会］はびこる失敗アジャイル（3ページ目） | 日経 xTECH（クロステック）
関連
- チケット駆動開発の参考書「Redmineによるタスクマネジメント実践技法」
- Agile Tour Osaka 2010に参加してきた
- ソフトウェア開発を俯瞰する読書「ソフトウェア開発はなぜ難しいのか」
- XP祭り関西2010に参加してきた - Basic
- キッチリソフトウェア開発 - Basic
*1:たまに「メールを勝手に公開するな」と怒る人がいるのだけど、開発現場にて、そもそも個人情報や経営に関する機密情報を除き、転送や公開されて困るメールが存在すること自体、理解に苦しむ気がする。
