コンテンツにスキップ
Scrum Knowledge Graph

開発者 (Developer)

概要

Section titled “概要”

開発者（旧・開発チーム／チーム）は、スクラムにおいてプロダクトバックログの要求を利用可能な「完成」したインクリメントへと具体化する専門家集団である。設計、実装、テスト等を担う機能横断的かつ自己管理型の構成員であり、作業手法の選定や日々の計画を自律的に遂行する。テスト駆動開発やクリーンコード等の技術的卓越性の追求に加え、アーキテクチャの不確実性軽減に向けた実験やスパイク等の技術計画活動を通じて品質を担保し、顧客ニーズの具現化を直接担う。明確な優先順位とタイムボックスで持続可能なペースを維持し、高い自律性を発揮することが成果の基盤となる。評価では包括的指標が重視される一方、大規模化に伴う調整負荷やビジネス知識不足への対処が求められる。

詳細

Section titled “詳細”

主な責任と業務

Section titled “主な責任と業務”
  • プロダクトバックログの項目（要求）を出荷判断可能・動作するインクリメントへと変換し[1]、各スプリントで利用可能なプロダクトインクリメントを作成することに貢献する[2][3][4][5][6][7][8][9]。また、スプリントごとに利用可能かつ有用なインクリメントを作成することにコミットする[10][11]。スプリント内でセキュアなプロダクトの構築を目指し、未解決課題の解決や機能実装に取り組む[12]。
  • スプリントゴール達成に向けたスプリントバックログの計画を作成・調整・更新する[10][11]。作業の見積りやスプリントバックログの作業選択は、開発者自身の裁量によって行われる[11]。
  • スプリントプランニングにおいて、提示された機能を実装するために必要な具体的なタスクを定義する[13]。
  • 完成の定義（Definition of Done）を忠実に遵守し、作り込み品質を確保する[10][11]。デジタルカンバンボード上でタスクを管理し、デイリーミーティングで進捗状況を更新・共有する運用も行われる[14]。
  • フローベースの運用における作業管理：フローベースのスクラムにおいては、デイリースクラムなどを通じて作業の流れ（フロー）をアクティブに管理し、一定の流れを維持・回復するためのアクションを実行する[15][8]。作業が滞っている箇所や流れを回復・維持できる領域にフォーカスして協力し[15]、ブロックされた作業項目の解除や、サービスレベル期待値（SLE）の超過リスクがある項目の完了に向けた日常的な対応する[15]。受け入れテスト（AT）を通じて顧客ニーズや利用方法を直接把握し、曖昧さを排除して重大な欠陥を防ぐ役割も果たす[16][17][18][19]。動くソフトウェアを短期間で継続的に届ける姿勢が求められる[17]。共有リポジトリを通じてチームが担当するコードベース全般に取り組み、新機能の開発や既存システムの維持・改善する[20][12]。
  • アーキテクチャの不確実性管理と技術計画活動：ソフトウェアアーキテクチャの不確実性や影響度を軽減・検証するため、デジタルカンバンボード上で機能タスクとともにアーキテクチャ仮説に対応する技術計画タスクを管理し、実験、スパイク、分析、ガイドライン実装などの活動を実行する[14]。また、各タスクに必要な作業量を見積もり、持続可能なペースを守るために作業範囲を適切に管理する[21][8]。
  • プロダクトバックログを動作する機能（プロダクト）に変える方法や具体的な手順を自分たちで決定する自律性を持ち[1][6][7]、外部からの指示を受けることなく自己組織的・自己管理的にタスクの消化や成果物の構築方法を管理し、スプリント期間中にタスクを完了させて成果物を生み出す[1][4][13][2][19]。高い自律性を持ち、タスクを完了させるための作業手法、技術、ツールの選定やスケジュール決定に共同で関与する[21]。
  • ライフサイクル全体への関与：開発だけでなく運用や保守を含めて説明責任を負い、フィードバックから継続的に学習する[11]。
  • セキュリティ教育とコードの堅牢化：セキュリティに関するトレーニングや教育を受け、脆弱性を抑えた堅牢なコードを開発・実装する[12]。
  • 指標を用いたプロセス改善：スクラムを採用する小規模企業の事例では、各スクラムチームのレトロスペクティブで、選定したプロセス指標の可視化・分析に通常15〜20分を費やしており、開発者はこうした統計や傾向のグラフを好むと報告されている[22]。Scrum チームのメンバー 182 人への調査（自己申告の横断データ）では、開発者が計画をスプリントゴールに向けて日々適応させる能力は、成功しているという認識に特に影響が大きい要素の一つだった[23]。ロバート・ボッシュの 75 人へのグラウンデッド・セオリー研究（1 社）のインタビューでは、リーダーシップを発揮していたのはスクラムマスターだけではなく、開発者もスクラムマスターのアクティビティの一部を引き受ける傾向にあることが明らかになった[24]。

