プロジェクト規模の設定と合意，契約の締結，信頼の確立といったニーズに直面する契約環境において，どうすれば#NoEstimatesテクニックを適用できるのだろうか – InfoQは，先頃刊行された書籍のインタビューに引き続き，著者のVasco Duarte氏に話を聞いた。

InfoQ: 契約ベースのソフトウェア開発者は，#NoEstimatesをどのように実践すればよいのでしょうか？

Duarte: #NoEstimatesは，どのようなソフトウェア開発活動にも適用可能なアイデアを集めたものです。その目的は，タスク+見積によって事前に定義，決定された計画に従うような開発に対して，開発目標を価値の提供に再設定することです。

従来のワークブレークダウンストラクチャに代えて，ユーザストーリを使用するという基本的なアイデアは，すでに#NoEstimatesへの第一歩であると言えます。MicrosoftのBill Hanlon氏が指摘したように(その話のビデオがこちらにあります)，ストーリの数を数えれば(INVESTアプローチを重視したストーリ定義を行なったとすれば)，プロジェクトのリリース日を簡単に予測できるからです。

Hanlon氏が公開した実験結果は，私たちにあることを教えてくれています。それは，事前にプロジェクト全体の見積をしなくても，リリース日を知ることは可能だ，ということです。 ですから，質問に戻って，プロジェクト成果の提供日を知りたいのであれば，その答は簡単です   チームがユーザストーリのデリバリに要する時間を測定しておけば，すでに分かっているストーリをプロジェクトがいつ頃提供できるかは，おのずと明らかになるのです。

ソフトウェア開発の契約(オフショア，ニアショア，あるいはアウトソース)についても，最初にプロジェクトに必要なストーリを(例えばストーリマッピングを使って)定義することさえ注意しておけば，簡単に行なうことができます。

InfoQ: 契約ベースのソフトウェア開発者は，このようなテクニックを次のプロジェクトや契約で採用するべきなのでしょうか？

Duarte: そのような疑問が生じるのは，意思決定プロセスに関わる重要な情報をユーザに提供することへの懸念があるからでしょう。一般的にソフトウェア契約の提供者側は，プロジェクトに投資する費用(通常はチーム数と時間の乗数)と，ユーザが特的の機能に対して支払うべき金額とを知ることが必要になります。

つまりこれは，論理的なものです。しかしながら，本当に提供すべき価値が何であるのかは，これらの疑問に答えなければならない時点では分かっていません。皆さんよくご存知の，具体的な例を示しましょう。

顧客のプロジェクト入札(スコープは明確に定義されています)に対して，プロバイダがプロジェクトの見積プロセスを実施します(ここでスコープに加えて期間が定義されます)。契約が確定し，署名し，開発に着手します。何が行われたのか確認してみましょう。

• 顧客は機能セット(スコープ)を定義しましたが，自分たちが必要なものは何か，実はこの時点では分かっていません(何が欲しいのかは分かっていますが，何が必要なのかを知るには，これから開発するソフトウェアを使用した上でのフィードバックが必要です)。
• プロバイダは，顧客が望むもの(スコープ)を許容可能な期間(スケジュール)と支払可能な出資額(コスト)で実現するために必要と思われる投資を定義します。
• 顧客に入札ないし提案を提示するために，プロバイダはいくつかの仮定を立てます   見積上の前提とする開発チーム(少なくともその人数)，チーム(ソフトウェアの開発と提供を行なうため)およ顧客(開発チームと対話し，質問に回答するため)に必要なスキルレベルなどです。
• 問題なのは，両者の時間的なアベイラビリティやスキル，チーム規模といったものが，契約時点では定義されていないことが多く，従って議論もされていないことです。

この時点でソフトウェア提供プロセスは“始動(set in motion)”しているのですが，ある時点で必ず“驚き”が現れます。当初予定していた開発者が(退職したり，別のプロジェクトにアサインされて)参加できない，顧客が何かの四半期目標達成に忙しくて質問に答えられい，といったことが明らかになって，驚かされるのです。

どうすればいいのでしょう？計画をやりなおすべきでしょうか？価格や当初の仕様を見直すべきでしょうか？

