アジャイルソフトウェア開発と聞くと、顧客への迅速なサービス提供を重視する手法を連想する人が多いことでしょう。

今回はそんなアジャイル開発の中でも、少人数での集中的なプログラム開発手法に特化したスクラム開発について注目。

従来のアジャイル開発との違いなどについてチェックしていきましょう。


スクラム開発とは?

little girl, computer, portable


少人数の開発チーム短期的に行うシステム開発のための手法を指す言葉です。

アジャイルソフトウェア開発の手法は、短期間でのシステム開発を実現することが目的となります。

その中でもスクラム開発は、開発チームが着実に前進する仕組みをもつ開発手法です。

その際開発チームは、参加しているチーム全体で確実に情報を共有するために、バックログ(Backlog)というリスト群を定義。

作業の遅れや変更・作成の漏れが起きないように、全体の進捗状況を誰もが把握しやすい管理体制の構築を目指します。

スクラム開発の際に作成されるバックログは、大きく分けて二つです。

一つはプロダクト・バックログ

もう一つはスプリント・バックログです。

一つずつチェックしていきましょう。


プロダクト・バックログ

プロダクト・バックログは、直近での改善点について判断しなければならない時に重要な役割を果たします。

開発中のシステムで優先される機能や技術的な改善要求、現状で解決することが求められる課題や問題点について明記するものです。


スプリント・バックログ

スプリント・バックログは、顧客から求められている要求事項や、現在のシステム課題への解決策として計画された作業全般を列挙。

チームとして対応することで、開発されるプロダクトすべてをタスク管理することができるようになります。

また、チームが定めた期間をスプリントと呼ばれる単位で表します。

その際、情報を提示する手段を事前に共通化し、情報の重要性を共有認識できるようにチームの意識を方向付けておきましょう。

より効果的にスプリント・バックログの恩恵を受けることができるようになります。

例えば、多くの企業では作業に従事する前にミーティングを実施する時間帯が設けられていることが多いのではないでしょうか。

そのようなミーティングでは、様々な情報が発表されるものです。

しかし情報が多すぎると、結局何が重要な情報だったのかが分かりにくくなってしまいます。

そこで限られた時間で、必ずチーム全員に伝えなければならない情報は何かをスプリント・バックログと照らし合わせるのです。

短時間であっても、スムーズなコミュニケーションを実現することができるようになります。


スクラム開発の特徴

startup, meeting, brainstorming


スクラム開発において、もっとも重要な記録文書はバックログです。

開発チーム全体で、プロダクトの進捗状況を各自が把握するために必要不可欠になります。

加えてスクラム開発は、システム開発途中での顧客からのシステムの変更の要望に対して柔軟に対応でき得ることです。

これはアジャイルソフトウェア開発の特徴の一つでもあります。

以前のシステム開発は、事前に決定した設計開発を重視されていました。

所定の工数を経てから次工程への引き渡し後になり、その時初めてシステムテストが行われるのです。

その場合、随分後になってから顧客が現状のシステムの問題点を知り得ることになります。

当然顧客が得られたシステムテストの結果に満足できなかった場合、テスト後に設計開発の変更を要望していました。

しかし、既にプロダクトとして完成してしまっている場合、再設計開発が困難になってしまうのです。

このようなことが起こらないためには、随時顧客からの変更の要望に応える必要がありました。

それを考えた先駆者たちによって、スクラム開発はアジャイルソフトウェア開発の一つとして生み出されたのです。


アジャイル開発とは

typing, computer, desk


冒頭にて少し触れましたが、スクラム開発はアジャイルソフトウェア開発の一つです。

英語のagileとは、敏捷や機敏、軽快・素早い動きなどを意味します。

そこから転じて、アジャイル開発(アジャイルソフトウェア開発)はソフトウェアを迅速に開発する手法です。

依頼から提供までを素早く顧客に届ける、ソフトウェアの開発用語として定着しました。

<関連記事>
アジャイル開発とは?要件定義やメリットを徹底解説!他の開発手段との違いは?失敗事例とその理由から正しい対策方法もご紹介!


アジャイル開発が目指す4つの思想性

startup, business, people


アジャイル開発では、次の4点に特に高い価値を見出しています。


プロセスやツールよりも個人と対話を

ネットワークの普及に伴い、距離と時間がそれまでよりもはるかに縮み始めた頃に、個人との対話の重要性を説いています。

その意味するところは多岐に渡りますが、対話は一方通行では実現できません。

双方向に意見を通わせて、はじめて理想的なシステムの開発が適うと考えることができます。


包括的なドキュメントよりも動くソフトウェアを

あれもこれも統括すると、状況の変化に対応できなくなる可能性があります。

