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からアジャイル版「情報システム・モデル取引・契約書」でたよ!"

リモートアジャイル開発のノウハウ集を公開!

アジャイルスタジオ福井(ASF) にて培ってきた、アジャイルでリモート開発、WFH(Work From Home)する場合のノウハウ(コツ)集をまとめました。PDF で以下からダウンロードできます。 中身ですが、典型的なフォーメーションでグループ化しています。 読んでいただければ分かりますが、フォーメーションに関わらず使えるパターンも多く含まれます。 リモートエンジニア 全員常時オンライン、グループチャット、雑談、リモート飲み会 リモート拠点 傍らに写真、リーダーから無礼講、たまには会う、とにかく画面共有、チームマップ 全員リモート 通信環境にこだわる、顔写真アイコン、リモートホワイトボード、サブディスプレイ、デジタル化アナログツール ノウハウ出しにあたっては、ASFのメンバーからアイディアを集め、岡島さんが編集しています。ぜひ、ダウンロードしてご一読ください。

Read more "リモートアジャイル開発のノウハウ集を公開!"

新製品 astah* system safety をリリースしました

astah* ファミリーの新エディション、astah* System Safety をリリースしました(→製品サイト) 。久しぶりの新製品にチェンジビジョンのメンバーもドキドキわくわくしています! これは何か? 今回は、これまでの astah のような汎用的なモデリングツールではなく、製造業とくに安全性を By-Design で確立する分野、例えば自動車のシステム開発向けに提供されるバージョンです。 チェンジビジョンは、これまでもモデリングを中心とする製品をUMLからはじまり、マインドマップ, SysML, GSN, そしてER図やフローチャートを含めた professional と対象を広げてリリースしてきました。現在、モデリングが扱える範囲は、ソフトウェアからシステム全体、そしてSoS(System of Systems)に、さらに構造や振る舞いだけでなく、要求、安全設計やセキュリティ設計、さらには認証(ISO26262やSOTIF)のための論証、へと広がっています。 これまでの astah がUMLが中心で、単発的に SysML, GSN と出してきたものを(青いモデリング領域)、今回、安全設計を中心にして、システム開発向けに繋げて提供しているのが(赤いモデリング領域)、今回の astah、すなわちastah* System Safety です。 なぜ作ったか? 製造業は日本の重要な産業であり、その分野にMBSE(Model Based Systems Engineering)の適用が進み、モデリング手法が大きなパワーになる、と考えています。自動車、航空宇宙、ロボット、原子力、医療機器など、複雑化と、セイフティ・セキュリティの両面が問われる分野です。 機能安全コンセプトの設計では、うまく品質要求レベルを割り振ることで開発のコストと安全性を調和させることが求められます。また、安全性説明の表現として、セーフティケースも求められます。 さらに、自動運転への期待とその安全設計、検証の難しさが大きなトピックになっています。これまで、FTAやFMEAなどの分析手法が用いられてきました。しかし、自動運転のように複数の部品間および人間の認識にまでまたがって、はじめて実現される機能を扱う場合、個々の部品は非故障であっても、想定される機能が実現されないケースを分析する必要が出てきます。 あるいは、組み合わせの爆発とAIの登場により、網羅的なテストを行うことが難しい領域において、シナリオベースト・テストが注目されています(参考: Sakura Project のSenario)。そこでは、オントロジーと機能ツリーを用いた効果的なシナリオ作成が必要となります。欧州で先行して Pegasus プロジェクトにて社会受容性(事故を社会としてどこまで受容できるか、また、どのようにフィードバックするか)が議論され、さらに機能が意図通りに動いた上で、ミスユースや性能限界などによって生じるリスクに対する安全性の標準化がSOTIF(ISO/PAS 21448)として進んできました。 このような、現代的な安全設計のためのツールを提供し、製造業のこれからの品質をささえる現場のモデリングツールとして、それらの手法が一体で繋がるものを提供したかった、というのが開発の動機です。 何ができるの? ぜひ、製品サイトをみてください。無償試用期間もありますので、ここまでの話やキーワードにピンと来る方は、現場のみなさんで実際に使ってみてください! 技術的に楽しいこと あまり機能には関係ありませんが、長年作ってきた astah は、独自の Java コードによる UML メタモデルと、データ保存には […]

