スクラムまとめ

ソフトウェアの開発でよく言われるアジャイル開発。その中でもスクラムというやり方についてまとめます。スクラムガイド やScrum.incのアグレッシブスクラム、Scrum Starter Guideを参考にしています。

スクラムの概念

公式ガイド

• スクラムガイド（日本語）
• スクラムガイド（英語）

公式ガイドのサブタイトル

サブタイトルに、「The Rules of the Game 」とある。スポーツのルールブックのような感覚で書かれたことが読み取れる。

スクラムを作った人

スクラムは、Ken Schwaber と Jeff Sutherland が開発

スクラムの定義

• 複雑で変化の激しい問題に対応するための 作業管理フレームワーク
• for リーン生産方式（トヨタ生産方式）with アジャイル開発宣言
• 3役割、5活動、3共有ツールを駆使してスプリントを繰返し・漸化的に進める方法論

スクラムの用途

• 軽量で理解しやすいが、習得難易度は高い。
• 複雑で変化の激しい問題に対応するためのフレームワーク
• プロダクトの研究、開発、追加、保守、刷新など

向き不向きで考えると以下

• 向き
  • リーンスタートアップ、MVP、、、
  • アジャイル、PoC、スモールスタート、
  • 日本ピラミッド型の受託開発構造（理想的に自己組織化されると指示不要）
• 不向き
  • 大型建造物
  • ウォーターフォール開発
  • 長期間（1か月以下での成果報告が考えにくい）
  • 大人数（体制図ありき、サブチーム多数）
  • 日本ピラミッド型の受託開発構造（通常は作業指示系統と完成がグレー）

多段型の受託開発の場合、下請けがスクラムを完全に理解していれば、フレームワークに則って指示不要で動けます。そういう契約にしましょう。

しかし、下請けがスクラムを理解してなかったり誤解していると、作業指示・号令などは偽装請負ギリギリのグレーゾーンに直撃しかねません。また、成果物の定義が曖昧になりがちです。ご注意ください。

スクラムにおける経験主義

• スクラムは経験主義をベースにしている。
• 経験主義とは知識は経験に由来するという考え方。

スクラムの3本柱は下記

• 透明性
• 検査
• 適応

「経験主義だから透明性・検査・適用の３本柱です」という日本語訳でしたが、急に経験主義だからと言われると飛躍を感じました。

「経験主義をスムーズにチームに適用するために、スクラムとして3本の柱が必要と考えた」というニュアンスでしょう。

透明性(Transparency) 　＝透明度を保て！

「透明性」という単語は私は日本語としてなじみがなかった。

原文の「Transparency」は透き通り具合の話で、「透明性」「透過性」「透明度」といった日本語訳が出てきます。

「透明度」から、水の透明度をイメージするとわかりやすい。

水の濁り具合によって物事の見通しは悪くなります。濁る原因を取り除いたり、定期的にろ過したり、場所を変えたり、色んな工夫が必要になるでしょう。

「水の透明度」のように「澄み渡った環境」を維持すべきと理解しましょう。

検査(Inspection) 　＝　現物検査せよ！

英語ではインスペクションです。訳すと「検査」となるのですが、インスペクションは直接的な検査です。

例えば、ソースコードの検査として「コード」は見ずに「テスト結果報告書」を検査するのは、検査の一種としては正しい。しかしこれはインスペクションではありません。ソースコードそのものを検査するのがコードインスペクションです。

なので、「現物検査」という言葉でどうでしょう。

適応(Adaptation)　＝　臨機応変に！

Adaptionだけを見ると、「適応」とか「順応」とかです。

しかし、現場レベルに「順応」してねと伝えるのは誤解が起こりそう。日本語における「順応する」は、悪い環境でも我慢して悪い方に順応してしまうケースがある。例えば、スクラムっぽく活動しているけど実態がウォーターフォール開発の現場に「順応」されても困る。

スクラムガイドでの解説をみると、例示がAjustment（調整）の話ばかりだ。つまり、「臨機応変にやれよ」ってことが言いたいようだ。これはガイドがわかりにくい。

日本語だとひとつの単語なのに、外国語では表現に困るニュアンスってのは存在するようです。
例えば「KAIZEN」（改善）や「MOTTAINAI」（勿体ない）などのように。。。

ここは「RINKI-OUHEN」（臨機応変）だと思う。

スクラムが重視する価値観