そうなると、システムの完成が困難になってしまうのです。

チームの力を傾けるべきであるという、アジャイルソフトウェア開発の願いが込められている文章といえるでしょう。


契約交渉よりも顧客との協調を

これは行動規範に等しい考え方です。ソフトウェア開発の多くは、ビジネスとは切っても切れない関係にあります。

そんな環境の中で顧客の満足度を高めることで、継続可能な価値を新たに生み出すことを目標としている言葉です。


計画に従うことよりも変化への対応を

顧客満足を尊重する姿勢は、常に新しい価値観と向き合う勇気を持つことを求めているといえます。

その行動は、挑戦といい換えることもできるでしょう。

社会の変化に対応して、ソフトウェアは常に新しい価値観を提示することができるという言葉です。


従来のアジャイル開発とスクラム開発の違い

startup, meeting, brainstorming


アジャイル開発はその目的に応じて、いくつかの開発手法に分類することができます。

アジャイルソフトウェア開発に属する開発手法を紹介しましょう。


エクストリーム・プログラミング

エクストリーム・プログラミングは、略してXPと表記されることのあるシステム開発手法です。

スクラム開発との大きな違いは、2人1組でプログラミングを行うペアプログラミングなどです。

少人数での開発チーム主体の運営に適していることです。

開発者の業務による負担が過剰にならないように1週間の労働時間を40時間内に制限するなどチーム全員の満足度を高くすることが求められます。

また参加するプログラマーの共通理解を明確化するために、そのルールに全員が従うことを確認するプロセスや、ソースコードの共同所有も行います。

チーム全体でプロダクトの品質に関わりを持ち、意識の向上を促すのです。


ユーザー機能駆動開発

ユーザー機能駆動開発は、略してFDDと表記されることのあるシステム開発手法。

5つに分類できる活動を通し、顧客が重要と考えている機能を実現することを目的としています。

開発を行う際には、可能な限り機能を細分化し、計画を策定するためのfeatureリストが作られるのが特徴です。

featureリストに基づく開発計画を立案する過程で、責任者となるプログラム・オーナー(担当責任者)が決定されます。

スクラム開発との違いは、各feature毎にそのタスクを担当するチームが結成されることと、責任者が明確に定められることです。

責任者ある立場の者が定められ、その責任を果たすための権限が付与されます。

一貫性や性能を保ちながら、顧客の要求を適切に実現することができると考えられている点です。


スクラム開発で失敗しないためのポイント

student, typing, keyboard


スクラム開発には、失敗しないためのポイントがいくつか存在します。

その多くは、プロジェクトを推進する開発チームがセルフマネジメントを目指し、実践する内容を判断しなければなりません。


少数のチームで活動する

スクラム開発ではチームが一団となって取り組む目標を定めて、ゴールを目指します。

チームの人数は、3名から10名程度が妥当です。

2名の参加で結成されたチームでは、どちらかの意見が優先されてしまうことになります。

逆にあまりに多くのメンバーでチームを結成すると、ミーティングの度に費やされる時間が増加する傾向にあるからです。

スクラム開発は短期間で集中的にシステム開発を行い、顧客へ迅速にプロダクトを提供しなければなりません。

実現するためのチームの人数は守るようにしましょう。


スクラム開発が求める価値の基準を理解する

startup, start-up, notebooks


スクラム開発では、チームが一団となって取り組む目標を定めています。

ミーティングの場では、プロダクト・オーナーを任命することが可能です。

プロダクト・オーナーはプロダクト・バックログの作成と、項目の優先順位の判断に最終責任を有する役割を持つ責任者となります。

また、開発に参加するチームのメンバー全員はスクラム開発が求める次の5つの価値基準について理解し、実践することが必要です。

  • 確約(Commitment):チーム各員、チームが目指すゴールの実現を確約しなければならない。
  • 勇気(Courage):チーム各員が正しいことを成し遂げるための勇気を持って課題に取り組まなければならない。
  • 集中(Focus):各員がチームが定めたスプリントの作業チームが目指すゴールの実現に向けて集中しなければならない。
  • 公開(Openness):チームの各員が仕事や課題、進捗作業を公開することに合意しなければならない。
  • 尊敬(Respect):お互いを尊敬する気持ちを持たなければならない。

それぞれがスクラム開発の目指すチーム全員で果たすべき役割を円滑に行うために守る必要があります。

この5つは開発が円滑に進むように、チームが互いを手助けできる意識を広げるための言葉だということです。


円満なコミュニケーション

スクラム開発は、ゴールを目指してチーム全員が協力して前へと進む開発手法となります。

そのため、多角的な視野から導き出されるチーム・プレイが重要です。