Read more "新製品 astah* system safety をリリースしました"

Design It! プログラマのためのアーキテクティング入門

Design It! 読みましたか?(よい本ですよ!) Design It! ―プログラマーのためのアーキテクティング入門 ”設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを作り上げていく方法を包括的に解説します。本書を読むことで、適切なステークホルダーを特定してニーズを理解する方法、アーキテクチャ上重要な要求に基づいて技術やアーキテクチャを適切に選択する方法、アーキテクチャを軽量かつ効果的に評価する方法、チームのアーキテクト力を高める方法などを学べます。モダンなアーキテクチャ設計のための実践的な手法が詰まった本書は、より良いプログラマー、技術リーダー、そしてソフトウェアアーキテクトになるために必携の一冊です。” ソフトウェア開発のアジャイル化が進み、ソフトウェアは生き物としてますます頻繁な変更にさらされるようになった。 アジャイルとアーキテクチャの民主化 アジャイル開発のアーキテクチャに対する基本スタンスは、最初に先読みをしすぎた設計(BDUF = Big Design Up Front)をしないということだ。設計に大きな先行投資をせず、動くソフトウェアを維持しながら進化させていく。アーキテクチャはこの繰り返しによって立ち現れてくるもの、実験と実装とユーザフィードバックの結果として「収穫」されるものである。中心となるユーザ価値から作りはじめ、イテレーションを繰り返しながら全体設計が現れてくる、というのだ。これは、これまでの大きな先行設計がかえってシステムを複雑にし、結局作らなくても良い汎用構造や複雑なメカニズムを作ってしまうというリスクを下げている。さらに、アーキテクトと呼ばれる神様が実装をせずに机上で架空のかっこよい構造を作り出してしまうことも避ける。アーキテクトとプログラマという構造ではなく、アーキテクチャを民主化した。ソフトウェアの機能は実装して動くとを確認しつつ、追加や変更を受け入れながら、リファクタリングによって内部の重複部分を取り除いていき、コードベースの成長にしたがって必要だった抽象構造が現れてくる、、、はずだ。 しかし、本当にそうだろうか?アジャイルとアーキテクチャ論は何度も議論になることがあった。特にリファクタリングの繰り返しによってのみ、アーキテクチャは本当に現れるのだろうか。それは現在意図している機能だけから作られるものだろうか。リアクタリングで扱い切れないような大きな変更はどう扱うのだろう。アーキテクチャは現在作ろうとしているソフトウェアの機能や非機能だけでなく、過去の経験や知見からもヒントが得られるのではないか。アーキテクチャは選択する、ものでもあるはずだ。BDUF は良くないとしても、NDUF(No Design Up Front)はあまりにもリスクが高い。私たちには、ENUF(Enough Design Upfront)をを作る活動、そしてそれを共有、維持、変更する活動が必要だ。 アーキテクチャとソフトウェア工学、パターン 本書は、この議論について現実的な視点で、アーキテクチャを作り出すための指針について書かれている。参考文献のリストやSEI/IEEEが定義するアーキテクチャへの言及を見れば、筆者が過去のソフトウェアエンジニアリングの要所を押さえていること、かつ、アジャイル方法論の発展の経緯や歴史についても造詣が深いことがうかがわれる。 本書の中で私が特に気に入っているのは、過去に特定され、名前が付けられているアーキテクチャーパターンが紹介されていること(7章)だ。アーキテクチャパターンを知っておくことは、最初の入り口を選ぶ時に大きな道しるべとなる。これらに縛られることは危険だが、発想の種を多く持つことはアーキテクトとして重要だ。そしてもう一つ、具体的になアクティビティが目的とともに紹介されていること(パート3全体)。このパートだけでも本書の価値がある。人の活動としてアーキテクチャづくりにアプローチしており、アーキテクトの道具箱として活動が具体的に紹介されている。アーキテクチャづくりはHow-Toとして書けるものではない。ステークホルダーとの必要なアクティビティを通して形作られていく。あるいは、それらのアクティビティそのものが創発的な合意形成であり、アーキテクチャだとも言えるだろう。 アーキテクチャとビジネス文脈 大切なことは、最良のアーキテクチャは、その文脈によって変わるということだ。文脈なしにアーキテクチャは成立しない。このことを強く思い出させる印象的なエピソードを1つ紹介しよう。Twitter は最初 Ruby on Rails で開発されたが、2009年ころからJVM(Java VM)ベースのアーキテクチャに移行し、レスポンスとスケーラビリティを改善した(O’Reilly OSCON Java 2011: Raffi Krikorian, “Twitter: From Ruby on Rails to the JVM”)。これは、大きくアーキテクチャを変更した商用アプリケーションの例だ。これは、最初のRuby On Railsの選択が間違っていたということではない。スタートアップでは、ビジネスとしてプロダクトが軌道に乗らない限り、資金は集まらない。twitter が最初からJVMを採用したとしたら、現在の成功はなかっただろう。スタートアップの段階では、Ruby on Rails の選択が素早いアプリケーションの構築とユーザーフィードバックに必要だったのだ。 アーキテクチャとコミュニティ(人) さらに、このアーキテクチャ変更に影響を及ぼしたのは、スケーラビリティなどの非機能要件だけではない。JVM 移行理由には、「より幅広いコミュニティからエンジニアを集められる」という「人」や「チーム」の観点も含まれていた。現在JVM上で動く言語が多くなっているため、様々な現代的言語が使えるようになり、このテクノロジをベースに使うことでコミュニティに発信し、それらが得意なより多くのエンジニアを参加できるようにするという狙いもあったのだ。アーキテクチャの設計もしくは選択には、こういった多様な視点の「文脈」が影響を及ぼす。スタートアップとして開発するのか、最初から多くのユーザーベースを扱うことが分かっているのか、では話が全く違ってくるし、実際に開発するエンジニアにはどのようなコミュニティに属するのか、にも影響される例だ。 […]

