Agile2010 Day One

本日はワークショップやチュートリアル中心の日。コマ数が多い中、Organization & Enterprisesを「持続可能な範囲で*1」聞いてきた。

目次

How Agile Taught IBM about New Leadership Competencies

現在はPitney Bowes社の国際技術担当副社長をのSue McKinney女史による「大企業のAgile化に求められる指導者の資質」に関する発表。彼女は去年まではIBMにて「世界各支社のIBM開発体制をAgileに移行する」プロジェクトを担当していた人であり、結果として500チーム25000人がAgile対応できたという。→昨年のAgile2009でのインタビュー。この業界で26年働いているというベテランだ。

IBMで習ったことは「Agileとは不確実性・複雑さをどう扱うか」であり、特に年間平均10社という勢いで買収を繰り返しているIBMでは放置していても組織がどんどん複雑化していく。その中で開発体制をAgileに持っていくというのは並大抵の困難さではなかったと思われるが、結果として

  • 会計ベースでの生産性(投入人件費 vs 収益)は2007年から2009年までで上昇(数字はでなかった)
  • 開発チームの大きさは平均で100人から40人に。余った60人は首になったのではなく、別のプロジェクトに。この分が収益を押し上げた。

という結果が得られているそうな。

その成果を買われ、彼女は今年からPitney Bowes社に移籍する。

PB社は郵便物処理システム(ハード、ソフト両方)を得意とする企業で、創業90年。世界各地に33,000の従業員を抱え年商は56億ドルの大きな企業。インターネットの発展と普及で紙の郵便物は減りつつあり、郵便物処理システム一本に頼るわけには行かなくなる一方で、古い大企業にありがちな硬直化した文化が自己改善を拒んでいた。
How Agile Taught IBM about New Leadership Competencies
同社のAgile化はまだまだ途上と思われるが、彼女がIBMAgile化で習った経験を活かしたいと考えているのは当然であろう。現時点ではAgile対応の技術者が450人育ち、部品点数30%削減などの成果もでているという。

以下、発表で印象に残った言葉:

How Agile Taught IBM about New Leadership Competencies

  • 指導者は開発現場を信頼し、思い切った指揮権委譲をするべきである。(Trust and Empowerment)
  • 指揮統制を断念せよ。(Give up "Command and Control")
  • Agile化は旅である。(This is a journey.)
  • 500ページもある設計書なんて誰が読みますか。(Who reads a 500 pages of design document?)
  • 相互不信に値札をつけるといくらになると思いますか?

彼女の主張は一貫していて「相互不信が過剰な管理を生む」「過剰な管理は生産性を下げる」「それはさらに相互不信を加速させる」という負の連鎖こそが、システム発注者と開発者との関係を悪くする、というものである。これは社内開発だろうが外部委託開発だろうが同じだ、と。

そうではなく、相手を信頼しろ、と。もちろん、盲目的に信頼するのは自殺行為である。だからこそ彼女がかつて在籍したIBMは技術者のAgile化を推進し、同じことが今のPB社でも推進されているわけである。ボトムアップでの改革を助けるような経営からのトップダウン支援。これは見習う必要があろう。

Agility@Scale - Experiences from the Trenches at IBM Rational

こちらはIBM RationalのJean Michel Lemieux氏のお話。

IBMがRationalを買収したのが2003年。そのRationalの開発支援ツールをオープンソースEclipseと統合して、IBM Jazzなるものができたらしいが、自分はRationalがどうしても好きになれなかったのでJazzそのものについてはどうでもよい。

面白かったのは合併に伴う製品統合、しかも片一方はプロプラ、片一方はオープンソース、当然顧客ベースも異なるという泥沼の中で、IBM Rationalがどういう工夫をしてきたか、という苦労話に尽きる。(きわめて稀な話なので、全部を真似する必要はないが、参考になる話もあった)

  • 開発者と顧客の間でバックログやチケットを一本化し、共有。

