このように複数の開発手法がある中で、実際にアジャイルを選択して開発を行うのはどのようなプロジェクトになるのでしょうか? 弊社ではプロジェクトに以下のような特徴がある場合は、アジャイルを選択することが多いです。
クライアントがチームの一員となってくれるような場合は、アジャイル開発を選択することが望ましいかと思います。
クライアントがチームの一員ということは一見すると推進力が上がるだけのように見えますが、共に進めていくということは、要件や仕様などを共に考えるということで、それはつまり要件や仕様が移り変わっていくことになります。
このような場合、それを吸収できつつ、プロジェクトの推進力を生かせるアジャイルは非常に有効な手法となります。
プロジェクトを進めていく中で、ビジネス要件などから優先順位が変更になる可能性がある場合は、イテレーションの境目で優先度の変更ができるアジャイルを選択します。
また「クライアントのビジネスの優先度を考える」ということは、「開発メンバーがクライアントのビジネスを共に考える」とも言い換えることができます。
クライアントに協力してもらうだけでなく、開発メンバーもクライアントに協力する体制を構築することで、より一層チーム力が上がるように思います。
プロジェクト全体の8割程度の要件が決まっているが、残りの2割が決まっていないような場合は、イテレーション単位にクライアントにアプリケーションを届けられるアジャイルは向いています。
クライアントは実際に動作するアプリケーションを確認しながら、決まっていなかった2割の要件を検討・確定し、以降のイテレーションで最終形へと仕上げていきます。
いくつかの例を挙げましたが、ここで重要なのは全てのプロジェクトでアジャイルが答えになるわけではないということです。その時のプロジェクトの内容・難易度、クライアントの思い、メンバーの人数・経験から正しい開発手法を選択することが、プロジェクトを成功に導く第一歩といえるかもしれません。
ここからは、数あるアジャイル開発手法の中でも、弊社で実践している2つの開発手法を紹介します。
アジャイルの開発手法はさまざまなものが存在します。ここでは代表的な開発手法の1つであるスクラムに焦点を当てて解説します。
スクラムとはアジャイル開発を行うためのフレームワークの1つで、主にチーム開発に主眼をおいた枠組みです。
スクラムではいくつかの役割が存在しますが、全ての役割、全てのメンバーで共通し、「自分のタスク」ではなく「チームのタスク」として推進することが重要となります。
プロジェクト管理者であり、プロジェクトに対して責任を持つ役割です。クライアントがプロジェクトオーナーとなるケースもあります。
プロダクトオーナーと兼任しないことを前提としスクラムでの進行が円滑に進むように推進する役割です。
動作するプロダクトを開発するメンバーです。チームは多くとも10人未満で構成されることが望ましいです。
次に、スクラムでのプロジェクトの進め方について記載します。
アジャイルでいうところのイテレーションになります。
情報共有のために毎日実施します。共有する内容は、昨日の実績、今日の予定、障害(不安に思うこと)の3点となります。
スプリントで仕上がったアプリケーションの確認を行います。仕様漏れ、認識ずれなどがあれば、以降のスプリントで吸収していきます。
スプリントレビューの結果を基に振り返りを行います(※前章参考)。
プロダクトオーナーがクライアントの場合でも、スプリントレビューや振り返りなどにクライアントに積極的に参加してもらうことが望ましいです。クライアント、ベンダーという区分けではなく、一つの「もの」を作るチームとして一体になることがプロジェクト成功の秘訣(ひけつ)につながるかと思います。
※参照
リーンは具体的な実践手順ではなく、考え方のフレームワークです。もともと製造業の中で、特にトヨタ生産方式をはじめとした考え方(リーン思考)をアプリケーション開発に応用したアジャイル開発手法です。
原則1:ムダをなくす
原則2:品質を作り込む
原則3:知識を作り出す
原則4:決定を遅らせる
原則5:速く提供する
原則6:人を尊重する
原則7:全体を最適化する
弊社ではウォーターフォールと併用して用い、「ムダをなくす」「決定を遅らせる」「速く提供する」の3点を意識することで大規模プロジェクトに成功した実績があります。
※参照
さて、次回はアジャイル開発における理想と現実についてお話しします。アジャイルを利用した際の理想と現実や、他の開発手法との融合など、実際に現場で起きた苦労話などを交えながらお話ししますので、お楽しみに。
Copyright © ITmedia, Inc. All Rights Reserved.