• 確約（commitment）
• 勇気（courage）
• 集中（focus）
• 公開（openness）
• 尊敬（respect）

上記を価値基準としている。

価値基準の補足

チーム活動になるので価値基準は重要です。スクラムガイド（日本語訳）には以下のように続きますが、この翻訳は日本人向けには誤解を与えます。まずは日本語版の翻訳から。

• 個人は、スクラムチームのゴールの達成をコミットしなければいけない。
• スクラムチームのメンバーは、正しいことをする勇気を持ち、
• 困難な問題に取り組まなければいけない。
• 全員が、スプリントの作業とスクラムチームのゴールに集中しなければいけない。
• スクラムチームとステークホルダーは、課題を公開することに合意しなければいけない。

「～しなければならない」のオンパレード。

表現が強くて、排他的な原理主義者が現れる原因になる。この翻訳は現場に伝えたくありません。

実際に、愚直に読み取った結果、価値基準の合わないメンバには「ご遠慮」いただくことを実践したケースも聞いたことがあります。うまくいけばよいのですが、日本の組織でそうは問屋が卸さないケースは多々あります。少なくとも私は恐ろしくてそのようなチームにいたくありません…心理的安全性や幸福度の概念が欠けている気がしませんか。

さて、原文を読むと「must」でも「have to」でもなく「should」も使われていません。そこまで強い表現とは思えません。

さらに、「challenges」を「課題」と訳してしまっているのも誤解のもとです。「挑戦中の課題」というニュアンスだと思いますが、まだ「チャレンジ」とした方がマシです。

原文と意訳

• People personally commit to achieving the goals of the Scrum Team.
  • 個人はチームに達成をコミットするんだよ。
  • （引き受けたタスクはやり遂げてね）
• The Scrum Team members have courage to do the right thing and work on tough problems.
  • チームで勇気をもって適正な物事と課題に取り組もうね。
  • （協力してズルせずに問題に当たろうね）
• Everyone focuses on the work of the Sprint and the goals of the Scrum Team.
  • 全員でスプリントのゴールに向けて集中しよう。
  • （コソコソ割り込み作業などに浮気すんなよ）
• The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.
  • チームとステークホルダは、挑戦中のもの含むすべての実行業務を公開することに合意してね。
  • （現状の全ての「ワーク」と「チャレンジ」を公開するよ。チームも利害関係者もそこんとこヨロシク。）

スクラムの基本構成

スクラムのルールについて

スクラムガイドには、ルールという表現が多用されている。

しかし、ルールそのものを解説する項があるわけではないです。進め方、法則、規則、各構成要素の関連性などニュアンスとしては様々な意味合いを包含していると解釈すると読みやすい。

スプリントについて

• スクラムの中心的な開発単位。
• 長さが一定の開発サイクルのことで、これを繰り返す。
  • １スプリントで１つ以上のリリースを可能とする１期間
  • プロダクトとチームの性質を考えてスプリント期間を決める。
  • １週間～4週間の中で決めたらその期間は固定。
  • 例えば１スプリント＝２週間と決めたら、２週間を繰返し行う。

長くても１か月というのはポイント。多くのデータが長期間のPJほど無駄が多いことに起因。

スクラムの構成要素（3-5-3）

スクラムルールは、下記の3-5-3で構成される。（参考資料）

• 3つの役割（3 Roles）
• 5種の会議（5 Activities)
• 3種の共有ツール（3 Social Objects)

3つの役割（3 Roles）

• プロダクトオーナー（POと略す場合あり）
• 開発チームメンバー（TMと略す場合あり）
• スクラムマスター（SMと略す場合あり）

チーム内の役割。チーム外にもステークホルダーがいる。

5つの会議（5 Activities)

• バックログリファインメント
• スプリントプランニング
• デイリースクラム
• スプリントレビュー
• スプリントレトロスペクティブ

Activitiesとなっているが、あえて会議と訳した。
スクラムでは実施可能な会議を決めておくことで、余計な会議を排除するニュアンスを込めた。
日本の企業は会議多すぎ。

3種の共有ツール（3 Social Objects)

• プロダクトバックログ
• スプリントバックログ
• 見える化ツール

