Agile2010 Day Three

本日も我が道を行く。

From Estimate to Contract - Choosing the Right Model for Your Situation

Chris Shinkle/Jim LaRue両氏による好発表。基礎となっているのは「熊とワルツを」で紹介されているモンテカルロ法を使ったプロジェクト見積もり変動シミュレーション。このシミュレーションを元に、契約をFFP(Firm Fixed Price: 定額)にするのか、T&M(Time and Material: いわゆる人月課金)にするのか、ハイブリッド(FFPとT&M組み合わせ)にするのかを判断し、その過程を顧客にも正直に見せよう、というお話。

そもそもなぜ「契約」が必要なのか、という所から両氏の説明は始まる。

  • 信頼できない相手との交渉は難しい。
  • だから契約で互いを縛り、両者間に「信頼」が醸成されることを期待するのである。

その契約は、基本的には二種類しかない。

  • FFP: Firm Fixed Price=この金額で成果を納めます、という契約。
  • T&M: Time and Material=成果を納めるまでの時間単価×期間を請求いたします、という契約。

例えばシステム開発FFP契約を締結すると、理論的には開発側は無限のリスクを背負うことになる。初期見積もりが甘すぎて、実はとんでもない開発量を見逃していた、という場合だ。

一方のT&Mだと、今度は顧客側が無限のリスクを背負うことになる。やはり初期見積もりが甘すぎて、実はとんでもない開発量を見逃していた、という場合だ。

どちらの場合も、開発側と顧客との間の信頼は醸成されない。

反対に過大見積もりを行えば、ある程度の予算・期間超過に対するバッファは得られる。だが、ゲタをはかせていた事実がばれればやはり相互の信頼は損なわれる。

これらのリスクをある程度押さえ込む方法もある。FFPとT&Mを組み合わせるハイブリッドで、その組み合わせ次第でリスクを誰がどんな形で持つかは色々変わってくる。とはいうものの、やはり初期の想定を大きく外れるような結果は、やはり相互の信頼を損なう。

Chris/Jim達が実践しているのは「熊とワルツを」で紹介されているモンテカルロ法を使ったシミュレーションで、見積もりの「ブレ」を検証することだ。
From Estimate to Contract - Choosing Right Contract Model for Your Situation

  1. 通常に(Story Pointなどで)必要人月を見積もり、スプレッドシートに入力。
  2. 付帯条件を取り除いた必要人月を見積もり、スプレッドシートに入力。
  3. 見積もり時の各種リスクを設定。ここは主観が入るが、これについては後述。設定項目は「見積もりの粗さ」「関係者の離職率」「要件の成長率」「プロジェクト失敗確率」「関係者生産性のばらつき」で、設定方法は「なし」「低」「中」「高」と簡単になっている。(写真下)

From Estimate to Contract - Choosing Right Contract Model for Your Situation

From Estimate to Contract - Choosing Right Contract Model for Your Situation
プロジェクトの価格設定。FFPの場合は付帯条件をつけられる。T&Mの時は基本料と人月課金とを設定できる。

From Estimate to Contract - Choosing Right Contract Model for Your Situation
これらの条件を設定すると、右側のほうのチャートが描画される。上から順に「人月数のばらつき期待値分布」「原価期待値分布」「T&Mでの売値期待値分布」「FFPでの売値」。上の3つには縦棒が入っているが、これは上限・下限からそれぞれ10%のところ。つまり、この領域に挟まれる部分に落ち着く確率は80%となり、リスクが低いと判断できる。また、曲線が横に広がる場合はばらつきが大きいということなので、リスクは高いといえる。

Chris/Jimが強調していたのは、このチャートを顧客と共有しろ、ということ。これにより、売り手は粗利率など手の内をを顧客に見せることになってしまうが、同時に「もう少し見積もりに費用をかけるほうがいい」とか「不明な条件が多すぎる」といった要望を堂々と出せるようになる。彼らの経験では、このような見積もりの「透明度」を顧客に与えることで信頼度が上がり、顧客側も協力的になることが普通だ、とのことである。

帰ったら久しぶりに熊とワルツを、を読んでみよう。なお、見積もりに使っているスプレッドシートへのURLも同本に掲載されている。(発表で使っていたのはそのシートを改造したもの)

熊とワルツを - リスクを愉しむプロジェクト管理

熊とワルツを - リスクを愉しむプロジェクト管理

Becoming Agile: Designing a Transition Plan from Waterfall to Agile

Jorgen Hessenberg氏による発表。

正直期待はずれだった。ウォーターフォールな体質の企業がAgile型企業に移行するための経営レベルでの5段階行動、という「思考フレームワーク」を説明してくれた。ただし内容は過去何度も発表されていて目新しさは感じられなかった。

「技術、組織、指導者、人、文化を変えないとAgile化はできません!」という考え方には完全に同意するが、ではどうしたらそれらが変わるのかという方法論については中々簡単ではない。今回はその「どうしたら良いか」という部分を机ごとに議論することになったが、「トップダウンで変わるんだ!」みたいな机上の空論をぶち上げるいかにもMBA風味のおじさんもいれば、「総論賛成・各論中立という多数派を動かすのは本当に難しいよね」と実際に苦労した経験を語る兄ちゃんもいて、この「変化させる」過程の難しさを実感した。

ちなみにトップダウンで変えるんだ! とぶち上げていたおじさんは、Agile化がうまくいかなかったらウォーターフォールに戻すと断言していた。本当はそこに「なぜうまくいかなかったのか」の分析と対策を入れてほしいんだけどね。

そのうち発表資料が公開されるはずだが、技術、組織、指導者、人、文化の「Agile度」をLevel 5からLevel 1(一番高い)まで分類するための判断指標が使われていた。まあ、いかにもビジネススクールなやり方だよなぁという印象を受けたが、公開されたらここにリンクを張っておくつもり。

おまけ Uncle Bobは怒ってます

Uncle Bob Martin:

< 10% of the talks at #agile2010 are about programming. Is programming really < 10% of Agile?

Agile2010の発表のうち、プログラミングに関する話題は1割もないじゃないか。プログラミングはAgile開発の1割未満しか占めないものかね?

→今年のAgile2010は確かに計画管理偏重。昨日も書いたけど、開発軽視な雰囲気が漂っていて、それが「何か変だぞ」という印象につながっているのかもしれない。