こんにちは、オレンジ色が好きで、よくグラフや表のアクセントカラーとして使っています。エンジニアリングソリューション事業部の「せきしん」です。
Webアプリケーションの開発リーダー兼、サーバサイドエンジニアとして複数のアジャイルプロジェクトに参画しています。
開発リーダーとして、お客様とプロジェクトの納期や体制のお話をする機会が多く「やっぱりスピード感を持ちたいからアジャイルでやりたいよね」、「今のプロジェクトをウォーターフォールからアジャイルに切り替えることって出来ないかな？」といったご要望を頂くことがあります。
こちらは、ガートナーが2019年２月に発表した「アジャイル型開発手法に関する現在および今後の方針×従業員数規模」のグラフです。
海外では開発の80%以上でアジャイル開発が採用されていると言われています。しかし、日本では上記の図のように、2,000人以上の規模の企業でもアジャイル開発を採用している企業は40%程度となっており、ウォーターフォールを採用する企業、プロジェクトがまだ多いのが実状です。
そのためにアジャイルの良さを知らない、逆にアジャイルに過剰に夢を抱き魔法のツールだと勘違いされている方もいるかと思われます。
そこで今回は私が経験から学んだアジャイルの(特にスクラム開発)手法や特徴をご紹介し、「アジャイルを初めてみたい」「未経験だからイメージを掴みたい」という方の参考になれば嬉しいです。
目次
■アジャイル・スクラム開発とは
まずは「アジャイル・スクラム開発」がどういったものなのかを簡単にご説明します。
アジャイルとは
Agile（アジャイル）は、英語で機敏な、素早いと言う意味で、正式にはアジャイルソフトウェア開発と言います。一定の期間を設け、その期間ごとに機能を追加し、動くソフトウェアを短期間で繰り返し提供していこうという開発プロセスです。
上図のように、一つの期間の中で要件定義→設計→開発→テスト→リリースといった一連の流れを行います。
アジャイルには「12の原則」というものがあり、これに則り開発をします。
アジャイル12の原則
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する
2. 要求の変更を歓迎する
3. 動くソフトウェアを2-3週間から2-3ヶ月というできるだけ短い間隔でリリースする
4. ビジネス側の人と開発者はプロジェクトを通して日々一緒に働く
5. 意欲に満ちた人々を集めプロジェクトを構成し、仕事が終わるまで彼らを信頼する
6. 情報を伝えるもっとも効率的で効果的な方法としては会って話をする
7. 動くソフトウェアこそが進捗のもっとも重要な尺度となる
8. アジャイルプロセスは持続可能な開発を促進する
9. 新しい技術を取り入れる、可読性を維持し俊敏さを高める
10. シンプルさが本質となる
11. 最良の仕事は自己組織的なチームから生み出される
12. チームの振る舞いを最適に調整するために定期的な振り返りを行う
引用: アジャイル宣言の背後にある原則 ※上記は左記リンクの内容を要約して記載しています。
スクラムとは
アジャイルソフトウェア開発をする上で、「どのようにプロジェクト管理をしていくか」にフォーカスした方法論です。(フレームワークと言われています)
開発者だけでなく、ステークホルダーを含めたチームを作り「役割」を明確にし、決められた「会議体系(以降、スクラムイベントと呼称)」に則り、プロジェクトを進行していきます。
スクラムの基本的な考え方
・顧客の望むものは常に変化するので正確な見積もりはしきれない。
・上流工程で仕様のすべてを決めるのは難しいので、そこには注力しすぎない。
・素早いリリース、新たな要求への対応、新しい技術の取り入れ、チームの生産性向上に注力する。
スクラムで押さえておくべき用語
スクラムの詳細を説明するに当たって、単語の意味を知らないと役割やスクラムイベント（会議体系）が理解しづらいと思うので、先に用語を押さえておきましょう。
・スプリント（Sprint）
一定の期間のことを指します。（通常1週間か2週間）
前述の「アジャイルとは」で説明した「一定の期間」を指します。要件定義→設計→開発→テスト→リリースまでを2週間で行い、それを繰り返しましょう、となった場合は、「1スプリント2週間」となり、スプリント1でAの機能をリリース、スプリント2でBの機能をリリースといった具合に使います。
・プロダクトバックログ（Product Backlog）
提供したい機能の一覧を指します。
「このシステムではA〜Zまでの26の機能が欲しい」となった場合、優先順位付がつけられた26項目の一覧表だと想像してもらえればと思います。
・スプリントバックログ（Sprint Backlog)
1スプリントの中で提供する機能の一覧を指します。
「スプリント1ではA機能とB機能を作って提供して欲しい」となった場合、スプリント1のスプリントバックログにはA機能とB機能が含まれているといったニュアンスになります。
スクラムでの役割
スクラムには3つの役割が存在します。
1. プロダクトオーナー (1名)
ステークホルダー及び開発した機能を利用する側の代表者です。
ビジネス観点で判断を下すことも必要なため、ビジネス側での意思決定者が適切です。
2. 開発チーム (3-9名ほど)
プロダクトオーナーが決めた仕様と作る優先順に沿って設計、開発、テスト、リリースまでを行います。
3. スクラムマスター (1名 プロダクトオーナーとの兼務などはNG)
スクラムが上手く行くように発生した阻害要素を取り除いたり、プロダクトオーナーと開発チームとの間を調整します。プロダクトオーナーがスクラムマスターを兼任すると、プロダクトの提供速度を重視する進行調整や決定になりがちで、「持続可能な開発」がおろそかになり、開発チームの負荷が高くなる可能性があるため、プロダクトオーナーの兼務NGとされています。できれば選任者をおくことがベストですが、開発チームの一人がスクラムマスターを兼務することは、ままあります。
スクラムイベント
スクラムには5つのイベントが存在します。
1. バックログリファイメント（Backlog Refinement）
プロダクトバックログの優先順位の見直しと次回のスプリントに向けて仕様の認識合わせを行うイベントです。
2. スプリントプランニング（Sprint Planning）
1回のスプリントで提供したい機能を決めるためのイベントです。
「プロダクトオーナー」と「開発チーム」で、プロダクトバックログの中からスプリント バックログを決めます。
3. デイリースクラム（Daily Scrum）
毎日実施する「スクラムチーム」の短時間のイベント（ミーティング）です。(朝会とか夕会みたいなものです)スプリントバックログの進捗、今日やるべきことの確認、問題点の共有などを行います。
4. スプリントレビュー （Sprint Review）
成果物のレビューを行うイベントです。
プロダクトオーナーからは決まった仕様や方針の展開を、開発チームからは開発した機能のデモンストレーションなどを行います。
5. スプリントレトロスペクティブ (Sprint Retrospective）
スクラムチームが上手く稼働したか、次のスプリントにおける改善計画を作成するイベントです。(いわゆる振り返り会です)
生産的でポジティブな議論をするように、働きかけながらうまくいった点、改善すべき点を整理し改善に繋げます。
スクラムでは以上のイベントに則りながら、スプリントを繰り返してプロジェクトを進行してきます。
以上が、アジャイル・スクラム開発の概要です。
つまり「アジャイル・スクラム開発」とは、「スクラムのルールに則ってプロジェクト管理をしながら、アジャイルの思想で短期間かつ継続的に機能を提供していく」ということになります。
■なぜアジャイル・スクラム開発が人気なの？そのメリットとは
次に、アジャイル・スクラム開発がなぜ人気なのか？その特徴をいくつかピックアップし、ウォーターフォール開発と比較したいと思います。
理由その１：仕様や優先順位が変わることを前提とした思想
これは開発側ではなく、特にビジネス側のメリットです。
環境の変化が激しい現代では「Bの機能の優先度が高くなった」「Aの機能より先に提供したい」といった変更要望が少なくないと思います。
ウォーターフォール開発では要件定義→設計→開発→テスト→受入と進むため、工程によっては容易に変更ができず、全体的な再調整が必要となる可能性が高いですが、アジャイル・スクラム開発では1つのスプリントで提供する機能を都度決めながら進めていくため調整がしやすいです。
理由その２：実際のソフトウェアによる動作確認
ウォーターフォール開発の場合、最初の要件定義と最後の受入でしかプロダクトオーナーが関与しないため、全ての機能が完成した後になって「イメージと違った」「もっとこうして欲しかった」と言われてしまうこともあるでしょう。
アジャイル・スクラム開発ではスプリントレビューのタイミングでプロダクトオーナー(ステークホルダー)に開発した機能を実際に触ってもらいます。
そのため「欲しかった機能のイメージと合っているか」という確認が早い段階でできるため、開発チーム共に安心しながらプロジェクトを進めることができます。
理由その３：不具合の早期発見
ウォーターフォール開発は、テスト工程でまとめて不具合を検知・修正するため、不具合の数が膨れ上がり納期に影響を及ぼすリスクがあります。
アジャイル・スクラム開発では1スプリント中の開発要件を絞るため、テストで不具合が出た場合の原因特定や影響範囲の調査が限定的になり、低コスト低リスクで抑えることができます。
以上の内容を表にまとめるとこのような感じになります。
■勘違いしてはいけない！良いことだけではない、デメリットも！
ここまでアジャイル・スクラム開発の特徴とメリットについて見てきましたが、当然デメリットもあります。それに気づかず、メリットだけを見て「アジャイルにすれば何でも上手くいく」と思い込んでしまう方や、アジャイル・スクラム開発だと思っていたのに、いざ蓋を開けてみらた「あれ、これどっちかというとウォーターフォールじゃないか！」となるチームも少なくないと思います。
ここではそんなアジャイル・スクラム開発の落とし穴を私の経験を踏まえて語っていきます。
落とし穴１：仕様変更をする場合は常にトレードオフを考慮
アジャイル12の原則にもあるように、「要求の変更を歓迎する」という言葉から「アジャイルならいくらでも仕様変更しても良い」と思い込む方が多く、これが一番勘違いされやすいポイントです。
アジャイル・スクラム開発ではプロダクト開発において機能のスコープなのか、予算なのか、納期なのか、何を重視するのかによって方針が変わってきます。
例えば「納期」を重視した場合、例え要求の変更を歓迎したとしても、対応により納期が遅れてしまうのであれば断念せざるを得ません。
それでもプロダクトオーナーが仕様変更を要求するのであれば、各々合意を取った上で次のスプリントから対応し、納期や別で機能のスコープを削減するなどで調整を行いましょう。
(詳細は次の「スクラム開発で実際に1スプリントを回してみよう！」のインセプションデッキを作ろうを参照してください。)
落とし穴２：アジャイルの根源はベストエフォート
ビジネス企業とベンダー企業が協力してアジャイル開発を行う場合、IPA(情報処理推進機構)が掲げている通り、基本は準委任での契約を結ぶことがほとんどです。参照: アジャイル開発版「情報システム・モデル取引・契約書」
つまり、決められた期限内に、契約で定められた成果物の作成のために労働力を提供する、成果物納品の義務がない「ベストエフォート」になります。
アジャイル開発では開発プロセスの中で、仕様の変更や優先順位が変わることを前提としているため、成果物納品の義務を課して(つまり請負契約にして)しまうと、成果物の完成の定義が曖昧になってしまいます。
しかし、中には「アジャイルのようなスタンスとスピードで開発を進めたいが、納品の義務は課せたいため請負契約で進めたい」といお客様もゼロではありません。
もし請負契約で契約を進めると、納期が決まっていて、ベンダー企業は成果物納品の義務があるにも関わらず、開発の途中で仕様が変わりまくる炎が上がりそうなプロジェクトができあがってしまうわけです。
アジャイル開発では契約による縛りを設けるのではなく、ビジネス企業とベンダー企業がお互いを信頼し合いながら成果物の完成に力を注ぐことが重要になってきます。
落とし穴３：最低限必要なドキュメントの不足
アジャイル12の原則にもあるように「動くソフトウェアこそが進捗のもっとも重要な尺度となる」という言葉から「詳細設計書を完璧にすることよりも、動くソースコードを書きなさい」と読み取れるため、詳細設計書を廃止するプロダクトがほとんどです。
ここまでは間違っていません。しかし、詳細設計書だけでなくドキュメント類全般を廃止、もしくは後回しにする発想にまで達してしまうと危険です。
アジャイル開発では開発プロセスが持続可能であることも原則に含まれています。ドキュメント全般を廃止したり後回しにすると、「ドキュメントが無いので、Aさんがいなくなったら機能を修正できる人がいない」、「新しくプロジェクトに参画してもらったBさんがソフトウェアの仕様を知りたいのに、ソースコードベースでしか解釈できない」といったことが起こり持続可能なプロセスが破綻してしまいます。
ドキュメントの命名は各プロジェクトによってそれぞれだと思われますが、Webアプリケーションの開発を例とした場合、最低限これだけは作成していくべきと私が考えているものを一覧にします。
落とし穴４：開発の生産性向上のためにコストがかかる
アジャイル開発はスピード感を持って機能を提供できるため、開発期間が短くなる分、ウォーターフォール開発よりコストが下がると考える方もいらっしゃいます。
実際、アジャイル・スクラム開発ではスプリントを繰り返すことでチームとしての生産性が向上したり、不具合の早期発見によるリスク回避により、結果的にコストが下がる可能性はあります。ですが、この「チームとしての生産性が向上」を導くまでの環境を整えるまでに、現状ではウォーターフォール開発とは違ったコストが必要となってきます。
まず、ウォーターフォール開発との大きな違いは「開発者の役割」です。
ウォーターフォール開発では各工程ごとに必要なスキルが決まっているため、特定の工程のみ担当できるスキルの方を募集すれば問題ありません。
一方、アジャイル開発の場合、持続可能なプロセスとするために、各工程を開発チーム全員で担当します。
そのため「1人で要件〜テストまでを一貫して担当する」、もしくは「担当できるように育成していく」必要があります。
もうこの時点でお分かりだと思いますが、特定の工程のみ担当できるエンジニアと、全ての工程を一貫して担当できるエンジニアを比較すると、後者の方が市場価値（単価）が高いです。
いまのところ、一貫して担当できるエンジニアの数はそれほど多くないので、現状の人員を育成しながらプロジェクトを回していくことが多いです。人材を育成するためには、ある程度の回数、スプリントを回す経験を積んでもらう必要があります。新規でアジャイル開発のプロジェクトを立ち上げる時には、このような育成も考慮した計画を立てる必要があることを忘れないでください。
人に対してばかりスコープを当てていましたが、開発を行う環境に関しても忘れてはいけません。アジャイル・スクラム開発はスプリント単位で機能を提供していくため、機能提供の仕組み(ソフトウェアのデプロイ)が自動化できていないと手間が増え、逆に生産性が低下する恐れがあります。
自動化するためのCI/CDツールは当然コストがかかりますが、ここは惜しまず導入することを強くオススメします。
■スクラム開発で実際に1スプリントを回してみよう！
ここまでで、アジャイル・スクラム開発がどういったものなのかが見えてきたと思います。
ここからはスクラム開発をする(したい)場合、どのように進むのか、よりイメージを掴んで頂くために例題をあげて実際にスプリントを回してみたいと思います。
例題 会社への来客/受付対応で利用するタブレット用アプリケーションをスクラム開発しよう
この例題をもとに、具体的にステップ毎にご説明します。
0.インセプションデッキを作成しよう
まず真っ先にやることは要件定義でも実装でもありません。
スクラムチームの全員が同じ目標に向くために、「インセプションデッキ」をプロダクトオーナーが作成します。
インセプションデッキとは、プロジェクトの全体像(目的、背景、優先順位など)を明確にするための資料としてRobin Gibson氏が考案したものです。
参照: The Agile Inception Deck
以下のような内容をスライド形式でまとめていくのが一般的です。
・何のためにプロジェクトに取り組むのか？(背景とゴール)
・プロジェクトの概要(どんなものを作り提供していきたいのか？)
・プロジェクト内で優先すべきことは何か？(スコープ/予算/納期/品質)
特に「プロジェクト内で優先すべきこと」は、プロジェクトの中で判断ポイントの大きな軸となってきます。
王道と言われる「スコープ」「予算」「納期」「品質」などから、どれを優先するのか「トレードオフ・スライダー」を作成し、プロジェクトの指標を明確化しましょう。
ちなみに、トレードオフスライダーのメモリの位置を同じにすることはNGです。メモリ位置を同じにする＝優先順位を同位にすると、「このプロジェクトでは納期を最優先にする。そのためなら予算を超えても…」といった判断が行えるようになってしまうためです。
今回の例題であれば、以下のようなインセプションデッキになります。
この資料を元にキックオフを行い、全員の意思統一を図ってからスプリントを
スタートしましょう。
1.バックログリファイメントで開発する機能の仕様と優先順位の確認をしよう
それではスプリント開始のために、プロダクトバックログの作成と整理（バックログリファイメントBacklog Refinement）をしましょう。
*refinement=洗練する、精製する、区分するなどの意味
例：プロダクトオーナーが作成したプロダクトバックログ
バックログリファイメントでは、プロダクトバックログをもとに以下のような観点で話を進めていきます。
・提供機能の優先順位は変更ないか
・提供機能の仕様変更はないか
・画面デザインや具体的な動作イメージはすり合わせできているか
開発チームAさん：「来客者情報は何を入力してもらいますか？」 プロダクトオーナー：「お名前と会社名と連絡先電話番号だけにしましょう。」 開発チームBさん：「来客通知はメールですか？それとも社員用のチャットでしょうか？」 プロダクトオーナー：「社員用のチャットでお願いします。」
これらの観点から情報の精度をあげていき、開発チームが設計やコーディングに着手できるレベルにまで持っていきましょう。
(1回のバックログリファイメントで全ての機能を整理する必要はありません。直近のスプリントで対応をする分だけで構いません。)
2.スプリントプランニングで、1スプリントでやることを決めよう
ここでは主に以下のような作業を行います。
・本スプリントの目標決め
・プロダクトバックログから本スプリントで行うストーリーの選定
・ストーリーのタスク化(細分化)
・タスクのポイント見積もり
重要なのはストーリーのタスク化とタスクのポイント見積もりです。
ストーリーを選定した上で、具体的に何をしなければいけないのか、それがどれぐらい重たい作業なのかをチーム全体で話し合いながら決めていきます。
特にストーリーのタスク化では対象機能の開発に目が行きすぎて、本来最初に考えなければいけないアプリケーションのベース開発や、データモデルの設計などが明文化されずに蔑ろにされがちです。
実際は開発チームがよしなにやることでも、プロダクトオーナーが認識していなければ「なぜ1機能の開発でこんなに時間がかかるのか、生産性が低いのでは？」と思われてしまうこともあります。
必要なタスクはチーム全体で共有し認識し合うことが、信頼できるチームを作るために必要不可欠です。
タスクのポイント見積もりはプランニングポーカーがおすすめです。
プランニングポーカーとは「1、2、3、5・・・」といったフィボナッチ数列が書かれたカードを利用し、タスクの規模を相対的に見積もる手法のことです。
基準となるタスクを決め、そのタスクのポイントを1もしくは3とした時、他のタスクはどれくらいのポイントとなるのかをチームで話し、合意した数値をポイントとして設定します。
もし、チームメンバー内で提示したポイントが違っていたら、それぞれの意見を聞き合いましょう。
開発チームAさん：「私はアプリケーション開発の経験があまりないのですが3にしました。このタスク簡単ですよね？」 開発チームBさん：「いや、アプリケーションのベースをここで一緒に作る必要があるから、13くらい必要かなと思いました。」 開発チームAさん：「確かにそうですね。。。他にも失念してることあるかもしれませんね。」
このようにチームメンバーのスキルや経験が異なれば、タスクを見積もる観点や発想も違ってきます。ポイントの過剰/不足を無くしていくために意見を言い合い、合意して進めることが重要になります。
本スプリントで必要なポイントの合計値が出せたらスプリントを開始しましょう！スプリントの期間は1週間もしくは2週間が一般的です。
最初は流れを掴むために1週間毎に、慣れてきたら2週間毎に切り替えるパターンが多いです。また、スプリントの開始を火曜日や水曜日に設定するのをオススメします。月曜日の方がキリがよく思えますが、日本では月曜日に祝日が重なることが多いため、スクラムイベントのリスケをしなくて済むように、週の中日に開始を設定することが多いです。
3.デイリースクラムで進捗確認をしながら課題解決をしよう
スプリントを開始したら、毎日15 ~ 30分のデイリースクラムを実施しましょう。
ここで重要なのは
・一方的な進捗確認だけにならないようにすること
・課題や懸念点などがあれば早めに共有し、早期解決を目指すこと
・30分以内に収めること
具体的にどこまで進んでいるのか、現状のスケジュールに問題ないのか、現時点で課題や懸念などの不安要素はないのかを、チーム内で共有することで、「よく確認したら実は遅延していた」、「タスクに余裕が出ているので助っ人できる」、「実はチーム内で同じ課題にぶつかっており、解決方法が見つかった」といった課題の発見や解消できることがあります。
各メンバーにオンスケジュールなのかどうかを聞くだけでなく、それぞれが状況を把握し、チームでキャッチアップができるようにしましょう。
また、各メンバーの作業時間をしっかり確保するために、スクラムイベントの時間はなるべく順守し、余計なミーティングを増やしすぎないように注意しましょう。
4.スプリントレビューで動くものを見せよう
スタートから1週間が経ちました！それではスプリントレビューを始めましょう。もしタスクの完了が間に合わず、レビューできない場合は、素直にその理由を共有してください。
実施したタスクが設計であれば、データモデルや業務フローなどの資料展開と説明を。アプリケーション開発であれば、実際に動くアプリケーションをプロダクトオーナーやステークホルダーに見て触ってもらいます。
今回の場合、実際に作ったアプリケーションをタブレットにインストールし、タブレットごと触ってもらうことが理想的です。
ただ、タイミングによっては難しい場合もあるので、開発チームのローカル環境で画面を共有しながら、という方法でもありだと思います。
作ったアプリケーションを触り終わったら、OK/NGの判定をプロダクトオーナーからもらいましょう。
OKなら対象機能をリリース、もしくは次のスプリントで残りのタスクを進めていくという流れになります。注意点として、NGの場合は本スプリントを延長するのではなく、次のスプリントに持ち越し、そこで改善のタスクを行うようにしてください。
決められたスプリントの中で終わったか、終わらなかったかを厳密に判断し、チームの生産性を正確に測ることが重要です。
5.レトロスペクティブでチームの改善をしていこう
スプリントレビューが終わったらレトロスペクティブ(振り返り)をしましょう。
レトロスペクティブでは、見積もりをしたポイントの達成率の確認と、チーム改善につなげる作業を行います。
まず、この数値のことを「ベロシティ」と呼び、チームが1スプリントで消化できるポイントの基準となります。
ベロシティとスプリントプランニングで算出した必要なポイントの合計値の乖離が大きい場合は次のスプリントで設定するタスクの量やポイントを調整しましょう。
チーム改善ではKPTというフレームワークを利用することが多いです。
KPTとはKeep/Problem/Tryのそれぞれの頭文字を取った言葉となります。
・Keep：良かったこと
・Problem：悪かったこと
・Try：次に挑戦/改善すること
チーム内でKPTそれぞれに5分の記載時間と10分の発表時間などを設け、以下のようにボードにまとめていきます。
レトロスペクティブ内で会話が弾むように、Keep（良かったこと）から始めるのをお勧めします。また、Keepの中に感謝のコメントなども含めると、よりチームの結束力が高まるのでこれもお勧めです。
Problem（悪かったこと）からTry（次に挑戦/改善すること）への展開は、Problemを深掘りしていき、誰がいつ何をするかまでTryに落とし込めると良いでしょう。
なるべく具体的にするのが重要で、「がんばる」や「なんとかする」といった感情や曖昧な表現にならないように注意しましょう。
レトロスペクティブが完了したら、次のバックログリファイメントを開始しましょう！
■まとめ
いかがでしたでしょうか？アジャイル・スクラム開発は奥が深く、書ききれていないことがまだまだ沢山あります。
ウォーターフォール開発の経験が長い方にとっては考えてしまうことも多く、手を出しづらいかもしれませんが、「考えすぎずに一度やってみる、もしうまくいかなかったらしっかり振り返りましょう！」というのが、アジャイル・スクラム開発の思想なので、思い切ってチャレンジしてもらえればと思います。
アジャイル・スクラム開発にチャレンジしたい！スキルアップしたい！という方は、ぜひ一緒に働きませんか？
●エム・フィールド採用ページ
-メンバーインタビュー （1日の仕事の流れ／やりがい／仕事内容）
-プロジェクトストーリー （プロジェクトでの実績／苦労エピソード）
●募集ページ
プリセールス/ エンジニア/ クリエイター/ データサイエンティスト /営業・コンサルタント /コーポレート /サービス企画 /教育担当