原文は「３つのソーシャルオブジェクト」という言葉になってます。ソーシャルオブジェクトは Jyri Engeström の造語。
人をつなげるもの。共有や議論の対象といったニュアンスとして共有ツールと訳してみました。ソーシャルオブジェクトというままでもよかったかも。
英語資料のArtifactsから「作成物」と訳されているものも見られるが、共有というニュアンスがなく成果物のような意味合いが強くなるため、作成物という翻訳は誤解の元で避けた方が良いと考える。
最近では情報ラジエータという言葉も見かけます。情報の等価交換装置のニュアンスとしてこのセクションに当てはまるのかもしれない。

スクラムの実践とはどういうことか

以下のような表現となっている。

• スクラムの一部だけを導入も可能だがそれはスクラムとは言えない。（スクラムガイド）
• 3-5-3のないチーム活動はスクラムを実践していると言えない（アグレッシブスクラム）

日本語で表現すると印象として厳しい表現。

もし、会社が「スクラム導入しろ、KPIだぞ」などと言えば、厳密にガイドに従うとする原理主義的な考えを持つ人が出てきてしまいそう。

スクラムの根本にはアジャイルの思想がある。変化への対応やコミュニケーションを「より重視」するべき。

価値の最大化が目的。原理主義に走ってしまうことで本来成し遂げたかったことを見失わないことが大事。

一方で「ScrumBut 」というアンチパターンもあるようなで、やはり最初は愚直にやってみるのが正解への近道。

スクラム関連の詳細やTips

３つの役割の関係と責任分担

役割名	責務	主な作業内容
プロダクトオーナ	価値の最大化	プロダクトバックログの内容と優先順位の確定
開発チーム	価値の具現化	バックログからインクリメントを生成
スクラムマスター	透明性の最大化	スクラムの円滑な活動への奉仕
ステークホルダー	真の価値の伝達	フィードバックの提供

インクリメントとは、バックログのDone定義をクリアした成果物のこと。過去の成果物からの増分や蓄積のニュアンスが込められている。

3種の共有ツールの概要

参考ページ

プロダクトバックログ（Product Backlog)

プロダクトバックログは、プロダクトに必要と把握されている事柄の一覧。
プログラムバックログの一つ一つの項目をプロダクトバックログアイテム（PBI）と呼ぶ。
ユーザストーリ＝PBIとして扱うケースは多いらしい。

全体として、バックログありきの説明が多く、ガイドにはバックログそのものを生成するイベントは見かけません。バックログ不足の場合はリファインメント会議の議題にしてよいかもしれません。

スプリントバックログ（Sprint Backlog)

• スプリントゴールを達成するための計画
• 「完成」に必要な作業について開発チームが予想したタスクの一覧

スプリントプランニングで確定させる。

見える化ツール

ガイドでは特に定義してません。見える化は視認性の肝です。スクラムの柱「透明度」につながります。

よって、視認性確保のためには、１つのツールにこだわらず日々進化していきましょう。

とはいえ、フレームワークとしてまず取り入れるべきものとして下記が示されています。

• スクラムボード（カンバン）
• バーンダウン
• ストーリポイントによる見積
• ベロシティの測定による適切なキャパシティプランニング

情報ラジエーター

情報ラジエータなる言葉も使われ始めているらしい。バーンダウンやスクバムボードのような作業状況を視覚化するツールの位置づけのようだ。（⇒参考サイト）

ラジエータという言葉は、日本では冷却装置的な使われ方が多いためわかりにくい。恐らく情報の等価交換装置のニュアンスと思われる。例えば、

• 周りの状況を知るツールであると同時に、自分の状況を伝えるツール
• 課題を提示すると同時に、周囲の課題を手伝うツール

そういうツール群を指して情報ラジエータという言葉を使おうとしている理解をしたのだが、一般的に浸透しているようにも見えず、情報収集が追い付いていない。今後の動向を見守りたい。

5つの会議の目的・参加者・時間目安

スプリントはプロジェクトで一定の期間で定義する１か月以下のタイムボックス
下記表の時間目安は、１スプリントが1か月とした場合。

会議名	目的	時間目安
バックログリファインメント	バックログをレディにする	10%程度？
スプリントプランニング	スプリントバックログの完成	最大8時間
デイリースクラム	モチベーション維持・向上	最大15分
スプリントレビュー	フィードバック収集	最大4時間
スプリントレトロスペクティブ	振り返りとカイゼン計画	最大3時間

バックログリファインメント関連

バックログリファインメントでは、荒いバックログを細かくしていく。最終的にREADYのバックログにもっていくことが目標。

バックログが枯渇気味の場合は、バックログの生成も議論の対象にしたい。

INVEST：バックログのREADY条件

