アジャイル開発の落とし穴とは？ よくある失敗を回避し成功へ導くポイントを解説

市場の変化や技術革新に柔軟に対応するために、システム開発にアジャイル型の手法を取り入れる企業が増えています。しかし、従来のウォーターフォール型開発との違いに戸惑い、せっかく導入しても期待していた効果が得られないケースも多いようです。

アジャイル開発の失敗談として「終わりが見えずに期間やコストが増えてしまった」「品質が低いものができてしまった」などの声を聞いた方も多いのではないでしょうか。
こうしたよくある失敗には、その問題を引き起こしている要因にも多くの共通点があります。

本セミナーでは、経験豊富なScrum Inc.認定スクラムマスターが講師を務め「アジャイル開発プロジェクトの落し穴」ともいえる失敗の要因と、その改善策・予防策をお伝えします。

これからアジャイル開発に取り組む方や、アジャイル開発導入のためのご支援を求めている方はぜひご参加ください。

Transcript

1. アジャイル開発の落とし穴とは？ よくある失敗を回避し成功へ導くポイントを解説 2023 / 12 / 20 NCDC株式会社
2. Business 事業領域の推進 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation • コンサルティング • 新規サービス企画 • PoC⽀援 • デザイン思考 • UX/UIデザイン • モバイル・Web先端技術 • IoT / AI / AR • クラウドインテグレーション 2 NCDCのサービス体系
3. 私たちにできること① l デジタルビジネスに必要な要素にフォーカスし、⼀元的に提供しています。 l スモールスタートでの検証から、本開発・継続的な改善までサポートします。 3 ワークショップを中⼼とし た合理的なプロセスで、ビ ジネスモデルの検討からUX デザインまで、迅速に⾏い ます。 関係者が多数いる場合の組 織横断、会社横断のファシ リテーションも得意です。 新規性の⾼いプロジェクト ではMVP（Minimum Viable Product）を⽤いた検証を⾏ うなど、⽬的に応じて段階 的な開発を企画します。 早い段階でモックやプロト タイプを⽤意してユーザの 評価を確認します。 ユーザとのタッチポイントとなる各種デバ イスのフロントエンドデザインから、クラ ウドサービスを駆使したバックエンドの開 発まで。多様なテクノロジーをインテグ レーションします。 l AI / IoT / AR l モバイル・ウェブ アプリ開発 l クラウドインテグレーション l システムアーキテクチャコンサルティング など ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善
4. 私たちにできること② l 社内に最適な組織がない場合の組織づくりや⼈材育成から、⾼度な技術をもったエンジニア による技術移管まで、幅広くお客様をサポートします。 4 ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善 企業のDXやデジタルビジネスの創出に必要なこうしたプロセスを多⾯的にサポート DX戦略⽴案 ⼈材育成 技術移管 DX組織構築⽀援 アジャイル導⼊⽀援 ⼿法や技術の選定 ブランディング 内製化⽀援
5. 自己紹介 5 ITコンサルタント 局 芳暁 （つぼね よしあき） l 入社5年目 l アジャイル開発や新規事業開発の支援 l 認定スクラムマスター l スクラム＠スケールプラクティショナー l ノーコードの調査、研究をしている l 起業経験があり、サービスインはしたもののマ ネタイズできず撤退 担当業務
6. Chapter List l Chapter1 l なぜアジャイル開発なのか l VUCAの時代に求められるアジャイル開発 l 局の起業経験談 l アジャイル開発における失敗の定義 l Chapter2 l うまくいかないアジャイル開発のパターン l よくあるアジャイル開発のトラブル l 理解不足アジャイル l アジャイル ＝ “早い、安い、うまい”ではない l 「変化に柔軟」に対する勘違い l そもそも？アジャイル l 部分的アジャイル l フェーズ分離型のアンチパターン l スコープ分離型のアンチパターン l Chapter3 l 解決策：NCDCのアジャイル方法論から引用 l 質疑応答 6
7. Chapter1 なぜアジャイル開発なのか
8. なぜアジャイル開発なのか l VUCAの時代に求められるアジャイル開発 l 変化が激しく、先行きも見通せず、複雑で、曖昧である状態 l Ｖ（Volatility：変動性） Ｕ（Uncertainty：不確実性） Ｃ（Complexity：複雑性） Ａ（Ambiguity：曖昧性） l アジャイル開発を取り入れることで、変化を受け入れ、素早くリ リースすることができる l DXの文脈でも新規サービスを立ち上げたくアジャイル開発したい という要望が多い 8
9. なぜアジャイル開発なのか l 局の起業経験談 l ミュージシャン向けコンテンツマーケットプレイスを開発 l 「アジャイル開発」という言葉さえ知らない頃で、振り返ればアジャ イル開発っぽいことはしていた l ファーストユーザーに意見を聞くまでに、およそ2000万円の開発を1年 かけて行った l ユーザーから意見を聞いた時には、ユーザーがやりたいことの機能追 加を考えると技術的負債が多すぎて、１から作り直した方がいいので はと判断 l マネタイズまで辿り着けず、資金ショート l アジャイル開発を意識して実施したわけではないが うまくいかないケースに当てはまっている 9
10. アジャイル開発における失敗の定義 l アジャイル開発では「失敗」はない l なぜならアジャイル開発は、一定のサイクルを繰り返すことに特徴を 持っており、そのためうまくいかないことをを改善していく開発手法 である l だが、うまくいかないこと、なかなか改善の糸口が見えないトラブ ルはある l 早くアンチパターンに気づいていれば、もっと早く改善ができたと いう予防策や回避策はある 10
11. Chapter2 うまくいかないアジャイル開発のパターン
12. よくあるアジャイル開発のトラブル l あまり要件は決まってないからアジャイルで開発を始めたい l 成果物が思った通りに出てこない！ l アジャイルで早く開発してリリースしたい l できたものがリリースできる品質ではなかった！ 12
13. よくあるアジャイル開発のトラブル l 既存の基幹システムのリプレイスをアジャイルで段階的にリリースし たい l 蓋を開けてみたら想定より長い期間がかかってしまった l その結果、予算超過になってしまった！ l 要件定義はきちっと固めて、開発はアジャイルで進めたい l 変更要望がうまく通らず、雰囲気も悪い・・・ l バックエンドの開発はウォーターフォールにして、変化の多いフロン トエンドの開発はアジャイルで進めたい l なかなかリリースできない状態に陥ってしまった！ 13
14. うまくいかないアジャイル開発のパターン l 理解不足型アジャイル 1. アジャイル(素早い) ＝ “早い、安い、うまい(品質が良い)” で はない l リリーススパンが1スプリント(2週、1ヶ月など)であるから、早くリ リースできることは間違いない l ≠ 安い l その時点で最も重要な要件を最優先に考えて実装するため、後から出て きた要件を取り込むために、既存機能の再設計をし直すこともある l 大規模のシステム開発や既存システムのリプレイスをアジャイルで実施 する場合、最終的な機能を揃う時点を見た際、ウォーターフォール型よ り多くの工数がかかることがある 14
15. うまくいかないアジャイル開発のパターン l 理解不足型アジャイル l ≠うまい(品質が良い) l アジャイル開発では、自動テストを組んで、一定の品質を保つのが前提 であるが、すなわち品質が高いことには繋がらない l 昨今は、複数のデバイスやOSでの運用もあることから、高い品質を保つ ためには、長期のテスト工程が不可欠である 15
16. うまくいかないアジャイル開発のパターン l 理解不足型アジャイル 2. 変化に柔軟 ＝ 仕様追加は無制限に受け入れられる ではない l リリース直前での仕様追加はもちろん、リリース日や予算に響く l 変化に柔軟だからといって、工数や予算が無限に存在するわけではない l すなわち、リリースや予算と、仕様変更・追加の天秤になる 16
17. うまくいかないアジャイル開発のパターン l そもそも？型アジャイル l そのプロジェクト、本当にアジャイルが向いている？ l 確実性が高い市場でのアジャイル開発 l 定型が決まっている業務でのシステム開発 l 業務が変わらないのであれば、ユースケース予測が可能 l システムを通して業務変革を起こしていきたい意向があるか l 既存システムの移行 l 使い慣れている既存システムから必要不可欠な機能や業務フローを定義して行く方 が結果早い l あれもあった、これもあったと追加していくことで予算、スケジュールが延びるこ とも・・・ l 規模の大きなシステム l 早くリリースできること ＝ 必要最低限の機能が早く使える ではない l リリースに必要最低限の機能が多い場合は、ウォーターフォールで進める方が、予 算、スケジュール、品質にも優しいことがある 17
18. うまくいかないアジャイル開発のパターン l 部分的アジャイル l フェーズ分離型におけるアンチパターン l ソフトウェア開発の要件定義・設計・開発・テストのフェーズのうち、要 件定義と設計という仕様決定フェーズまできちっと固めて、決まった仕様 の実装フェーズである開発とテストをアジャイルで実施する l 設計までで仕様を固めてしまい、その後の変化が多くない。そこに中途半端にア ジャイルを入れてしまったため、状況に合わせて設計書の見直しが頻発し、できあ がった成果物の品質がボロボロで、工数も膨れてしまう 18
19. うまくいかないアジャイル開発のパターン l 部分的アジャイル l アーキテクト分離型におけるアンチパターン l 変更要求が頻繁に発生する画面周りを含むフロントエンドの設計はアジャ イル、データベース設計など変更が発生しないバックエンドはウォーター フォールで行う l 両方の開発が完了するまで結合テストはできない l バックエンドをウォーターフォールで完成させてから、フロントエンドの開発をア ジャイルで行うのであれば良い 19
20. Chapter3 解決策：NCDCのアジャイル方法論から引用
21. 解決策 l プロジェクトの初めが肝心、初めを手厚く行うこと l 初めの認識合わせが結果を決める l アジャイルと言えども、なんとなくで始まると混乱が起きる 21
22. 解決策 l インセプションデッキを用いたワークショップを通して、メンバー 全員がアジャイルやプロジェクトへの理解をし、合意を得る l なんのためのアジャイルなのか、アジャイルの副作用に対してどう対 処するか l 5つのWhyと5つのHowで構成されている 22
23. 23 • プロジェクトが「何を解決したいために発足したのか？」を確認する作業です 目的 • このプロジェクト根幹に関わる理由を1つ書きます 手法 • 日本の貧困格差を是正するため • 褒められる体験を増やして自己肯定感を助長したい 例 Why we are here 我々はなぜここにいるのか Section 2 Inception-Deck
24. 24 Find your neighbors ご近所さんを探せ 目的 • 今回のプロジェクトの参加者を中心にプ ロジェクト相関図を作成します プロジェクト相関図 A社 B社 PO 代理PO レビュー ・これにより、PO、SM、エンジニア、デザイナー、ス テークホルダーの関係や決済権を明確にし、プロジェク ト遅延のリスクを回避します ステーク ホルダー 決済 観 察 競合 F社 C社 SM シニア エンジニア エンジニア デザイナー Inception-Deck Section 2
25. 25 Find your neighbors ご近所さんを探せ POの重要性の理解 • POの役割 当該プロジェクトによって作られる成果物(システムや製品)の価値を最大化させることがPOの役割 です。そのため、成果物の価値や品質に責任を持ちます。 • POは、責任に応えるために必要な裁量権限を持つ バックログの優先順位を判断し決定できる権限があることが求められます。 また、そのためにも契約内容を把握していることが重要です。 • ユーザーやステークホルダーから上がった意見を鵜呑みにしない ユーザーやステークホルダーから上がった意見に忖度を計らず、対応の優先順位をつけることができ ることが重要です。 プロジェクトの目的を把握しており、開発対象機能の取捨選択ができる必要があります。 また、収支を把握していて、予算の使い所がわかることが大事です。 Inception-Deck Section 2
26. 26 Trade-Off-Slider 目的 • プロジェクトの中で、必要な機能の取捨選択をする際に立ち返る指標です。 ・スライダーは他の項目と重ならないようにします ・下記の例では期日を最優先にしており、期日を守るためであれば予算を使っても構わず、ある程度のスコープアウ トやバグは許容する指標となっています ・プロジェクトで優先度が高い項目があれば、これとは別の指標を作成します。 スライダー 項目 機能を全部揃える（スコープ） 予算内に納める（予算） 期日を死守する（時間） 高い品質、少ない欠陥（品質） MIN MAX MIN MAX MIN MAX MIN MAX トレードオフスライダー Inception-Deck Section 2
27. 27 Trade-Off-Slider スライダー 項目 機能を全部揃える（スコープ） 予算内に納める（予算） 期日を死守する（時間） 高い品質、少ない欠陥（品質） スキルトランスファー MIN MAX MIN MAX MIN MAX MIN MAX トレードオフスライダー Inception-Deck Section 2 MIN MAX
28. 具体例 28 構築 What and how much do you need? / Determine the period 何がどれだけ必要なの？/期間を見極める 目的 • リリースまでに必要な予算、メンバー、期間をざっくり見積もります ・スプリント中にスコープが変更になった、予算が減ったという際は適時調整をします 6ヶ月 テスト 運用 • エンジニア ３名 • デザイナー ２名 • 期間 ６ヶ月 • 予算 100万円 Inception-Deck Section 2
29. 解決策２ l リリースの定義 l プロダクトレベルやテスト品質の合意を得る 29
30. 30 • 施策と直近の対象プロジェクトのスコープの確認と最終成果物の認識合わせを行います。 目的 見積や要件の大前提となる、リリースレベルの一般的概念 • MVP リーンスタートアップの中で出てくる方法論であり、Minimum Viable Product の略で、「実用最小限の製 品」と訳す MVP自体でリリースレベルの定義はしておらず、MVPの目的がどこにあるのかをプロジェクトごとに定義 する必要がある。この前提がプロジェクト途中で変わる際は、プロジェクトの仕切り直しが必要である • PoC Proof of concept、 「概念実証」という意味 新しい概念や理論、原理、アイディアの実証を目的とした、試作開発の前段階における検証やデモンスト レーションを指す リリースの定義 施策全体の目的の共有 Section 1
31. 31 施策全体の目的の共有 Section 1 名称 その他通称 製品概念 デザイン 開発環境 テスト工程 セキュリティー リリース先 デザインモック デザインのみ モックアップ（フロ ントのみ） デザインをソースコード に落とし込んだもの モックアップ（API モック） データベースからの表 示ロジックまでモックに したもの プロトタイプ α版 コンセプト、技術の実現 性（フィジビリティ）が確 定している上での製品 やシステムの試作のこ と ワイヤー程度 開発環境 結合テスト、正常 フローテスト、バ リデーションなし。 稼働端末やOSも 制約あり。 考慮なし 社内で確認程度 パイロット β版 機能範囲や対応範囲、 ユーザー数などを制限 して実行する先行的/試 験的プロジェクトのこと。 主な目的は全面展開へ 進めるかの可否判断や、 プロジェクトの有意性や 見直しの判断。 ワイヤー程度 開発環境 テスト環境：本番環境に 近いシステム構成での 実施 結合テスト、正常 フローテスト。稼 働端末やOSも制 約あり。 基本的なレベル （HTTPS等の暗号 化、認証等） 一部の一般ユー ザー ＊社内の別部署 の方もあり ＊アプリの場合、 各ストアにて限定 公開 プロダクト 正式版 販売できるレベルの製 品 デザイン、トラ ンジション、イ ンタラクション、 アニメーション を考慮 開発環境 テスト環境 本番環境 結合テスト、総合 テスト、正常系テ スト、異常系テス ト、負荷テスト、セ キュリティー診断。 テスト対象端末も 定義。 考慮あり。脆弱性診 断等の実施も検討 一般ユーザー リリースの定義例
32. 解決策３ l 全体的なアーキテクチャを描く l 新たな要望が上がった時に破壊的変更が入らないようにする l または破壊的な変更を許容した修正であることを可視化する 32
33. • 採用技術の定義後、アーキテクチャ設計書を作成する 33 S3 API Gateway Lambda Dynamo DB Lambda VPC CloudFront S3 API Gateway CloudFront SAML WAF WAF Cognito Azure AD S3 Architectural design Section 1 アーキテクチャ設計
34. 解決策４ l 共通言語集の作成 （専門用語、アジャイルの知識の認識合わせ） 34
35. 解決策５ l 定められた予算、スケジュールでどの機能を優先的に開発したいか l どの機能がないとリリースできないのか l テスト計画をあらかじめしておく 35
36. • POにて管理いただくシートとなり、スプリントレビュー にて完了の判定をしていただきます • 状況には、該当の機能の説明が終わり、開発が始まっているのかを記載します • ストーリーは、UXの鍵となるユーザーの行動を記載します • 優先度は、優先して開発すべき機能を1~3でランク付けします • 完了の定義は、なるべく実数値を伴うものとします • リファインメント（見直し）をします 36 No 状況 ストーリー 優先 完了定義 誰が 何を なぜ 1 完了 居住者 駐車場申請をする 駐車場を使いたいから 3 申請を１分以内で 終えることができるか 2 開発中 居住者 引越し申請をする 引越しをするから 2 申請後の流れを認識できたのが ５人中３名か 3 保留 工事業者 工事の日程を申請する 工事をするため 1 工事の手続きが完了する 4 未着手 フロント 掲示内容の入力をする 工事の日程を お知らせするため 3 入力を３クリック以内で 終わらせられるか Product Backlog / Refinement Design Sprint Plan Section 1 プロダクトバックログ作成 /リファインメント
37. • テストの種別は以下です。 37 テスト種別 責任者 目的 内容 成果物 単体テスト NCDC 該当の機能が単体で仕様通り に動作することを確認。 不具合の修正もスプリント内 で完了させる。 開発者が自分でテストする。APIのテスト コードを作成する。 PMが画面から操作して仕様通りであるこ とを確認。 実装物。テストと しては特になし 結合テスト NCDC スプリントごとに作成したも のを結合してテストする。 他システムとの連携がある場 合もここでここで結合テスト を行なう PM、テスターがテスト仕様書を作成して、 実施する。 開発者は不具合修正を行う必要があるため、 テスターは別のメンバーが実施する。 開発範囲外の既存システムとの連携なども あるため、お客様の協力も必須。 結合テスト仕様書 兼テスト結果報告 書 総合テスト NCDC 成果物の最終的なテスト。 本テストの結果をお客様に提 示することで、システム完成 を示す。 負荷試験やロングランニング テスト、脆弱性テスト、運用 テスト（障害時テスト）を必 要に応じて行なう。 PM、テスターがテスト仕様書を作成して、 実施する。 開発者は不具合修正を行う必要があるため、 テスターは別のメンバーが実施する。 開発範囲外の既存システムとの連携なども あるため、お客様の協力も必須。 総合テスト仕様書 兼テスト結果報告 書 ユーザー受 入テスト お客様 お客様が検収を行なうための テスト お客様が実施。NCDCはサポート。 テスト仕様書は総合テストのものを使うこ とも可能（NCDCから提供可能） 特になし Test Plan as Design Section 7 テスト計画
38. セミナーのまとめ l アジャイルといえども、初めの認識合わせが必要である l またアジャイルはうまくいかないを改善していくフレームでもある l 早いうちに気づいていれば致命的にならないことがある l とは言っても、始めの認識合わせが大事である l 改善はしていくけども、はじめの目的があっていればのこと l NCDCのアジャイル方法論でなくても、はじめのうちにプロジェクトで 認識あわせを十二分に持っておくことが重要である 38