はじめに
こんにちは、ソリューション事業部の中居と申します。
この記事は社内でアジャイルトレーニングを受けて、改めて考えた「アジャイルに対する6つの誤解」についてまとめたものです。
これから記載する誤解はウォーターフォール開発に慣れた組織が初めてアジャイル開発を行う際にぶつかる壁のひとつだと感じましたので、ご参考になれば幸いです。
今回取り上げた誤解は下記の6つです。
- 1.「計画を立てない」
- 2.「要求変更は自由である」
- 3.「ドキュメントはいらない」
- 4.「プロジェクトマネジメントはいらない」
- 5.「スクラムマスターはいらない」
- 6.「アジャイル＝ソフトウェア開発方法論と捉え、IT部門が開発を考えるべき」
1.「計画を立てない」
以前、インセプションデッキを作成していた時、ステークホルダーより「で、リリースがいつかわかる計画はないの？」と質問されました。このご質問は「ウォーターフォールのガントチャートのようなリリース日程を確約した計画はアジャイルにはないの？」という趣旨でした。
アジャイルのプロジェクト開始時の「計画は見込みであり確約はできません」が、初めてアジャイル開発に取り組む組織では「確約できる計画はないのか？」「計画を立てないのか？」「それは曖昧過ぎるのでは？」という疑問になり、ひいては「アジャイルは計画を立てない」という誤解につながります。
アジャイルはまったく計画を立てないわけではありません。アジャイルにはガントチャートのような計画はありませんが、アジャイル・スクラムではリリースの計画（リリースプランニング）・スプリントの計画（スプリントプランニング）・日々の計画（デイリースクラム）を立て、常に計画を調整しながらリリースを目指します。
もしリリース時期が最優先の場合は、「計画に柔軟性を持たせ、状況に応じてスコープ等を調整して計画を修正、リリース時期を守る」ことになります。
これはアジャイルとウォーターフォールの大きな違いなので、最初の質問の根幹は「アジャイルとはなにか」にあり、「なぜこの開発手法がアジャイルと呼ばれているのか」「なぜ確約できないか」「アジャイルでは計画や変更に対し、どのように対応するか」等からステークホルダーの理解を得られるよう、説明する必要があります。
※リリース計画については下記記事で取り上げられておりますので、ぜひご参照ください。
tech.mti.co.jp
2.「要求変更は自由である」
ウォーターフォールの開発ではプロジェクトで変更が発生した場合はプロジェクトマネージャーや会議体によって変更管理の手続きが行われます。
それに対して、アジャイルは「ウォーターフォールのような変更管理手続きはない」「アジャイル（敏捷）なのだから、ステークホルダーからいつでもどんな変更でも依頼可能」という誤解を生む場合があります。
しかし、プロジェクトは常に、限られた時間・人員・予算で行われるため、アジャイルプロジェクトでもまったく自由に「いつでも」「どんな変更でも」受け入れられるわけではありません。
Aという機能を追加できるかどうかは、Aの優先順位や、その目的や価値次第になります。また、Aの代わりにトレードオフする機能の有無、変更を反映する時期はいつか（スクラムであればスプリント中に実装中の機能の変更や、開発チームの理解を得られない・説得力のない変更追加は不可）により、変更を受け入れられない場合もあります。基本的に、要求の追加・変更はスプリント計画で受け入れられなければなりません。
この「いつでも自由に変更できるわけではない」についても、ステークホルダーの理解が必要です。
3.「ドキュメントはいらない」
これは開発者から頂くことが多かった質問です。たしかに「包括的なドキュメントよりも動くソフトウェアを」とアジャイルマニフェストでは述べられていますが、「＝まったくドキュメントはなくてよい」ではありません。必要最低限の仕様書・設計書、法律で義務付けられた文書、ユーザーマニュアルなど、必要なドキュメントは存在します。
ドキュメント作成は、ユーザーストーリーでは表現しづらいため、ユーザーストーリーとは別に「ドキュメント作成」というタスクを作る必要があります。
もし必要最低限のドキュメントが存在しないと、どのような影響が出るでしょう？
ナレッジ・スキルのトランファーや後任者への引継ぎに困るかもしれませんし、実際にどういう仕様に基づいてテストしたか、テストした結果どういう不具合が出たか、エビデンス（証跡）が残らないと監査やリリース承認時に指摘されるかもしれません。
4.「プロジェクトマネジメントはいらない」
アジャイルを採用したとしても、スコープ、品質、スケジュール、コミュニケーション、リスクなど様々な観点でプロジェクトマネジメントは必要です。アジャイルというとプロジェクトマネジメントは不要だという誤解があるかもしれませんが、スクラムであれば、スクラムチームがそれぞれ分担し責任を果たすことで、たとえば一例として、下記のようにマネジメントが行われることがあります。
- スコープ・スケジュールは、プロダクトオーナーと開発者で検討し、インセプションデッキのトレードオフスライダーやリリース計画をもとにステークホルダーの合意を得てマネジメントします。
- コストは、プロダクトオーナーと開発者がステークホルダーと調整します。
- 品質は、事前に定めた完成の定義・受け入れ基準や品質の作りこみ、テスト設計に表れます。 プロダクトオーナーと開発者が担います。
- 資源・調達は、プロジェクト初期のリソース確保であればプロダクトオーナーとスクラムマスターがステークホルダーと協議して決めるのがよいと思います。
- ステークホルダーとのコミュニケーションは、プロダクトオーナーが担います。
- リスクは、いくつかのイベントを通じて話し合われます。プロダクトオーナーや開発者が主体となり、うまく前進できるようにスクラムマスターがファシリテートします。
マネジメントは必要！
5.「スクラムマスターはいらない」
「スクラムマスターは何をする人なのかわからない」。こちらはステークホルダーから頂くことが多い質問です。
「開発者＝プロダクトを開発する、プロダクトオーナー＝プロダクトを通じて提供する価値を最大化する。でもスクラムマスターは何をしてくれる人なのか？ 何かを作るわけでもないし、ステークホルダーに対し成果物について説明してくれるわけでもない。開発者とプロダクトオーナーがいればアジャイル開発（スクラム）になるのでは？」
スクラムマスターがいない場合、そのチームはアジャイルになるかもしれませんが、スクラムにはなりません。
スクラムマスターはプロジェクトのプロセスが適切に回ることを保証する人です。わかりづらいですね……。
開発プロジェクトを車にたとえてみます。開発者はエンジンです。車の動力源となります。プロダクトオーナーはドライバーです。どの方向へ車が進むか、ゴールはなにかを理解し、道筋を示します。スクラムマスターは整備士として車の状態を可視化したり、車が故障しないよう定期的にメンテナンスを行います。
スクラムマスターはチームのフェーズ（タックマンモデル）ごとにどのようにふるまえばチームが自律的に動けるようになっていくか、いま障害になっていることは何か、どうすれば高いパフォーマンスを発揮するチームになれるか、スクラムとしてマインドセットを保つことができるか、等を支援します。
スクラムマスターはウォーターフォールにはない役割なので、戸惑う方もいらっしゃると思います。
その場合は、スクラムマスターは「スクラムマスターとはなにか」から説明を始める必要があります。
6.「アジャイル＝ソフトウェア開発方法論と捉え、IT部門が開発を考えるべき」
アジャイル開発はたしかに「開発手法・開発方法論」ではありますが、IT部門だけで閉じるソフトウェア開発ではなく、システム、しいてはプロダクト全体を顧客目線で考え、価値を素早く提供する組織や仕組みを作る手段です。
ゆえに、IT部門任せではなく、事業部門による積極的関与が重要（特にプロダクトマネジメントに携わる方）となります。インセプションデッキ作成はもちろん、成果物のレビューにも事業部門の方に参加いただき、フィードバックを得ることがとても重要になります。
たとえば、顧客と会話する事業部門の方から「こういう機能があったほうがいい・この機能はなくてもよい」「なぜこの画面にしたのか？」というご意見・質疑を頂けるかもしれません。カスタマーセンターの方のご意見によって、成果物の機能が大きく変わり、顧客にとってよりよいものになるかもしれません。
顧客にとっての価値は何かを考える時、ぜひプロダクト目線で考えていただければと思います。
さいごに
今回取り上げた「アジャイルに対する6つの誤解」は、初めてアジャイルに挑戦する組織ではよくある誤解です。
開発者は実際にアジャイルプロジェクトが始まるとチームとして経験を積み、成長していきますので、誤解を解消、疑問も解決することが多いのですが、ステークホルダーにはなかなか「アジャイルとは」が正確に伝わりにくく、そのため誤解が誤解のまま進んでしまう恐れがあります。
スクラムであれば、スクラムマスターの支援はチーム→組織と広がっていきますので、ステークホルダーの誤解を解き、ご理解いただけるよう巻き込むことが必要になります。誤解をなくし、1チームでも多く、Fun！な開発が広がればよいなと思います。
今回のトレーニングを通して、「なぜアジャイルなのか？」を振り返って考える機会をいただき、「アジャイルに対する誤解」について記載させていただきました。アジャイルに対する誤解解消への一助になれば幸いです。
※アジャイルとウォーターフォールの違いについては下記記事で取り上げられておりますので、ぜひご参照ください。
tech.mti.co.jp