REDAYの条件として、INVESTが満たされているとよいとされている。

Immediately actionable	着手可能
Negotiable	交渉可能
Valuable	有意義
Estimable	見積れる
Small	小さい
Testable	テスト可能

ユーザストーリの考え方

• Who、What、Whyを満たすのが良いとされる。
• 「誰にとっての」「何ができることにより」「何が達成できるか／結果／価値」
• 日本語は省略しても文章が成立してしまうので曖昧に傾向がある。具体的に書く。
  • 誰
    • 具体的で意味のある役割・ロールで書く
  • 何ができる
    • 対象にたどり着くための手段
    • 操作対象のデータやオブジェクト
    • 対象に対する実現したい具体的な操作内容
  • 価値を具体化する
    • 達成できてほしい具体的内容
    • もたらされる結果、状況
    • 結果に対する定量的・定性的な価値

受入れ基準

• ルール基準とシナリオ基準の2つの考え
• ルール基準
  • チェックリスト形式
• シナリオ基準
  • Given/When/Then フォーマット
    • Given：（条件）シナリオによってもたらされた条件
    • When：（操作）どのような動作を行ったら
    • Then：（期待）どのような結果になる。
  • 例
    • 管理者ロールを付与されたら
    • システムにログインすると
    • 管理者メニューにアクセスできる
    • 管理者ロールをはく奪されたら
    • システムに再ログインすると
    • 管理者メニューは非表示になる。

ストーリポイントとプラニングポーカ

• 作業時間を見積もることの弊害
  • 人は、８時間と見積もった仕事を２時間で終えると６時間サボる習性がある。
  • 人は、８時間と見積もった仕事に１６時間かかるとモチベーションが低下する。
• ベロシティという考え方
  • 速度v= 距離d/時間t　という一般的な速度の式に当てはめる
  • vはverocityで速度のこと。スクラムではこれをベロシティという単語でそのまま使う。
  • ベロシティは目標への到達速度でありチームが1スプリントで進むことができる距離である。
  • 時間は働く時間。
  • 距離mに相当する値が未知のため、ストーリポイントという概念でメンバーの経験をベースに見積もる。
• ストーリポイント
  • ベロシティ測定の距離に相当するものを見積もる
  • 実際の作業者になりうる全員で見積る
  • 大まかなサイズを見積る。
    • 洋服に例えると、S,M,L,XL,XXLといったサイズ。個々人のサイズを見積もるようなオーダメイド方式にしない。大よそあってればよいと考える。
  • 大まかのサイズはフィボナッチ数列が丁度よい
    • 1, 2, 3, 5, 8, 13, 21, 34,,,,　
    • S,M,L,XL,XXL といったサイズでもよいかも。ただしベロシティ図るのに数値化が必要。
  • 0, ?, 休憩　などもあってよい。
    • 0はタスクに作業発生なしまたは実現済み。
    • ?は見積もれない要素がある。
    • 休憩いわずもがな。
  • リファレンスストーリを決めそれを５として見積もるとやりやすい。
  • 「何時間で終わるか」という発想にならないように注意する。
  • チームが洗練されても同じ作業は同じストーリポイントとなるのが望ましい。（どんなに手段が洗練されても東京-大阪間の距離感は変わらない。いつの間にか東京-横浜間の距離感に変わってしまっては相対的な見積もりにならない。チームの感覚的な相対値でよく、絶対値でなくてよい）
• プランニングポーカ
  • フィボナッチ数列の書かれた見積もりカード
  • メンバは該当ストーリのサイズを考えテーブルに伏せる。
  • 全員がテーブルに伏せたのを見計らって同時にオープンする
  • フィボナッチの連続する3数字に収まれば平均をとる。収まらなければ、最大値、最小値の人は根拠を共有してやり直す。
  • 2回（多くて3回）で収まらなければ、最大・最小を除外して平均をとる。
  • ケンカNG。ケンカするくらいなら適当に決める。

テスト可能であること＝Done定義＋受入れ基準

バックログは、バックログDone定義と受入れ基準を満たして「完成」となる。

• Done定義
  • チーム共通の品質基準を定義する
  • コードならば、ユニットテストでカバレッジX％以上など
  • 参考 Doneの定義のサンプル ／ Doneの定義のサンプル(2)
• 受入れ基準
  • POの立場で完成を判断に使うクライテリア（判断基準）
  • Done定義と異なり、バックログごとに基準は異なる。

