多くの企業で採用され始めているスクラム開発。ITに詳しくなくても、名前だけは何となく聞いたことがあるという方も多いのではないでしょうか。注目を集めているこのスクラム開発とは一体どんなものなのか、活用することで生じるメリットやデメリットの紹介だけでなく、スクラム開発のプロセスやツール、失敗例や成功例までベトナムオフショア開発のMattockが広く解説いたします。
スクラム開発とは
スクラム開発とは、「アジャイル開発」の手法の一つです。コミュニケーションを主体とした開発方法で、開発メンバーのチームワークを重視することが特徴です。プロジェクトの生産性と品質を高めるためには、開発チームのコミュニケーションを密にとることが必要です。また、スクラム開発はアジャイル開発の中でも特に短い期間で開発工程を区切って行われます。こうした短い期間をスプリントと呼び、多くは1～4週間単位で組まれることが普通です。このスプリントは後程詳しくご説明いたします。
スクラム開発は、基本的に「テスト駆動開発」や「継続的インテグレーション」など、他の開発方法と組み合わせて行います。スクラム開発はソフトウェア開発のために考案されましたが、実はそこに技術的な側面は含んでおらず、プロジェクトを進めるためのフレームワークという位置づけのためというのが大きな理由となっています。まとめると、スクラム開発とは「短期間で少人数の開発チームが協力し合いながら行う開発方法」となります。
アジャイル開発って？
そもそもアジャイル開発とは一体どんなものなのでしょうか。ソフトウェアの開発では、「ウォーターフォール開発」と「アジャイル開発」に分類されます。このアジャイル開発は2000年ごろから採用する企業が増加してきました。少人数制の開発チームが協力し合いながら業務を進めていきます。
大きな特徴として、アジャイル開発はウォーターフォール開発のように、一度決定した計画を絶対とはしません。開発メンバーや関係者からのフィードバックを定期的に得ることで、計画変更などを柔軟に対応・調整し、一度にまとめて開発するのではなく、ある程度の短期間で一つづつの機能を追加開発していきます。
スクラム用語「スプリント」とは？
スクラム開発では作りたい機能を小さい単位に分割し、短い期間で完成させます。短い期間のことを「イテレーション」と言いますが、繰り返される期間を個別に「スプリント」と呼びます。スクラム開発では、短くて1週間、長くて約1か月間までの、固定期間の中で繰り返し開発を行います。この固定期間がスプリントです。もし仮に、スプリント最終日に作業工程が残っていたとしてもスプリントは終了となり、延長などはありません。
スプリント期間はプロダクト規模の規模、開発チームの人数や熟練度、ビジネスの状況など、ありとあらゆる部分を踏まえて決定します。基本的には週単位でのスプリントとなりますが、状況の変化などにより現在のスプリントでの作業が意味をなくしてしまった場合などは、スプリントを途中で中止することが出来ますが、この判断はプリダクトオーナーのみに許された権限です。このプロダクトオーナーについても、後程詳しくご紹介致します。
メリット・デメリット
スクラム開発におけるメリット・デメリットを理解することで、取り入れるべきかどうか、開発方法として自社に適しているかなどが分かります。また、メリットをさらに引き出すためにすべきことや、デメリットを最小限に抑えるための施策なども同時に考えることができます。。このメリット・デメリットを細かくしっかり理解するということは、イレギュラーなトラブルや予期せぬ失敗を回避する事にも繋がりますので、必ず開発チーム全員で共有しましょう。
メリット
短期間で成果を上げる
スクラム開発は、顧客からの要求を、リスクや必要性を基準に並べ替え、優先順位の高いものから順に開発を行っていきます。そのため、期間は短くても上げられる成果は非常に大きいものとなります。また、こうした優先度の高い順通りの開発をすることにより、最低限必要な機能が揃った段階でリリースすることが可能となります。完成を待たずに顧客へ一部プロダクトの提供が出来ます。また、不特定多数に公開されるようなWebサービスなどでは、早期収益化にもつながるでしょう。
変化に柔軟に対応可能
スクリプトごとに要件の見直しや方向性の確認などを行うため、仕様変更や機能追加などの対応を柔軟に行うことが可能となります。また、案件の内容に限らずこうした定期的なミーティングを開発チームが行うことで、そのチーム内で発生している問題の検知も早くなります。
スクラム開発のミーティングでは、「分からない事」「疑問に思った事」「困っている事」などは隠さず素直に話し共有することが推奨されています。こうした細かな部分までしっかりとチーム内で共有することで変化に対応する速度も上がりチーム内の結束も強まっていきます。
早期にフィードバックが得られる
スクラム開発は、短期で動作するプロダクトを完成させることが可能になるため、定期的に顧客からのフィードバックを得ることが出来ます。これにより、開発の最終段階になって「望んだものと違う」というトラブルを回避することが出来るようになるでしょう。開発終了間際でのこうしたトラブルが起きてしまうと、コストが掛かるだけでなく、企業としての信用問題にもつながってきます。顧客との信頼関係や会社としての信用性を守るためにも、このスクラム開発は非常に有効と言えるでしょう。
自立的チーム作成が可能
短く区切った開発期間ごとの工数見積もりを開発メンバーが各自自分で立て、期限を切ります。それに対しチームからの了承を得て進行するため、自然と責任感を持つようになるでしょう。セルフマネジメントはもちろんのこと、自分のタスク以外の部分にも目を向け、チームの成果として計画を達成させるためにはどうしたらいいのかというのをじっくり考える必要があります。こうした部分から、各々の視野が広がり、各自が責任感とチームへの気遣いをもつことに繋がり、自律的なチーム作りを促進することが可能となります。
デメリット
習得が困難
ウォーターフォール開発とは大きく異なるスクラム開発では、移行する際の習得が困難な場合がります。また、チームは組織化されている必要があるため、全員がスクラム開発についての知識を持ち、しっかりと理解しておかなくてはいけません。これが出来ていなければ開発が失敗するリスクが大幅に高まります。スクラム開発を行う際は、まずは慣れるまで、2スプリント程度の学習期間を設けるといいでしょう。
顧客の協力が必要不可欠
メリットとしてあげた「顧客の早期フィードバック」ですが、これは顧客側の協力が絶対的に必要となります。こうした正しいフィードバックが得られなければ、スクラム開発の真価を発揮することは不可能でしょう。そのため、こうした部分はしっかりと開発前に顧客へ協力をお願いしておく必要があります。フィードバック送信のフォームなどを設けておくといいかもしれません。
完了が未定
スクラム開発は短期間のスプリントで行いますが、開発初期段階ではこのスプリントを何回繰り返すかは決められて今￥。そのため、予想以上に長引いてしまうという場合もあります。また、スクラム開発は仕様変更などの受け入れアリというのが大前提のため、開発対象の増減があります。こうしたことからも、スクラム開発でははっきりとした完了時期を見通すことが困難となってしまうでしょう。
メンバーによって開発の質が変わる
スクラム開発の大きな特徴は、開発メンバーのチームワークを最大限活用した開発方法です。もしも、メンバーの中でスKラムで決まった開発方針や方向性に賛同できないメンバーが一人でもいる場合、非協力的になる可能性が大きくなってしまいます。そうなると、適切に機能しなくなってしまうでしょう。
また、メンバーの技術に大きな差がありすぎると教育が必要となり余計な時間もかかってしまいます。メンバー内の入れ替わりが起こると失敗につながるため、最初のメンバー決定時にこうした部分を考慮しなくてはいけません。
スクラム開発チーム内の役割
スクラム開発はおよそ3～9名の少人数体制のチーム編成で開発を行います。チーム内では、それぞれに役割が分担されています。3つの役割に分けられ、個々のポジショニングをしっかりと認識し開発作業を行うことが大切です。この3つの役割とは一体どんなものなのかを詳しくご紹介致します。
プロダクトオーナー
開発するプロダクトにおける責任者です。主な役割としては、「どのような機能が必要か」「優先順位はどの並びか」といったビジョンを考え開発チームのメンバーへ伝えます。他にはプロダクトバックログのメンテナンスや優先順位の決定・リリース計画の立案・開発チームが作成したインクリメントを受け入れるかどうかの判断・ステークホルダーとの調整などを行います。
また、プロダクトオーナーはスプリントをキャンセルすることが可能な唯一の存在で、基本的に開発は行わずスケジュールや予算の管理などを行います。そのため、プロダクトオーナーはスクラムマスターと兼任しないしないことが強く推奨されています。プロダクトオーナーは、開発チームの中の責任者という位置づけと認識しておきましょう。
スクラムマスター
スクラム開発のチームが、スクラムの価値などをよく理解しプロセスを正しく実践できることに責任を負います。スクラムのルール、進め方をチームメンバー全員に説明し効果的な実践を促します。プロジェクトを円滑に進めるための調整役のようなものです。コーチングやファシリテーション、チームへの奉仕的活動が主な役割となっています。
また、プロダクトオーナーや外部メンバーからの無理難題な要求から開発メンバーを守ったり、特定のメンバーに負荷がかかりすぎないようなタスク調整なども行います。プロダクトオーナーとの兼任はよくありませんが、開発メンバーとスクラムマスターの兼任という場合は多くあり得るでしょう。開発メンバーが気持ちよく業務遂行をするための守り役のような役割をいいます。
開発メンバー
実際にスクラム開発を行うメンバーの事です。設計やドキュメントの作成、データベース管理、アプリケーション開発、テスト、運用などの一通りのスキルを持っていることが求められます。決まった分野のみしかやらない・これはできないなどというのは望まれません。仮に苦手分野などがあったとしても、作業を融通しあいながら、全メンバーが全ての作業をこなせるようになることを目指します。
また、仕事のやり方は、開発メンバー同士で決めることが出来ます。開発メンバーは上下関係などは必要ありません、役職や年齢などに左右されず、皆が平等の立場になります。開発チームの人数はおよ3～9名程度で構成され、おなじ場所にいなければいけません。人数がそれ以上になる場合には、開発チームの分割を行う必要があるでしょう。
スクラム開発のプロセス
ここまでは、スクラム開発の概要やそれぞれの開発チーム内の役割、メリットやデメリットなどを解説しました。では、実際のスクラム開発はどのように行うのか、スプリントの流れはどのようなものなのかをご紹介致します。この流れをしっかりと把握しておかなければ円滑な業務遂行は困難とないってしまいます。各々の役割に沿って、適切な作業を行うよう心掛けて下さい。
1・計画を立て、実施する
スプリント第一段階です。まず開発の計画を立てなければ何も始めることはできません。プロジェクトで必要となる機能一覧をバックログと言います。ここから当該スプリントで実装する機能を選択します。ここでは優先順位の高いものから開発していくのがポイントです。このように、スプリントの中で実装する機能一覧を「スプリント・バックログ」と呼び、スプリント・バックログを決める会議を「スプリントプランニングミーティング」といいます。ここで決まった内容をいよいよ実施していきます。
2・進捗報告
スクラム開発では毎日決まった時間にミーティングを行います。これは絶対欠かすことはできません。これを「デイリースクラム」といい、毎日進捗報告を行い、状況によってその日の作業を決めていきます。スクラム開発は、冒頭でもお話しした通りコミュニケーションを密にとり進めていく開発方法です。こうした報告機会が多くあるのが特徴で、プロジェクトの進み具合だけではなく、今後起こりうる開発上の課題なども共有しておくといいでしょう。このデイリースクラムはあまり時間をかけず、短時間で正確な情報のやり取りが求められます。
3・機能評価を行う
開発がある程度進行し、計画した機能の実装ができたらその都度機能のテスト、評価を必ず行います。この機能評価の実施を「スプリントレビュー」といい、スプリントの最終日の行います。特に重要視するのは、スプリントを始めるにあたり第一段階で決定したバックログの基準を、どの程度満たしているかがポイントです。また、このスプリントレビューによっては機能を追加したり再度バックログを作成する場合もあるでしょう。
4・スプリントを振り返る
スプリント最終段階です。単一スプリントで完了せずに、何度かスプリントを繰り返して行います。そのため、スプリント最終日はスプリントレビューと同時に振り返りを必ず行いましょう。ここで何かしらの課題がった場合には、次のスプリントに備えた改善計画を立案することが出来ます。スプリントはこの1～4のプロセスを短くて1週間、～長くて最長4週間の間に行います。これがスクラム開発です。
スクラム開発のツール
スクラム開発を行う際には、ツールの有効活用がオススメです。スプリント期間を設定できることや、かんばん方式のインターフェースであることなどを選択のポイントとするといいでしょう。また、課金が可能なのか、無料ツールのみの使用とするのかなども重視して選択するといいでしょう。
Jira
オーストラリアのATLASSIANの開発管理ツールJiraは、日本語化されており非常に使い勝手抜群のツールです。スプリントの期間決定やかんばん方式のインターフェースはもちろん、その他の細かな設定も可能となっています。また、最大の特徴として、ソースコードと連携が出来ます。
コードとタスクを連携させ、履歴管理することはこれまでの物理かんばん方式では不可能なモノでした。このJiraは、世界で最も利用されている管理ツールともいわれています。多少設定が複雑な箇所などもありますが、使い慣れてくれば特に問題なく活用できるでしょう。
Zube.io
GitHubで開発を進めている場合には、二重管理にならないように「GitHubのissueと連動したタスク管理を行いたい」というニーズが非常に高く、様々なサービスがあります。その中でも、特にスクラム開発向きで評価が高い管理ツールがZube.ioです。
Webサービスですのでクローズ環境では使用できないという弱点がありますが、UX・UIに優れ、使い慣れていない方、非ITエンジニアのアジャイルマスターやプロダクトオーナーでも苦労せず活用できるでしょう。4名までなら無料で利用できるため、少人数のスクラム開発で試しに取り入れてみるのもいいかもしれません。
Trello
非常にシンプルで分かりやすいUIが採用されています。拡張機能を使用すればスプリントの期間設定も行うことが出来ます。Jiraのような複雑な設定をすることはできませんが、小規模プロジェクトや少人数の開発チームのあ場合であれば十分な機能といえるでしょう。プロジェクト管理、タスクの整理、チームワークの促進をすべて行えます。世界中で100万を超えるチームに活用されているTrelloは、チームの生産性を向上させるのに非常に有効でしょう。
エクセル
表計算ソフトのエクセルは、実は非常に優れたスクラム開発のツールになります。追加コストもかかりませんし、関数やマクロの仕掛けなどはともかく、使い方をメンバーに説明する必要もないでしょう。こうした観点から、エクセルはとてもオススメのツールの一つと言えます。
出来合いの管理ツールを活用するよりも、自分たちで管理項目や管理粒度を模索しながら管理ツールを作り上げていくことで、チームメンバーへの教育としても非常に有効的でしょう。初めてスクラム開発を行う場合はぜひエクセルを活用してみて下さい。ある程度スクラム開発を行い、エクセルだけではやはり厳しいという感覚がつかめてきてから、本格的なツールの導入を検討してみてはいかがでしょうか。
スクラム開発の失敗
スクラム開発は、スクラムガイドに背くことで失敗のリスクが高まります。その中でもよある役割別に失敗例をご紹介致します。役割による失敗を犯してしまうと、他メンバーへの負担も大きくなり開発の円滑な進行が不可能となってしまうでしょう。個々の役割をしっかりと理解し、なすべき仕事をきっちりこなすことが失敗を回避する大前提となります。
プロダクトオーナーの失敗
| PBL管理を怠る | 優先順位が正しくつけられていなかったりINVESTを満たしたPBIになっていない場合、開発に大きな支障をきたします。最悪の場合、スタート時点から失敗してしまうという事もあり得るでしょう。プロダクトオーナーは開発の責任者であり進行を左右する大きな要です。まずはこの最初の出だしをしっかりと行わなければ開発自体がスタートさせることが困難となってしまうでしょう。 |
| 開発メンバーと離れている | 基本的に開発チームは同じ時間、おなじ場所で作業を行わなければいけません。仕様の確認事項などを開発メンバーはプロダクトオーナーに確認しますが、場所が離れていたりすれば即確認がとれず時間のロスが発生してしまいます。開発の遅れにもつながり、会社の信用問題へと発展していく場合もあるでしょう。そもそもこうした確認事項が多発してしまう時点でプロダクトオーナーの役割をこなしているとはいえないでしょう。 |
| 完了の定義を共有しない | PBIの完了定義を開発チームのメンバーと共有しなければ、他メンバーは作業範囲が分からなくなってしまいます。明確な完了定義をしっかり共有することで、開発の質を高めメンバー内の結束も強まる効果があります。受け入れ条件を明確に行うことが最適です。プロダクトオーナーは開発の全権を握っていますので、しっかりとした指針を示すことが最大の役割と言えるでしょう。 |
プロダクトオーナーの失敗に多いのは、チームへの情報共有や優先順位決定の失敗などがあげられます。こうした部分はしっかりと行わなければいけません。開発チームの責任者でもあり様々な決定権を持つプロダクトオーナーが一つでも間違えてしまうと、他メンバーを巻き込み開発そのものを失敗にさせてしまうでしょう。
実際、プロダクトオーナーにチームを率いる力量が足らずに失敗したという話も多くあります。まずはプロダクトオーナー個人の力量、コミュニケーション能力を明確にし、本当に任せられるのかどうかを判断しましょう。
スクラムマスターの失敗
| 開発メンバーと兼任 | 兼任すること自体は様々な企業でも少なくありません。兼任することが間違いなのではなく、しっかり両方の役割をスムーズに行える力量があるかどうかです。IT業界は人手不足でこうした事はさほど珍しくはありませんが、個人の能力以上の仕事を行うのは不可能です。スクラムマスターの仕事はそうなくなりませんし、開発メンバーも個々にタスクが振り分けられているためこれはこなさなければいけません。どちらかの作業がネックとなってしまえば開発の遅れに繋がりますので、十分注意が必要です。 |
| チームへの奉仕がない | リーダーシップがなく、開発メンバーを守る役割が出来ていない場合も出てくるでしょう。開発メンバーを業務に集中してもらうためには、スクラムマスターが外野からしっかり守る必要がります。チームが抱えるあらゆる障壁の解消を務めるのが大きな仕事と言っても過言ではありません。ここをしっかりこなさなければ、開発の成功は遠のきます。 |
| スクラム開発の説明不足 | スクラムマスターは開発メンバーへ、スクラム開発に対する正しい知識を伝える必要があります。しかし、これを怠ったり適切な説明が出来ないと、スクラム開発に対する理解が浅く成功を収めることが難しくなるでしょう。開発メンバーの意識を高め生産性を上げるため必要ですが、この部分をおろそかにしてしまうスクラムマスターが多いのも事実ですので、特に注意してください。 |
スクラムマスターはとにかく開発メンバーを守ることが大切です。また、プロダクトオーナー同様に個人の力量がどの程度なのかを明確にする必要があるでしょう。非常に優れた人材であれば、開発メンバーとの兼任も可能です。しかし、可能な限りスクラムマスターのみの業務に集中できる環境の方が、開発を上手く進めることが出来るでしょう。また、メンバーへ適切な説明を行わなければ全員の知識が揃わずスクラム開発は失敗してしまうでしょう。ここができないとスタート時点で間違った方向へ進んでしまう可能性が大きくなります。失敗を回避するためにも、適切な説明は必須です。
開発メンバーの失敗
| 必要な知識・スキルがない | 開発メンバーは一定以上のスキルが必須です。しかし中には、人員の都合上どうしても無理という場合もあるかもしれません。こうした場合、チーム内で上手く振り分けが可能であれば問題ありませんが、メンバー内での仕事量に差が出るのは問題です。上手く振り分けが出来ない場合、開発に大幅な遅れが生じます。 |
| スーパースターエンジニアがいる | スーパースターエンジニア（ゴリラとも言います）がいなければチームが動かない、判断が出来ないとなると、「開発チームに自立性がなくなってしまいます。こうした方は外からのサポートが向いているので、メンバー選定の際にこうした要素があるかないかの判断が重要です。 |
| 問題がっあても共有しない | スクラム開発は毎日しっかりとしたミーティングを行いますが、そこで発言をしなかったり問題点の共有が行えないメンバーは、チームプレイに向いていません。後々大きな課題となる前にしっかりとメンバーで問題を虚位有することで、スムーズな開発が行えますが、ここが出来ないと失敗するリスクが高くなります。 |
開発メンバーは一定以上のスキルがある同じくらいのレベルの人材で揃える必要があります。大きな差があると失敗に繋がりやすくなり、開発自体が不可能となってしまう場合もあるでしょう。メンバー内のコミュニケーションを強めチームワークを向上させるためにも、協調性や情報共有能力などもしっかりと備えている必要があります。
失敗リスクを高めないために
失敗するスクラム開発の主な理由としてあげられるのが、開発メンバー内の意思疎通の低さや個々のモチベーションです。少人数で構成されるスクラム開発のメンバーは、おなじ目標に向かい協力し合っていく必要があります。チーム内の雰囲気が悪かったり問題を抱える人がいる場合、士気も下がり失敗するリスクは非常に大きくなります。チームプレイを行うためには、一人一人コミュニケーションをしっかりとり協調性を重視する必要があります。
スクラム開発の失敗を回避するためには、プロダクトオーナー、スクラムマスター、開発メンバーがここの役割をしっかりと認識し、与えられた使命をきっちり果たす必要があります。メンバーがころころ変わるのも避けましょう。また、開発における最初の段階で様々な部分を詰めすぎると、外れた場合の修正やコストが大きくなります。こうした事を注意することで、スクラム開発の失敗を回避する確率は非常に高くなるでしょう。
スクラム開発の成功
スクラム開発を成功させるためには、まず最初の準備を重点的に行うことが肝心です。例えば「初めてのスクラム開発で初めての技術、初めてのチーム」では成功する確率は低いでしょう。ある企業では、初めてスクラム開発を行う際に、プロダクトオーナー、スクラムマスターとなる人材に一定以上の研修を行い、スクラム開発におけるノウハウを学ばせました。また、自社外で開催されているスクラム開発に関する講義などにも積極的に参加し、様々な知識を吸収させました。
その後、実際にプロジェクトをスクラム開発で行いましたが、このスクラム開発の目的は教育がメインとなっているため時間のほとんどを開発メンバーの育成に充てながら進めていきました。その効果は非常に強く、半年ほどで素晴らしい有能なスクラム開発チームが誕生しました。個々のメンバーを他のスクラム開発チームに振り分けることで、一定以上のスクラム開発に関する知識やスキルを持ったチームを多く構成することが可能となりました。
全ての企業でこうした方法が可能ではないかもしれませんが、ビックバンスタートでは必ず成功率は低くなるでしょう。最低でも一人以上はスクラム開発経験者がいなければ、大きく成功を収めることは難しくなります。スプリントを決めその中で教育しつつ開発を進めるのは大変ですが、ある程度の知識やスキルを身につけさせることで、企業としてのスクラム開発に対するレベルも上がり、高度な開発を行うことも可能となるでしょう。
スクラム開発のポイントとは
アジャイル開発の理解
スクラム開発は、まずアジャイル開発を理解することがポイントとなるでしょう。アジャイル開発は急な仕様変更などに柔軟な対応が可能ですが、万能ではありません。仕様変更が起こればコストが掛かり期間も延びます。これは開発メンバーのみならず、プロダクトオーナーやスクラムマスターにもあたりますが、まず初めにアジャイル開発を徹底的に理解しましょう。こうした知識が多ければ多いほど、顧客側は無茶な要求はしてこなくなります。
とにかくコミュニケーションを
開発メンバーのコミュニケーションがとにかく重要なスクラム開発。メンバー内の雰囲気を良くし開発を行うことで、モチベーションも上がりつつスムーズな作業を行うことが可能となります。毎日の情報共有も大切なコミュニケーションの場です。同じ開発チームの仲間として同じ方向を目指し、共に協力し合う姿勢を大切にしましょう。
まとめ
開発段階での仕様変更などに柔軟な対応が可能なスクラム開発。概要やメリット・デメリット、気を付けるべきポイントなど理解できたでしょうか。短期集中型のスクラム開発は、人員育成をまず行い一定以上の知識を身につける事が必要です。メンバー内のコミュニケーションを円滑にし、各々の役割をしっかり担うスクラム開発は、今現在、中小企業から大手の有名企業まで、様々なジャンルの企業で取り入れられています。これから先の時代、開発方法の主流の一つとして更に発展していくのではないでしょうか。
