こんにちはラクスの iketomo です。
今回はアジャイル開発(Agile)について紹介させていただきます。
アジャイル開発の特徴やウォーターフォールと比較、弊社でのスクラムの取組事例などを紹介させていただきます。
皆様がアジャイル開発手法をどう取り入れるべきかのご参考になればと思います。
- ① アジャイル開発とは？
- ② アジャイル開発の特徴とウォーターフォール開発との違い
- 開発サイクルの違い
- ③ アジャイル開発のメリット・デメリット
- ④ アジャイル開発で気を付けるべきこと
- ⑤ スクラムの取組事例
- ⑥ アジャイル開発の関連書籍の紹介
① アジャイル開発とは？
アジャイルには「素早い」や「機敏」という意味があります。
従来のウォーターフォールモデルと呼ばれる開発手法が「技術や環境の変化」に対して仕様変更を即応することが難しくなる側面がありました。
アジャイル開発はそのような煩わしさから解放されるために作られた開発手法になります。
アジャイル開発の基本概念はあまりに有名すぎるので、割愛させていただきリンクだけ張らせていただきます。
アジャイルソフトウェア開発宣言
② アジャイル開発の特徴とウォーターフォール開発との違い
戻らないことを前提としたウォーターフォール
ウォーターフォールでは基本的に各工程（要件定義・概要設計・詳細設計）は一方通行で戻らないことを前提としています。
ウォーターフォール開発において工程が戻るということは、大きなリソースを消費することになるため、避けなければいけません。
そのため各工程では入念にレビューやチェック、関係者の承認を得て進むことになります。
ただ開発をしたことがある皆様はわかると思いますが、どれほど入念にレビューしても後工程で問題が発生し仕様変更をしなければいけないことは現場ではよくあります。
例えば実装フェーズで仕様に問題があった時に「概要設計」「詳細設計」まで戻って修正し
さらには実装前にテストケースまで作っていた場合、ほとんどのテストケースを作り直しということもあり
そういった場合、そこまでに使っていた大きなリソースを無駄にしてしまうこともあります。
また実際に開発完了して顧客に検収してもらうと「まったく思っていたものと違う」と言われて呆然としまうこともあるでしょう。
そこでアジャイル開発の登場です。
戻ること（仕様変更）を前提としたアジャイル開発
アジャイル開発では戻ること（仕様変更）を前提としています。
そのため、ウォーターフォールに比べ重厚なチェックなどは行わずに
ある程度仕様が纏まったら、とりあえず作って、実物を見てもらいチェックしてもらおうという進め方になります。
見てもらう相手（承認者）は開発内部だけではなく、場合によっては顧客を含めることもあります。
承認者から違うと言われ、仕様変更になれば即対応を行います。
なぜそれができるかというと開発サークルの単位が小さいからです。
開発サイクルの違い
アジャイル開発ではイテレーション（スプリント）と呼ばれる小さいサイクルの開発を反復して行います。
通常イテレーションは1週間～長くても1カ月位の単位で反復して機能追加を行っていきます。
各イテレーションの中で設計・実装・テストを行い、必要であれば承認者（顧客も含むこともある）に実際の機能を見てもらうことになります。
見てもらった時に、もし予定外の機能要望や変更等があれば、またイテレーションのサイクルを繰り返すことになりますが、小さいサイクルなので問題がありません。
③ アジャイル開発のメリット・デメリット
アジャイル開発のメリット
前述していますが、アジャイル開発の大きなメリットは不具合や仕様変更が発生した時の手戻り・工数が少ないことです。
これにより柔軟に顧客の要望を取り入れやすく、顧客ニーズに最大限に答えることができます。
また要件がはっきり決まっていない案件でも作りながら見てもらいながら開発を進めることができるのでそういった案件にはアジャイル開発が向いているでしょう。
アジャイル開発のデメリット
全体のスケジュール・予算が見えずらい
アジャイル開発では開発初期に全体のかっちりした仕様を決めずに、仕様変更を許容しているため、全体像がぼやけています。
仕様変更・追加を繰り返していくと、当初計画から大きくスケジュールがずれてしまうこともあります。
この点については下記の対策をする必要があります。
・仕様変更などを考慮し、バッファをもったスケジュールにしておく
・全体進捗を監視し最終的な納期に間に合うかどうかを常に判断する
・顧客とスケジュールのずれについて合意しておく
開発工数が大きくなったり、スケジュールが伸びてくると、予算・リソースについても同様のことが言えます。
全体が見えずらいため、ある時に予算オーバーとなってしまった。開発リソースが確保できなくということもあり得ます。
・仕様変更・追加に伴い予算追加の議論ポイントについて顧客と合意する
・リソースが大きくなった時に、確保できるように関係各署と交渉しておく
といった前準備が必要になるでしょう。
アジャイル開発とウォーターフォール開発のメリット・デメリットを整理すると、以下の表のようになります。
④ アジャイル開発で気を付けるべきこと
アジャイル開発≠ドキュメントを作らない
ウォーターフォールのように重厚なドキュメントを作るということではありませんが
アジャイル開発においても場合に応じて各種ドキュメントを作成し、要求者と認識が合っているかを確認することが必要です。
適時のコミュニケーションと確認
小さいサイクルだから作った後に見てもらえば大丈夫！！という考え方は間違っています。
小さいサイクルと言えども、何度も繰り返し修正が積み重なると、大きなリソースを失いますし、進捗せずにスケジュールが伸びてしまいます。
あれ？と迷った時や疑問に感じるならば、即時で各関係者へ確認することによって、修正の度合いを減らすことができます。
どちらのケースでも言えますが、仕様変更・追加があっても修正するから確認しなくても大丈夫。
ということではなく、あくまで修正は少ない方が良いという考え方をバランスよく持ち合わせる必要があります。
顧客にチーム参画してもらう
顧客が忙しくて見ることができません。最後にできたものを見ます。という状態に陥るとアジャイル開発の意味をなさなくなります。 開発前にしっかりと顧客と事前合意して、チームの一員となってもらい、各イテレーションごとの成果物を見てもらいましょう。
⑤ スクラムの取組事例
スクラムとはアジャイル開発の手法を取り入れたフレームワークの1つで最も有名な開発手法の１つになります。
弊社で実際にスクラム開発手法を取り入れたチームの状況を説明させていただきます。
配配開発チームでのスクラムの取り組み
不確実性の低減
スクラム導入前の開発チームはスケジュールの遅延が多発し、メンバーは疲労していたのですが
スクラム導入によって、チームで少しずつ解消していきました。
ただ、導入当初はタスクを順番通りに進めていくというウォーターフォール的な進め方で開発していたため、重要なタスクが後の方に残ったり、個人の遅れがそのままチームの進捗遅れに繋がってしまっていました。
これを打破するため1週間毎のスプリント反復開発とカンバンを導入しました。 カンバンによって終わらないタスクが可視化され、終わらないタスクはスウォーミング（問題のある所に人が集まり解決する）でチームで解決していきました。
1週間毎に計画・振り返りを行うことで、プロジェクトが進むごとに計画の不確実性が低減していくという良い循環になりつつあります。
改善文化の醸成
スプリント毎の振り返りで改善のアイデアを出し合うことを反復することでチームメンバーに改善の文化が醸成されていきました。
こういった意識が芽生えたことで「顧客から始める」というアジャイル原則に回帰し
チームの在り方、将来のロードマップを作るという、より本質的な改善を行うことができました。
詳細な記事は下記をご覧ください。
speakerdeck.com
楽楽明細開発チームのスクラムの取組
失敗から学びとスクラムとウォーターフォールの融合
楽楽明細の開発チームでは2019年春～スクラムの取り組みを始めました。
スクラムを取り入れたものの当初は大きな課題にぶつかってしまいました。
開発した成果物を営業・企画に見てもらうと「思っていた機能と全然違う！！」と言われてしまい
大きな仕様変更が発生。
「多分こうだろう。違ってもスプリントごとに見てもらえるからまぁ大丈夫か。」といった過信が原因です。
そこで
「小さめの案件は今まで通りのアジャイル開発」
「大きめの機能はウォーターフォールとアジャイルの融合」といったやり方に方針変更。
大きめの機能は要件定義の段階で前よりは詳細に設計を進めることにしました。
今では小さな手戻りはあるものの大きな手戻りはなくなり効率よく開発を進める事ができています。
・スクラムの取組で良かった点
昔は開発メンバーが増えてきたが1人の熟練技術者に設計が依存していてボトルネックになることが課題でした。
アジャイル開発手法の導入で設計フェーズが軽量化されたことによりボトルネックが分散され全体の開発力・スピードが向上することができました。
また営業・企画がスプリントごとにフィードバックしてくれることで、営業・企画との連携・風通しが良くなってます。
詳細な記事は下記をご覧ください。
speakerdeck.com
⑥ アジャイル開発の関連書籍の紹介
SCRUM BOOT CAMP THE BOOK
スクラムのことを知るならまずこの本。アジャイルの必読入門書。 www.shoeisha.co.jp
アジャイルサムライ
アジャイルとセットで語られる事が多い手法やプラクティスが一通り網羅されており、アジャイルのマインドや全体像を抑えることができる、アジャイルの現場の教科書。 shop.ohmsha.co.jp
みんなでアジャイル
手法が中心の書籍が多い中で、顧客からはじめるのがアジャイルであると言い切っている点で貴重な書籍。 www.oreilly.co.jp
アジャイルレトロスペクティブズ
アジャイルに挑戦するときに多くの人が最初に取り組み、馴染み深いが実は奥が深い「ふりかえり」にスポットを当てた、ふりかえりの教科書とも言うべき書籍。 shop.ohmsha.co.jp
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
アジャイルに取り組む中で直面する様々な課題に向き合うためのマインドや行動様式を48のパターンを通して学ぶことができる。 www.maruzen-publishing.co.jp
スクラムガイド
言わずと知れたスクラムのルールブック。スクラム実践者の多くが経験を積めば積むほど結局ここに立ち戻るとも言われている。 https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
アジャイルマニフェスト
アジャイルの原典にして原点。 agilemanifesto.org
今回ご紹介したアジャイル開発のご紹介が、これからアジャイル開発を導入を検討されている方々の一助となれば幸甚です。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
forms.gleイベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com