スプリントプランニングの進め方

「What」と「How」 ２部構成を意識する。（参考）

「What」何を実施するかを決める

POとチームで決める

• ベロシティと実働計画を確認する。（実働とは休暇・祝日など考慮した働ける時間）
• ベロシティと実働から、次のスプリントのキャパシティを決める
• スプリントのゴールを設定する
• READYバックログを優先順位の順番でスプリントバックログへ移動
• キャパシティ＞ストーリポイント合計　となることを確認
• バックログごとの受入れ条件を確認・確定
• Done条件の再確認

初めてのスプリントの場合、ベロシティ不明のためキャパシティが不明。データが蓄積されるまでは、適当に計画し、結果論で分析する。

スクラムは経験主義であり未経験で未知の領域には滅法弱い。ゆえに経験値を稼ぐことが最優先だ。

「How」どうやって実現するかを決める

チームで決める。REDAYなバックログをどうやって実現するかをタスク化する。
参考：スプリントのタスクに関するTips29個

• どうやったらバックログを実現できるかの作業タスクを洗い出す
• １つのタスクは５時間以内の、相当正確に見積り可能なサイズとする。
  • 見積工数は人時で決める。
  • ２日以上Doingに滞留するタスクはおかしい。
• タスクはデイリースクラムでの軌道修正を許容する。

デイリースクラムの進め方

目的

• スプリントゴールを目指すチームメンバのモチベーション維持・向上
• 今日も一日がんばろう、という気持ち作り

手段

• ゴール認識の再確認・再計画
• 情報共有・情報公開の促進
• タスク状況の確認・見直し
• 毎日同じ時間・同じ場所
• 短時間で（MAX１５分くらい）
• 立ち会議
• ボードの見えるところで会議
• ３つの質問
  • 昨日何したか（実績）
  • 今日何するか（予定）
  • 困り事・心配事がどこにあるか。（課題・リスク）
• パーキングロット
  • 長くなる話題は、終わってから必要メンバが残る。

目的は「一日のメンバのモチベーション維持・向上」です。
「よっしゃやるぞ」という気持ち作りです。

その解決手段に「立ち会議」や「３つの質問」があるのです。もし手段が合わなければ別の方法を考えましょう。

「毎朝」「立ち会議」で「３つの質問」やればOKとして、無気力な朝会が続くようなケースは一度チームで考え直した方が良いです。やらされ朝会はメンバのモチベーション低下だけでなく情報発信をしなくなったり透明度の低下を招きます。

スプリントレビューの進め方

参加者

• 重要ステークホルダー
• PO、開発チーム、SM

目的

• ステークホルダーからのフィードバックや協力を得ること

参考

• スプリントレビューの進め方
  • 特に「ステークホルダーへの質問（例）」や「こんなスプリントレビューには気をつけよう」は参考になります。

スプリントレトロスペクティブの進め方

目的

• ふりかえりとカイゼン計画の立案

よくあるやり方