組織的特徴とルール

Section titled “組織的特徴とルール”

「プロダクト開発者」とも位置づけられ、スクラムガイド等で規定されたスクラムチームにおける明確な役割および説明責任の一つである[10][25][11][13][19]。なお、「開発者」と表現される場合と、「開発チーム」または「チーム」と表現される場合がある[7][2]。特にLeSS版スクラムガイドの2024年改訂においては、「開発者」という用語自体が削除され、単に「チーム」という表記に置き換えられた[2]。スプリントにおいて価値を提供する作業をする構成員であり[15]、スプリントごとに利用可能なインクリメントを作成することにコミットする[26][27][28]。また実務のチーム編成においては、各チームがチームリーダー、プロダクトオーナー、テクニカルリードに加え、バックエンド、フロントエンド、UXなどの専門分野を横断的にカバーする複数の開発者によって構成される事例も見られる[20]。

  • 人間および自動化された存在の包含：構成員には人間だけでなく自動化された存在が含まれ得るが、複雑性への対応と認知的多様性の向上のため、少なくとも1人は人間でなければならないとされる[11]。
  • 労働環境と信頼・保護：意欲に満ちた環境と適切な支援が提供され、仕事の完遂に向けて信頼される存在として位置づけられる[17]。また、タイムボックス化された会議や明確な優先順位設定に守られた環境で作業することで、業務中断を抑え、高い生産性と集中力を維持する[21]。
  • 求められる能力と成果の基盤：効果的に機能するためにハードスキル（技術的専門知識）とソフトスキルの両方が必要とされる[19]。多職能的なスキルを持ち、自律的に作業を計画・実行する環境への適応が求められる[16]。また、高い自律性と社会技術的スキルを備えた開発者集団が、スケーリング手法の如何を問わずチームが高い成果を生み出す基盤となる[29]。組織から自らの作業を構成・管理する権限が与えられている[7][4][5][6][2][29]。スキルの専門化のみに偏らず、要求を利用可能なプロダクトに変えるための共有スキルが重視される[1][3][4][5][6][7][2][19]。一方で、主にソフトウェア開発の実装フェーズを担当し、決定された設計に基づいて構築する役割として位置づけられる場合もある[12]。
  • 多様な専門性の包含：エンジニアやプログラマーに限らず、アナリスト、研究者、マーケターなどの専門家が含まれる[11]。
  • 技術的卓越性の追求：クリーンコードやテスト自動化などのプラクティスを通じて高品質な価値を提供する[11]。
  • チームの規模：最適なチーム規模は「7±2名」と定義され、相互作用と生産性のバランスが考慮されていた[1][3]。その後「3人から9人（3人以上9人以下）」[4][5][6][7]と定義され、この基準から外れると生産性や透明性に影響を及ぼすとされていたが、「10名以下」と定義される場合もある[2]。多すぎず少なすぎない最適な人数構成が推奨される[7]。また、テストやアーキテクチャ等のサブチームの形成も一切認められず、全員がゴール達成に向けて助け合う[1][3][4][5][6][7][2]。プロフェッショナルとして相互に責任を負い、継続的な学習と改善を実践する[10][11][3][4][5][7][2]。
  • 開発者の生産性とチーム有効性の評価：コード行数やマージ時間などの個別の開発者生産性指標は文脈依存性が高いため、チーム全体の有効性を測定する上では、ステークホルダー満足度や士気（モラール）といった包括的な指標が重視される[29]。
  • 意思決定における中核的役割：アジャイルソフトウェアエンジニアリングの意思決定に関する文献では、開発者が最も頻繁に扱われる意思決定者であり（重複集計で78%以上）、特に優先順位付けとプロセスに関する意思決定では重複率80.6%を示す[30]。これは、実装作業に最も近い人々が意思決定権を持つという、アジャイル手法の分散型でチーム中心的な性質を反映している可能性があるとされる[30]。
  • 実装と検証の分離：安全重視のソフトウェア向けの Scrum for Safety（S4S）は、安全規格の独立性の要件に合わせて、設計上の配慮がテスターや統合者の判断に影響しないよう、同じスプリントの中で同じ開発者が実装と検証の両方を担当できないと定める[31]。