Read more "Design It! プログラマのためのアーキテクティング入門"

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"

Scrum Interaction 2019-3 Thank you

Scrum Interaction 2019その3です。 ワークショップ 各セッションの後にテーブルごとのディスカッションの時間をとり、聞いた内容を議論します。それぞれの議論を模造紙に付箋で残していき、最後の時間で、出た疑問を Scrum@Scaleを模倣するように、EAT=Executive Action Team(講師チーム)に集めて答えます。 Scrum Inc. Japan 社長の荒本さんが全体をファシリテートしました。 MSDのFraserさんへの質問の中に、「HowとWhat」そして「Why」についての議論がありました。Simon Sinek の Golden Cycle も連想させる質問だったかと思います。Whyについては全くその通りで、もっとも大切なもの。そして野中流では、Common Good がWhyが繋がることが重要。What/HowについてFraserが言いたかったことは実はぼくも野中先生と二人で書いた本に書いています。 what/how の話。Scrumは開点(1.sprint review, 2.retro.)を持った知識創造マシン。What知識はプロダクトとして(1)、How知識はチームのやり方(2)として蓄積される(by 野中+平鍋)。 — Kenji Hiranabe (@hiranabe) November 9, 2019 全体を通して感じたこと 今回は、ソフトウェア開発としてのアジャイルの話はほとんど出てきませんでした。組織変革の文脈(Jeff)、および、経営・組織論、哲学(野中先生)を基調として、事例も大企業での変革事例を中心に選びました。特に以下を2つの立場から感じました。 米国では経営レベルでのAgile組織変革が進んでいること、Scrum@Scaleの事例がでていること。それが日本でも起きようとしている。「アジャイルスクラム」側から見ると、ソフトウェアの話、チームの話からずいぶんと大人の領域に影響力が出てきた。 一方で、「野中スクラム」側から見ると、最初組織論だったものが、ソフトウェア開発の領域で再注目されていたのがアジャイル。今回は、それが一周してもともと先生の中心課題であった経営領域に進展し(あるいは経営がアジャイルを発見し)、さらに大きなムーブメントを形成していると見える。その中で人と人との「共感」が、経営論、チーム論、イノベーション論、ソフトウェアを貫いて、再度声高く謳われている。そのことは、野中理論がアジャイルを通過することによって、現代のイノベーション経営に見えてきたと言える。 ふりかえって自分ごととして考えると、この組織改革レベルは、経営のコミットメントがなければ進まない。経営を口説いていこう。 みなさん、ご参加ありがとうございました。今回のカンファレンスで、共感のエネルギーと、多くの事例を提供できていたら嬉しい限りです。ぜひ、自分たちの組織でどう実現できるか、考えていきましょう。。。。。難しいですが、やりがいあるじゃないですか!早く日本の事例を作りたい。その事例で来年また、Scrum Interaction 開催できることを願って。 レファレンス 他の方もたくさん、よいまとめを書いてくれています。ここに、ご紹介します。 野中先生の基調講演マインドマップ by Akapon (@Akapon2010) Scrum Interaction 2019で、なま野中先生とジェフ博士に会ってきた話(by YasudaTadahiro) https://www.creationline.com/lab/agile/30757 エンパシー(共感)ってなんなんだろう?(by kobase16 (id:kobase16)) http://kobase16.hatenablog.com/entry/2019/11/09/011305 エンパシーについて (by […]