私は#NoEstimatesに関する自分の書籍で，これらとは違う提案を詳しく説明しています。すべてのパラメータを事前に定義しようとせずに，すでに分かっているもの，重要なものだけを定義するのです。プロジェクトの価格には上限がなくてはなりませんから，予算を定義する必要があります。顧客の側には，契約者が提供するものの“承認”を業務とする人あるいは人々がいることも少なくありませんから，最終的に提供すべきソフトウェアは何か，という考え方は一般的です。これに基づいた新たなソフトウェア提供のアプローチは，次のようになります。

• プロジェクトの投資ボックス(予算)を定義する。
• プロジェクトへの時間と人の割り当てボックス(別の形の予算)を定義する。
• 価値の提供ないし実証の期限とペース(チームによる定常的な価値の検証と提供の指針となる制約)を定義する。
• ユーザストーリを更新するための定常的かつ周期的プロセスの確立と，すべてのユーザストーリの提供完了日を評価するための納品率(毎週いくつのユーザストーリを完了できるか)の設定を行なった上で，予算に対する最終納期を定期的にレビューする。

スクラムと非常によく似た(ただし見積はありません)このプロセスは，開発プロセスに継続的な透過性を提供する上で十分であると同時に，顧客が必要とするもの(単に望むものではなく)を確実に提供しながら，当初合意した予算に沿うようにプロジェクトを管理することができます。

このアプローチについては，#NoEstimatesの書籍や，ドイツSitegeistのCEOであるSven Ditz氏とともに同書を説明したビデオインタビューでも詳しく説明しています。さらにはiBiko2 CEOのDiego Cenzano氏など７名の#NoEstimates実践者とのインタビューの中でも，世界中のさまざまなソフトウェアプロジェクトにおいて，#NoEstimatesのアイデアがどのように利用されているか述べられています。

InfoQ: 多くの場合において，請負開発者が仕事を始める上で最初に必要なのは契約，すなわち両者の合意ですが，#NoEstimatesでは何が合意の基準になるのでしょうか？

Duarte:どんな契約であっても合意は必要です。見積があってもなくても，それは同じです。合意は言わば，両者が共同で作業することによって，失うものより得るものが多いことを確信するための手段のひとつなのです。ここで見積は大した役には立ちません。実際のところ，見積が契約において何よりも重要な要因であるならば，契約はもっと少なくで済むはずです。理由は単純で，ソフトウェアの実際のコストを推し量る上において，見積はあまり優れたツールではないからです。しかもプロジェクトの規模が大きいほど，許容可能なコストの上限を設定するために，不適切な見積が行われる傾向があります。

• “完成した大規模システム中，およそ66%がスケジュール遅延やコスト超過を経験している”   “Project Management Tools and Software Failures and Successes”, Capers Jones, Crosstalk, Journal of Defense Software Engineering
• 2011年のCHAOSレポートによると，調査対象となったプロジェクトの遅延の平均は63%でした。この数値は，あるソフトウェア開発企業で私が2003年に行なった個人的な調査とも一致しています。17プロジェクトを対象としたその調査では，遅延の平均は62%，最大のプロジェクトでは200%でした。
• Scott Ambler氏は，ソフトウェア業界でのプロジェクト成功に関する調査で有名ですが，2013年のデータによると，従来形式のプロジェクトの53%が“失敗”(ソリューションを提供できなかった)あるいは“問題あり”(成功基準に達しなかった)でした。
• AccentureがNHSプロジェクトの失敗によって１億英国ポンドのペナルティを課されたことは有名な話です。そのような特殊なケースで非難されるべきなのは，何も見積だけではありません。この失敗を引き起こした増分的な成果提供の欠如が，私たちが見積と称しているツールへの信仰によって容認されるだけでなく，奨励までされていることに問題があるのです。

これらは，私たち一人ひとりが知っている数多くの例の，ほんの一部です。見積は，ソフトウェアプロジェクトのコストに上限を設定するツールとしては，極めて非効率的なのです。

ですからプロバイダと顧客の関係における基本的な取り決めは，価値の定期的かつ検証可能な提供に基づいた，明確なものでなくてはなりません。私が顧客ならば，具体的な価値の提供をいつまで待てるかを定義したいと思うでしょう。逆にベンダならば，提供した機能の妥当性を確認するためのフィードバックが，どの程度迅速に得られるかを知りたいと思います。

提供した結果に顧客が満足して，それ以上の成果を求めないのいであれば，契約の終了を定義するのは簡単なはずです。逆にユーザからのフィードバックがなければ，開発成果を後になって拒絶される可能性が非常に高くなるので，フィードバックが提供されるまで契約を停止するような仕組みがベンダには必要になります。