大規模アジャイル・スケーリングの枠組み（Nexus・SAFe）と組織変革での実態

Section titled “大規模アジャイル・スケーリングの枠組み（Nexus・SAFe）と組織変革での実態”
  • Nexusにおける役割と連携：開発者は各スクラムチームにおいて自己管理のもと具体的な設計・構築・テスト等を担当する[25]。完成の定義を満たす統合インクリメントを作成するため、他チームの開発者と密に連携する[25]。クロスチームリファインメントなどを通じてチーム間の依存関係を削減・解消し、統合インクリメントのデリバリーに向けた開発作業を実施する[25]。また、自身の知識や能力に応じてNexus統合チームのメンバーとなり、ツール導入や依存関係解決の支援する場合もある[25]。
  • SAFe導入の実態調査において、開発者はチームリーダーと共に「開発チームレベル」の役割として扱われている[27]。
  • 同調査における開発チームレベル（開発者・チームリーダー）の回答者割合は、全体回答者の8%を占めている[27]。
  • 大規模アジャイル変革期における役割：大規模アジャイル変革期において、開発チームは管理層（管理レベル）と協働してタスクの適切な割り当てやインフラ構築を実施することが不可欠なステップとなる[32]。
  • 変革成功の要因：経験豊富な開発者を効率的に登用・配置することや、開発者のモチベーションを適切に高める施策が、大規模な組織変革を成功に導く主要因として挙げられる[32]。
  • 課題調査における焦点：大規模アジャイル開発の課題調査において、利害関係者の視点に基づく分析対象として開発チームの役割に高い焦点が当てられている[32]。
  • 機能チーム内の構成とスキル多様性：大規模アジャイルの現場事例では、各機能チームに4〜5名の純粋な開発者が配置され、ジュニアからシニアまでの多様なスキルレベルの混成で編成される運用が見られる[33]。
  • ビジネス側との直接確認：イテレーション中の「ミニデモ」などを通じて、配置されたビジネスチームのオペレーターとユーザーストーリーの内容を直接確認し、迅速なフィードバックを得て要求を具体化する活動が行われる[33]。
  • 自律的な問題解決と非公式な連携：オープンオフィス環境等を活用し、異なるチームの開発者同士が非公式に議論してタスクの交換や解決策の提案を自律的に進める調整メカニズムが機能する[33]。
  • 調整とコミュニケーションの課題：大規模化に伴い、デイリースタンドアップ会議が長大化して自身への関連性が薄いと感じるなど、調整プロセスの非効率性に直面することがある[20]。
  • ボトムアップの改善への寄与：開発現場における課題感や依存関係の摩擦は、レトロスペクティブやテクニカルフォーラムを通じて共有され、会議形式やツールの利用ガイドラインの改善へと繋げられる[20]。
  • スケーリング枠組みにおけるタスク自己割り当て：スクラム、LeSS、SAFeにおいて、メンバーが実行するタスクや活動の決定は開発チーム全体の合意（グループコンセンサス）によって行われる[34]。なお、SpotifyのHack daysのような取り組みでは完全な個人決定も許容される[34]。
  • アイテムの分解と見積もりの自律性：イテレーション計画において、プロダクトバックログアイテムをタスクやストーリーに分解し、規模を見積もる自律性を持つ[34]。
  • 技術と手法の選定権限：同期イベント等において、使用する開発技術、調整手法、開発ツールを決定する完全な権限を持つ[34]。
  • バックログの自律的調整：計画フェーズではプロダクトオーナーが主導するが、スプリント実行中においてはグループ合意に基づいてバックログを調整できる[34]。
  • スプリント終了権限（LeSS）：LeSSでは例外的に、開発チームがスケジュールより前にスプリントを終了させる権限を持つ[34]。
  • スケーリング手法を越えた成果の基盤：高い自律性と社会技術的スキルを備えた開発者集団の存在は、どのようなスケーリングアプローチを採用しているかに関わらず、高い成果を達成するための共通した基盤となる[29]。
  • 大規模アジャイルでは、現場の最前線で作業を遂行する開発者と管理層との間に生じる認識ギャップを解消するために、個別視点のモデル化と調和が不可欠である[35]。

テイラリングの実態と影響

