「今回はアジャイルで進めます」と言われたとき、発注する側は何を期待し、何をすればよいのでしょうか。
アジャイル開発は「ベンダーがいい感じに作ってくれる方法」ではありません。
IPA（情報処理推進機構）と経済産業省のモデル契約は、アジャイル開発を効果的に進めるには、プロジェクトの主体であり開発するプロダクトに責任を持つユーザー企業が、主体的かつ積極的に開発に関わる必要がある、とはっきり述べています [G3]。
この記事では、アジャイル宣言、スクラムガイド、IPA・経済産業省のモデル契約という、公式の資料を根拠にアジャイルとスクラムの基礎を整理します。
注記：契約についての内容は、IPA・経済産業省のモデル契約の説明にもとづく一般的な整理で、
法律上の助言ではありません。
実際の契約は案件ごとに異なるので、法務の専門家にご確認ください。
3つの要点
| 要点 | ひとことで言うと |
| アジャイルとは（詳細①） | 計画どおりに進めることよりも、変化に対応し・動くものを早く届けて・フィードバックを受けながら改善する、ということを重視する考え方。 |
| スクラムとは（詳細②） | アジャイルの代表的な進め方。 「スプリント」という短い期間を繰り返し、決まった役割・会議・成果物で運営する。 |
| 発注と契約（詳細③） | 一般に、完成を約束する「請負」ではなく、業務の遂行に対価を払う「準委任」の契約を使う。 その分、発注側の関与と判断が重要になる。 |
ウォーターフォールとの違い
IPAのモデル契約は、開発対象全体の要件と仕様を確定してから開発に進む「ウォーターフォール方式」とアジャイル開発を対比しています。
アジャイル開発では、開発のプロセスの中で、開発する機能の追加・変更やその優先順位の変更が行われます [G3]。そのため、当初は開発する予定だった機能を、ビジネス環境の変化などに応じて開発の対象から外すこともあります [G3]。
| ウォーターフォール | アジャイル | |
| 要件・仕様 | 最初に全体を確定する | 進めながら、追加・変更・優先順位の見直しをする。 |
| 完成の考え方 | あらかじめ決めた成果物を、決めたとおりに完成させる | 優先度の高いものから、順に開発・リリースし、反応を見て改善する。 |
| 向くもの | 最初に要件を固めやすいもの | 変化が大きく、状況に応じて価値を見直したいもの。 |
注記：表の「向くもの」の行は、IPAのモデル契約の記述（アジャイル開発の特徴）から、
私が整理した目安です。
モデル契約が、この2つの方式の優劣を述べているわけではありません。
読み進め方
参照元
[G1] Manifesto for Agile Software Development（アジャイルソフトウェア開発宣言） — https://agilemanifesto.org/
[G2] Ken Schwaber & Jeff Sutherland, The Scrum Guide（2020年11月版） — https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
[G3] IPA・経済産業省, 情報システム・モデル取引・契約書＜アジャイル開発版＞ アジャイル開発外部委託モデル契約 R1（2020年3月、2025年4月 R1） — https://www.ipa.go.jp/digital/model/ug65p90000001ldr-att/000081484.pdf
コメント