システム開発手法

「アジャイル」が「ウォーターフォール」の対極にある新しいシステム開発手法だということは、ITエンジニアの皆さんならご存知だと思いますが、「アジャイル」開発には「スクラム開発」という手法もあります。今1度ここで確認し、DX時代に対応したシステム開発手法として活用しましょう。

アジャイル開発という言葉は、今から20年前の2001年に生まれました。従来のウォーターフォール開発では、「要件定義→仕様策定→設計→開発→テスト」の各プロセスごとに厳密な文書化が求められます。そのため開発プロセスは重厚で時間を要するものですが、仕様変更に弱く、プロジェクトがしばしば頓挫するという難点もありました。

そのような問題を解決するために、ソフトウェア工学の専門家17名が中心となって、互いの主張や考えをぶつけ合い「アジャイルソフトウェア開発宣言」という文書で表明をしたのがアジャイル開発の始まりでした。

ちなみに"アジャイル（Agile）"は「素早い」を意味する英語で、アジャイル開発は、大まかな仕様が決まったら、「手直しを恐れず、まずは作る」という考え方です。「できるだけ少ない工数」で、「短期間」でシステム開発をする手法と覚えておきましょう。

今でこそ「アジャイル開発」はメジャーな開発手法ですが、従来は「ウォーターフォール開発」が主流でした。システム開発の際、まずプロジェクトの要件定義を行い、綿密な設計を行ってから開発に着手するのがウォーターフォール開発の段取りです。「システム分析」から始まり、「システム設計」→「システム開発」→「システムテスト」→「保守」の一連の工程を、上から下に落ちるように実行して様子が、滝をイメージさせることからウォーターフォール開発と呼ばれています。

ウォーターフォール開発は主に汎用コンピューター（メインフレーム）で用いられたシステム開発手法ですが、ダウンサイジングなどの新しい技術が主流となる中、ウォーターフォール型の開発手法がマッチしなくなってきたことから、アジャイル開発に置き換わってきたのです。

アジャイルとは開発スタイルの総称であり、アジャイルの中には「スクラム」をはじめとして、さまざまな手法があります。「スクラム」については後述しますが、スクラム以外のアジャイル開発手法を以下で紹介します。

▪リーン開発 無駄は「価値」の対極にあるものと捉えて、無駄を最小化し、（顧客）価値の最大化を目指す手法です。トヨタの生産方式をシステム開発に適用させたものです。

▪ エクストリームプログラミング（XP）開発 「コミュニケーション」「シンプル」「フィードバック」「尊重」「勇気」の5つの価値（ポイント）を重視した開発手法で、「テスト駆動開発」や「ペアプログラミング」などを取り入れて短期のシステム開発と変化への対応を実現しています。

▪ カンバン カンバンは「作業を可視化」を基本とし、作業の効率（生産性）を最大化する手法です。 カンバンボード（ホワイトボードやWebボードなど）を使用して、作業フローの継続的な改善を進めます。

スクラム開発はアジャイル開発の1つの手法

「アジャイル開発」にはさまざまな手法がありますが、「スクラム開発」はその代表的な手法で、チームメンバーのコミュニケーションに特に重きを置いた手法といえます。

スクラムは、ジェフ・サザーランド氏とケン・シュエイバー氏によって1990年代に編み出されたアジャイル開発の1つの手法です。

アジャイル開発では、計画を厳密には作成しないため、システム開発全体の方向性が定まっていないと、個々の機能がうまく実装されていても結果的に一貫性に欠けるシステムとなってしまうリスクがあります。これに気付く頃にはある程度システム開発が進んでいるため、修正する場合には負荷や工数が大きくなってしまうという問題があります。

こうした問題を解決するため、アジャイル開発で多く採用されている作業管理のフレームワークが、「スクラム」です。スクラムはプロジェクト管理の枠組みで、「チームの統制」や「コミュニケーション」を重視します。また、スクラムにはアジャイル開発の最大の特徴ともいえる柔軟性や自由さを保ちつつ、チームの意識統一を高め、プロジェクトを円滑に進めるという利点があります。

詳細はスクラムガイドを参照ください。

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

1.機能単位での開発 機能をプロダクトに対する要望の高いものから優先順位をつけ、その順位に従って機能を構築します。

2.個別の開発期間を短期間で設定 機能ごとの開発に区切り、その中で開発計画を立てます。個々の期間は1週間から最大4週間程度です。この期間のことをスプリントと称します。

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

4.プロダクトの機能のレビュー 機能がユーザーの要望に合致しているかを定期的にレビューします。

スクラム開発ではチームの単位で活動を行いますが、チームメンバーは3人～10人程度で編成します。またその活動主体はメンバーであり、リーダーはおらず主役はメンバーです。

1.プロダクト・オーナー プロダクト・オーナーの役目はチームの舵取りです。チームへの口出しはせず、チームメンバーが主体的に最高のパフォーマンスが発揮できるように、側面サポートします。

2.スクラム・マスター スクラム・マスターの位置づけはメンターです。メンターとはよきアドバイザーのことで、スクラム・マスターとメンバーは対等な関係にあります。メンバーが悩みや問題に目を向けて、その改善や治療を行うドクター的な存在です。

3.メンバー スクラム開発のチームにはリーダーがいない代わりに、舵取り役のプロダクト・オーナー、ドクター的存在のスクラム・マスターがいます。どんな組織にもリーダーはいますが、スクラムではリーダーは存在しません。全員が対等で、全員が主役です。スクラム・マスターはリーダーに近い存在ですが、チームをリードするのではなく舵取りでメンバーをサポートします。スクラムチームの主役はメンバーの1人1人だという点を覚えておいてください。

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