Section titled “テイラリングの実態と影響”
  • スクラムマスターの兼任：プロジェクトの技術的詳細を熟知しているという理由から、開発者の一人がスクラムマスターの役割を兼任することがある[36]。
  • スプリント外の責任とイベント不参加：スプリントの範囲外にある他の業務や外部責任が開発者に平行して割り当てられる事例が存在する[36]。また、スプリントレビューなどの主要なスクラムイベントに開発者が参加せず、一部の管理層のみに役割が委ねられるケースも報告されている[36]。
  • 兼任や外的一般タスクの影響：開発作業以外の責任やスプリント外業務の兼務が過度になると注意が散漫になり、最終的に納期の遅れを引き起こす要因となる[36]。

分散・リモート開発環境での課題と管理の仕組み

Section titled “分散・リモート開発環境での課題と管理の仕組み”
  • 信頼および支払いの懸念：分散アジャイル開発環境において、開発者はプロジェクトの中止、報酬支払いに対する信頼性の欠如、継続的なコーディネーションの不備といった課題に直面する[9]。
  • スマートコントラクトによる自動分配とペナルティ：受け入れテストに合格したユーザーストーリーに対し、スマートコントラクトを用いて暗号資産（Ether）による支払いをデジタルウォレット経由で自動分配する評価・報酬の仕組みが提供される[9]。一方で、事前に定義された締め切りを超過してタスクを完了した開発者には、スマートコントラクトによる自動的なペナルティ制御も適用される[9]。
  • 地理的分散・リモート開発における利点と課題：世界中の優秀な開発者をプロジェクトに参加させられるメリットが存在する一方[37]、リモート環境下ではコミュニケーションの遅延や会議の増大による直接的な影響を受けやすくなる[13]。また、リモート環境でのオンボーディングや、設計ルールおよび割り当てタスクの確実な理解、プロジェクトマネジメントチームとの日常的な密接連携が重要課題となる[37]。

教育技術・デザイン領域での実践事例

Section titled “教育技術・デザイン領域での実践事例”
  • デザインベース研究（DBR）とスクラムを統合したインクルーシブ教育技術プロジェクトにおいて、ソフトウェア開発者はスクラム開発チームとして位置づけられる[26]。
  • 開発者は優先順位付けされたユーザーストーリーに従い、アクセシブルなARオーサリングツールをはじめとするソフトウェア機能の実装等を具体的なタスクとして担当する[26]。
  • 単にコードを実装するだけでなく、定期的なスプリントレビューやテストを通じてユーザーの挙動・反応から得られた実証的インサイトを研究チームに共有する役割を担う[26]。
  • 分析スプリント期間中には、コードのリファクタリングや技術的負債の解消に集中し、システムの品質維持に貢献する運用も行われる[26]。

DevOps・セキュリティの自動化とログ分析の実践と影響

Section titled “DevOps・セキュリティの自動化とログ分析の実践と影響”
  • 「開発＆DevOps」グループに所属する開発者は、Webアプリケーション開発に加えてインフラ管理も担当する[28]。
  • 自動化セキュリティツールの導入は、開発者の認知負荷や手動作業の負担を削減し、迅速なデリバリーと安全性の担保を両立させるために有効であると考察されている[28]。
  • ログベースのセキュリティアナリティクスをアジャイル開発に組み込む取り組みにおいて、開発者はチームに統合され、Splunkでの検知ルール構築やFlask Webサービス等の具体的な実装作業を担当する[38]。
  • ログベース不正検知機能の統合による日常の直接的な開発業務への影響は軽微であるものの、会議や関係者との調整に伴う時間的コストが課題として挙げられる[38]。一方で、このようなシステムの導入運用を通じて開発者の潜在的な攻撃ベクターへの理解は深まり、自身の警戒感やセキュリティ意識の向上という効果が確認されている[38]。
  • 継続的インテグレーション・デリバリーの実践：継続的インテグレーションでは、チームメンバーが1日に複数回など頻繁にコードを統合・マージする[39]。また、開発者やテスターが本番環境で自身のコードに責任を持つべきだという主張があり、コードを変更したエンジニア全員がリリース期間中にオンコールするという方針（Facebookの例）が報告されている[39]。
  • セキュリティ専門の役割との協働：セキュアソフトウェアのアジャイルエンジニアリングでは、セキュリティチャンピオン、セキュリティデベロッパー、ペネトレーションテスターなどのセキュリティ専門の役割が、セキュリティに関する知識を提供してチームを支援する[40]。

