アジャイル開発版契約書の手引について再考
IPAがアジャイル開発版契約書の手引きを公開されていたのでメモ。
以下、結論のないメモ。
【参考】
アジャイル開発版「情報システム・モデル取引・契約書」~ユーザ/ベンダ間の緊密な協働によるシステム開発で、DXを推進~:IPA 独立行政法人 情報処理推進機構
『ソフトウェアが世界を飲み込む理由』 - 渡部薫 ジークラウド CEO - 経歴・略歴 - Kaoru Watanabe, Profile, Career
「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索
このタイミングでIPAがアジャイル開発の契約書の手引を公開したことには大きな意義があると思う。
その背景には、DXというバズワードがIT業界以外にも広がっていることだけでなく、製造業やサービス業でもアジャイル開発の考え方や手法を適用していかなければならない、という強い意志が働いているのではないか、と想像した。
特に、自動車業界では、テスラが電気自動車を販売するだけでなく、「自動車という空間移動を持ったコンピュータ」を実現したために、ガソリンをベースにしたエンジンの自動車を生産する既存メーカーは脅威を持っているだろう。
自動車が単に電気で駆動するだけでなく、ソフトウェアで自動車の制御やユーザ環境を常時アップデートし、自動運転も視野に入れた仕組みを実現しているからだ。
そして、Uberやカーシェアリングのように、自動車というハードを所有しなくても便利な生活ができるビジネスモデルも生まれている。
それは丁度、iPhoneが携帯電話を駆逐するだけでなく、世界中の人達の生活を大きく変えてしまった歴史をなぞっているように思える。
特に日本では、自動車業界というメーカーに経済が大きく依存しているため、影響は計り知れないほど大きく、メーカーであってもソフトウェア開発へ重点を置く方向へビジネスモデルも変化しているように思う。
だからこそ、メーカーが苦手とするアジャイル開発も必要だという認識が広がっているのだろう、と思う。
中身はサラッと読んだだけだが、発注者であるユーザ企業と受託者であるベンダーがスクラムをベースとしたアジャイル開発をどのように契約し、ソフトウェア開発を推進していくべきか、という点が書かれている。
準委任契約をベースとした契約の内容は具体的に書かれていて参考になる反面、何となく、もう少しビックリするような、刺激を受けるような内容がなくて、もう少し読み直してみたくなった。
たぶん、具体的な経験談に相当するような内容は、公式資料として書きにくい部分もあったのだろう、と推測する。
僕は、従来のSIがやっていたWF型開発とは価値観そのものが違うから、従来のリーダーや開発メンバーは総入れ替えして、新たなチームを作るべき、みたいな過激な発言を期待していたのかもしれない。
アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索
個人的には、倉貫さんが言う「「全部つくらない」を前提をした契約は保証されるのか」という観点があるのか、もう一度読み直してみたいと思う。
従来の一括請負契約が好まれていた理由は、全部作ることを想定した契約を結ぶことで、それが実現できない開発リスクをベンダーに一方的に押し付けることが、発注者が好んでいたからだ。
アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change!
DXのように、そもそもゴールが不明確なソフトウェア開発は一括請負契約にはなじまない。
PoCのように、仮説検証しながらあるべきソフトウェアを策定していく開発にも一括請負契約はなじまない。
他方、従来の準委任契約でDXやPoCを進めても、いつまで経っても完成しないソフトウェアが延々と作られるだけだ。
おそらくストーリー的には、発注側がプロダクトオーナーとしてソフトウェア開発に大きくコミットすべきであり、受託側のベンダーへのリスクを減らし、お互いにWin-Winとなる関係を築くような契約にすべき、ということだろうと推測する。
しかし、発注側のユーザ企業と受託側のベンダー企業という全く組織文化の異なる企業同士で、大規模なソフトウェア開発を円滑に進めるのは、アジャイル開発でも至難の業と思う。
その時に、そういう水と油の組織文化を持つ混成チームが持つ問題点と、アジャイル開発特有の本質的な問題点を区別して、それぞれの解決方法が書かれているのかな、と期待して読み直してみたいと思う。
個人的には、スクラムマスターの振る舞い方に鍵があると直感している。
【追記】
@papandaさんの意見では、プロダクトオーナーの振る舞い方に鍵があるという指摘。
参考にする。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmine利用成熟度モデルによる運用戦略(2026.07.12)
- なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine(2026.06.30)
- 製造業DXを支える工程管理とは?Redmineの大規模プロジェクト階層化における課題:プロジェクトツリーの設定継承と関連チケット制限の壁(2026.06.27)
「ビジネス・歴史・経営・法律」カテゴリの記事
- パランティアテクノロジーズの正体とはAI時代のSIerだ(2026.06.21)
- 【読書メモ】ミアシャイマーに学ぶイラン情勢と、社会科学における仮説検証の醍醐味(2026.03.29)
- 自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か?(2026.02.15)
- E-BOMとM-BOMの違いは何か?(2026.02.08)
- 製造業におけるPLM製品とMES製品の違いは何か?(2026.02.08)
「ソフトウェア工学」カテゴリの記事
- 脱PDCA!DXを加速する超高速戦略「KillChain」(2026.08.10)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)
- AIが設計も思考も代替する時代ではエンジニアはモデルを理解するだけの存在なのか?(2026.07.25)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
「プロジェクトファシリテーション」カテゴリの記事
- 組織変革の鍵を「聞く」体験から探る(2026.06.14)
- PM理論で読み解く日本人リーダーの弱点(2026.05.12)
- astahでPJ管理もプロセス設計もアイデア発想も全て表現したい(2025.10.25)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
「Agile」カテゴリの記事
- アジャイル開発を強化するキルチェーン進化の歴史~VUCA時代におけるモノづくりの新アーキテクチャ(2026.08.11)
- 脱PDCA!DXを加速する超高速戦略「KillChain」(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)
- AIが設計も思考も代替する時代ではエンジニアはモデルを理解するだけの存在なのか?(2026.07.25)
- 製造業の工程管理の課題とアジャイル化の壁(2026.07.12)


コメント