Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Duarte氏に話を聞いた。#NoEstimatesは,どのようなソフトウェア開発活動にも適用可能なアイデアを集めたものです。その目的は,タスク+見積によって事前に定義,決定された計画に従うような開発に対して,開発目標を価値の提供に再設定することです。従来のワークブレークダウンストラクチャに代えて,ユーザストーリを使用するという基本的なアイデアは,すでに#NoEstimatesへの第一歩であると言えます。Hanlon氏が指摘したように(その話のビデオがこちらにあります),ストーリの数を数えれば(INVESTアプローチを重視したストーリ定義を行なったとすれば),プロジェクトのリリース日を簡単に予測できるからです。Hanlon氏が公開した実験結果は,私たちにあることを教えてくれています。それは,事前にプロジェクト全体の見積をしなくても,リリース日を知ることは可能だ,ということです。チームがユーザストーリのデリバリに要する時間を測定しておけば,すでに分かっているストーリをプロジェクトがいつ頃提供できるかは,おのずと明らかになるのです。ソフトウェア開発の契約(オフショア,ニアショア,あるいはアウトソース)についても,最初にプロジェクトに必要なストーリを(例えばストーリマッピングを使って)定義することさえ注意しておけば,簡単に行なうことができます。そのような疑問が生じるのは,意思決定プロセスに関わる重要な情報をユーザに提供することへの懸念があるからでしょう。一般的にソフトウェア契約の提供者側は,プロジェクトに投資する費用(通常はチーム数と時間の乗数)と,ユーザが特的の機能に対して支払うべき金額とを知ることが必要になります。これは,論理的なものです。本当に提供すべき価値が何であるのかは,これらの疑問に答えなければならない時点では分かっていません。皆さんよくご存知の,具体的な例を示しましょう。顧客のプロジェクト入札(スコープは明確に定義されています)に対して,プロバイダがプロジェクトの見積プロセスを実施します(ここでスコープに加えて期間が定義されます)。契約が確定し,署名し,開発に着手します。何が行われたのか確認してみましょう。顧客は機能セット(スコープ)を定義しましたが,自分たちが必要なものは何か,実はこの時点では分かっていません(何が欲しいのかは分かっていますが,何が必要なのかを知るには,これから開発するソフトウェアを使用した上でのフィードバックが必要です)。プロバイダは,顧客が望むもの(スコープ)を許容可能な期間(スケジュール)と支払可能な出資額(コスト)で実現するために必要と思われる投資を定義します。見積上の前提とする開発チーム(少なくともその人数),チーム(ソフトウェアの開発と提供を行なうため)およ顧客(開発チームと対話し,質問に回答するため)に必要なスキルレベルなどです。問題なのは,両者の時間的なアベイラビリティやスキル,チーム規模といったものが,契約時点では定義されていないことが多く,従って議論もされていないことです。motion)”しているのですが,ある時点で必ず“驚き”が現れます。当初予定していた開発者が(退職したり,別のプロジェクトにアサインされて)参加できない,顧客が何かの四半期目標達成に忙しくて質問に答えられい,といったことが明らかになって,驚かされるのです。すればいいのでしょう?計画をやりなおすべきでしょうか?価格や当初の仕様を見直すべきでしょうか?私は#NoEstimatesに関する自分の書籍で,これらとは違う提案を詳しく説明しています。すべてのパラメータを事前に定義しようとせずに,すでに分かっているもの,重要なものだけを定義するのです。プロジェクトの価格には上限がなくてはなりませんから,予算を定義する必要があります。顧客の側には,契約者が提供するものの“承認”を業務とする人あるいは人々がいることも少なくありませんから,最終的に提供すべきソフトウェアは何か,という考え方は一般的です。これに基づいた新たなソフトウェア提供のアプローチは,次のようになります。プロジェクトの投資ボックス(予算)を定義する。プロジェクトへの時間と人の割り当てボックス(別の形の予算)を定義する。価値の提供ないし実証の期限とペース(チームによる定常的な価値の検証と提供の指針となる制約)を定義する。ユーザストーリを更新するための定常的かつ周期的プロセスの確立と,すべてのユーザストーリの提供完了日を評価するための納品率(毎週いくつのユーザストーリを完了できるか)の設定を行なった上で,予算に対する最終納期を定期的にレビューする。スクラムと非常によく似た(ただし見積はありません)このプロセスは,開発プロセスに継続的な透過性を提供する上で十分であると同時に,顧客が必要とするもの(単に望むものではなく)を確実に提供しながら,当初合意した予算に沿うようにプロジェクトを管理することができます。Ditz氏とともに同書を説明したビデオインタビューでも詳しく説明しています。Cenzano氏など7名の#NoEstimates実践者とのインタビューの中でも,世界中のさまざまなソフトウェアプロジェクトにおいて,#NoEstimatesのアイデアがどのように利用されているか述べられています。多くの場合において,請負開発者が仕事を始める上で最初に必要なのは契約,すなわち両者の合意ですが,#NoEstimatesでは何が合意の基準になるのでしょうか?Duarte:どんな契約であっても合意は必要です。見積があってもなくても,それは同じです。合意は言わば,両者が共同で作業することによって,失うものより得るものが多いことを確信するための手段のひとつなのです。ここで見積は大した役には立ちません。実際のところ,見積が契約において何よりも重要な要因であるならば,契約はもっと少なくで済むはずです。理由は単純で,ソフトウェアの実際のコストを推し量る上において,見積はあまり優れたツールではないからです。プロジェクトの規模が大きいほど,許容可能なコストの上限を設定するために,不適切な見積が行われる傾向があります。Engineering2011年のCHAOSレポートによると,調査対象となったプロジェクトの遅延の平均は63%でした。この数値は,あるソフトウェア開発企業で私が2003年に行なった個人的な調査とも一致しています。17プロジェクトを対象としたその調査では,遅延の平均は62%,最大のプロジェクトでは200%でした。Ambler氏は,ソフトウェア業界でのプロジェクト成功に関する調査で有名ですが,2013年のデータによると,従来形式のプロジェクトの53%が“失敗”(ソリューションを提供できなかった)あるいは“問題あり”(成功基準に達しなかった)でした。AccentureがNHSプロジェクトの失敗によって1億英国ポンドのペナルティを課されたことは有名な話です。そのような特殊なケースで非難されるべきなのは,何も見積だけではありません。この失敗を引き起こした増分的な成果提供の欠如が,私たちが見積と称しているツールへの信仰によって容認されるだけでなく,奨励までされていることに問題があるのです。これらは,私たち一人ひとりが知っている数多くの例の,ほんの一部です。見積は,ソフトウェアプロジェクトのコストに上限を設定するツールとしては,極めて非効率的なのです。プロバイダと顧客の関係における基本的な取り決めは,価値の定期的かつ検証可能な提供に基づいた,明確なものでなくてはなりません。私が顧客ならば,具体的な価値の提供をいつまで待てるかを定義したいと思うでしょう。逆にベンダならば,提供した機能の妥当性を確認するためのフィードバックが,どの程度迅速に得られるかを知りたいと思います。提供した結果に顧客が満足して,それ以上の成果を求めないのいであれば,契約の終了を定義するのは簡単なはずです。逆にユーザからのフィードバックがなければ,開発成果を後になって拒絶される可能性が非常に高くなるので,フィードバックが提供されるまで契約を停止するような仕組みがベンダには必要になります。ソフトウェアの開発は家を建てるのとは違います。事前にすべての結果を知ることはできません(家を建てるときもそうですが)し,自由度が高いために,顧客とベンダ双方に有益な相互関係に基づいた開発が必要になります。非常に重要な質問ですね。Leybourn氏に#NoEstimateについてのミニ電子ブックを書いてもらって,さまざまな契約の種類や,顧客とベンダが信頼関係を結ぶ上でそれらがいかに重要かを説明することにしています。ミニ電子ブックの内容全体をここで説明することはしませんが,(#NoEstimatesのような)相互利益的なアプローチの利用をサポートする契約と,一方のリスク(と責任)を他方へ移行するための契約がある,ということの理解が重要です。信頼性の低い状態で使用される契約の一例として,費用や範囲,期間を完全に固定した契約が考えられます。それでは,より強い信頼関係を築くどころか,かえってお互いの不信感を増すことになります。ベンダ側は契約に含まれた変更要求の準備を利用(ないし乱用)することで(契約で定義されていないものはすべて有償とすることで)利益を得ようとするでしょうし,顧客の側では,新しい発想もすべて当初のスコープ内であると主張するでしょう。“契約交渉よりも顧客との協調を”とは正反対です。その対極に,契約を行なわない企業の存在があります(#NoEstimateの書籍では,そのCEOにインタビューしています)。2週間ごとに価値を提供することで,両企業の共同作業から生み出された価値に基づいて関係を継続ないし停止する,というものです。話を明確にするために極端な例をあげましたが,これらは#NoEstimateの利用をサポートしない(期間,費用,範囲を固定した契約)モデルと,その正反対にあって#NoEstimatesをサポートすると同時に,価値の提供に常に重点を置いた,#NoContractsとも呼べるモデルとを表しています。Ditz氏がNoEstimates書籍にインタビューで述べているように,#NoContractsはすべての顧客に対して適用すべきものではありません。契約(これは法律的に自らを保護する手段でもあります)をせずに開発を行なうという考え方が受け入れられやすい顧客と,そうではない顧客があるからです。#NoEstimatesや#NoContractsのような斬新なアイデアを実施するには,実験に参加して開発を行なう意思のある顧客を見つけることが必要になります。素晴らしい質問ですね。契約について話した時に述べたように,信頼を築くには時間といくつかのツールが必要で,契約もそのひとつです。ステークホルダにとって価値のあるものを早期かつ頻繁に提供することです。このアジャイル原則が,信頼構築のための重要なツールのひとつなのです。ひとつの信頼構築ツールは透明性で,#NoEstimatesについて説明する場合に重視しているものです。前に,あるプログラムマネージャ(プログラム内のいくつかのプロジェクトを管理する)と,チーム(複数のプロジェクト)が期日にプログラムを提供可能かどうか,結論を出そうとしていた時のことです。件のプロジェクトマネージャは,別のプロジェクトチームが期日までに提供可能だと考えていました。彼はそのチームに対して,そのことを要求済みだったのです。チームの側でも,プロジェクトの見積を行なった結果として,期日までに提供可能だという結論に(全員が)達していました。“素晴らしい!”,全チームが期限までに作業を完了できそうだ,と彼は考えました。ここで分かるのは,彼は個々のチームによる見積から結論を出した,ということです。プログラム全体での提供率については見ていませんでした(プログラムはさまざまなモバイルデバイス用に単一のソースベースを提供するもので,内部的に複数のアプリケーションがありました)。そこで私は#NoEstimateを使って,システム全体,つまりひとつの完全なシステムを提供するチームすべてを一体として,そのスループットを評価することにしたのです。私の見解は彼とは違いました。作業の速度あるいはプロジェクト全体としてのスループットが,期日までにプログラムを提供するにはまったく不足していることが,(見積ではなく)事実として分かったのです。私はデータを揃えて,プログラムマネージャに状況を説明しました。彼は礼儀正しく聞いていましたが,私の頭がおかしいとでも思ったのでしょう。結局,プログラム(とプロジェクト!)は続けられました。マネジメントスクールでは,プロジェクト計画+見積が“真実”だと教えられます。各チームが個別に,期限までに完了すると見積もったのですから,プログラム全体も期限どおりに完了するはずだ,というのです。1年後(6ヶ月の予定が18ヶ月となって),そのプログラムはキャンセルされ,その会社は最終的に(そのプログラム以外の多くの理由で)倒産しました。私が正しかったことで残念な思いをしたケースです。本当は私が正しかったのではありません。私は単なるメッセンジャだったのです。正しかったのはシステムです。システムのスループットはプログラムマネージャに,彼とその会社が失敗することを告げていました。プログラムマネージャは,システムメトリックを見ることも信じることも,教わっていなかったのです。私たちの多くがそうであるように,彼もまた,将来のイベントに対して人が考えた見積だけを信じるように教えられていました。ソフトウェア産業における見積の歴史が惨憺たるものである(上記参照)にも関わらず,なのです。信頼の構築には,システムの測定を重視する必要があります。見積はフィードバックを遅らせるだけです(遅れに気付いた時には,もう手遅れです)。スループットやサイクルタイムのようなシステムメトリックスを使うことで,意思決定に必要な透過性をプロジェクトの初期段階から手に入れられるようになります。長くて退屈な見積セッションに付き合う必要がない,というおまけ付きなのです。私たちの使うテクニック(見積)がいかに美しくても,最終的にはその結果を受け入れなくてはなりません。見積には,極めて悪い結果があるだけなのです。その定義について話す前に,契約について,私たちが考えている特徴についてまとめてみましょう。成果の提供から承認までのフィードバックサイクルを短縮することによって,成果提供後の承認(および支払)までの期間が長くなることによるリスクを軽減するベンダの貢献(時間,素材,IP)に対する正当な保証の受け取りを可能にする顧客との関係が持続不可能な場合,すべてのベンダが関係破棄を可能にするこれらの要件のほとんどは,ベンダと顧客の合意で簡単に達成することが可能です。ベンダは2週間(あるいはそれ以下)に期間を限定して,合意された全体目標,機能,あるいはユーザストーリ集の開発を実施し,その期間の終わりに完成したものを,実際に近い環境でデモンストレーションする。2週間のイテレーションに要する作業負担については,例えば開発者/テスタ3,プロダクトオーナ1,スクラムマスタ1というよに,前もって両者で取り決めておく。期間の終了時に,顧客は,成果物を拒否して支払を行なわない権利を持つ。ベンダも等価的に,イテレーションの境界(この例では2週間毎)にプロジェクトの作業を停止する権利を持つ。上記のルールは,ソフトウェア開発へのアプローチとしてスクラムを実施する場合に,多くのチームがすでに使用しているものと非常によく似ています。このアプローチでは見積は必要ありません。顧客のビジネスニーズを満たす価値を早期に,定期的に提供することだけが要件なのです。上記のルールのもうひとつの利点は,ベンダと顧客の双方が契約の必要性を放棄し,単にこれらのルールに従って作業を進めることによって,リスクを非常に低く(2週間の投資のみに)できることです。Ditz氏がNoEstimates書籍に関するインタビューで説明したものとほぼ同じです。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。