人材・知識共有と技術環境の課題

Section titled “人材・知識共有と技術環境の課題”
  • 専門知識への過度な依存：技術的、設計的、またはドメイン固有の専門知識が特定の開発者やグループに偏ると、ボトルネックが生じて全体の進行が滞る原因となる[41]。
  • 離職と人材維持の難しさ：アジャイル開発は自律的で優秀な人材に依存する傾向があるため、プロジェクト終了に伴う頻繁な離職や人材の解雇が組織にとって重大なリスクとなる[41]。
  • 暗黙知の共有困難：プロセスやドキュメントよりも人を重視するアジャイルの性質上、個々の開発者が保有する知識や経験がチーム内外へ円滑に伝達・共有されにくい問題が発生する[41]。
  • テスト環境と統合の不一致：開発者が独自の開発・テスト環境を使用することにより、統合テスト環境との互換性が損なわれ、継続的インテグレーションが阻害される事例が報告されている[41]。
  • ビジネス知識と技術知識のギャップ：開発者は技術知識だけでなくビジネス知識を備え、実装とテストの両方を自律的に完結させることが求められる[42]。しかし実態調査では、開発者に関する反パターンのうち、発生するとの回答が最も多かったのは「ビジネス知識の欠如」である[42]。65%以上の回答者が「時々」「頻繁に」「常に」発生すると答えた[42]。表IXの重み付けスコアは47.02%（満点168に対する割合で、組織の割合ではない）である[42]。一方で「不十分な技術知識」の重み付けスコアは29.17%（満点168に対する割合）と比較的低く、純粋なプログラミング等の技術力よりもドメイン理解の不足が開発者の課題となりやすい実態が示されている[42]。
  • 準機能的なチームの反パターン：開発者間での多能工化が進まず、実装やテストなどの特定役割に依存してしまう「準機能的なチーム（クロスファンクショナルでない状態）」という反パターンについては、半数を超える回答者は「一度もない」か「まれ」と答えた[42]。表IXの重み付けスコアは36.31%（満点168に対する割合）である[42]。
  • 長時間のミーティングはチームメンバーの集中力を失わせることが多く、ミーティングへの参加が通常の業務タスクの準備に必要な時間を削ってしまうことも、ミーティングに対する否定的な態度につながる[43]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Developer Scrum Role
  • カテゴリー: Scrum Core

オントロジー上の位置

Section titled “オントロジー上の位置”

脚注

