概要
ウォータフォールでの開発経験が長いチームメンバにて、アジャイル開発推進プロジェクトとしていくつかのアジャイル開発のプラクティスをレクチャーし、その感想を伺いました。
メンバの現職ではどのようにプロジェクトを進めているか
- 機能単位のタスクを出して見積もりを行う
- 線表(スケジュール)を引く
- 基本的にスケジュール通りに進めていく
- 遅れが出たら別部署から助けを借りる、人を増やす、お客さんと調整を行う
- 「この人はこの機能を担当」という風に分担し、個人でコーディングを進めていく(他の人がどんなプログラムを書いているかは全く見えない)
- 基本的にその部署が今までやってきた案件をとってくるため「なにこれ」という仕事はこない
メンバが感じているウォーターフォールの良いところ/悪いところ
良いところ
- 得意な案件を慣れた手順で開発していくため、不安なくプロジェクトを進めることができる
- 「こういうものを作りたい」という設計書がコーディング段階で明確になっているのでストレスがない
悪いところ
- 工程が進めば進むほど変更があると手戻りが大きくなるため変更に弱い
- 他の人の進捗が見えにくいため、できない人が進んでいるか心配になる
導入したプラクティス
- スプリントを区切ってのスクラム開発
- カンバンによるタスク管理
- テスト駆動開発
- ペアプログラミング
- リファクタリング
- ストーリーポイントによる見積もり
スプリントを区切ってのスクラム開発を導入しての感想
- 一番価値があると思う機能だけを設計してすぐにコーディングをするので、PlanからDoまでのスパンが短いのが良いと思った。ウォーターフォールだと全てをPlan(設計)してからじゃないとDo(コーディング)できないので検証するには遅い。
カンバンによるタスク管理を導入しての感想
- タスクの粒度が小さく慣れなかったが、タスクが小さいとそれに集中して作業できてよかった
- 誰が今なにをやっているか、が可視化されて進捗の不安がない
テスト駆動開発を導入しての感想
- 少しずつ形になっていくのが面白い
- テスト仕様書やテスト報告書を納品物として求められた時にテスト駆動開発は相性が悪そう
- テストが仕様書のように振る舞うのはすごく面白いと思うので、お客さんから理解を得られるならば積極的に取り入れたい
ペアプログラミングを導入しての感想
- 困りごとがすぐ解決してやりやすい(一人で悩んでいる時間が減る)
- コーディングしている時間よりも、考え事をしていたり調べごとをしている時間が長いので、ペアプロにしても生産性はほとんど下がらないと思った
- 人月計算と相性が悪そう
- 現職ではみんなでコーディングしようという雰囲気が一切ないため導入は心理的障害がありそう
リファクタリングを導入しての感想
- ウォーターフォールでは作って終わりであるケースが多いため、リファクタリングをする動機はあまりない
- 綺麗なコードである必要はない。動けばヨシ！
- やった方がいいことは分かる
- アジャイル開発は仕様変更が当たり前にやってくるので、コードベースを変化が受け入れられる体制にしておくことは重要だと思った
ストーリーポイントによる見積もりを導入しての感想
- 感覚で見積もるよりも精度が高かった
- スプリントをこなすごとに精度が改善されていくのを体験できた
まとめ
ウォーターフォールによる開発は、「今までやってきて慣れた案件をやる」という意味では非常に効率的に作用します。IT業界に落とされた案件が分解あるいは丸投げされて個々の組織の得意領域で引き受け、定型化された作業で実現されていくことでシステム開発がなされています。
アジャイル開発はそれを全て取って代わるかというと自分はそうではないと考えています。アジャイル開発で行う方が効率が下がることも多々あるでしょう。
一方で、ウォーターフォール開発は変化に弱いことが明らかになり、その場にいる現場のPGの方々も仕様の変化に対して脆弱であることを認識しています。
時代の流れとして、「ユーザがなにを求めているか分からない。とりあえず仮説を立ててやってみて、フィードバックを受けてプロダクトを成長させていこう」というやり方でやっていく重要性が増しています。
その際に、上記のようなプラクティスは役に立つと思われます。