Zenn
Accenture Japan (有志)
🔥

# アジャイル開発を学びなおそう

sakaki
に公開
agile
project
idea

はじめに

私たちってアジャイル開発できているのか、、なんちゃってアジャイルになっていないか。アジャイルの効果をフルに生かせているか。。新人にアジャイル開発を説明して理解してもらっているか。。
私たちのプロジェクトでは上記の疑問が生まれたため、原点に振り替えるべくアジャイル開発についてもう一度考えるため以下の記事を作成しました。
必要な部分を抜粋してプロジェクトで読み合わせできるといいなと思っています。

1. アジャイルとは何か？その誕生と歴史

アジャイル開発は 2001 年 2 月、ユタ州スノーバードで 17 名のソフトウェア開発者が集まり「アジャイルソフトウェア開発宣言」を採択したことに端を発します。ウォーターフォール型の計画主導型開発に対するアンチテーゼとして誕生し、変化と顧客価値を最優先に置く文化が根付いていきました。

年表ハイライト

  • 1991: ラピッドアプリケーション開発 (RAD) 登場
  • 1995: Scrum プロセス公開 (Jeff Sutherland, Ken Schwaber)
  • 1999: XP 本格提唱 (Kent Beck)
  • 2001: アジャイル宣言採択
  • 2005: Lean Software Development 普及
  • 2011 以降: DevOps ムーブメントと融合

参考リンク

2. アジャイル宣言 4 つの価値と 12 の原則

目的

  • アジャイルの核心となる価値・原則を明文化し、判断基準を統一する。

期待される効果

  • チームメンバー全員が同じ価値観で意思決定できるため、衝突や迷走を防止。
  • レトロスペクティブで原則に立ち返ることで、改善ポイントを構造化できる。

本文

4 つの価値

  1. プロセスやツールよりも個人と対話を
  2. 包括的なドキュメントよりも動くソフトウェアを
  3. 契約交渉よりも顧客との協調を
  4. 計画に従うことよりも変化への対応を

アジャイルソフトウェア開発宣言に基づく 12の原則 は以下のとおりです（公式サイトより全文翻訳）：

アジャイルソフトウェア開発の12の原則（Principles behind the Agile Manifesto）

  1. 顧客満足
    　早く、かつ継続的に価値あるソフトウェアを提供することにより、顧客満足を最優先とする。

  2. 変化の要求を歓迎する
    　たとえ開発の後半であっても、変更要求を歓迎する。アジャイルプロセスは顧客の競争優位性を高めるために変更を活用する。

  3. 動くソフトウェアを頻繁にリリースする
    　数週間から数ヶ月の間隔で、できるだけ短い時間スケールで動くソフトウェアを頻繁に提供する。

  4. ビジネス担当者と開発者は日々協力する
    　プロジェクトを成功させるために、ビジネス担当者と開発者は日常的に密接に連携する。

  5. 意欲ある個人を中心にプロジェクトを構成する
    　適切な環境と支援を提供し、仕事を成し遂げる彼らへの信頼をベースに構成する。

  6. フェイスツーフェイスの対話を重視する
    　情報伝達の最も効率的で効果的な方法は、対面での会話である。

  7. 動くソフトウェアこそが進捗の最も重要な尺度
    　プロジェクトの進行状況を測る上で、動作するソフトウェアを唯一の評価基準とする。

  8. 持続可能な開発を推進する
    　関係者（開発者、ビジネス側、ユーザー）は、一定のペースで無理なく作業を継続できるようにする。

  9. 技術的卓越性と優れた設計に絶えず注力する
    　アジリティ（俊敏性）を高めるためには、常に高い技術水準と良い設計が必要である。

  10. シンプルさ――作業しないことの最大化――が本質である
    　やらなくてよいことをやらないようにするシンプルさが最重要。

  11. 自己組織化チームから最良のアーキテクチャ、要件、設計が生まれる
    　最良の設計や仕様は、上からではなく、チームの中から自然に生まれる。

  12. チームは定期的に振り返り、より効果的になるよう調整する
    　一定の間隔でチームはどのようにより効果的に働けるかを内省し、それに応じて行動を最適化する。

