「アジャイルなマインドセットとは」5回目、これが本シリーズ最終回です。
今回は、「システムを中間成果物とみなすこと」です。
振り返り
ここまでの「アジャイルなマインドセット」を振り返ってみましょう。今回も含め、
- 小さく失敗すること
- チーム自身が開発プロセスを継続的に変えること
- ○○より○○ingが重要
- 要件・計画・見積・設計の無段階の階層性を認めること
- システムを中間成果物とみなすこと
です。どちらかというと、アジャイル界隈でより一般的な、賛同者が多いと思われる順に並べました。
つまり、今回が、一番賛同していただける人が少ないのでは、と思っています。
開発者のみなさん、自分の作ったシステムが「所詮一時的なもの」「すぐにでも壊して作り直すかもしれないもの」と言われることに耐えられますか? 特に請負開発をされている方には、「そんなことはない」「客は作ったシステムに対価を払っているんだ」と怒られそうです。
しかし、現状がどうであれ、アジャイル開発が「ビジネス価値」というものを前面に押し出した結果、この方向性は決まっているのでは、と考えています。
これまで、多くのソフトウェア開発プロセスが提唱され、その中には、何かしら反復的な要素を持った開発プロセスも多くあります。しかし、ビジネス側にまで踏み込んだソフトウェア開発手法は、アジャイルが初めてではないでしょうか(ビジネス側・業務側だけに特化した手法は他にもあります)。
そうやってビジネス側に踏み込んだ結果、システム(ソフトウェア)は、中間作成物になったのではないか、と考えます。
スクラムフレームワークに立ち戻る
ピンとこない、という方のために、基本中の基本、スクラムフレームワークに立ち戻ってみましょう。
みなさまご存じの通り、スクラムには3つの作成物がありますね。プロダクトバックログ、スプリントバックログ、インクリメントです。これらはすべて「中身が変動する、ダイナミックなもの」です。
スクラムを初めて学ぶ方には、このダイナミックさを理解していただくように説明します。
スプリントバックログが一番わかりやすいですね。スプリントプランニングで作り直し、スプリント内でもどんどん変わっていきます。
「ウォーターフォール脳」の方に、最初に乗り越えていただかないといけない考え方の転換は、プロダクトバックログの動的な性格です。ウォーターフォールが染みついている方は、どうしても、
- プロジェクトの最初にプロダクトバックログを作る
- 中の項目は優先順位の高いものから順に並べる
- 上位の項目から順番に消化していく
という、上から順に消し込まれていく以外は、変わらない(静的)リストを思い浮かべがちですが、開発中にも、プロダクトバックログはダイナミックに変化し続けます(増えたり、減ったり、優先順位が変わったり、詳細化されたり)。だからこそ、プロダクトオーナーはフルタイムの仕事なのですね。
問題は、インクリメント。名前(増加とか増分という意味です)からして、スプリントごとに増えていくイメージがあります。弊社でも、アジャイル入門の講座ではこんな図で説明をしています。
でも、本当は、このようになる可能性もあるのではないでしょうか。
これを見て、「え、毎回作り直すの、もったいない」と思ったそこのアナタ! じゃあ、スプリントごとに作り直すスプリントバックログは、なぜ「もったいない」と思わないのでしょうか。
そうです、スプリントバックログは「中間作成物」「スプリント内で開発を進めるための手段」だと思っているからですね。では、ビジネス価値を目的と考えると、ソフトウェアも「中間作成物」「単に手段」にならないでしょうか。
結び
まあ、実際のところ、「変化の激しいビジネス環境」と言われている現在でも、ここまで極端なことになることは、正直そうないとは思います。しかし、システム開発手法が「ビジネス価値」と言った途端、V字モデルがシステムを超えてビジネスに踏み出した(共通フレーム2013のV字モデルはこれです)途端、数多くの開発ドキュメントと共に、システムが「中間成果物」になることは、必然ではないか、そんなふうに考えています。
間違えていただきたくないのですが、「中間成果物だから軽く考えていい」と言っているわけではないのです。すべての職業人は、人が「手段」とするもののために、渾身の力をもって仕事をしています。同じようにシステム開発者も、システム開発に懸命に取り組んでいます。スプリントごとのインクリメントは、「中間」でありつつ、「現時点最新成果物」であり、「現在最大価値成果物」です。ただ、「このシステムの目的は何か」「目の前のコードのこの一行は何のために存在するのか」は、時には振り返ってみてはいかがでしょうか。
※転載元の情報は上記執筆時点の情報です。
上記執筆後に転載元の情報が修正されることがあります。