一人ではないからこそできる解決の糸口を発見するためには、自分の課題をチーム内で共有する必要があります。

それが公開の価値です。

そのためには自分の威厳よりも、チームのゴールを優先する勇気と、チームの力を信じなければなりません。

ミーティングの度に随時課題を共有することで、問題意識の共有と尊敬の意識が高まり、極めて円満なコミュニケーションができるようになります。


プロダクト・オーナーの役割

プロダクト・オーナーはプロダクト・バックログの作成と、項目の優先順位の判断に最終責任を有する役割を持つ責任者です。

それ以外の権限は持ち合わせておらず、いわゆるところのプロジェクト・リーダーとは異なります。

プロダクト・オーナーは、合議体の議事進行の上で必要となる次のような情報を把握し、チームに公開できるように準備します。

  • 開発チームが目指すプロダクト(成果物)の価値について
  • 現在のチームが抱える課題の内容について
  • 現在のチームのメンバーが持つ固有の技術、知識についての情報
  • 顧客から要望されている変更の内容について
  • 新たな予算額の提示や、その条件、予算に関わる要求事項について

プロダクト・オーナーは、議事の進行に関わる権限を持ちますが、それは情報を整理してチームに説明するためのものです。

プロダクト・オーナーによって整理された情報からどのような結論を導き出すのかを決めるのは、チームのメンバーとなります。

プロダクト・オーナーはチームに対して、あれこれと指示を出す存在ではありません。

チームの成果物に必要な要素リストアップし、タスクの優先順位を決める。これがプロダクト・オーナーの務めです。


スクラムマスターの役割

network, round, project


これに対してチームが有効に機能し続けるために、もう一つの重要な役割を担うのがスクラムマスターです。

スクラムマスターはチームが抱える問題点を洗い出し、リスト化する存在となります。

スクラムマスターが気づいた課題はその人の手でリスト化され、次回のミーティングでメンバー全員に公開するのです。

スクラムマスターが見つけた課題や現在の問題点は、誰かの責任を追及するためのものではありません。

現在のチーム全体が直面する課題や危機を指します。

無論、解決策を考えるのはチームメンバー全員です。

スクラム開発は情報の共有というコミュニケーションを通して、よりチームとしての活躍の場を広げるための成長を促すことができます。


スクラム開発向けの管理ツールも紹介

student, typing, keyboard


プロジェクト管理ツールは数多くありますが、中でもスクラム開発に向いた分かりやすいオススメツールを紹介しましょう。

様々な環境から遠隔地からの参加を必要する場合もあるため、チャット機能を設定できる管理ツールも紹介しています。


Backlog

「Backlogは日本製のプロジェクト管理ツールです。

その名前の通り、参加するメンバー間での情報共有に強い意識を向けたデザインとなっています。

英字の表記ツールが苦手な人や初めてプロジェクト管理に挑戦するという人にオススメです。

抵抗感なく使い始めることができるように配置、配色されたレイアウトは、直感的な操作を可能にしています。

特に印象的な機能が、視覚効果の高いガントチャートやバーンダウンチャートの作成機能です。

癖がないので比較的使いやすいツールといえるでしょう。

<関連記事>
Backlogの機能や使い方を徹底解説!ログインやAPIの使用方法は?JIRAの料金や特徴と比較。導入が進む理由にも迫る


JIRA

「JIRAは、オーストラリア製のプロジェクト管理ツールです。外国製ですが日本語化されていて、操作に困る心配はありません。

ただししっかりとした作り込みがなされており、重厚という言葉が似合います。

少し入力項目が多く、慣れない内は煩わしさを感じることもあるかもしれません。

このJIRAは、「商用顧客に対して、すべてのソースコードを開発者のソースライセンスのもとに使用できる」という特徴を持っています。

また、他の管理ツールに比べるととても安価です。

そのため、世界でもっとも利用されているアジャイル開発のための管理ツールといわれています。

更に同社の製品である「HipChat」や、「Slack」などのチャットツールと連携することが可能です。

遠隔地であってもチャットを通して、互いのアイディアを出し合うことができるようになります。

その後、チャットの記録を公開することもできるのです。

<関連記事>
JIRAの特徴や機能・使い方を徹底解説!プロジェクトやタスク管理のガントチャート作成方法とは?アプリやフリープランも紹介


PivotalTracker

『PivotalTracker』は、アメリカ製のプロジェクト管理ツール。

主要なページは日本語化されており、操作も問題なく日本語版として行うことができます。

認識性に重点が置かれた柔らかなデザインと、簡単な操作で実現できる多機能性が秀逸な管理ツールです。

多くのニーズに応えるための機能が豊富。図式化も申し分なく、画面内の情報を綺麗に整理してくれます。

