Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。原文(投稿日:2011/02/08)へのリンクアジャイル手法に関してよく質問されることのひとつに,"アジャイル開発の契約はどのようにすればよいのか",というものがあります。価格を提示して,両者が法的拘束力を伴う契約書にサインする,というやり方は,企業が何かを購入する場合にはとても都合のよいものです。関連スポンサーコンテンツサインが完了すれば,次は開発期間です。開発のスコープ内に実際にあるものは何か,何が範囲外なのか,契約変更を要するものは何か,などについて全員で議論します。しているうちに開発作業が完了します。白熱した議論を繰り返した後,顧客がソフトウェアを正式に受け入れれば支払いが行われます。従来の方法で契約を行った上で,プロジェクト作業にアジャイル技法を用いても,もちろん構いません。そのようなやり方は,アジャイルの本質を損なうことにもなります。アジャイルチームにとって,変更要求は大した問題ではありません。それは当初から想定されたものであるだけでなく,変更要求がまったくないことが逆に問題と見なされる場合さえあります。極端な場合,アジャイルチームは要件資料が何もない状態でも作業を始められるのです。対照的に,ソフトウエアの納入は漸次に行うことができますから,早期の検収を期待することも可能でしょう。顧客とサプライヤがともにアジャイル開発から最大限の利益を得ることができるのであれば,従来形式の開発契約は考え直す必要があります。この領域は今なお発展中であって,企業はアジャイル契約のための新たなモデルを模索し続けているところなのです。そのため,革新的な思想の持ち主が状況を混乱させることも時にあります。この資料では,サプライヤと顧客がアジャイル開発契約を成立させる方法として,4つのモデルを検討します。新しいモデルが登場すると思われますが,現時点で選択肢として存在するのは,概ねこの4つのオプションです。業界における契約の標準的ベンチマークであり続けています。この種の契約は,プロジェクトの初期段階で作業のスコープを定義可能である,という考えに基づきます。決定し,金額を算出します。それが完了すれば契約書が正式に署名され,実施に移されます。一定量の専門的ソフトウェアである,という解釈を基準としています。カスタムソフトウェアを購入するというのは,テーラーメードのスーツを買うことよりも,どちらかと言えば財務上のアドバイスを受けるのに近いのです。購入対象は品物や商品というよりも,サービスなのです。ひとつとして緩和せずにプロジェクトを完遂した例には,これまでお目にかかったことがありません。業界は長年に渡ってこのような形式の契約へのサインを積み重ねてきました。それは取りも直さず,開発失敗の歴史でもあるのです。いったところでしょうか。契約のスコープが変更される理由をすべて説明しようとすれば,それだけでこの記事が埋め尽くされてしまうくらいです。契約要件が変更されたならば,他の部分もすべて変更しなければなりません。当初の予定期間や人員計画も変更が必要となり,結果的に金額も変わってきます。引いて考えてみると,このような契約の形式を使い続けるというのは,まったくもって痛ましい限りです。信念の強さや肯定的思考を実演してみせた上で,次は何とか違う結果が出てくれないだろうか,と願っているのですから。このような契約形式がこれまで生き長らえてきたのは,おそらくは法廷での自己弁護に有利だからでしょう。判断は裁判に委ねられます。固定的な契約モデルが本質的に持っている欠点を考えれば,結局は裁判所に呼び出されるリスクを増やしているに過ぎないのです。最後に,契約にサインしたということは「要件が出尽くして確定している」「見積が適切である」「品質が許容範囲内である」ということを,関係者全員がその時点で確信していたということに他ならない,という点にも注目すべきでしょう。このタイプの契約の歴史を振り返ると,これには驚きを禁じ得ません。すべての人には当てはまらないそれぞれのオプションについて検討する前に,この問題はソフトウェアを開発する,あるいはアジャイルを試みる企業すべてに影響するものではない,という点を強調しておきたいと思います。この問題に直面する機会は,ごく周辺部分に限られています。彼らの顧客の大部分は完成した製品を購入するだけであって,製品の動作に関して直接意見を言う機会がほとんどないからです。部門の中にも,これら企業と同じような方法で契約問題を回避しているものがあります。購入するか,あるいは企業内でのみ使用されるカスタムソフトウェアを開発しています。部門がサードパーティのソフトウェア提供企業に対する顧客の立場になります。アジャイル開発を提供する契約の必要性がもっとも高い存在でしょう。実際にアジャイルプラクティスの多くが,このセグメントを起点として発生しているのです。世界にも同じようにフィットします。顧客がアジャイル開発を導入する場合には,いくつかの問題があります。両者の間で法的契約を締結する必要があるからです。同様な問題が起こる可能性は他にもあります。プロジェクトに問題が発生することを想定するため,契約条件はより厳格に,金銭的なペナルティはより高価になる傾向があります。中小の企業はペナルティ条項に対処できないため,巨額のペナルティに対処できるだけの資金を持ち合わせた大手と競合することができないのです。シナリオをもたらす可能性があります。固定された価格,固定されたスコープ,固定された開発期間から抜け出すことのできたサプライヤが,マーケットリーダを越える競争的優位性を獲得できる位置に立つのです。顧客は,より良い結果を提供する革新的アプローチの恩恵を受ける役なのです。オプション1:隠す開発契約でアジャイルを使用するにあたって,もっともシンプルで当たり障りのない方法は,その事実を隠してしまうことです。顧客に対して,自分たちが通常とは異なる作業方法を採用することを告げないでおくのです。いつもの方法で作業見積と計画を行い,ごく普通の契約にサインした上で,成果改善のためにアジャイル手法を使用するのです。いう形であれ,テスト駆動開発や継続的統合,定期的なリファクタリングと再計画などは,よりよい成果の獲得に有効です。できる限り無視するか,可能ならば捨ててしまいます。知りたがった場合です。したら,でっちあげてしまいましょう。計画を遵守しているように見せかけるため,計画の方を更新してしまうチームの話もあるくらいですから。このアプローチには,誠実性というものがありません。顧客に嘘は付きたくはありませんし,信頼を築きたいと望むのも当然です。計画遵守を偽るようなサプライヤを顧客が信用するはずがありません。実際の成果よりも計画進捗の管理の方を希望する顧客など,最初からお互いを信頼などしていないのだ,という反論ももちろんあるでしょう。しても,彼らの信頼を得られる結果を示すことは,業務受託者としての私たちの仕事なのです。形式の方針が必要になってきます。このような方針に,あるいは計画遂行よりも実際の成果進捗を計測することに同意してくれる顧客がいるとすれば,アジャイルを隠す方法もうまく行くかも知れません。そのような理解のある顧客ならば,最初からアジャイルを隠す必要もないのではないでしょうか。アプローチを採用するには,ある程度の信頼関係が必要です。支払いをしない場合には,成果を手元に残しておくことはできません。このアプローチは厳しいものにも思えますが,同時に報酬を増やすチャンスも得られます。このアプローチを採用すればクライアントはリスク額を低減できますが,その一方で請負う側のリスクは増大します。このようなリスクの再バランスの結果として,価格が高くなるのです。採用しやすい位置にありますが,新たなリスクの発生も伴っています。顧客側のリスクが少ないため,開発の成功に対するモチベーションが低くなるのです。難しい決断を要するとき,妥協が必要なとき,時間が不足したとき,関与が望まれるとき,必要なことを実行するためのインセンティブが顧客にはありません。顧客に起因するものでない限りにおいては,どのような失敗もすべてサプライヤ側の失敗なのであって,顧客が失うものはなにもないのです。サプライヤ側で責務を守る顧客のみを作業相手として選ぶことができるならば,このようなリスクも相殺できるかも知れません。それには,契約請負側が危険であると判断する作業を拒否できる状況にあること,顧客のコミットメントのレベルを適正に評価できること,この2つが前提となります。現在までこのモデルが適用されたと聞いたのは,ごく小さなサプライヤでの1例しかありません。資金の潤沢な企業はリスクに対して慎重であるか,あるいはこのオプションの必要性をそもそも感じていないか,のいずれかなのです。Contract)顧客との関係を維持したいのならば,関係を維持するための仕組みを用意した上で,作業の再付託を継続的に要請しなければなりません。形式で合意を得る代わりに,顧客とサプライヤの双方で,一連の短期開発ミニプロジェクトへの構造的な合意を導入するのです。作業単位はエピソードあるいはイタレーションなど,好みの名称で呼べばよいでしょう。契約にはたいていの場合,何らかの総合的な目標がありますが,具体的な機能に関しての個別計画リストは含まないのが通常です。ニーズを見つけ出すこと自体が,開発作業の一部なのです。すべての要件を法的契約の対象外にしているくらいです。各イタレーションには何らかの成果がありますが,同じくらい重要なのは要件への理解が進むことです。顧客はサプライヤに対して成果ごとの対価を支払った上で,次のイタレーションに進むか,あるいはそこで中断するか,を選択します。価値を高めるために実施すべき作業の存在を示すこと,の2つです。生み出された価値がコストより大きいと確信できなければ,顧客らはそこまでの成果を受け取って,この開発から手を引くことが可能です。顧客が非協力的であると判断すれば,サプライヤ側も同じように作業を離れることができます。ごとに対価を支払った上で次の作業を付託する,という従来の方法と同じです。違っているのは,プロジェクトを中断した場合,従来型モデルでは顧客の手元に何も残らないのに対して,このモデルでは何らかの成果が得られるという点です。通じてその価値を示すことには,明らかなインセンティブが存在します。顧客は,開発された成果,付加された価値,それらが一体となったソリューションを確認することができるので,作業の継続に熱意を持つに違いありません。万が一誓約が守られない事態があっても,作業を中断するというオプションがあると知っていれば問題ではありません。このオプションは,法的なフレームワークを「もの」の提供から「サービス」の提供へと移行させます。顧客はサービスに対して契約をします。したがって彼らが購入するサービスの量には,何らかの方針が必要でしょう。部門やサプライヤの多くは,すでに身近な領域でサービス契約を使っているのです。サポートデスクやソフトウェアメンテナンス契約などです。これらの作業は,サービス契約として記載されるのが一般的です。氏の手による詳細な資料があります。複数の小規模プロジェクトで構成された契約を組み上げるよりも,このアプローチではむしろ大規模な契約を推奨します。同時にそれは,大規模な事前要件分析の暗黙的な提案でもあります。この契約には,2つの追加条項があるのです。最初の追加条項は,最高の優先度の項目に最初に取り組むこと,新たな作業に対応すること,この2つを促進するように契約を変更するものです。顧客はサプライヤと定期的に会合して,残作業の優先度を再設定することに同意します。この時,代わりに何らかの作業を中断するか,あるいは実行を見合わせることを条件に,新たな作業をバックログに加える場合もあります。これによってサプライヤとの共同作業や支援へのインセンティブを高め,顧客との関係を維持するのです。顧客は定期的に,例えば毎月,提供される稼働ソフトウェアに対して対価を支払います。これが第2の追加条項であり,前項と同じように顧客との関係を維持し,暗黙的な再付託を新たに受けるためのものです。規定により,顧客はどのステージにおいても,残りの作業をキャンセルして,それまでの成果物を獲得することが可能になります。サプライヤ側に支払います。万ドルを支払うことになります。結果的として,契約完了時よりも480万ドル節約したことになるのです。一見するとこのオプションは,提供する側にとっては望ましくないように思われるかも知れません。万ドルを失うことになるからです。万ドルが,最終的にはそれを相殺します。万ドルはまるごと利益になるのですから。上記のようにこのオプションは,作業に参加して早期完了させることで,コスト削減を図るためのメカニズムとインセンティブを顧客に提供します。サプライヤも同様に,変更を許容し,良い作業をすることで自由な資金を得るように動機付けされるのです。この形式の契約例は非常に少ないのが現状です。組み合わせこのような4つのオプションがあれば,さまざまな方法でこれらを組み合わせて,さらに別のオプションを考えることも難しくはありません。他の3つのオプションのいずれかと組み合わせて,より強力なソリューションを作り出すことも可能でしょう。個々の成果に適用することができます。金銭的な部分を除けば,オプション3と4にはおそらく大きな違いはないでしょう。違いは主としてオプション3が,開始時点ではの知識は限られたものであるという前提から,顧客の反復的な付託を積極的に依頼するという部分で,従来のモデルを打ち破っている点です。逆にオプション4は既存モデルの範囲内において,先行的要件という仮定を維持しながら作業するものです。この初期要件は,作業が開始されてしまえば放棄しても構いません。シミュレートしています。アジャイルチームの契約がいずれの方法で書かれるにせよ,考慮すべき重要な要素が2つあります。具現化でなければなりません。サイクルの実践に他ならないのです。第2に,契約は顧客とその代表者に対して,プロジェクト全期間に渡る継続的関与を動機付けるものでなければなりません。プロジェクトを成功に至らせる主要因であることを指摘しています。アジャイルを実践するか否かに関わらず,顧客との継続的関係は必須のものなのです。業界の従来の作業方法に馴染みのない顧客には,これらのオプションのいくつかが,完全に論理的なものだと感じられるかも知れません。サプライヤとの仕事を続けてきた人たちは,いくつかのオプションに驚きを覚えることもあるでしょう。いう神話を広め,顧客を裏切り続けてきました。顧客の一部は間違いなく,従来型の契約モデルに固執するでしょう。一部のサプライヤがこのような顧客に付け込んで利益を得る一方で,他のものは役に立たないモデルに固執することによって損失を被ります。どちらの結果もあまり魅力的ではありません。事前にすべてを確定することが可能である,と顧客が考えるなら,従来のアプローチを選択することができます。確信が持てないようであれば,反復的なアジャイルアプローチの方を選択すればよいでしょう。契約の新たなアプローチ方法と幅広い選択肢が用意されていることに関する顧客の理解が進めば,すべての人たちが恩恵を受ける側に回ることができるはずです。今の時点では,新たな契約モデルへの早期移行が可能な人々に対して,選択の機会が与えられています。その見返りもあるのです。氏はシステム管理者,テスタ,開発者,アーキテクト,プロダクトマネージャ,開発マネージャなど,ソフトウェア業界のあらゆる業務を経験してきました。現在はロンドンに居を構えていて,ソフトウェア企業がアジャイルとリーンプラクティスを導入し,より深めていくことをトレーニングやコンサルティング,コーチングの実施を通じて支援しています。いう著書も持っています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。