ソフトウェアの開発は家を建てるのとは違います。事前にすべての結果を知ることはできません(家を建てるときもそうですが)し，自由度が高いために，顧客とベンダ双方に有益な相互関係に基づいた開発が必要になります。

InfoQ: あなたがこれまで経験した契約関係には，どのような種類のものがありましたか？その中に，このアプローチが適さないものはあるのでしょうか？

Duarte: 非常に重要な質問ですね。これについてはEvan Leybourn氏に#NoEstimateについてのミニ電子ブックを書いてもらって，さまざまな契約の種類や，顧客とベンダが信頼関係を結ぶ上でそれらがいかに重要かを説明することにしています。ミニ電子ブックの内容全体をここで説明することはしませんが，(#NoEstimatesのような)相互利益的なアプローチの利用をサポートする契約と，一方のリスク(と責任)を他方へ移行するための契約がある，ということの理解が重要です。

例えば，信頼性の低い状態で使用される契約の一例として，費用や範囲，期間を完全に固定した契約が考えられます。しかしそれでは，より強い信頼関係を築くどころか，かえってお互いの不信感を増すことになります。ベンダ側は契約に含まれた変更要求の準備を利用(ないし乱用)することで(契約で定義されていないものはすべて有償とすることで)利益を得ようとするでしょうし，顧客の側では，新しい発想もすべて当初のスコープ内であると主張するでしょう。その結果のダイナミクスは，おそらく皆さんよくご存知だと思います   アジャイルの第３価値 “契約交渉よりも顧客との協調を”とは正反対です。

