IPAからアジャイル版「情報システム・モデル取引・契約書」でたよ!

IPAからプレス発表がありました。 DX推進に向け、アジャイル開発版の「情報システム・モデル取引・契約書」を公開 https://www.ipa.go.jp/about/press/20200331.html ざっと見た内容をお伝えします。この特徴や意味についてです。 スクラム用語に統一 アジャイルはもちろんスクラムに限った話ではありません。でも、今回の成果物に出てくる用語と基本となるプロセスフレームワークはスクラムです。ソフトウェア開発の技術的詳細に立ち入らず、プロセスの枠のみを提示しているスクラムが、こういった契約などの問題を扱う際にはちょうどよい語彙なのだと思います。もちろんスクラムはXPと共存もできるので、プロセス面の用語としては、スクラムの定義を持ってくるのが分かりやすでしょう。 さらに、現実的にはスクラムが一番普及している、ということもあると思います。そして、これからアジャイルを組織的にスケールさせる場合も、スクラムを由来とするフレームワークを用いることが多いと思いますので、この選択はとても分かりやすかったと思います。 日本の産業構造への適合 「ユーザ企業」、「ベンダ企業」、「発注」という言葉が出てきます。これは日本で非常に強く残っているSIの形で、ユーザ企業側にIT人材がほとんどおらず「ITは発注されいている」という状況を構造として表しています。現在、Web系の企業や2000年以降に起業した企業はこの形を取っているところは少なくなっているでしょう。また、ユーザ企業でもソフトウェアの内製化が進んでいます。 とはいえ、この構造の中でどうするのか、という考えがないと話が進まないのです。ここを見捨てて、それは古いよ、これからは内製だよ、と言ってしまうと、日本の現在ソフトウェアエンジニアの6-7割を見捨ててしまうことになると思います(ぼくも出自がそこだから逃げ出さずになんとかしたい)。なので、この形での「契約と取引」に踏み込んだことは、とても意味のあることだと思うのです。 チーム体制、特にPO その中で、POが発注側の役割だ、としたのが特によいと思います。こうでないと、「丸投げ」から脱却できないのです。少なくとも要件の変化が激しく市場変化に対応したい、というのが目的であれば。 準委任契約 契約は2社間のものなので、どんな形でも本来よいのですが、日本には2大類型として「請負契約」と「準委任契約」があります。ユーザ企業の調達部門はこの2つに分けて考えています。ので、この中で準委任契約が本筋だ、という割り切りにも大きな意味があったと思います。また、その場合でも「指示命令系統」や「現場責任者」という話が出てきます。それらについての解釈もこの中で触れられているという踏み込みがとてもいいと思いました。 回顧 最後に、2011年にIPAから出された「非ウォーターフォール型開発 WG 活動報告書」では私も参加して、日本のアジャイル開発への提言をまとめました。その時はこの名前からも分かるようにアジャイルは非主流でした(非ウォーターフォールって何?)。そしてモデル契約にも取り組みました。でもそれはほとんど使われなかったようです。 日は流れ、メンバーも刷新して、この取引・契約モデルを作成したワーキンググループには永和システムマネジメント・アジャイル事業部の木下さんが参加しています。 今回の発表に関して、木下さんが考え、提案し、議論した記録がここにありましたので、ぜひこちらもどうぞ!そして、WGのみなさん、おつかれさまでした!    IPA の アジャイル開発版「情報システム・モデル取引・契約書」

Read more "IPAからアジャイル版「情報システム・モデル取引・契約書」でたよ!"

Scrum Interaction 2019 keynote by Jeff Sutherland

Scrum Inc. Japan主催のはじめてのカンファレンス、Scrum Interaction 2019が11/8東京で開催されました。当日はぼくが総合司会を勤め、300人のスクラム実践者が参加され、スクラムの父、Jeff Sutherland とスクラムの祖父、野中郁次郎先生が一つの場に会する場は熱気でいっぱいでした。 このブログでは3回に渡って内容をご紹介したいと思います。第1回目は Jeff Sutherland の基調講演です。 Jeff Sutherland の基調講演 産業のディスラプション DXによって産業がソフトウェアによってディスラプトされている現状の例。Amazonの縦産業相次ぐ参入は、ホントすごいですね。 金融: Amazon がドイツで金融に参入。3,300のスクラムチーム 運輸: Amazon が中国船をリース購入、航空機も購入して参入。NYでUberがFedExを凌駕 電力(Utility): 風力・太陽光が安価になり、家庭自家発電が広まる(彼自身の家では、自分の作った電力を近所に売買、教会に寄付。それも携帯のアプリで!) Agile BS(だめだめアジャイル) ところが、米国でもだめだめアジャイル(Agile BS = Agile Bullshit)がはびこっているらしい。例えば米国防省(DoD)では「ほとんどのプロジェクトがアジャイル開発をしていると宣言しているが、本当はそうなっていない!(Fake Agileだ)」という議論(ここに発見。redditで炎上してたらしい)があり、「Agile BSチェックリスト」が作られた。 ここまでの議論では、 DXがおこり、成功企業の多くの企業がスクラムを採用している。 米国ではアジャイルがソフトウェア開発はデフォルト(政府調達でも)。 ただし、名前だけのアジャイルにやっているとろこは失敗している。 さまざまな企業がスクラムを「組織改革手法として」導入しはじめている。 アジャイルをやるにしても、こんな形でやっていないか? さあ、失敗しないために組織的にアジャイルを取り入れないといけない。 そこで、Scrum@Scaleですよ。 Scrum@ScaleはScrum同様、薄いフレームワーク。スクラムを階層的に組むのだが、「スクラムマスターの階層」と「プロダクトオーナーの階層」の両方があり、組織がフラクタルに形成されるのが特徴でしょう。フラクタルであるということが、生命的ですね。さらに、これが組織に「実装」されたときの具体形はそれぞれに違うという点も面白い。創発的、自己組織化的というか、生身の人間のチームがその場で考えて成長・進化していく過程が構造に現れています。   だから、変化に強く、仮にこの構造を任意の場所で2つに切ったとしても生きられる構造を作ることができる、そう生命組織ににているんです。自立分散が集まって、一つの目的を満たそうとしている形なんです。

Read more "Scrum Interaction 2019 keynote by Jeff Sutherland"