アジャイル開発は、常に変化し続けるビジネス環境や顧客の要求に対応できるよう、柔軟で継続的なソフトウェア開発を行う方法論です。プロジェクト管理の手法も従来とは異なるため、タスク管理やスケジュール管理のやり方を見直す必要があります。本記事では、アジャイル開発におけるプロジェクト管理の考え方を説明した上で、進捗を可視化し、生産性を向上する方法を紹介します。
目次
アジャイル開発とは
アジャイル開発の目標は、ビジネス価値の最大化です。顧客にとっての価値は何か、顧客が満足しているかを確認しながら、スピーディかつ継続的にソフトウェアを提供します。アジャイル開発の概念を具体化する手法には複数のアプローチがあり、その組織の文化や企業規模、開発方針によって合わせていく必要があります。
アジャイル開発宣言
2001年米国ユタ州に17名の技術者やプログラマーが集まり、ソフトウェア開発のそれぞれの主義や手法について議論しました。それをまとめたものが｢アジャイルソフトウェア開発宣言｣です。｢アジャイルマニフェスト｣と言われることもあります。そこには、彼らがソフトウェア開発を行ううえで重視している｢価値｣が書かれていました。その後、この価値観は世界中のソフトウェア開発者に支持され、｢アジャイルソフトウェア開発｣という名で世に広まりました。宣言は以下の通り。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
この宣言では、アジャイルソフトウェア開発の4つの価値｢プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする｣が示されています。
この宣言は、｢常に変化し続ける環境変化に適応しながら競争力を高めていくこと｣により価値を置くもので、ソフトウェア開発のみならず、ビジネスのあらゆる側面に必要なものです。
他の開発手法との比較
ソフトウェア開発手法を分類する視点には、｢適応的開発｣手法と｢計画重視｣手法があります。
適応的な開発手法では、現実世界で生じた変更にすばやく適応することに主眼を置きます。その一方で、長期的予測になるほど、予測の不確実性は大きくなります。計画重視の開発手法では、詳細な開発計画を立てることに主眼を置きます。その一方で、プロジェクト中に変更が生じると、すでに完了した作業の一部はやり直さなければならないこともあります。
アジャイルソフトウェア開発手法は、｢適応的開発｣手法から｢計画重視｣手法までの連続線上において、典型的な適応的開発手法に位置づけられます。一方、ウォーターフォール開発手法は典型的な計画重視手法に位置づけられます。そして、｢適応的開発｣手法と｢計画重視｣手法の中間に位置づけられるのが、反復型開発手法です。
反復型開発との比較
反復型開発の基本的考え方は、ソフトウェアシステムを徐々に開発していき、ソフトウェア開発者が過去の開発から学んだことを生かして、使用可能なシステムを段階的にリリースしていくというものです。反復ごとに設計が修正され、新たな機能が追加されていく開発です。
アジャイルソフトウェア開発手法の多くは、反復型開発手法と同様に、短い期間を単位として、リリース可能なソフトウェアを開発することを強調します。しかし、アジャイル開発ではリリースの期間単位が週単位と、月単位が一般的な反復型開発より短いことが多いです。その短い期間を実現するために、アジャイル開発手法では、高度に洗練された共同作業のもとで作業を行うことが強調されます。
ウォーターフォール開発との比較
従来のソフトウェア開発は、ウォーターフォール開発が主流でした。ウォーターフォール開発は、最初に全体の機能設計・計画を決定し、この計画に従って開発・実装していく手法です。ウォーターフォール開発手法は、数あるソフトウェア開発手法の中でも、最も計画重視であると位置づけられる手法です。機械製造や造船業、ソフトウェア開発などさまざまな開発に応用できる手法として、広く活用されています。
しかし、IT業界ではプロジェクトの初めにスコープを決定し、期間や費用の見積りを行い、確度の高い計画を立案することが困難という課題に長らく直面してきました。ウォーターフォール開発では、一連の工程が大規模に統合されます。この統合とテストの規模が大きいこが、プロジェクトが失敗する原因の一つとなることが多いのです。
対照的に、アジャイルソフトウェア開発では、1週間から数週間もしくは数か月という短い期間単位ごとに、完全に開発されたテスト済みの機能をリリースし、利用可能なシステムを早期に構築し、継続的に改良を行ってゆくことを強調しています。
アジャイル開発のメリット・デメリット
納期短縮を実現できるなどメリットが多く見えるアジャイル開発ですが、デメリットも理解した上で適切な開発手法を選択することが必要です。
メリット
対面のコミュニケーションによる意思疎通と、実際に動くソフトウェアを進行管理の尺度とすることで、作成される文書の量が減らせます。詳細な仕様や進行計画などの上流工程、文書作成の工数が削減されることから、従来の開発手法と比較して納期を短縮できます。
従来のウォーターフォール開発の場合には、最初に決定した設計・計画を重視するため、トラブルの発生箇所によっては戻る工数が大きく、時間やコストが膨大に膨らむ可能性がありました。しかし、アジャイル開発の場合は、小さな単位で計画から設計、実装、テストを繰り返しているため、テストで問題が発生しても手戻りが少なくなります。
また、計画段階で綿密な仕様を決めないため、開発途中でユーザーとコミュニケーションを取りながら仕様変更や機能追加に柔軟に対応でき、開発途中でも顧客のニーズを取り入れやすくなります。ユーザーのニーズに最大限応えることができ、高い満足度が得られます。
デメリット
詳細な仕様を決めずに着手するため、開発の方向性がブレやすいというデメリットがあります。顧客ニーズに応えて改善を繰り返し、追加・変更が重なって当初の計画から大幅に変わってしまうことが原因です。また、厳密な進行スケジュールを設定しないため、スケジュールや進捗具合が把握しにくくコントロールが難しくなります。チーム単位で｢開発～リリース｣の工程を反復するため、全体のスケジュールや進捗状況が把握できなくなり、納期に間に合わなくなるケースがあります。
どのような開発案件がアジャイル開発に向いているか
ここでは、どのような開発案件がアジャイル開発に向いているかを解説します。
アジャイル開発が向いているケース
開発途中で仕様の変更や追加が多発するシステムに向いています。特に、ゲームや新規サービスなどのWeb系でスピーディ・こまめに機能改善などをリリースするシステムに向いています。出来上がった部分を確認しつつ、それらと整合性をとりながら残りの要件を決めていき、最終的な完成の形へと持っていくことができるからです。
熟練した開発者が参加することも、アジャイル開発を進めるために重要になります。
ウォーターフォール開発が向いているケース
基幹系システムなど業務にクリティカルなシステムで、開発中に要件がほとんど変わらず、こまめなリリースが求められないシステムに向いています。
スクラム開発
ここでは、アジャイル開発の代表的な手法である｢スクラム｣を例に、アジャイル開発の流れを紹介します。
スプリント
スクラムでは、顧客からのフィードバックを頻繁に受けるため、反復的な開発プロセスを採用します。この反復の単位はスプリントと呼ばれ、1～4週間の期間が設定されます。スプリント期間内に開発できる機能を選択し、開発チームが実装を進め、スプリント終了時には製品をリリースします。
バックログ
製品へ追加するべき機能のリストがバックログです。開発サイクル全体を通じて、リストにある機能の優先順位を維持・管理します。各スプリントで実装するべき機能のリストは、スプリントバックログと呼ばれます。
デイリースクラム
開発チームが活動状況を確認するため、毎日同じ時間に短い時間のミーティングを行います。
｢昨日実施したこと｣｢今日やること｣｢進捗の妨げになっていること｣を各メンバーが発表し、問題解決の契機とします。
レトロスペクティブ
スプリント終了時には、その期間を振り返るミーティングを開催します。上手くいった点や上手くいかなかった点について話し合って、開発プロセスの改善につなげます。
スクラム開発で得られる効果
ウォーターフォール開発では、指示待ち開発体制になることが問題になりやすい点です。スクラム開発では、スピード感のあるプロジェクト運営のために、フラットな開発体制を構築するので、積極性を引き出し、チームの潜在能力を引き出す効果があります。
ウォーターフォール開発では、要件網羅の限界が問題になりやすい点です。スクラム開発では、ゴールを小さく分割設定し、繰り返し実施優先順に機能実装、効果検証しつつ優先順位を見直すことで、リリース時には要件が網羅される効果があります。
ウォーターフォール開発では、期間集中と属人的作業に偏ってしまうことが問題になりやすい点です。スクラム開発では、設計・実装などをペア作業することでノウハウを共有し、属人的作業の分散により、要員への負荷を平準化する効果があります。
アジャイル開発におけるプロジェクト管理
続いて、プロジェクト管理の観点からアジャイル型と、従来行われてきたウォーターフォール型の違いについて、スケジュールの立て方・プロジェクト管理のトレードオフ・コミュニケーションの観点から解説します。
スケジュールの立て方
ウォーターフォール型の開発では、要件定義・設計・開発・検証といった各局面が定義されます。手戻りが起こらないよう、上流工程で要件を確定するので、誰が何を実行するべきかが明確になるのが利点です。プロジェクト開発期間を通して要件が変化しない案件に向いています。
一方アジャイル型の開発では、実装するべき機能に優先順位を付けてバックログにまとめます。開発期間の最中に優先順位が変更されることを前提としており、各スプリントを始める時点で開発するべき範囲を決定するのが特徴と言えるでしょう。顧客や利害関係者からのフィードバックを受けながら、徐々に要件を明らかにしていく案件に適しています。
プロジェクト管理のトレードオフ
ウォーターフォール型では、上流工程で決定した要件の全てを実装します。そのため、不測の事態が生じて進捗が遅延した場合、人員追加・コスト超過してでも、納期を維持するよう努める必要があります。一方、アジャイル型では、スプリントの期間が固定されています。定められた期間で最大の顧客価値が生み出せるよう、重要な機能から優先順位をつけて実装を進める点が特徴です。
コミュニケーションの取り方
ウォーターフォール型では、計画主導・階層的な関係性があり、上流工程で決定された計画に沿うようプロジェクトが進みます。局面ごとに異なる人員が担当できるよう、属人化を避け、文書を通した情報の伝達が好まれます。顧客や利害関係者は、局面完了時などのマイルストーンのみにコミュニケーションをとる傾向があります。
アジャイル型では、開発チーム内、及び開発チームと顧客との間でのコミュニケーションが自律的に行われるような仕組みを設けます。開発サイクルを通じて、同じチームが継続して開発を担当するので、ノウハウが蓄積されていくのがメリットです。顧客や利害関係者は、各スプリントで継続的に関与していきます。
PMBOKから見るプロジェクト管理の全体像
グローバルスタンダードであるプロジェクト管理手法の「PMBOK」では、ソフトウェアのアジャイル開発に対応するために考慮すべきポイントが解説されています。ここでは、その概要を紹介します
統合マネジメント
統合マネジメントでは、プロジェクト全体を管理するプロセスを定義します。特に、発生した変更に対してどのように対応するのか、バックログをいかに整理するかを決めておくことが重要です。
スコープ管理
バックログを定義し、スプリントごとに作業範囲を決定する計画を策定すると良いでしょう。
スケジュール管理
スクラムボードを活用し、未着手・仕掛かり中・完了といった進捗ごとにタスクを管理しましょう。また、各スプリントでどの程度のタスクが消化できているかを可視化するバーンダウンチャートが用いられる場合もあります。
コスト管理
アジャイル開発においても、プロジェクト管理ツールなどを用いて工数の見積もりと実績を管理しましょう。
品質管理
品質を維持するための活動を定義します。テストの自動化を積極的に進め、スプリントごとに効率的な品質保証活動を行うと良いでしょう。
要員管理
作業計画に基づきチームを編成し、計画と実績を管理します。また、スキル評価を行い、作業に必要なスキルを有した要員が確保できるよう、確認します。
コミュニケーション管理
デイリースクラムやレトロスペクティブを通じて、チーム内外のコミュニケーションを促進しましょう。
リスク管理
顧客価値の実現や、アーキテクチャーの選定といったリスクを洗い出し、継続的な評価と共に、必要なアクションをとりましょう。
調達管理
協力会社にプロジェクト作業を依頼している場合、そのスキル管理・要員管理を行いましょう。
ステークホルダー管理
顧客や自社の上層部を含めた全ての利害関係者が継続的に関与するよう促しましょう。
アジャイル開発における工数見積もり
アジャイル開発では、高い精度で見積もりができるよう、スプリントごとに計画を立てます。計画との乖離が許容されにくいウォーターフォールと異なり、見積もりに時間をかけ過ぎず、十分な精度を出せるよう心がけます。見積もりには、以下のポイントがあります。ここでは、アジャイル開発における工数見積もりのポイントを紹介します。
ストーリーポイントを各機能に割り当て、相対的な作業の大きさを見積もる
バックログにある機能のそれぞれに割り当てられた工数はストーリーポイントと呼ばれます。厳密な作業日時を計画するよりも、相対的な作業の大きさを数値化する方法が採用されます。スプリント計画時には、スプリント期間内に完了できる分のストーリーポイントのみを作業範囲に含めるようにします。
各スプリントで見積もりの誤差を洗い出し、修正する
スプリント完了時に、計画通りに作業が終わらなければ、当初のストーリーポイント見積もりの精度に問題があったことが推測されます。誤差の要因として考えられるのは、楽観的すぎる・悲観的すぎる、あるいは、想定以上に機能が複雑で実装のリスクが大きいといった要素です。
バーンダウンチャートで、予定と実績を可視化する
バーンダウンチャートはプロジェクトの進捗状況を可視化する図で、縦軸にストーリーポイントを使った作業量、横軸に時間を割り当てます。各スプリントでどの程度の作業が進んだかが理解しやすくなります。
スプリントごとに完了できるタスク量で生産性を評価する
スプリントごとに完了できるタスク量を継続的に計測していると、作業が予定よりも速い場合や遅い場合が検知可能になります。作業が遅れている場合、作業の妨げになっている要因がないか確認する必要があります。
アジャイル開発を円滑化するITツールの活用
現場の開発チームにとっては、スクラムボードやバーンダウンチャートによる管理が便利です。一方で、プロジェクト全体を見通すには、ガントチャートで機能単位の進捗を管理するのが望ましいとされます。機能ごとにおおよその工数を計画しておき、その作業に費やした工数を実績として入力していくと、計画と実績の比較が可能です。
近年は、受託開発でもアジャイル開発が採用されるケースがあります。受託開発においては、スプリントごとの見積もりだけでは契約を交わすのが難しいため、プロジェクト全体での工数見積もりを行い、スコープや契約金額の決定を下す必要があります。バックログの機能単位で工数を見積もった上で、誰がいつ何の作業を担当するのかを可視化するガントチャートへ反映させます。
開発サイクルを通し、開発チームが作業に費やした時間をシステムに入力し、実績工数から作業の進捗を管理することが推奨されます。エクセルで工数管理を行う企業も見受けられますが、バージョン管理や変更管理が難しいため、チームで最新の情報を閲覧・編集できるオンラインツールの利用が望ましいでしょう。
まとめ
アジャイル開発では、スクラムやカンバンなどの手法により、顧客価値を最大化することを目的としています。従来のウォーターフォール開発とは異なる管理手法を採用し、変化する要件へ柔軟に対応することが狙いと言えるでしょう。
アジャイル開発におけるプロジェクト管理のポイントは、ウォーターフォール型の開発と同じく、適切なプロジェクト管理ツールを導入し、行うべきタスクの実行を効率化しながらプロジェクトをコントロールすることです。そのためには、近年主流となっているクラウド型のプロジェクト管理ツールを活用すると良いでしょう。
