スクラム開発とは

ソフトウェアの開発手法としては、従来主流だった「ウォーターフォール開発」と最近主流になりつつある「アジャイル開発」の2つの手法がよく知られています。

「アジャイル開発」では、少人数の開発メンバーが協力しあいながら作業を進めていきます。また、「ウォーターフォール開発」方式のような、一度決定した事を絶対視せず、都度見直しながら柔軟に進めていきます。各チームメンバーから定期的にフィードバックを得て、その時点でベストと思われる方法を採用していきます。システム開発においては、1度にすべての機能をまとめて作るのではなく、機能単位に、あるいは一定期間ごとに開発を繰り返し、積み上げていきます。

「スクラム開発」は「アジャイル開発」の代表的な手法で、特にチームメンバーのコミュニケーションを重視した手法です。この「スクラム開発」には次のような要素があります。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

スクラム開発の要素は大きく分けると以下の4つですが、この手法はシステム開発以外のプロジェクトにも適用が可能です。

1.機能単位で開発 していくのがスクラム開発の特徴ですが、機能はプロダクトに対する要望を優先順位の高いものから並べ、その順番に従って機能を作ります。

2.個別の開発期間は短期間（1～4週間程度） に区切って、その中で計画を立てていきます。

3.メンバー同士のミーティング は毎日行い、その中でプロジェクトの状況を共有し、進捗に問題がないかなどを確認していきます。

4.プロダクトの機能 がユーザーの要望通り正しく作られているのかを、定期的にレビューします。

スクラム開発ではチーム単位で活動をしていきますが、1つのチームは3人から多くて10人程度までで編成します。またその活動は責任者に任せず、メンバーが主体的に行動するのが原則です。

1.プロダクト・オーナー プロダクト・オーナーと言うと仰々しいですが、プロダクト・オーナーの役割はチームの舵取り役です。舵取りはしますが、チームへの口出しはしません。チームが最高のパフォーマンスを発揮できるよう側面からサポートする役目を負っています。

2.スクラム・マスター スクラム・マスターはメンターという立場です。よき助言者といえば良いでしょうか。チームメンバーとの関係は対等です。メンバーが困っていることや、不都合な問題などに目を向け、その改善や治療を行います。ドクターのような存在です。

3.主役はメンバー スクラム開発のチームにリーダーはいません。舵取りをしてくれるプロダクト・オーナーや、ドクターのような存在のスクラム・マスターはいますが、チーム・リーダーの立ち位置の人はいないのです。リーダーのいないチームとは？と不思議に感じると思いますが、一般的な組織のリーダーとは役割が違います。一応、リーダーに近い存在はスクラム・マスターですが、スクラム・マスターはメンバーのサポートに徹します。あくまでもスクラムチームの主役はメンバー1人1人なのです。

スクラム開発のメリット・デメリット

スクラム開発は新しく編み出されたアジャイル開発の1つの手法で、多くのメリットがありますが、一方でデメリットもあります。スクラム開発をより理解するために、そのメリット、デメリットについて確認しておきましょう。

1.チームメンバーが当事者意識を持って主体的に取り組める スクラム開発の主役はメンバー個々人です。スクラムを組んで全員でシステム開発を進めていくため、1人でも手抜きをすればスクラムは崩れます。そうならないよう、うまくサポートし、全員がモチベーションを維持しながら取り組めるように動くのがスクラム・マスターです。このため、メンバーはチームメンバーと協力し合いながら最高のパフォーマンスを発揮できるのです。

2.問題が起きても迅速に発見し、迅速に解決できる スクラム開発では毎日ミーティングを行い、昨日の成果、今日の課題、問題点などを共有します。問題点や障害となっていることはスクラム・マスターがさらに浮き彫りにし、メンバーと共同でその解決に努めます。そのため、問題発見と問題解決が早く行えるため、プロジェクトが予定通り進みます。

3.工数見積もりの精度が上がり予定通り開発が進む 最初にプロジェクトの全工数を見積もる「ウォーターフォール開発」と異なり、アジャイル開発の一種であるスクラム開発では、機能単位で工数を見積もりながら開発を進めていき、障害などの早期発見、早期対応が行えるので、計画通りに開発が進行します。

スクラム開発とは？エンジニアが知っておきたい情報をまとめました！

スクラム開発は開発の生産性を高める上で大変効果的な手法なのですが、一方で必要な条件を満たさないと、スクラム開発の効果が得られないことがあります。そのデメリットついて述べていきます。

1.短い期間での対応でメンバーの協力体制が整わないことがある スクラム開発の最短のスパンは1週間です。未習熟のメンバーが参画した場合、ウォーミングアップ期間や教育機関が十分に設けられないため、力を発揮することなく期間が終了してしまいます。開発リズムを崩さないよう、できるだけメンバー編成を変えずに開発を進めることが求められます。

2.コミュニケーションが苦手なエンジニアには不向き スクラム開発ではメンバーのコミュニケーション力が問われます。日々のミーティングで自分のタスクの進捗や課題を簡潔に発表し、他のメンバーの状況を正しく理解する能力が求められます。仕事はできるが、コミュニケーションが苦手というメンバーはスクラム開発に不向きです。こうした事を考慮し、メンバーの人選や、メンバーの育成に配慮する必要があります。

