アジャイル開発には主に手法として3つのパターンがあるため、開発をはじめとした作業を効率の良さを大事にして進めるためには、それぞれの特徴をよく理解することが重要と考えられます。
そして今回解説していくスクラムは、チームマネージメントに重きを置いたフレームワークとして知られます。
本記事では、アジャイル開発におけるスクラムについて詳しいことをひも解いていきます。メリットとデメリット、そしてチームの成り立ちなどをチェックして、どのようなパターンで取り入れるべきかを決めていきましょう。
アジャイル開発とは
アジャイル開発は短いスパンでのローンチを目指して取り入られている、ここのところ注目度の高い開発のやり方の一種です。これまでによく見られた開発の進め方と比べると、短い期間の中で設計からテストまでのプロセスを幾重にも渡って重ねるという点において優れているため、「中盤でスペックなどが変わることにも柔軟に対応したうえで価値を高めていけるやり方・考え方」として知られます。
これまでの開発現場では、細かくやるべきことを分けてタスクを管理し、必要に応じて分業化も行うかたちのウォーターフォールモデルがよく採用されてきました。
しかし近年は、仕様や規格の変化に強い開発のあり方がソフトウェア開発の場においても重要視される傾向になり、それに伴ってソフトウェアは時代のスタイルに応じてどんどん変化していると考えられます。
昔からよく取り入れられてきた考え方であるウォーターフォールモデルは、もともと全体図を把握したうえで細かく工程を分けているという特性から、求められるスペックが変わった場合にはなかなか融通が利きません。
一方でこれに対してアジャイル開発は、変わることにも臨機応変に対応することが可能です。タイトな納期でローンチできるというポイントも、競合に勝っていくという面で見れば非常に魅力的です。したがって、以前よく見られたウォーターフォールモデルよりもここ何年かの間では、自由度の高いアジャイル開発が求められるようになったのです。
3つの開発手法について
より細分化すると3つのパターンが、同じアジャイル開発でもとられるようになっています。
- エクストリームプログラミング（XP）…仕様変更に柔軟に対応
- スクラム…主にチームワークに重きを置いた枠組み。逐一確認しながら進行を管理
- ユーザー機能駆動開発（FDD）…ユーザー目線での機能価値に重きを置く考え
このようにアジャイル開発は3つに分類することができます。
エクストリームプログラミングでは仕様が変わった際にも途中で柔軟に対応できるというメリットがあるため、正確な工程や綿密なプランに縛られないのが大きな特徴となっています。しかしその分エクストリームプログラミングを行う場合、チーム全体で高い水準の技術力や知識、固定観念に縛られない総合的な知見が求められる傾向にあります。開発プロジェクトの内容の達成難易度も上がりやすくなります。
2つ目のスクラムは、もっとも採用されているメインのやり方に該当します。そのほかのやり方と比較するとよりチームワークを重視する傾向にあり、メンバー同士で逐一確認しながら進行を管理するため、丁寧な進め方でローンチまで持っていくのが特徴です。
しかしよりチームワークを大事にするやり方だからこそ、「スクラムマスター（≒プロジェクトリーダー）のリーダーとしての手腕次第で、進捗の良し悪しが左右されやすい」のも事実です。スクラムマスターに負担が偏りやすいという難点もあります。
そして最後のFDDとも呼ばれるユーザー機能駆動開発は、原則としてユーザー目線であることに重きを置いたになっており、顧客がもっとも望む機能を効率的に提供できるようになっています。
スクラムとは、アジャイル開発に必要なフレームワーク
中心的な手法としてよく用いられるフレームワークであるスクラムについて、ここからは解説していきます。
このフレームワークには主に以下のようなメリットとデメリットがあると考えられます。
【メリット】
- チームワーク重視の開発なので丁寧に確認しながら進められる
- プロジェクトの進行が悪くローンチできないという問題を避けられる
- 短い期間で企画からテストまでの行程を重ねるため品質が上がりやすい
- 優先度の高い機能から開発するため必要最低限の機能がそろった高品質なプロダクトのローンチができる
【デメリット】
- 協力体制がしっかりと整わないと成立しないことがある
- 柔軟な動きが求められるため全体の状況が把握しづらい
- スクラムマスターにチーム管理の負担が集中しやすい
このように利点と難点はそれぞれあるため、取り入れる際には本当に適しているのか慎重に判断する必要があります。
続いては、スクラム開発に見られるバックログやタスクボードの概要をわかりやすく整理していきましょう。
バックログについて
スクラム開発について知るためにとても大切な要素であるバックログとは、作業の計画やチームにおける待ち行列などを指します。そしてスクラムにはプロダクトバックログ、スプリントバックログという2つのバックログが存在します。
前者はユーザー目線での優先度の高い機能や価値を記述したもの、後者は平たくいうとタスクリストを指し、「ローンチできるまでに何をどのくらいの期間で行うのか」という予定をまとめたものです。スクラム開発ではこの2つのバックログで作業を管理していきます。
タスクボードについて
スクラム開発ではタスクボードでメンバーの作業や進捗状況を互いに確認・把握していきます。ToDo、InProgress、Doneの3種の領域に分けて管理しますが、上で解説してきたバックログを付箋など用いて活用されます。
タスクボードにおいて壁を使うことで作っていき、それぞれのタスクをふせんに書いて、3つの領域の中で進捗状況に応じて動かしていくのがポイントです。
スクラムと構成チーム
スクラム開発はチームワークに重きを置いた開発の手法となっており、
- プロダクトオーナー
- スクラムマスター
- 開発メンバー
といったように主に3つの役割を当てられるのが特徴です。チーム全体の人数は3～10人ほどがちょうどよいとされています。ではここからは、それぞれのロール（役割）について特徴を解説していきます。
プロダクトオーナー
開発するプロダクトの責任者のポジションになります。プロダクトの価値はどのように最大化されるのかという点を、チームによって提案・開発された価値を基に検討していきます。また、プロダクトバックログでどの機能に優先度を高く設定するか決定するのにも大きくかかわります。
スクラムマスター
チーム全体の総合的な管理を担当する役割です。開発の進捗状況とともにチーム全体を統括する立場なのでリーダーシップがスキルとして求められます。作業遅延が見られるようであれば、その要因を洗い出す作業を担当します。より広い視野で行動できる知見が必要となるため、開発に関してあらゆる経験を持っているメンバーが適任と言えるでしょう。
開発メンバー
選抜された技術者たちは、コーディングやテスト、運用などを担当するため幅広い作業を臨機応変に行っていきます。もちろん設計も担当するため、ある程度高い水準のスキルを持っている人が多いと進捗状況はより良くなります。
まとめ
アジャイル開発におけるスクラムは、チームでの動きをより重視したかたちの枠組みになるため、協力体制ゆえのメリットとデメリットがあるのが特徴です。しかし現在のメインとも言えるアジャイル開発の中では、スクラムは中心的な枠組みにあたるため、理解を深めることは忘れないでおきたいところです。メリットやデメリット、チームの構成などを理解し、手法として取り入れるべきかじっくり検討を進めていきましょう。
Microsoftが提供するAzureは、チームでの作業進捗管理やデータ共有を、クラウド上でスムーズに実現します。ビジネス環境の効率化を図る際には、Azureの導入を積極的に検討していきましょう。