参考リンク

3. アジャイル主要フレームワーク

目的

  • Scrum、Kanban、XP の特徴を比較し、自チームに最適な手法を選択・適応する。

期待される効果

  • フレームワークごとの強み／弱みを理解し、状況に応じてハイブリッド運用が可能になる。
  • 新人には実践の全体像、シニアにはコーチングの指針を提供。

本文

3.1 Scrum

  • 役割: プロダクトオーナー、スクラムマスター、開発チーム
  • イベント: スプリント、スプリントプランニング、デイリースクラム、レビュー、レトロスペクティブ
  • アウトプット: プロダクトバックログ、スプリントバックログ、バーンダウンチャート
  • 新人 Tips: Definition of Done を壁に貼り出し、完成の基準を共有しよう。
  • シニア Tips: メトリクスを KPI として強制せず、チームが自律的に改善に使える "情報の鏡" にする。

3.2 Kanban

  • 特長: WIP 制限、リードタイム短縮、フロー効率最適化
  • ボード例: Backlog → Ready → In Progress → Review → Done
  • 新人 Tips: カードは 1 タスク 1 カード。途中で細分化が必要なら分割する勇気を。
  • シニア Tips: ボトルネックの列が赤信号。週次でサイクルタイムヒートマップを確認する。

3.3 XP (eXtreme Programming)

  • プラクティス: ペアプログラミング、テスト駆動開発 (TDD)、リファクタリング、継続的インテグレーション
  • 新人 Tips: Red → Green → Refactor のサイクルを 5 分以内で回す「ベビー・ステップ」思考を体得しよう。
  • シニア Tips: ペアやモブを “教育装置” として位置づける。新人の成長速度はチームの資産。

参考リンク

4. 役割と責務：新人の視点・シニアの視点

目的

  • 役割ごとのミッションを明確化し、期待値ギャップを防ぐ。

期待される効果

  • 新人は自分の成長ロードマップを描ける。
  • シニアはメンタリング計画を立てやすくなり、属人的なフォローを防止。

本文

役割 主な責務 新人が学ぶこと シニアが提供すること
開発メンバー 設計・実装・テスト ドメイン知識・コード規約 コーチング・コードレビュー
プロダクトオーナー ビジョンと価値最大化 ビジネス言語の翻訳 要件の優先順位づけ支援
スクラムマスター ファシリテーションと障害除去 セレモニー運営 サーベイ＆リスニング

Reflection

  • 新人: 「自分の役割が曖昧だ」と感じた瞬間を書き出す
  • シニア: そのギャップを埋めるためにどんな“場”を用意できるか？

参考リンク

5. セレモニーとイベント徹底解説

目的

  • 各イベントの意図を理解し、形骸化を防ぐ。

期待される効果

  • イベントが“儀式”でなく“価値創出の場”になる。
  • タイムボックスを守ることでチームのリズムが整う。

本文

スプリントプランニング

  • 目的: ゴールと達成手段を合意する
  • アンチパターン: PO が一方的にタスクを割り振り、開発者のコミットメントが無い

デイリースクラム

  • 典型フォーマット: 昨日やったこと / 今日やること / 困りごと
  • 新人 Tips: ステータス報告の場ではなく、同期と障害共有の場。

レトロスペクティブ

  • ステージモデル: Set the Stage → Gather Data → Generate Insights → Decide Actions → Close
  • シニア Tips: “お祭り”ムードを忘れず、小さな成功を祝う。

参考リンク

6. プランニングと見積り技法

目的

  • 予測可能性を上げ、顧客へのコミットメントを強化する。

期待される効果

  • ストーリーポイントによる相対見積りで会話が活性化。
  • モンテカルロシミュレーションでリスクを数量化可能。

本文

  • ストーリーポイント: 相対見積りで複雑性とサイズを可視化
  • Planning Poker: 合意形成をゲーム化しバイアスを低減
  • モンテカルロシミュレーション: 過去のベロシティからリリース日を予測