事前にチーム内で相談を行い、どこまでの機能を必要としているのかを確認した上で導入を検討すると良いかもしれません。

この「PivotalTracker」には、いくつかの料金プランがありますが、30日間無料トライアルもあります。


アジャイル開発の理念を応用する

student, typing, keyboard


スクラム開発を通してアジャイル開発の理念は、システム開発以外の問題解決のための手法としても応用することができます。

特に少数で事業を展開する組織にとっては、スプリントやバックログを用いた工数管理は事業全体を見渡す際に、とても有効です。

管理ツールもありますが極めて少人数である場合には、必ずしもパソコンやスマートフォンを使う必要はないのかもしれません。

例えば、ホワイトボードにマグネットを用意し、少し大きめの付箋を貼り付けて、次の3つを書き出してみましょう。

  • 今日行うべきタスク
  • 昨日完了したタスク
  • 現在課題となっている事柄

このわずかな作業であっても、直近の進捗状況が明確に可視化されることになります。

可視化された情報が共有されることで、それまで不鮮明だった工数の計算と納期の予測精度が飛躍的に高まる効果を期待できます。


アジャイル開発以外のシステム開発手法

project management, business planning, project manager


アジャイル開発以外の主だったシステム開発の手法を紹介します。

アジャイル開発手法が生まれるに至った流れを感じ取ることができると思います。


ウォーターフォール・モデル

ウォーターフォール・モデル(Waterfall Model)は、をイメージして名付けられたと言われるシステム開発手法です。

どのようなシステムを開発すべきなのかを事前に決定し、その後の各プロセスを明確化します。

コミュニケーションの頻度を下げ、開発作業に集中できるように配慮された仕組みです。

反面、開発途中での変更に対しては柔軟な対応をとることが難しく、当時から大規模システム開発向きの開発手法であると考えられてきました。

また、いくつかの作業工程を経た後に、前工程に問題が残されていないことを確実にする方法に乏しいのも注意点です。

それでも、ウォーターフォール・モデルが採用されるのは各工程の作業と順番が以下のように明示されているからです。

  • 基本設計
  • 詳細設計
  • プログラミング
  • システムテスト
  • ユーザーテスト

納期に対しての進捗状況の把握が比較的容易であることが理由として挙げられます。

ウォーターフォール・モデルについては、以下の記事で詳しく解説しています。

ウォーターフォール・モデルを徹底解説!メリットと好まれるケース、アジャイル・モデルとの違いとは?時代遅れといわれる理由も紹介


プロトタイプ・モデル

busy, home, desk


プロトタイプ・モデル(Prot-Type Model)は、システム開発の初期段階から試作品を平行作業で作成します。

動作の検証を行いつつ再設計開発を行う手法です。

顧客の要求事項への柔軟な対応が必要な場合は、開発初期から最低限度での機能やインターフェイスでの動作テストを行うことが可能。

必要とされる要素を確認しながらの設計開発が求められる場合に、有効な開発手法です。

実質的に設計の変更が生じる場合でも、顧客に対して試作品を提示しながら設計開発を進めます。

顧客とコミュニケーションをしやすいのが利点です。

一方テストの結果で大幅な変更が求められた場合、納期が不透明になりやすい傾向があります。


スパイラル・モデル

スパイラル・モデル(Spiral Model)はシステム開発を必要とされている機能毎に分けて、プロダクト全体を開発するソフトウェア開発手法です。

  • 検討
  • 設計
  • 製造
  • テスト
  • 顧客への確認

上記の5ステップを繰り返します。

どちらかというとプロトタイプ・モデルに近い性質を有している手法です。

最初に完成したプロダクトは上記のプロセスを再度繰り返すことで品質を向上させ、より高い顧客満足度の実現を目指します。

結果として、スパイラルを回して反復を繰り返せば繰り返すほど、完成度は高まるでしょう。

ただしどの水準までの設計開発を目標として定めるのかによっては、予算面が膨らむことも考えられます。

そのためコスト・納期の両面での管理が重要となるシステム開発手法です。

スパイラル・モデルについては、以下の記事で詳しく解説しています。

スパイラルモデルとは?アジャイル開発など他のモデルとの違いを確認し解説します!導入におけるメリットとは?


まとめ

home office, workstation, office


スクラム開発は、仕様の変更を含む環境の変化を受け入れた上で迅速なシステム開発を可能にしてくれます。

繰り返し参加することで、技術や手順に加えて問題解決のために自ら考えることのできる活動的なチームの成長を促していることになる訳です。

コミュニケーションを通じて、チーム全体で改善と問題解決しながら素早く高品質なシステムを開発しましょう。