Section titled “脚注”

  1. Scrum Guide 2009（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Scrum Guide (LeSS Version)（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  3. Scrum Guide 2010（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4 ↩5

  4. Scrum Guide 2011 October（ライセンス: All Rights Reserved） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  5. Scrum Guide 2013（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  6. Scrum Guide 2016 — 「開発チームに作業を依頼できるのは、プロダクトオーナーだけである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  7. Scrum Guide 2017（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  8. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  9. ChainAgile: A framework for the improvement of Scrum Agile distributed software development based on blockchain — 「“ソフトウェアデベロッパー”: “n”。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  10. Scrum Guide 2020 — 「開発者はスクラムチームの一員である。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  11. Scrum Guide Expansion Pack — 「プロダクト開発者」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  12. Agile Software Development with Secure and Scrum-Centric Approach（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  13. Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered — 「参加者のうち71.2%が開発者（Developers）、17.3%がスクラムマスター（Scrum Masters）、11.5%がプロダクトオーナー（Product Owners）である。」（原文: “The participants perform different Scrum roles. Of these participants, 71.2% are Developers, 17.3% are Scrum Masters, and 11.5% are Product Owners.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  14. ArchHypo: Managing Software Architecture Uncertainty Using Hypotheses Engineering — 「並行して、開発者は後でリファインできるように、Trello上に実装されたカンバンボードにそれぞれのタスクを追加した。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  15. Kanban Guide for Scrum Teams 2021（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  16. Adoption of Large-Scale Scrum Practices through the Use of Management 3.0 — 「このアプローチにより、開発者は顧客が何を求めているのか、プロダクトがどのように使われるのかを直接把握できるため、プロセスにおける曖昧さを排除し、重大な過ちを犯す可能性を減らすことができる。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  17. Principles behind the Agile Manifesto（ライセンス: 著作権あり・告知を含む全文に限り複製可） ↩ ↩2 ↩3

  18. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development（ライセンス: CC BY 4.0） ↩

  19. A Theory of Scrum Team Effectiveness（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  20. Responding to change over time: A longitudinal case study on changes in coordination mechanisms in large-scale agile（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  21. Relationships between Agile Work Practices and Occupational Well-Being: The Role of Job Demands and Job Resources（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  22. Measuring and Improving Agile Processes in a Small-Size Software Development Company — 「メトリクスの選定が行われると、各スクラムチームのレトロスペクティブ（ふりかえり）ミーティングにおいて、チームは通常15〜20分をかけて、選定されたこれらのプロセスメトリクスを可視化・分析します。」（訳）（ライセンス: CC BY 4.0） ↩

  23. Mastering scrum with a focus on team maturity and key components of scrum — 「特に影響が大きいのは、計画を適応させる開発者の能力、優先順位を決定するプロダクトオーナーの権限、そしてすべてのイベントが確実に開催されるようにするスクラムマスターの能力である。」（訳）（ライセンス: CC BY 4.0） ↩

  24. An empirical study on changing leadership in agile teams — 「しかし、インタビューによって、スクラムマスターだけがリーダーシップを発揮していたのではなく、開発者もスクラムマスターのアクティビティの一部を引き受ける傾向があることが明らかになった。」（訳）（ライセンス: CC BY 4.0） ↩

  25. Nexus Guide（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  26. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  27. Benefits and Challenges of Adopting SAFe - An Empirical Survey（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  28. Integrating DAST in Kanban and CI/CD: A Real-World Security Case Study（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  29. Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches — 「したがって、実務担当者には、チームの有効性やステークホルダーの満足度と実証的に結びついている要因を優先し、どのスケーリングアプローチを選択すべきかについて悩む度合いを減らすことを推奨する。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  30. Decision-Making in Agile Software Engineering: A Systematic Literature Review of Models, Methods, Actors and Lifecycle Contexts — 「研究手法にかかわらず、アジャイルの意思決定に最も多く関与している役割はソフトウェア開発者であり、重複計算で78%超、重み付け計算で45%超の出現率を示した。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  31. Scrum for safety: an agile methodology for safety-critical software systems — 「S4Sでは、スクラムの各スプリントにおいて、同一の開発者が実装と検証の両方の活動を担当することはできないと定めている。」（原文: “Therefore, S4S prescribes that during each Scrum sprint, the same developer cannot cover both implementation and verification activities.”）（訳）（ライセンス: CC BY 4.0） ↩

  32. Agile Transformation at Scale: A Tertiary Study（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  33. Inter-team Coordination in Large-Scale Agile Development: A Case Study of Three Enabling Mechanisms（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  34. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  35. Building Shared Alignment for Agile at Scale: A Tool-Supported Method for Cross-Stakeholder Process Synthesis — 「両マネージャーは要求、タスクの割り当て、検証に焦点を当てた、より管理的な視点を共有している一方、開発者はソフトウェアの実装に向いた、より技術的な視点を持っている。」（原文: “Both managers share a more managerial perspective, focusing on requirements, task assignment, and validation, while developers hold a more technical perspective oriented toward software implementation.”）（訳）（ライセンス: CC BY 4.0） ↩

  36. Tailoring Choices Made in Scrum Projects: A Systematic Literature Review（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  37. An Empirical Investigation of Geographically Distributed Agile Development: The Agile Enterprise Architecture is a Communication Enabler（ライセンス: CC BY 4.0） ↩ ↩2

  38. Integrating Log-Based Security Analytics in Agile Workflows: A Real-World Experience Report（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  39. Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices — 「チームのメンバーが開発作業（コードなど）を頻繁に、例えば1日に複数回統合・マージする。」（訳）（ライセンス: All Rights Reserved） ↩ ↩2

  40. Identifying Key Activities, Artifacts and Roles in Agile Engineering of Secure Software with Hierarchical Clustering — 「彼らの主な役割は、セキュリティに関する知識を提供し、開発チームをサポートすることです。」（訳）（ライセンス: CC BY 4.0） ↩

  41. Systematic Literature Review Report on the Challenges of Agile Scrum（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  42. Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  43. Development and Validation of a Theoretical Model for Addressing Problems in Agile Meetings: A Systematic Literature Review and a Qualitative Study — 「長時間のミーティングは、チームメンバーの集中力を失わせることが多いと観察されている。」（訳）（ライセンス: CC BY 4.0） ↩