Agile2010 Day Two

Agile2010 Agile開発

目次

基調講演

An Unplugged Retrospective on the Agile Decade: “Mirror Mirror on the wall are we really the most beautiful of all?”
この10年のAgileをざっくばらんに振り返る。「鏡よ鏡、この世で一番美しいのは誰？」

  • Bedarra Research LabsのDave Thomas氏による講演。
  • 去年の開幕基調講演も「過去10年を振り返る」みたいな感じだった。
  • 個々の部分で面白い話はあったけど、基本的には「もういいよ」みたいな内容ばかり。
  • 終了後も自分の周りではあまり評判はよくなかった。

いくつか印象に残った話は...

  • 昨今のAgileにおける資格重視に対する皮肉。
  • XPにしてもTDDにしても、その他のプラクティスにしても、注目されて、その行き過ぎに対する反省みたいなのが生まれて、それなりの地位に戻った例は多いよね、という指摘。
  • アーキテクチャは役目であり、職ではない。
  • その人自身がコーディングして実現できない内容は、アーキテクトとは呼ばない。

LEARNING AGILE AT HARVARD PILGRIM HEALTHCARE, ONE STEP AT A TIME

発表者はSusan Taylor(シニアプログラマ)/Brian Bpozzuto。

Harvard Pilgrim Healthcare(HPHC)とは、マサチューセッツ州拠点の地域医療保険NPO団体。35年の歴史を持ち、社員は1300人。加入者数100万人。売上は$20億だけど、利益はほぼない。NPOだから。

NPOだし、医療保険というあまり変化のない業界ということもあり、レガシーシステムをずっと使い続けてきた。最後のシステム置き換えは90年代半ば。技術の変化を考える必要はまったくなかった。

そんなHPHCに変化が訪れたのは2004年頃から始まった医療保険制度改革論議で、2006年には全米級の大手United Healthcareと提携。相手は2200万加入者の巨大企業。提携を形にするために、システムも見直しが必要となり、検討が始まったが... 出入り業者が持ってきたのは1億5000万ドルのパッケージソフト導入。しかも一斉切り替えが必要という代物。当然、その要求は飲めず。

そのまま現行システムを騙し騙し使いながら検討を続ける日々が続いたが、景気低迷でマサチューセッツ州の地域医療保険団体が一斉に大幅赤字を出したあたりで限界を感じ、なんらかの対策を打つことになった。一斉切り替えが無理なら、部品単位で徐々にシステムを移行する、ということになった。(が、まだAgileという判断はでていない)

RFP(384の質問)を出し、各業者からの提案を聞くが、ろくなものがない。生き残ったのはDell Perot(Dellが買収したシステムインテグレータPerot)で、年7回の分割リリースを繰り返して、2013年までに最終納品をするという提案。一点だけ不安要素があって、その提案で使われる基盤ソフトウェアはまだ開発途上というところ。

契約は人月単位だが、イタレーション毎に更改。(中止と判断したら、そこまで、ということ)　HPHCは管理のみ。設計実装はDell Perot。→丸投げAgileだ...