• KPT
  • Keep（継続すべきこと）、Probrem(やめるべきこと）、Try(挑戦すべきこと）
  • K、P、Tを並行で議論するような進み方。
• YWT
  • Y（やってみたこと）、W（その結果わかったこと）、T（次に挑戦すること）
  • Y⇒W⇒T　と順番にストーリ性をもって検討
  • 個人的にはKPTと比較し、やってきたことを思い出しがら検討しやすくてオススメ。
• 幸福指標（ファイブフィンガー）
  • ５本が幸せ全快、１本が幸せ全壊として、せーので意思表示する。
  • 指の数とその理由を共有する。指の数は重要ではない。
  • 指が少ない＝悪いこと　ではない。。

バックログ vs 要件定義

ウォーターフォールでは「要件定義」が未確定だと先に進まない開発プロセスである。そして、要件定義工程は、上流工程とされチームメンバはあまりタッチしません。開発チームはコーディング大好き軍団として要件を待っています。

チームメンバは「要件まだですか？」「そんな要件ではやれませんよ？」などの受け身のスタンスとなりがちです。

スクラムの場合に当てはめて、同じようなモチベーションが持ち込まれると「バックログがなくて進まない」というケースが発生しかねません。

実現すべき価値がない、なんて、スクラムってそういうことが起こりうるプロセスなの！？
では、もし、バックログが枯渇した場合、誰の責任だろう？

「バックログに責任持ってるのはプロダクトオーナなのでは？」と考えがちでは？
ちなみに、私は勘違いしたことがあります（汗

もし、バックログの生成はPOの責務と勘違いすると
POに負荷が集中し、バックログの枯渇状況が発生しかねません。

でも、本来、POの責務は「価値最大化のためのバックログの優先順位付け」。

バックログの生成ってスクラムガイド見ても、誰でもいつでも作ってよく、定義されたイベントに紐づかないから、宙に浮きそうです。

書籍「カイゼンジャーニー」では、コーディングに集中したいチームが、POにバックログの生成から、リファインメントまで押し付けるシーンで揉めます。このシーンでのチームビルディングは参考になります。

個人的には、バックログが不足した場合も、バックログリファインメントの場で、バックログの補充をテーマに議論するのが良いと考えます。

スクラムマスターの腕の見せ所ですかね。

受託開発文化やウォータフォールの思考回路になってプロセスに違和感が出た場合、立ち止まって良い考えを探してみましょう。

結合テスト・総合テストに相当するスプリント？

ウォーターフォール的な発想だと、「結合テストは？」「総合テストは？」となる。

その前に、ウォータフォール思考のリリースとスクラムのリリースは違う。リリースの違いを整理したい。

• スクラムでは１スプリントで１つ以上の「リリース」を行う。
• ウォータフォールでは、すべてのテストを実施して「リリース」を行う。

冷静に考えればわかるが、「リリース」の単位が違うしニュアンスも違う。

ウォーターフォールでは「リリースする」＝「納品する」＝「売上成立」という受託開発の契約の話まで包含してイメージしてしまう。一瞬でお金のイメージまで飛躍するウォータフォール思考の人に話を分かってもらうのは至難の業だ。

スクラムの場合、スプリントで完成できた「価値」をリリースする。完成できたストーリーポイントが大小はあるが、それは単にチームの実力を示すだけの話。

ここに「１スプリントあたり、２０ストーリポイントこなしたら、ｘｘ万円」とかないし、そういう契約は絶対しちゃダメ、絶対ダメ。マジでダメ。ストーリポイントは、チームごとに感覚の異なる感覚値なの。

さて、このように「リリース」の考えも粒度も異なる。

では、ウォーターフォールでいうところの、結合テストや総合テストはどう考えるか。

スクラム的には、各テストのチェック項目を細かい「価値」に分解できるはず。

• 結合テストなら「ｘｘシステムとつなげてｘｘ機能が動作確認できること」とか
• 総合テストなら「ｘｘを行うシナリオが確認できること」とか、「ｘｘ人が同時に利用しても性能が維持できること」とか。

スクラムなら、これらをストーリとしてバックログに起こして、リファインメントしてこなせば良いと考えてはどうでしょう。ウォーターフォール時代に定義した品質項目の一つ一つに価値があるはず。

そう考えると、ウォーターフォールの場合「総合テストとは何をどう確認したか」が不明なまま 「総合テストしたからリリース」という恐ろしいことが発生したりするんです。それでも、受託開発なら「納品がOK」ならば「売上」が上がるという契約に直結している話。なんと恐ろしいす。。。世の中にデスマーチがなくならない一つの要因でしょうね。

契約関連：『そもそも契約の問題じゃない』ということ

スクラムを含むアジャイル系で外部委託を含めた取引契約は、何かと苦労やトラブルが起きやすい傾向にあった。IPAではこうした状況を踏まえ、2020年3月31日に、契約ケースを想定したアジャイル開発版「情報システム・モデル取引・契約書」を公開。今後の業界でまず参考にする指標にしたい。

アジャイル開発版の「情報システム・モデル取引・契約書」発表

また本件の検討に携わった木下史彦のnoteには、その検討へのこだわりや苦労が記載され非常に参考になるので必見。『そもそも契約の問題じゃない』ことを十分に理解したもの通しで契約を進めることを薦めている。

そもそも契約が問題なのではなく、アジャイル開発をユーザ・ベンダ双方が都合よく解釈していたり、アジャイル開発を適用するための前提条件が揃っていないのに無理にアジャイル開発をやり方を当てはめてしまったうことがトラブル原因としては多く見られる。

IPAからこのようなメッセージを出すことができたことは非常に意義深い。

IPA の アジャイル開発版「情報システム・モデル取引・契約書」

参考サイト

• スクラムガイド
• アグレッシブスクラム、
• Ryuzee.com 、 Scrum Starter Guide