Agility@Scale - experiences from the Trenches at IBM Rational

  • 会話は原則全部オープン。
  • 大きなプロジェクトを分散で開発すればビルドで問題がでるのは当然。それを恐れてはいけない。
  • それどころか、誰がビルドをキックし、その結果がどうなったかをTwitterにフィードしているらしい(驚

Agility@Scale - experiences from the Trenches at IBM Rational
Agility@Scale - experiences from the Trenches at IBM Rational

Agility@Scale - experiences from the Trenches at IBM Rational
→なぜか債務超過の住宅ローンが例えとしてでてきたけど、本当にそうなのか? という疑問は残る(笑
Agility@Scale - experiences from the Trenches at IBM Rational
→投資行動を完全に公開するkaChingの話はわかりやすい例え。

プレゼン資料は字が小さく、しかも量が多すぎてピントがぼけた発表であったが、「バックログとチケットを顧客・開発者で一本化共有せよ」という主張にはうなづけるものがある。自分はまだやったことがないが、Twitterの@ryuzeeさんはかつてそれを実践していた。変に隠さず、正直に公開する。信頼を勝ち得るためは必然ともいえることではなかろうか。

Beyond Scope, Schedule, and Cost: Optimizing Value

Cutter Consortiumの常連発表者Jim Highsmith氏と、The Gap社のPat Reed女史による「Agileプロジェクト計画管理」のお話。Pat Reedは心理学専攻でMBAも持っているが、GAP社のIT Delivery Management Services担当上級部長という肩書き。大学の非常勤講師を30年続ける一方で、ソフトウェア開発の計画管理を「現場で学んだ」人。Agile暦10年。すごい。しかも説明がとてもわかりやすい。

まずはJimが本日の長い講義・実習の前置きを整理。「価値が100万ドル・開発見積もりが100万ドル」というシステムに対し、「実績も100万ドル・価値も100万ドル」という成果と「実績は120万ドルとアシがでたが、価値は110万ドル」という成果のどちらがいいか? という問いかけから始まる。ここでいう「システムの価値」とは、そのシステムが一定期間稼動することで得られる付加価値がいくらなのか? ということ。それは人件費削減による付加価値かもしれないし、新たな販路確保によるものかもしれない。

Jimの指摘は単純だが重要で「例え100万ドルという見積もりをきっちり守ったとしても、そのシステムが10万ドルしか稼がないのなら開発する意味はない」ということである。見積もり(期間、対象、価格)をする前に、そもそもの開発対象システムの「価値」を最適化する必要があるんじゃないの? ということだ。

その「価値」をどう見積もり、開発対象のフィーチャ間にどうやって配分していくかという実習。長くなるので要点のみ。

Beyond Scope, Schedule, and Cost: Optimizing Value

  • フィーチャの重要度を検討し、価値を各フィーチャに分配。
  • そのフィーチャ毎の価値に見合った開発見積もり=Good Enough。
  • 開発イタレーション毎に、見積もった価値と、開発見積もりと、稼動後の価値創造を比較し、フィードバック。

開発を発注する側(自社開発なら経営層、委託開発なら経営層やシステム部門)にとって非常に重要な話だと思った。Agileを喧伝していく時に「そのシステムの価値を見積もることが大事ですよ」という話をすると、「このシステムは価値が計れない」という反応が結構な確率で返ってくる。価値がないのになんで何千万円、何億円もの予算をつぎ込むのか私にはさっぱり理解できないのだけど、今回教えてもらったIntel Business Value Dialsなどのテンプレートを使えば大雑把とはいえ開発対象の価値を見積もれるのではないか。紹介したリンク先にPDFがあるので興味がある人は試してほしい。

以下、印象に残ったお話。

  • Standish Report(Chaos Report)を見る限り、システム開発の失敗は年々減少しているように見える。これは成功と失敗の区別を「見積もり納期を守れたか」で判断しているからであり、そもそもの判断尺度が間違っているという証拠に他ならない。

Beyond Scope, Schedule, and Cost: Optimizing Value

  • プロジェクトの管理指標を導入すれば、その管理指標は徐々に向上していく。ただしそれは指標を守らなければ、という圧力が働くからであり、本来の目的である生産性は低下していくのが常である。

Beyond Scope, Schedule, and Cost: Optimizing Value

  • 初期計画に固執する新興企業ほど早く潰れる。
  • とある企業Agile導入前後比較。圧倒的な品質改善が見られる。不良件数が減ることで、その検知と対策に費やされる労力が減り、生産性が向上する。その反対ではないことに注意。

Beyond Scope, Schedule, and Cost: Optimizing Value

  • 大規模Agileを推進しているBMCの事例。投入人員を増やしているが、納期が圧倒的に短くなっており、全体では収益が向上している。参考: BMCは受託開発が多い。

Beyond Scope, Schedule, and Cost: Optimizing Value

  • バグは早期に取り除くに限る、というお話。エラーフィードバック比率。あるバグを取り除くことで、別のバグを誘発する確率はバグ摘出が遅れるほど大きくなる。

Beyond Scope, Schedule, and Cost: Optimizing Value

  • 技術的負債(Technical Debt)のお話。テストや設計見直しなどの作業を後回しにすることで、プロジェクト後半で問題点が続出するというアレ。技術的負債が大きいほど、選択肢は減り、どれも地獄。

Beyond Scope, Schedule, and Cost: Optimizing Value

  • 見積もりがいかに外れるか、というお話。国防総省のソフトウェアはコード全体の2%しか使われていない。商用ソフトのコードで使われているのは全体の5%未満。

Beyond Scope, Schedule, and Cost: Optimizing Value

  • そういう外れる見積もりに対し、直球勝負で開発を挑むことにどれくらいの意味があるのか? 価値があるのか?
  • 顧客がシステムの価値を算出してくれなければ、開発側は原価計算できない。

Beyond Scope, Schedule, and Cost: Optimizing Value

  • Do More With Less(より少ない労力でより多くの作業を)からDo Less(より少ない作業を)へ
  • フィーチャの価値が高いからといって、そのフィーチャの優先度が高くなるわけではない。
  • 「偉い人」が採算度外視で支持するプロジェクトを「Pet Project」というらしい。このような案件にも、正直に「価値」「価格」を提示することが求められる。その現実を顧客経営ボードが直視できないのならそれはそれで問題。

でも一番印象に残ったのはPatによるGAP社の開発スタイルに関して。Web通販の仕組みは、やはり企画段階から相当揉めるらしい。かつては喧々囂々の議論が続いたが、Agile化してからは「じゃあ作ってから試してみよう」という判断ができるようになった。つまり、「A案」「B案」両方のフィーチャを開発し、消費者には二つのバージョンがあることを内緒で使わせて売上を見る。いわゆるABテスト。

これにより廃案となるどちらかのフィーチャ開発費用はドブに捨てることになる。

だが、議論だけで延々と時間が過ぎて事業機会を失うよりははるかに良い結果になる。もちろん、そんなことをできるのはAgile開発体制が整ったことで生産性が「とりあえず作って試せる」くらい向上しているからなのだろうが。年商145億ドル企業のGAPがAgileを使いこなしているというのはこちらではニュースにもなんにもならない。当たり前だから。

なんかまた日本の重厚長大SI産業が暗く見えてきた一日であった。

*1:報告書地獄にならない程度に間引いて、という意味

*2:IBMなどが支持したRUPのこと