Read more "Scrum Interaction 2019-3 Thank you"

AgileJapan2019-PFU-satellite

石川県宇野気(金沢近く)のPFU本社にて、AgileJapan 2019 のサテライトに参加してきました。 午後、ビデオ放映にはじまり、14:00から平鍋が講演をさせてもらいました。参加者は30名程度、横浜の支社とオンラインで繋いで、同時放映です。 ぼくは、アジャイルジャパン本家でやった Scrum の事例のお話をさせていただきました。参加者はテーブルごとにディスカッション、現場の課題共有、講演への質問などを討議、最後に私が各テーブルの質問に答えさせていただきました。 今回はほぼ現場エンジニア参加者です。草の根の会という意味合いが大きかったと思います。実は、2005年に一度 PFU にてアジャイルの講演をしたことがありますが、その時とは世代も変わっているようで、若い方の参加者多数。 横浜の舞台では、すでにScrumの採用も進んでいて経験者もいる、ということが(この場で)わかるなど、会社内部での情報共有と仲間づくりの意味も大きかったと思います。   会場からの質問には、ぼくの経験からできるだけの答えをしました。でも、ほとんどの質問への回答はみなさんの中にあります。いくら「正しいスクラム」の話を聞いても、そこには「あなたの現場の課題解決」の答えはないのです、、、ということが言いたかった。 一番印象的だった質問は、 仕事が楽しくなりますか? これに Yes と答えられなかったら、アジャイルなんて意味ないよ。誇りを持てるいい仕事をすること、そしてそれを楽しむこと。。。だよね? 全体を企画して頂いた柳澤さん、司会の中家さん、オープニングの和田さん、ワークショップのファシリテーション担当の敞田さん、横浜側をまとめて頂いた石原さん、会場づくり、社内調整、ありがとうございました。懇親会に参加されたみなさん、どうもありがとう!

Read more "AgileJapan2019-PFU-satellite"