アジャイルで失敗した体験談
はじめに
システムの開発プロジェクトを進めるにあたりよくある手法として
・ウォーターフォール
・アジャイル
の手法があります。
筆者が開発会社、内製の開発チームと関わるときに手法の勘違いをして
プロジェクトが炎上している場面をよく見ます。
その体験談をまとめてみました。
ウォーターフォールとは
ウォーターフォールとは、直訳すると「滝」を意味していて、
滝のように、上から下に流れるように工程を進める手法になります。
各工程ごとに承認ルールを用意して、承認が通れば次の工程に進みます。
承認フローを通過させることで、手戻りが少なく、
順序立てて進めれるので計画を立てやすくなります。
デメリットとして
「鯉の滝登り」という言葉があるように、滝を登るのは難しいのは
想像できると思いますが、開発でも一度承認をして次の工程に移ると
巻き戻すことが難しい手法になります。
アジャイルとは
アジャイルとは素早くという意味で、
要件定義～リリースを小さい機能単位でリリースしていく手法になります。
ウォーターフォールと違い、日々変化していくユーザーニーズに対応しながら機能のブラッシュアップをしていくには最適な手法です。
デメリットとしては、
要求を１００％満たすことはできなく、徐々に要求を満たしていく流れになります。
よくある開発内部での失敗談
アジャイルの基本軸は、
「ドキュメントより、動くソフトウェアを価値とする」とよく言われます。
ここでよくする勘違いは
「ドキュメントは書かず、動くソフトウェアを作る」
ことが様々なプロジェクトで浸透しています。
ドキュメントを書くのは時間がかかるということで
まずは動くものを作ってしまうことが多いです。
その結果よく発生する事象の１例で
・仕様把握は、ソースコードを見て判断することになる
・改修があるたびに、現状の仕様把握が難しくなる。
・メンバーの入れ替わり時に説明できるアウトプット資料が不足する
・バグ調査をするにも仕様の概要がないため、調査が進まない
・属人化してしまいう
・・・など、色々あり書ききれませんが
要は、ドキュメントを全く書かずに、開発が進むと
小さな火種があちこちで発生して、炎上につながってしまいます。
実践したこと
ウォーターフォールみたいにドキュメントを全て残す！
わけではないのですが、プロジェクト参画者が最低限合意して進めれる
レベル感のドキュメントは残すこと実践しました。
例えば、詳細設計書を作るまではしなくても
要求がしっかりと設計に落とせて問題ないか確認できる
基本設計部分までは残そう。
また、ドキュメントもWord、PowerPointとかでがっちりするのではなく、
Backlogなどのツールなどで、チケット管理、WIKIにまとめるなど
簡素化してあげることで、ドキュメント作成への抵抗感を減らすことも
できました。
詳しいことを書くと沢山書いてしまうので、ここまでしか書きませんが
まずは、必要最低限何があれば合意して進めることができるのか
を意識して取り組むべきと考えます。
個人的に思うこと
様々なプロジェクトを見てきて、これはウォーターフォールじゃダメ、アジャイルじゃないとダメ。と意見が飛び交う場に出くわしましたが、
アジャイルは、ウォーターフォールをいかに短い機能単位で回すか。
だと思うので
ウォーターフォールは基本、アジャイルは応用。
という考えを持っています。
そのため、ウォーターフォールができないのであれば、アジャイルなんてできない。というのが個人的な意見になります。
スポーツでも、基本プレーができないと、応用プレーをすることはできないと思います。
テニスなら、ラケットを持って相手に向かってボールを打つことができる前に、いきなりネットギリギリにドロップショットを
打つことは難しかったり、
野球でもまずはキャッチボールをしっかりする前に、
いきなり変化球を投げるのは難しいですよね・・・
まずは基本ができたうえで、難しいことをしていくと思います。
開発案件でウォーターフォール案件、アジャイル案件を選ぶのはなかなか難しいと思いますが、知識としてまずはウォーターフォールの進め方を理解したうえでどうアジャイルに対応するのかが重要ではないかと思っていたりします。