3.開発全体のスケジュール管理がしにくい スクラム開発は柔軟な開発ができるメリットがある一方で、柔軟が故に開発の方向が変わることがあり、スケジュールそのものがぶれる可能性があります。また工程が機能ごとに細かく分かれており、それも全体スケジュールの管理を難しくする要因です。クライアントからスケジュールの進捗の確認を求められた際、説明が難しい点は、ウォーターフォール開発と比較してデメリットと言えます。

スクラム開発失敗の原因

スクラム開発が失敗する原因は非常に多くありますが、ここでは絞って、代表的な失敗の原因について解説します。

スクラム開発という手法は、従来の開発手法とは大きく異なります。単なる掛け声だけで進められる手法ではありません。チームメンバーの理解と協力も欠かせませんが、会社全体、経営者、利用部門など幅広い理解とコンセンサスが必要です。これらを飛ばして、いきなりスクラム開発を進めると必ずと言ってよいほど失敗します。そのためには、関係者に対して、アジャイル開発・スクラム開発の目的や狙い、得られる効果、スクラム開発を進める上で必要なことをきちんと説明し、承認を得ておくことです。「単なるシステム開発の一手法だから、予算さえ確保しておけば問題ない」という甘い考えは通用しません。周到な準備を忘れないでください。

これは1.の失敗原因とも共通する部分がありますが、性急な導入は失敗する原因です。例えば、システム開発案件があり、そのプロジェクトを任されたとしましょう。納期が厳しく、従来型のウォーターフォール開発では間に合わないと判断し、スクラム開発方式の採用が頭に浮かびます。しかし、スクラム開発方式を採用するには準備期間が必要です。これまでに開発メンバーを含めて十分な経験があれば、問題はありませんが、初めての経験なら6カ月程度の準備期間が必要です。まさに「急がば回れ」です。

アジャイル型開発に計画は不要だという誤った考えを持つ方がいますが、これは大きな誤解です。どんなプロジェクトでも目標や計画は必要です。ただ、アジャイル開発の場合は機能単位に計画が分解されるだけのことで、少なくとも全体の大まかな計画は立てなければなりません。また、スクラム方式が初めての採用であるなら、スタートするまでの準備期間のスケジュールも組んでおく必要があります。関係者への根回しや説明、勉強会やセミナーの実施、進め方の決定、会議体やレビューボードの設定、役割分担など、やるべきことは山ほどあります。それらを進めるための緻密なスケジュールも必要です。これらを飛ばしていきなり着手するのは、飛行プランも立てずに飛行機を飛ばすようなものです。

アジャイル型開発が適した組織やプロダクトがあります。若い組織、古い考えに侵されていない組織、あるいは従来のプロダクトとは全く異なる新しいプロダクトにおいてアジャイル型開発は向いています。

一方、古い組織や成熟したプロダクトを対象にアジャイル開発、スクラム開発がブームだからと飛びついたら、失敗する可能性が高まります。スクラム開発を検討する際は、どの開発方式がベストパフォーマンスを得られるのか、きちんと精査することが求められます。

スクラム・マスターはスクラム開発におけるリーダー役ですが、一般的なリーダーとは立ち位置が異なります。スクラム・マスターはチームを牽引するというよりは、ユーザーとの調整弁であり、チームのドクター的存在で、チームメンバーのサポートに徹しなければなりません。一般組織の古いタイプの管理者のような振る舞いをしてしまうと、メンバーが萎縮し、それぞれの能力を発揮できなくなることがあります。スクラム・マスターはスクラム・マスターとしての研修を受け、しっかり役割を認識しておく必要があります。

スクラム開発を成功させるためには

従来型の開発手法、ウォーターフォールはあくまでもプロセス重視ですが、スクラム開発は人であり、マインドです。細かいプロセスが規定されているわけではなく、あくまでもメンバーが主役のやり方です。スクラム開発成功の鍵はそこにあると言えます。以下、もう少しかみ砕いて説明をしていきます。

先ほど、スクラム開発の失敗原因として、コンセンサス不足をあげました。スクラム開発は関係者の理解が最大の力になります。まずはアジャイルの考え方、マインドを関係者が正しく理解することが前提です。それはシステム部門だけではなく、経営層、マネジメント層、人事や管理部門、関係者全員の正しい理解が必要です。「アジャイル型組織」とは変化即応型で、迅速な意思決定と対応ができる組織です。できれば、経営者の理解と共感を得て、企業そのものを「アジャイル型組織」に変革できれば、それがベストです。まずは、企業変革と併せて、スクラム開発方式を利用できると、成功に大きく近づくでしょう。

システムやプロダクト開発には必ず目的があり、ゴールがあります。スクラムチームとして何を目指すのか、メンバーの意見を集約しながら目指すゴールを設定し、それを全員で共有する必要があります。メンバーのベクトルが一致した時に組織は最大限の力を発揮できます。また、なぜアジャイル開発・スクラム開発方式を導入するのかについても、しっかりメンバーのコンセンサスを得ておくことが大事です、スクラム開発にはスクラム方式のルールがあります。ゴールを決め、ルールに従って進めていくことが成功の秘訣です。

スクラム開発のチームメンバーは全員が主役です。主役ということは、メンバー1人1人を尊重し、その働きに対して感謝をすることからスタートします。スクラム・マスターがメンバーを尊重し、感謝の気持ちを伝えることで、チームメンバーが相互に尊重し合い、強い結束力が生まれます。チームに必要なのはロボットではなく、人です。血の通った人間です。ともに悩み、ともに汗を流し、ともに喜びを分かち合う仲間です。アナログ的な発想かもしれませんが、これがスクラムの強みとなるのです。