という長い長い前置きのあと、本題である「何を学んだか＝どんな失敗をしたか」という話題に移った。この時点で残り時間5分（笑

  • AgileについてHPHC側は何も知らなかった。コンサルを呼んで研修(しかも一人150時間×100人）まで受けたが、さっぱりわからないまま。習ったこと＝Agile研修は役にたたない。
  • 開発担当のDell PerotにHPHCのコンプライアンスを押し付けてしまった。→規約ベースだと、双方の関係はスパイラル的に悪化していく。相手を思い切って信頼する必要性あり。
  • Dell側の役割担当を個人ベースで指名してしまった。→役割はチームに振るべきだった。
  • Agileそのものに問題解決を期待してしまった。→Agileそのものも、Agileコーチも魔法使いではない。開発チームに対する、あるいは開発チーム内部での信頼感を醸成することが大事。だがこれはなかなか難しい。

まあ、結論は「来年も発表しにくるから、1年でどれくらい改善されたか見に来てね〜」ということだったわけだが、以下の点で興味深い。

  • いわゆるコテコテなレガシー企業であり、レガシーシステムとレガシーデータに埋もれている。
  • 幸い、医療保険という商品は息が長いし動きも遅いので、ゆっくりとしたリリースが可能。
  • HPHC自身はシステム企画に相当するところまでしか動かず、実際の設計実装はコントラクタに任せる。(日本でいう受託SI一次受け機能を、自社内に持っている。日本風なSIがアメリカでは珍しいのはこのあたりに理由がある。) ある意味、内製率ゼロのAgileともいえる。
  • とかいいながら規模はでかい。非機能要件込みとはいえRFP 384項目。HPHC側は100人いるが、これ全部管理担当なのである。

Fixed-Bid, Fixed-Feature, Fixed-Time Agile Development(Dan Rawsthorne)

金額固定、要件固定、納期固定におけるAgileのお話。メモを無くしてしまった(涙

要点は

  • 契約前のきわめて粗い要件(ストーリーに落ちる前のUse Caseの固まりくらいの段階)で金額と納期を見積もるコツ。ヒント:バッファの積み上げ方。
  • その後のチーム分割や管理計画の進め方。
    • Product Ownerチーム
    • Area Team...POチームと開発チーム(複数)の間を動き、情報伝達のきっかけを作る。
    • 複数の開発チーム...いわゆるスクラムチーム。

粗い要件段階でバッファを積み上げながら見積もるコツは、顧客を巻き込むこと。ケチり過ぎたらプロジェクトが失敗する可能性が高まることを正直に言え、と。ちょっと精神論っぽいが、これについては翌11日にもっと客観的・合理的に説明する方法を聞いたので、あとでまとめる。ちなみに「最初の見積もりが大きく狂っていたら誰がリスクとるの？」という突っ込みをしたところ、「そうならないように、顧客に見積もりをコミットさせるんだ」という意味不明な回答があった。

チーム分割や管理計画の進め方は、分散スクラムの典型ともいえるやり方。だが、プロジェクト初期の不確実性が残る中で開発チームを分割することによって発生するリスクについてどう対処するのかは、質問しても明確な答えはでてこなかった。「Area Teamが動いてなんとかしてくれる」と、発表者と同じ企業に勤める女性が答えてくれたが、「他チームのチョンボでビルドで止まったらどーすんだよ」という突っ込みには言葉が詰まっていた。→今回、実務がわかってない「自称Agile管理者」「スクラムマスター保持者」が目立つ。心配である。

「途中で初期見積もりにはなかった要件が発生したら？」という質問をしたところ、「初期スコープに入っていなければ、それは契約変更が必要となる。Area TeamとProduct Ownerチームがタスクとして立ち上げて、早急な契約変更を発注主に打診する」という答えがきた。つまり表題の「Fixed Bid, Fixed Feature, Fixed Time」というのは、「フィーチャに変更がなければ」という前提がある、ということ。

なお、発表者は「Agile開発チームはコモディティ化をするのが夢だ」と語っていた。自分のところではProduct Owner teamとArea Teamだけ持ち、開発は外部業者に任せる、と。→そもそもこの構図がソフトウェアの品質を下げ、Agileの存在が受けたはずだったのだが。なんか、今回のAgile2010は本来の路線を逸脱した事例が目立つ気がする。

追記　メモでてきた

  • 大雑把な見積もりは、スクラムの世界でいうストーリポイントで充分。CFP(Cosmic Function Point)使っても大差ない。
  • バッファ積み上げのためにS-Shape Curve(http://en.wikipedia.org/wiki/Sigmoid_function)を活用→意味不明
  • 固定納期固定予算固定要件でも、段階リリースは行う。そのリリースで実現されるESP(Earned Story Point)やEBV(Earned Business Value)も計測する。→消化状況と稼動状況を確認しながらリスクを把握する。