新人練習課題: 過去 3 スプリントの実績から、次スプリントの計画を Excel で組んでみよう。

参考リンク

7. 技術プラクティスと品質保証

目的

  • 高速なデリバリーと品質を両立し、技術的負債を抑制する。

期待される効果

  • TDD により回帰バグ減少、リファクタリングしやすい設計。
  • CI によりインテグレーションリスクを早期発見。

本文

テスト駆動開発 (TDD)

  • サイクル: Red → Green → Refactor
  • 得られる効果: 回帰テスト網、設計のモジュール化、安心と速度の両立

継続的インテグレーション

  • Pipeline 例 (GitHub Actions)

    jobs:
  build:
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node
        uses: actions/setup-node@v4
      - run: npm ci && npm test

ペア／モブプログラミング

  • 学習加速度: シニアの暗黙知をリアルタイム継承

参考リンク

8. CI/CD と DevOps：デリバリーを高速化する仕組み

目的

  • コードから本番リリースまでのリードタイムを最小化し、価値提供サイクルを高速化する。

期待される効果

  • リリース頻度向上によりフィードバックが早まる。
  • 障害発生時の MTTR 短縮。

本文

  • Continuous Delivery: デプロイ可能な状態を常時保つ
  • Continuous Deployment: 自動で本番リリース
  • DevOps カルチャー: 開発と運用の壁を溶かし、共同責任を持つ
  • 新人ワークショップ: Docker でローカル→ステージ→本番を 1 コマンドで動かす

参考リンク

9. チームダイナミクスと心理的安全性

目的

  • 信頼と挑戦が両立する環境を作り、チームパフォーマンスを最大化する。

期待される効果

  • メンバーが躊躇なく課題を共有し、改善提案が活発化。
  • 離職率低下、イノベーション創出。

本文

  • 心理的安全性の 4 段階 (Timothy R. Clark): Inclusion → Learner → Contributor → Challenger
  • シニア行動指針: ミスを隠させない “弱さの開示” をリードが率先
  • 新人セルフチェック: 毎日「質問できたか」自己採点 (1~5 点)

参考リンク

10. メトリクスと改善：可視化の科学

目的

  • データドリブンでプロセスを継続的に改善する。

期待される効果

  • スループット・リードタイムの可視化によりボトルネックを客観的に特定。
  • 改善施策の効果を定量評価できる。

本文

カテゴリ 指標 目的 高値/低値の解釈
スループット ベロシティ キャパシティ予測 安定 ≠ 高速、変動を抑える
リードタイム Idea → Prod アイデアの価値化速度 長い = ボトルネック警告
品質 バグ率、MTTR 顧客信頼 低 MTTR = 回復力高

参考リンク

11. スケールするアジャイル：SAFe / LeSS / Scrum@Scale

目的

  • 複数チーム・大規模組織でもアジャイル原則を損なわずに拡張する。

期待される効果

  • プロダクトポートフォリオ全体で価値の流れを最適化。
  • 横断課題の整合性を保ちながら各チームの自律性を維持。

本文

  • SAFe: ポートフォリオ、ART、PI プランニング
  • LeSS: Scrum 規模化最小限、機能横断チーム
  • Scrum@Scale: スクラムオブスクラムと PO サイクル
  • シニアの役割: ガバナンスかマイクロマネジメントかの分岐点に注意

参考リンク

アジャイル開発・新人とシニアのための徹底振り返りガイド

（前略）

12. リモート・ハイブリッド時代のアジャイル

目的

  • フィジカルな距離があっても、アジャイルの原則と効果を維持するための工夫を学ぶ。

期待される効果

  • 非同期・同期コミュニケーションの使い分けが上手くなり、チームの認知負荷を抑えられる。
  • 孤立の防止と、偶発的な協力関係の促進。