その対極に，契約を行なわない企業の存在があります(#NoEstimateの書籍では，そのCEOにインタビューしています)。２週間ごとに価値を提供することで，両企業の共同作業から生み出された価値に基づいて関係を継続ないし停止する，というものです。

話を明確にするために極端な例をあげましたが，これらは#NoEstimateの利用をサポートしない(期間，費用，範囲を固定した契約)モデルと，その正反対にあって#NoEstimatesをサポートすると同時に，価値の提供に常に重点を置いた，#NoContractsとも呼べるモデルとを表しています。

ただし，Sven Ditz氏がNoEstimates書籍にインタビューで述べているように，#NoContractsはすべての顧客に対して適用すべきものではありません。契約(これは法律的に自らを保護する手段でもあります)をせずに開発を行なうという考え方が受け入れられやすい顧客と，そうではない顧客があるからです。#NoEstimatesや#NoContractsのような斬新なアイデアを実施するには，実験に参加して開発を行なう意思のある顧客を見つけることが必要になります。

InfoQ: #NoiEstimatesは少なくとも２つのエンティティ間の信頼だということですが，信頼を築く上でのアドバイスは何かありますか？

Duarte: 素晴らしい質問ですね。契約について話した時に述べたように，信頼を築くには時間といくつかのツールが必要で，契約もそのひとつです。しかしながら，どのようなソフトウェアチームでも利用可能な，強力なツールがひとつあります   ステークホルダにとって価値のあるものを早期かつ頻繁に提供することです。このアジャイル原則が，信頼構築のための重要なツールのひとつなのです。もうひとつの信頼構築ツールは透明性で，#NoEstimatesについて説明する場合に重視しているものです。少し前に，あるプログラムマネージャ(プログラム内のいくつかのプロジェクトを管理する)と，チーム(複数のプロジェクト)が期日にプログラムを提供可能かどうか，結論を出そうとしていた時のことです。件のプロジェクトマネージャは，別のプロジェクトチームが期日までに提供可能だと考えていました。それには理由がありました   彼はそのチームに対して，そのことを要求済みだったのです。チームの側でも，プロジェクトの見積を行なった結果として，期日までに提供可能だという結論に(全員が)達していました。

“素晴らしい！”，全チームが期限までに作業を完了できそうだ，と彼は考えました。ここで分かるのは，彼は個々のチームによる見積から結論を出した，ということです。プログラム全体での提供率については見ていませんでした(プログラムはさまざまなモバイルデバイス用に単一のソースベースを提供するもので，内部的に複数のアプリケーションがありました)。そこで私は#NoEstimateを使って，システム全体，つまりひとつの完全なシステムを提供するチームすべてを一体として，そのスループットを評価することにしたのです。私の見解は彼とは違いました。作業の速度あるいはプロジェクト全体としてのスループットが，期日までにプログラムを提供するにはまったく不足していることが，(見積ではなく)事実として分かったのです。私はデータを揃えて，プログラムマネージャに状況を説明しました。彼は礼儀正しく聞いていましたが，私の頭がおかしいとでも思ったのでしょう。結局，プログラム(とプロジェクト!)は続けられました。マネジメントスクールでは，プロジェクト計画＋見積が“真実”だと教えられます。各チームが個別に，期限までに完了すると見積もったのですから，プログラム全体も期限どおりに完了するはずだ，というのです。１年後(6ヶ月の予定が18ヶ月となって)，そのプログラムはキャンセルされ，その会社は最終的に(そのプログラム以外の多くの理由で)倒産しました。私が正しかったことで残念な思いをしたケースです。本当は私が正しかったのではありません。私は単なるメッセンジャだったのです。正しかったのはシステムです。システムのスループットはプログラムマネージャに，彼とその会社が失敗することを告げていました。しかしプログラムマネージャは，システムメトリックを見ることも信じることも，教わっていなかったのです。私たちの多くがそうであるように，彼もまた，将来のイベントに対して人が考えた見積だけを信じるように教えられていました。ソフトウェア産業における見積の歴史が惨憺たるものである(上記参照)にも関わらず，なのです。

つまり，信頼の構築には，システムの測定を重視する必要があります。見積はフィードバックを遅らせるだけです(遅れに気付いた時には，もう手遅れです)。スループットやサイクルタイムのようなシステムメトリックスを使うことで，意思決定に必要な透過性をプロジェクトの初期段階から手に入れられるようになります。しかも，長くて退屈な見積セッションに付き合う必要がない，というおまけ付きなのです。

チャーチルの言葉を借りれば   私たちの使うテクニック(見積)がいかに美しくても，最終的にはその結果を受け入れなくてはなりません。そして見積には，極めて悪い結果があるだけなのです。

InfoQ: MVP(Minimum Viable Product)のことはご存知だと思いますが，あなた自身はMVPをどのように定義していますか？

Duarte: よい質問です。その定義について話す前に，契約について，私たちが考えている特徴についてまとめてみましょう。

• 顧客の立場から，契約が最低限備えるべきものは:
  • 将来的な訴訟費用の削減
  • 悪徳ベンダに対する法的保護の提供
  • 成果の成功を評価するための明確なルールの確立
  • 一定レベルの成果が提供されない場合，補償金の受け取りを可能にする
  • ベンダとの関係が存続不可能になった場合，ベンダの変更を可能にする
• ベンダの立場からは:
  • 透過的な関係を構築するために，ベンダと顧客の間の仲介者(弁護士など)を排除する
  • 無節操な顧客に対する法的保護の提供
  • 成果を評価するための明確なルールの確立
  • 成果の提供から承認までのフィードバックサイクルを短縮することによって，成果提供後の承認(および支払)までの期間が長くなることによるリスクを軽減する
  • ベンダの貢献(時間，素材，IP)に対する正当な保証の受け取りを可能にする
  • 顧客との関係が持続不可能な場合，すべてのベンダが関係破棄を可能にする

これらの要件のほとんどは，ベンダと顧客の合意で簡単に達成することが可能です。

• ベンダは2週間(あるいはそれ以下)に期間を限定して，合意された全体目標，機能，あるいはユーザストーリ集の開発を実施し，その期間の終わりに完成したものを，実際に近い環境でデモンストレーションする。
• 2週間のイテレーションに要する作業負担については，例えば開発者/テスタ３，プロダクトオーナ１，スクラムマスタ１というよに，前もって両者で取り決めておく。
• 期間の終了時に，顧客は，成果物を拒否して支払を行なわない権利を持つ。
• ベンダも等価的に，イテレーションの境界(この例では２週間毎)にプロジェクトの作業を停止する権利を持つ。

上記のルールは，ソフトウェア開発へのアプローチとしてスクラムを実施する場合に，多くのチームがすでに使用しているものと非常によく似ています。ただしこのアプローチでは見積は必要ありません。顧客のビジネスニーズを満たす価値を早期に，定期的に提供することだけが要件なのです。

上記のルールのもうひとつの利点は，ベンダと顧客の双方が契約の必要性を放棄し，単にこれらのルールに従って作業を進めることによって，リスクを非常に低く(２週間の投資のみに)できることです。アプローチとしては，Sven Ditz氏がNoEstimates書籍に関するインタビューで説明したものとほぼ同じです。