« オンラインのリーダーシップとは何だろうか | トップページ | 「Rubyのしくみ」を読んだ後のRubyの感想 »

2020/04/01

アジャイル開発版契約書の手引について再考

 

IPAがアジャイル開発版契約書の手引きを公開されていたのでメモ。
以下、結論のないメモ。

 

【参考】
アジャイル開発版「情報システム・モデル取引・契約書」~ユーザ/ベンダ間の緊密な協働によるシステム開発で、DXを推進~:IPA 独立行政法人 情報処理推進機構

 

『ソフトウェアが世界を飲み込む理由』 - 渡部薫 ジークラウド CEO - 経歴・略歴 - Kaoru Watanabe, Profile, Career

 

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

 

このタイミングでIPAがアジャイル開発の契約書の手引を公開したことには大きな意義があると思う。
その背景には、DXというバズワードがIT業界以外にも広がっていることだけでなく、製造業やサービス業でもアジャイル開発の考え方や手法を適用していかなければならない、という強い意志が働いているのではないか、と想像した。

 

特に、自動車業界では、テスラが電気自動車を販売するだけでなく、「自動車という空間移動を持ったコンピュータ」を実現したために、ガソリンをベースにしたエンジンの自動車を生産する既存メーカーは脅威を持っているだろう。
自動車が単に電気で駆動するだけでなく、ソフトウェアで自動車の制御やユーザ環境を常時アップデートし、自動運転も視野に入れた仕組みを実現しているからだ。
そして、Uberやカーシェアリングのように、自動車というハードを所有しなくても便利な生活ができるビジネスモデルも生まれている。
それは丁度、iPhoneが携帯電話を駆逐するだけでなく、世界中の人達の生活を大きく変えてしまった歴史をなぞっているように思える。

 

特に日本では、自動車業界というメーカーに経済が大きく依存しているため、影響は計り知れないほど大きく、メーカーであってもソフトウェア開発へ重点を置く方向へビジネスモデルも変化しているように思う。
だからこそ、メーカーが苦手とするアジャイル開発も必要だという認識が広がっているのだろう、と思う。

 

中身はサラッと読んだだけだが、発注者であるユーザ企業と受託者であるベンダーがスクラムをベースとしたアジャイル開発をどのように契約し、ソフトウェア開発を推進していくべきか、という点が書かれている。
準委任契約をベースとした契約の内容は具体的に書かれていて参考になる反面、何となく、もう少しビックリするような、刺激を受けるような内容がなくて、もう少し読み直してみたくなった。
たぶん、具体的な経験談に相当するような内容は、公式資料として書きにくい部分もあったのだろう、と推測する。

 

僕は、従来のSIがやっていたWF型開発とは価値観そのものが違うから、従来のリーダーや開発メンバーは総入れ替えして、新たなチームを作るべき、みたいな過激な発言を期待していたのかもしれない。

 

アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索

 

個人的には、倉貫さんが言う「「全部つくらない」を前提をした契約は保証されるのか」という観点があるのか、もう一度読み直してみたいと思う。
従来の一括請負契約が好まれていた理由は、全部作ることを想定した契約を結ぶことで、それが実現できない開発リスクをベンダーに一方的に押し付けることが、発注者が好んでいたからだ。

 

アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change!

 

DXのように、そもそもゴールが不明確なソフトウェア開発は一括請負契約にはなじまない。
PoCのように、仮説検証しながらあるべきソフトウェアを策定していく開発にも一括請負契約はなじまない。
他方、従来の準委任契約でDXやPoCを進めても、いつまで経っても完成しないソフトウェアが延々と作られるだけだ。

 

おそらくストーリー的には、発注側がプロダクトオーナーとしてソフトウェア開発に大きくコミットすべきであり、受託側のベンダーへのリスクを減らし、お互いにWin-Winとなる関係を築くような契約にすべき、ということだろうと推測する。
しかし、発注側のユーザ企業と受託側のベンダー企業という全く組織文化の異なる企業同士で、大規模なソフトウェア開発を円滑に進めるのは、アジャイル開発でも至難の業と思う。

 

その時に、そういう水と油の組織文化を持つ混成チームが持つ問題点と、アジャイル開発特有の本質的な問題点を区別して、それぞれの解決方法が書かれているのかな、と期待して読み直してみたいと思う。
個人的には、スクラムマスターの振る舞い方に鍵があると直感している。

 

【追記】
@papandaさんの意見では、プロダクトオーナーの振る舞い方に鍵があるという指摘。
参考にする。

 

ichitani / チーム・ジャーニーさんはTwitterを使っています 「仕方がないことなのだけど安易な準委任が増えないように、発信していかなければならない。空論ではなくて書籍「正しいものを正しくつくる」に、その道筋を示しているつもりです。」 / Twitter

 

ichitani / チーム・ジャーニーさんはTwitterを使っています 「私は契約によってPOとSMや開発チームのコミットメントラインを分ける方向性ではなくて、第3者(PO代行)が介在するモデルが現実的ではないかと思っています (かつ、その存在さえも消していくことが)。そのあたりのケーススタディを示していかないといけないと理解しました」 / Twitter

 

ichitani / チーム・ジャーニーさんはTwitterを使っています 「アジャイル契約のワーキンググループみると、事業会社側、DXを当事者として進めなければならない側がいないように思います。当事者側の意見や知見、現実にはどのくらい適応できているのかな? https://t.co/SEqWSEPBsP」 / Twitter

 

 

 

 

 

 

 

|

« オンラインのリーダーシップとは何だろうか | トップページ | 「Rubyのしくみ」を読んだ後のRubyの感想 »

プロジェクトマネジメント」カテゴリの記事

ビジネス・歴史・経営・法律」カテゴリの記事

ソフトウェア工学」カテゴリの記事

プロジェクトファシリテーション」カテゴリの記事

Agile」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« オンラインのリーダーシップとは何だろうか | トップページ | 「Rubyのしくみ」を読んだ後のRubyの感想 »