本文

  • ツール活用: Miro, FigJam, Zoom, Slack, Discord などでコラボレーションと情報共有を促進。
  • 仮想空間でのつながり: “雑談部屋”や“バーチャルオフィス”で偶発的な会話を再現。
  • タイムゾーンの配慮: Follow the Sun モデルで引き継ぎがスムーズに行えるようなドキュメント文化を構築。
  • 非同期の強化: 書き言葉ベースのやりとりを推奨し、議論や設計プロセスを文書に残す。

参考リンク

13. よくある失敗とアンチパターン

目的

  • アジャイル実践中に陥りがちな誤解・悪習慣を理解し、チームで予防策を講じる。

期待される効果

  • 反復的な振り返りの質が向上し、根本原因の特定がしやすくなる。
  • チーム文化の健全化に寄与する。

本文

  1. ScrumBut: 「スプリントはやるがレビューやレトロスペクティブは無し」など、都合のいい部分だけを切り取って運用。
  2. WIPモンスター: Kanban ボードの「Doing」に20件以上のタスクが滞留。流れが停滞しているのに気づかない。
  3. ヒーロー文化: 一人の“神エンジニア”に依存し、ナレッジが属人化。
  4. 見積りの空気読み: プランニングポーカーで本音が言えず、チーム外の期待に合わせたポイントをつける。
  5. 改善の停滞: レトロスペクティブで同じ課題を繰り返し出し続ける。アクションの実行が曖昧。

14. ケーススタディ：新人とシニアのリアルストーリー

目的

  • 現場で起こった実際の課題とその解決を通じて、抽象的な知識を具体的な学びに変える。

期待される効果

  • 経験に基づく実感値を得ることで、新人は成長イメージを持てる。
  • シニアは他のチームのベストプラクティスを学び、引き出しを増やせる。

Case A: 新人フロントエンド開発者・ゆか

  • 背景: チームにジョインして2週間。技術力はあるがアジャイル経験ゼロ。
  • 課題: タスクの分割ができず、1スプリントで未完タスクが4つも残る。
  • 対応: スプリントプランニングの前に「ユーザーストーリーマッピング」ワークショップを実施。
  • 成果: タスクの完了率が向上。以降は毎スプリントで1件以上の改善提案を出すように。

Case B: ベテランバックエンド開発者・たくや（10年目）

  • 背景: 技術力は高く、現場のボトルネックを解消することに定評あり。
  • 課題: DB スキーマの変更が怖くて進まない。「壊したらどうしよう」というマインド。
  • 対応: テストコンテナを使った検証環境の導入、Contract Testの導入。
  • 成果: 小規模なスキーマ変更が容易になり、レガシーの改善が進む。

15. 1on1・振り返り質問リスト

目的

  • 振り返りや対話での思考の枠組みを与え、深掘りしやすくする。

期待される効果

  • 新人が自己認識を深められ、シニアは的確なフィードバックを提供できる。
  • 組織の“暗黙の課題”に気づくチャンスが増える。

質問例

対象 質問例
新人向け 「今週一番学んだことは？」 「どんなことに困っていて、どう対応した？」
シニア向け 「チームのリズムに変化はあるか？」 「後進育成に何を注いでいるか？」
共通 「今スプリントで一番良かったことは？」 「次回スプリントで変えたいことは？」

16. 学習リソースと次のステップ

目的

  • 学びの継続を支援し、アジャイル実践者として自走する力を育てる。

期待される効果

  • 自主的に学ぶ文化が醸成される。
  • 議論や提案の質が上がる。

書籍

  • 『アジャイルサムライ』（Jonathan Rasmusson）
  • 『Lean Software Development』（Mary Poppendieck）
  • 『エンジニアのためのマネジメントキャリアパス』（Camille Fournier）

オンラインリソース

コミュニティ / イベント

  • Regional Scrum Gathering Tokyo
  • Agile Japan
  • DevOps Days

次のステップ

  1. この資料から1つ実践してみたいことを Slack に共有
  2. スプリントレトロでこの資料を使ってディスカッション
  3. Notion や Scrapbox で学びの記録をつけ、月次で振り返る

Let’s build software that matters, together.

Accenture Japan (有志)
Accenture Japan (有志)

アクセンチュア株式会社に所属する社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。

Discussion