アジャイル開発を勘違いしてる企画職やPMがいる会社は苦労する
Table of Contents
Web界隈では開発手法はウォーターフォールからアジャイル開発へとシフトしていると思います。 従来のウォーターフォール方式では完成した頃には既に二番手三番手、既に古いと思われるほど求められるニーズの変化速度が速くなっているからです。
この変化に柔軟に対応できる開発方法がアジャイル開発でした。正しく理解し運用することで安定した開発が可能になります。 また上位レイヤーのリーン開発との相性もよくリーン＋アジャイルでのフットワーク軽い開発スタイルは見かけます。 しかしこのアジャイル開発を浅く知って勘違いした企画職やPMがアジャイルでもウォーターフォールでもないどちらのメリットもない形に崩すのは典型例です
この記事はアジャイル開発を5年近く続けて経験した苦労話です。
なお私が経験したのはアジャイル開発はスクラム＋XPです。
アジャイル開発は細かくリリースしやすい
Webの特徴であるリリースを何回もできることを前提とした、数機能ずつリリースを繰り返すサイクルです。 実装する機能はスプリント初期に構築したプロダクトバックログのストーリーと呼ばれる機能をシナリオ化した物が並び順になっており、 1~2週間を1スプリント(SP)と称し1SP内にそのストーリーを対応して、SP終わりにプロダクトオーナー(PO)と呼ばれるプロダクト成長を責務とする人が ストーリーを満たしているか受入判定を行います。そしてSP頭になればまた次の優先度のストーリーを進めます。 プロダクトはSP毎に常にリリース可能な状態となっていなければならず、それにより期限が予定より短くなったり開発が遅れたりすることで優先度の低い未対応ストーリーはそのままで リリースすることでプロダクトにとって最も重要な順に対応された機能がユーザーに届けられます。
アジャイル開発が非開発者に勘違いされがちなこと
- 柔軟に仕様を変更できる
- 細かい仕様書が不要
- 開発やデザイナーだけで開発が回る
- 人員増やせばより開発が加速・安定する
- ウォーターフォールより早い
- 立て続けに機能追加できる
- プロダクトオーナーは若手でもできる
柔軟に仕様を変更できる
アジャイル開発の利点を概要部分だけ読んだ企画がよく勘違いします。 そんな夢物語があるわけないです。
厳密には次の通りです
- SPレビューからSP計画までの間にプロダクトバックログ内のストーリー単位での未対応ストーリーの優先順位変更が可能
- 未対応ストーリーの仕様変更が可能
- 仕様変更したら関連するストーリー全てのポイントが再見積もりとなる
となります。 これをSP中にも関わらず対応中の機能の仕様をコロコロ変えたら、そのSPでは何もストーリーを達成できません。 本来はSPが走り始めたらストーリーを変えてはいけません。対応してよいストーリーはReadyを満たしたものだけになります。
当たり前ですが、仕様変更するならした分だけ工数は伸びます。これはどの開発手法でも変わりません。
細かい仕様書が不要
アジャイル開発では「資料よりも対話」を大事にしようと言われています。 しかしこれを口頭で全部伝えればOK、細かいことは伝えずOKと勘違いする企画がバカのように多いです。
そもそもの前提が間違っています。
- 複雑なビジネスロジックや重要機能は最適量の仕様書は必要です。
- 不要とは言っていません。ちょっとした確認や本当に細かい部分を資料ではなく口頭でやろう。という逆位置からのスタートです。
- 大前提としてPOが隣や向かいの席など超近接です
これを仕様も伝えず最も重要な機能も伝えず、違う企画だらけの島に席をおいて、しょっちゅう会議でいない無能POがいます。
そんなテレパシーを超えたテクノロジーもビックリの情報疎通環境でできるんだと間違うお花畑企画がいます。
開発やデザイナーだけで開発が回る
SP計画とSPレビューだけ顔出してSP中は一切無関係みたいな勘違いも見かけます。 スクラムの前提はPOもデザイナーも開発、SMもコアメンバーは一つのチームとして動きます。 それぞれがスペシャリストでなければいけません。
それを勘違いして仕様バグ確認や優先順位や精査、プロダクトバックログの整理やユーザー分析などをせず、別の企画の決裁向けプレゼン資料を作ってるバカも多いです。 シニア企画に多いです。
人員増やせばより開発が加速・安定する
アジャイル開発はメンバー全員が「プロダクトを良くしたい」という同一姿勢が前提で、同じプロダクトに同じメンバーで続けることでチーム内成熟度が熟成し、手戻りや齟齬を減らしたり、付帯作業を抑えたり、プロダクトへの知識を蓄積することでベロシティを安定化させるなど、そのプロダクトにおいてそのチームが最も適切で先鋭となることがアジャイル開発をするチームにおいて重要なことです。
これを1フェイズ終わったからといって、メンバーをコロコロ変えたり、ベロシティが低くて期限に間に合わないからと言ってメンバーを増員したりなどするのは悪手です。 アジャイル開発はPOとしてしっかり接していないと、プロダクトバックログやスプリントバックログのマネージメントコストが超非常に高いという事実をまず知らないです。
これをチームとして参加せず数字だけ見てる人がよくやる典型的なリソースコントロールです。 机上の空論です。扱ってるリソースが機械だと思ってるのでしょう。
ウォーターフォールより早い
アジャイル開発はSP毎にリリースReadyにする、対応ストーリーのみを考慮した開発、先のストーリーは考えない（結局やらない可能性もあるから）といった特徴もあるため 開発に無駄があります。
例で言うと、ウォーターフォールでは全部の仕様を策定し、それを確認した上でデータベースのテーブル設計を行います。 設計されたテーブルは機能をカバーできる設計となります。
しかしアジャイル開発ではまずはフェイズ１などここまでをリリース対象としようと全部の仕様策定などはしません。 そのため目の前のストーリーを実現するには適切なテーブル設計でも、次SPや次フェイズのストーリーでは、カバーできない場合があります。 その場合はマイグレーション処理が発生します。
これはテーブル設計に関わらずクラス設計にも同様の話です。予め可変性の高い要件が見えていればその部分を柔軟性高めの設計にします。 しかしそれが見えないため、ガチガチに組んだ設計部があとで実は多様性を持たせないといけないことになり、結局大きめのリファクタリング入ることはよくあります。
実際見た目はそのままの言語やインフラなどテクノロジーリプレイ案件であれば、不安定で不透明な仕様や追加仕様は存在しないためアジャイル開発でやるメリットがありません。
アジャイル開発はある程度速度を犠牲にした代わりに柔軟性を手に入れているのです。
立て続けに機能追加できる
半分間違ってます。
技術負債を解消し続けなければ、ちょっとした変更でもリグレッションバグが発生しテスト工数がかさんだり、色々な箇所を読み解く必要があったり、気づけばアジャイルのメリットをなくなってしまいます。
アジャイル開発はWebサービスなどプロダクトを継続成長させる開発に向いています。 しかしそれを支えるには負債解消計画も継続的に考慮されてなければいけません。
プロダクトオーナーは若手でもできる
もう愚の骨頂です。 こう思ってる人は愚かにもほどがあります。
プロダクトの責任を負ってる人が若手ができるわけがありません。 プロダクトはライバルや市場、ターゲット分析に加えトレンド機能などプラットフォーム知識、そして機能毎のKPI策定やそれらの追跡、問題点の分析と改善などプロダクト成長させ収益を得ることを一手に引き受けます。 そこらの2年目3年目が一人でこなせる訳ありません。もともとPOは10年目以上のベテランが推奨です。
ちょっと考えれば分かることをいいように解釈して、本来必要な作業をやらなくても良いと何故か判断する部長などリソースマネージャーがいます。 アホですね。
アジャイル開発は銀の弾丸ではない
今後も含めいかなる開発手法が登場しても、元々やらなければいけないことの本質が消えることは絶対ありません。 仕様書も説明もなく仕様は伝わらないし、仕様バグも見つからないし、完了条件も定義できません。
未だにIT開発をコストと考える古臭い人は非常に多いです。特に数字をメインにしてる人は多いです。 こういった会社や上司のいる場所は、エンジニアがアジャイル開発を経て幸せになることはまずありません。