スクラム開発はアジャイル開発の優れた1手法で多くのメリットがありますが、デメリットも存在します。スクラム開発についての理解を深めるために、メリット、デメリットについて確認しましょう。

1.チームメンバー全員が主役 ラグビーのスクラムをイメージすると分かりやすいと思いますが、スクラム開発の主役はチームのメンバー全員です。スクラムを組んでシステム開発を進める上では、チームの1人でも手抜きをするとスクラムが崩れてしまいます。そうならないよう、チーム全員がモチベーションを高め、維持しながら取り組めるように努めるのがスクラム・マスターです。

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

3.計画通りに開発が進行 スクラム開発では、機能単位に工数を見積もって開発を進めていきます。機能単位でテストを行うので障害の早期発見、早期対応が可能で、計画通りに開発が進行する確率が上がります。

スクラム開発は開発スピードを高め、効率的な開発手法ですが、条件や状況によっては思うような効果が得られない可能性があります。

1.メンバーの協力体制が整わない スクラム開発のチーム活動は最短で1週間です。不慣れなメンバーばかりでチームが編成された場合、準備や習熟に時間を要し、メンバーがそれぞれの力を充分に発揮することなく活動が終了してしまいます。開発のリズムを維持するためにもメンバー編成をなるべく変えずに進めることが大切です。

2.コミュニケーション能力に左右される スクラム開発では毎日行われるミーティングで、自身のタスクの進捗状況や課題について簡潔に発表するとともに、他のメンバーの進捗状況を正しく理解することが求められます。仕事ができてもコミュニケーションが苦手というエンジニアはスクラム開発に向いていません。その点に留意してメンバーの人選や育成を行うことが求められます。

3.開発全体のスケジュール管理がしにくい スクラム開発は柔軟な開発がメリットですが、逆にそれが仇になることがあります。柔軟であるが故に、開発の方向性の変化やスケジュールのぶれが生じることがあります。また機能単位に工程が細かく分かれていることから、全体スケジュールの管理が難しくなるというデメリットもあります。

スクラム開発を失敗させない秘訣

従来型開発手法のウォーターフォールはプロセス重視で、手順も細かく規定されています。一方、スクラム開発の細かいプロセスは規定されておらず、柔軟な開発スタイルとチームメンバーが主役のやり方です。このスクラム開発を成功に導く鍵はそこにあります。スクラム開発を成功に導く秘訣について解説していきます。

先ほど、スクラム開発が失敗する要因として、コンセンサスの不足をあげました。スクラム開発は関係者の理解が大前提です。まずは関係者全員がアジャイルの考え方やマインドを正しく理解する必要があります。システム部門ばかりではなく、経営層・マネジメント層・人事部門・管理部門など関係者全員の理解が必要です。

変化即応型の「アジャイル型組織」への組織変革が求められるのです。システム部門だけではなく、企業そのものを「アジャイル型組織」に変革することができれば、成功に向かって大きく前進するでしょう。

システムの開発には、必ず明確な目的や目標があります。チームのメンバーのベクトルがずれていると、スクラム開発は成果を上げるのが難しくなります。スクラムチームが何を目指すのか、メンバーの意見を集約して目指すゴールを設定し、共有することが必要です。

また、なぜスクラム開発方式を採用するのかについても、しっかりメンバーのコンセンサスを得ることが大事です。ウォーターフォール開発をイメージしているメンバーが1人でもいると、そのメンバーによってスクラムが崩れます。スクラム開発は柔軟な開発手法ですが、スクラム方式には一定のルールがあります。きちんとゴールを定め、チームのルールに従って進めていくことが成功の秘訣です。

スクラム開発ではチームメンバー全員が主役です。メンバー全員が対等であり、1人1人を尊重し、その働きを褒めたたえる、感謝をするところからスタートさせます。スクラム・マスターは個々のメンバーを尊重し、感謝やねぎらいの気持ちを伝えると、メンバーが互いに尊重し合い、チームとして強い結束力が生まれます。スポーツチームのように、一緒に汗を流し勝利を喜び合う仲間という意識の一体感が鍵です。これこそがスクラムの最大の強みとなるのです。

DX時代にこそ求められるスクラム開発

ジェフ・サザーランド氏が編み出した開発手法を、『アジャイルソフトウェア開発スクラム』という本にまとめて発表したのは2003年のことですが、実際にサザーランド氏がスクラム開発を提唱したのは、そのさらに10年前だといわれています。

この30年近い歴史を持つアジャイル開発手法が、今注目されているのには理由があります。それは、政府主導でDXの必要性が叫ばれ、ビジネス領域とITとの距離が一気に縮まったからではないでしょうか。

アジャイル開発の概念が生まれた約20年前、ソフトウェア開発はエンジニアだけの世界でした。今やDX時代に入り、DXの取り組みを通じてビジネス変革を推進する企業では、企業そのものがIT的な組織になっています。アジャイル思考を持つ人材がDXを主導しています。

システム開発手法やアジャイル的な組織づくりが経営課題となっています。スクラムはシステム開発のみならず、あらゆるブロジェクトに適用が可能です。プログラム開発手法やノーコード開発よりも、スクラム開発のためのアジャイルチームづくりがDX成功の大きな鍵となっています。