アジャイルの隆盛

WEBの世界の中で、日々ITに関する情報を集めていると、アジャイル開発がシステム開発の完全なる主流になった気になってしまいます。偏った情報収集をしているせいだ、といわれればそれまでですが、WEB/ベンチャー業界・SIer業界・企業IT部門/IT子会社界・オープンソース界全てを通じて、Blogなどで声の大きい方々は多かれ少なかれ『アジャイル』という考えに肩入れしているように感じられます。

当然、世の中の流れが全てそうなっているかというと、そういうわけでは無さそうです。WEB/ベンチャー業界や、オープンソース界では、ほぼメインストリームとなっていると思いますが、SIer業界・企業IT部門/IT子会社界では、全くもって『アジャイル』がメインストリームになっていない状況でしょう（全くないとは言いません）。これは自分も身をもって体験していますが。

アジャイルへの『抵抗勢力』

強引に図解すると、

SIer(受託)業界 & 企業IT部門/IT子会社界

==> 一方的LOVE ==> ||||越えられない壁||||

WEB/ベンチャー業界 & オープンソース界

といった感じでしょうか。

（※他に、パッケージ開発業界とゲーム業界というIT関連業界がありますが、越えられない壁のどちらに位置するか迷うところです。どちらの企業も存在するというのが現状でしょうか。）

この『越えられない壁』に対する、一種諦観を込めたExcuseに使われるのが、

• 企業経営陣のITに対する意識の低さ
• SIerのビジネスモデル
• 契約スキーム
• ウォーターフォール型開発
• 大規模開発
• 人月・生産性

などだと思います。整理すると、

『ビジネスの分業に対する問題』

• 企業経営陣のITに対する意識の低さ
• SIerのビジネスモデル

→ アジャイルの重要なファクターである『顧客を巻き込んで協調した開発』を阻害する

『長期的計画に対する問題』

• 契約スキーム
• ウォーターフォール型開発
• 大規模開発

→ アジャイルの重要なファクターである『漸進的な開発』を阻害する

『メトリクス測定に対する問題』

• 人月・生産性

→ アジャイルの重要なファクターである『動くものを価値とする』という価値観を阻害する

これら『抵抗勢力』故に、アジャイル不可能、という論調がよく見られるように思います。

こういったポイントがちりばめられ、まさにテンプレート化された、しかし内情をえぐっているエントリーが毎年、毎年恒例のように繰り返されます。

• ディフェンシブな開発 〜 SIビジネスの致命的欠陥
• SIerという奇形児と、SIという珠玉の仕事
• 人月計算とExcelとスーツの世界より

『アジャイル』vs『抵抗勢力』に対する軽い違和感

これらのエントリーが全く見当違いだ、というわけではありません。ただ、この先に何か解決が待っていたかというと、そうではなく（これらは2006年から2007年にかけての記事です）、『IT土方』や『十年泥』という一種差別的・自虐的な響きを込めた言葉の流行でした。『抵抗勢力』に対し、改善が観られず防戦一方な気がします。

しかし、これはおかしな話です。本当に『アジャイル』が真に優れているのであれば、経済原理的に、怒濤の勢いでそちらの方向に流れていくはずです。

『人月単価と工数でビジネスが成り立っているから、労働生産性の向上が売上高増加につながりにくい』などといわれますが、これもちょっとおかしい気がします。安く、早く、そして品質を担保できるのであれば、入札時のメリットは計りしれません。期間が短くなれば、他での売り上げ機会も増える、というのが一般的なビジネスの流れでしょう。『そんなに単純な話ではない』と言われればそれまでですが、この通常の流れが阻害される端的な理由は、寡聞にして知りません。

さて、ここまで来ると、

これら『抵抗勢力』って、ホントにアジャイルの敵なのか？

そもそも、『アジャイル』って、ホントに価値があるのか？

と疑りたくなってきます。

アジャイル・グルは、『従来のウォーターフォール型のやり方との「戦い」』と言い、高々とアジャイル宣言が唱われ、RubyKaigi2009やデブサミ2009でも、アジャイルと、人間性と、デザイン・アートと、クリエイティビティに対する賛歌は感動的です。『抵抗勢力』はさながら帝国軍で、アジャイル・マスター率いる反乱同盟軍よ、立ち上がれ！といった構図が煽られている気がします。

この状況に対して自分が感じるのは、『格差社会』に対する見当違いな対立と同じ雰囲気です。『派遣労働者 vs 雇用主』とか、『非正規雇用 vs 正社員』とか。

『格差社会』の問題の本質が『雇用法』というそもそもの全体システムにあるんじゃないか？？というコンセンサスができはじめている気がしますが、まだまだバーサス型の対立はわかりやすいので、政党は『製造業への派遣禁止』などという、見当の外れた解決策を提示してしまったりします。

同じ違和感を、『アジャイル vs 大規模ウォーターフォール型開発』『アジャイル vs メトリクス測定』というバーサス型の対立に感じるのです。

この違和感が決定的になったのが、日本が誇るアジャイル・グルである株式会社チェンジビジョン代表・平鍋 健児さんによる、

『「測定できないものは制御できない｣は誤りだった。– by Tom Demarco』という記事でした。

トム・デマルコ氏の蹉跌と、その記事に対する誤謬

システム工学界の巨匠トム・デマルコ氏の言動の影響力は絶大です。自分も、『“ピープルウエア』や『“ゆとりの法則 Slack』『デッドライン』などは夢中になって読み、学んだ覚えがあります。そして、『測定できないものは制御できない』（測定できるものは改善できる、ともいいますね）という一文で始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』というソフトウェア工学の古典的名著も存在します。

そのデマルコ氏が、よりによって『「測定できないものは制御できない」は誤りだった。』と言ったというのですから、これは自分にとって一大事です。

平鍋さんの記事によると、こうです（以下引用）。

1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあるものだ。だから、「計測による制御」という概念を疑うことは、「ソフトウェア工学」というものの存在、あるいは、意味を大きく問う問題でもある。

では、計測しないで制御する、という方法があるというのだろうか？

この記事のなかで、例えば、GoogleEarch や Wikipedia といったソフトウェアが、果たして計測と制御という管理で作られただろうか、と問うている。そして、２つの種類のプロジェクトを例にし、

• Project A: 100万ドルのコストを使って 110 万ドルの価値を作る。
• Project B: 100万ドルのコストを使って 5,000 万ドル以上の価値を作る。

「計測と制御」は、Project A の世界では有効だが、Project B の世界ではほとんど意味をなさない、と指摘している。これは、

ソフトウェア開発という活動には「計測と制御」よりもっと大切なことが多く含まれており、その中では、「工学」の概念は「ポイントを外している」

ということだ。

An Agile Way 「測定できないものは制御できない｣は誤りだった。– by Tom Demarco

確かに、と思わせるところもありますが、少し違和感を覚えたので原文を読んでみました。

するとそこに書いてあったのは、平鍋さんのエントリーからは若干違う印象でした。（強調は自分。一部抜粋）

In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still beleieve that metrics are a must for any successful software development effort? My answers are no, no, and no.

考え込んでしまうが、（『品質と生産性を重視したソフトウェア開発プロジェクト技法』と言う本の中での）私のアドバイスは、その時正しかったのだろうか？そして、いまだに私は、メトリクスの測定を全ての成功するソフトウェア開発のための必須の努力と信じているだろうか？わたしの答えは全てNoだ（「違う、断じて違う」からコメント指摘により修正）。

Many projects have proceeded without much control but managed to produce wonderful products such as GoogleEarth or Wikipedia.

To understand control’s real role, you need to distinguish between two drastically different kinds of projects:

• Project A will eventually cost about a million dollars and produce value of around $1.1 million.
• Project B will eventually cost about a million dollars and produce value of more than $50 million.

What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B.

Googleアースや、ウィキペディアのように、過剰にコントロールされなくても素晴らしいプロダクトが多くのプロジェクトでマネジメントされてきている。

コントロールの本当の役割を理解するために、二つの全く異なった種類のプロジェクトを分けて考える必要がある。

• Project A: 100万ドルのコストを使って 110 万ドルの価値を作る。
• Project B: 100万ドルのコストを使って 5,000 万ドル以上の価値を作る。

明らかなのは、Project Aにとってコントロールは本当に重要だが、Project Bにとってはほとんど重要でないということだ。

Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much.

本当にコントロール無しで、あるいは相対的にほんの少しのコントロールでプロジェクトを実行して良いと言えるだろうか？ ほぼそうだ。私が提案したいのは、まず、精確なコントロールを必要としないプロジェクトを選ぶ必要があると言うことだ。

Consistency and predictability are still desirable, but they haven’t ever been the most important things.

一貫性と予測性は未だ望ましいものだ。しかし、それらはもはや最も重要な事柄ではなくなった。

The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.

最も重要なゴールは変化すること、世界を変える、あるいは組織のビジネスそのものを変えるソフトウェアを作ることだ。

Software Engineering: An Idea Whose Time Has Come and Gone? by Tom DeMarco

平鍋さんは、

ソフトウェア開発という活動には「計測と制御」よりもっと大切なことが多く含まれており、その中では、「工学」の概念は「ポイントを外している」

とまとめましたが、これはミスリードを招くまとめではないでしょうか？ 自分にはこのまとめ方は、『ソフトウェア開発』というひとくくりの活動には、「計測と制御」より重要なものがある、と、読めました。穿った読み方ですが、『（全ての）ソフトウェア開発は、本質的にアジャイルがマッチする、計測と制御は適当でない』と読めなくもない気がします。

しかし、トム・デマルコ氏が言及しているのは、

ソフトウェア開発には２種類のタイプがあり、それは「計測と制御」が重要なタイプ(Project A)と、全く重要でないタイプ(Project B)だ。

この二つは、厳密に分ける必要があり、ビジネスにとって重要なゴールは、より(Project B)タイプ、アジャイル型にシフトしている。

ということのように思います。これは同じようで大きな違いです。トム・デマルコ氏が言及している、『厳然と２種類ある』という視点がとても重要だと自分は思います。

さらに、平鍋さんのエントリーのタイトルである『測定できないものは制御できない｣は誤りだった。– by Tom Demarco』という記述は、原文のどこにもありません。強いて言うなら、『全ての成功するソフトウェア開発は、測定して制御されている、というのは誤りだった』ということでしょう。これについて、平鍋さん御自身がコメント欄にて、意図的な『釣り』タイトルであった、と述べられています。

アジャイル・エバンジェリストでありかつ、それが御自身のビジネスと直結している平鍋さんのポジションを考えれば、ある一定の煽りや釣りは、コミュニティ全体の活力につながることが理解できます（RubyOnRailsはJavaに比べて生産性１０倍、みたいなものです）。しかし一方で、『アジャイル vs メトリクス測定』という、『派遣労働者 vs 雇用主』式の対立構造を煽ることは、『本質的な全体システムの問題』への対応を遅らせ、結局のところ『アジャイル』の普及に影響を与える気がしてなりません。

ちなみに、今回は、深く考えるきっかけとなった平鍋さんのエントリーの件を例に挙げましたが、アジャイル、オープンソース系の論壇に立っている方々は多かれ少なかれこういった、『vs 抵抗勢力』型の問題定義をされることが多いと思います。別に平鍋さんの揚げ足をとりたいわけではありません。

それでは、アジャイルを阻む、『vs 抵抗勢力』でない、『本質的な全体システムの問題』とは、いったいなんでしょうか？

そこで、トム・デマルコ氏の『ソフトウェア開発には２種類のタイプが存在する』という考え方がものすごく大きなヒントになります。

氏は、Project A (100万ドルで110万ドルの価値)と、Project B (100万ドルで5,000万ドル以上の価値)の２タイプが存在し、Project B (100万ドルで5,000万ドル以上の価値)がより重要、と指摘しました。

それでは、Project A (100万ドルで110万ドルの価値)は、本質的に必要ないものなのでしょうか？

もし、Project B (100万ドルで5,000万ドル以上の価値)のために、Project A (100万ドルで110万ドルの価値)が、必要不可欠な存在であったらどうでしょう？

そのような考え方があります。著名な経営コンサルタントである、ジェフリー・ムーア氏による『ライフサイクル・イノベーション』というモデルです。

日本での初出は２００６年の『ライフサイクル イノベーション』出版です。『キャズム』の著者による新刊、と言うことで、２００６年当時、話題になったことを覚えていらっしゃる方も多いかと思います。

Project A (100万ドルで110万ドルの価値)を源泉とし、Project B (100万ドルで5,000万ドル以上の価値)が生まれる。そして、Project B (100万ドルで5,000万ドル以上の価値)が育って、やがてProject A (100万ドルで110万ドルの価値)に変わっていく、という『イノベーションのライフサイクル』を繰り返すモデルです。

このモデルが正しいとすれば、『本質的な全体システムの問題』とは、この全体サイクルの不全である、という仮説が成り立ちます。

自分の問題意識と、伝えたいこと

さてここで、まとめたいと思います。

• 自分の問題意識
  • 『アジャイル』というパワー、そしてそれを推し進めている人々が考えがちな『vs 仮想敵（ウォーターフォールや人月、契約モデル等）』は、解決の無い方向ではないか？
  • SIer、企業IT部門等で問題になっており、『IT土方』や『十年泥』という言葉に象徴される『現場 vs 経営層』『多重下請け vs SIビジネスモデル』という対立も、同様に解決に至らない道ではないか？

• 伝えたいこと
  • 組織内での『イノベーションのライフサイクル』という考え方がある
  • この『イノベーションのライフサイクル』が正しく設計されず、全員の認識が一致していないと、全体サイクルが機能不全を起こして上記の問題が発生するのではないか？

この後のエントリーの流れ

以上のことを解説するために、継続して以下の内容にまとめる予定です。

• アジャイルは二度死ぬ(Agile Only Live Twice)その２：ライフサイクル・イノベーション
  • まず、ジェフリー・ムーア氏の『ライフサイクル・イノベーション』に関して詳しく説明します。
  • トム・デマルコ氏が指摘した、Project A (100万ドルで110万ドルの価値)とProject B (100万ドルで5,000万ドル以上の価値)の２種類のソフトウェア開発が、なぜ相補的なものなのかを解説します。

• アジャイルは二度死ぬ(Agile Only Live Twice)その３：SIer、ITコンサル、大手企業、ベンチャー、そしてGoogle、それぞれのライフサイクル仮説
  • 次に、その『ライフサイクル・イノベーション』が様々な組織に、どのように適用されるか、ライフサイクル仮説を立てて検証してみたいと思います。

• アジャイルは二度死ぬ(Agile Only Live Twice)その４：『パターン、Wiki、XP』による創造とその限界
  • 最近、産総研の江渡浩一郎氏が書かれた、『パターン、Wiki、XP ~時を超えた創造の原則』という本を読みました。
    

    

    パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

    著者／訳者：江渡 浩一郎

    出版社：技術評論社( 2009-07-10 )

    定価：￥ 2,394

    Amazon価格：￥ 2,394

    単行本（ソフトカバー） ( 224 ページ )

    ISBN-10 : 4774138975

    ISBN-13 : 9784774138978

    ---

  • アジャイルだけでなく、クリエイティビティを語る上で、マイルストーン的な存在になると思われる素晴らしい本です。建築業界の異端児であるクリストファー・アレグザンダー氏の建築上の構想が、数十年の時を経て、デザインパターン、Wiki、アジャイル（XP）につながり、進化していく過程が分かる、エキサイティングな内容です。
  • しかし、クリエイティビティに対する思想的な成長と伝播は凄まじいものがあったものの、その源流たるクリストファー・アレグザンダー氏の実践や、ケント・ベッグ氏の記念碑的プロジェクト（クライスラーによるC3プロジェクト）は必ずしも大成功とは言えないものだったようです。
  • イノベーションのライフサイクルの観点から、これらの蹉跌は何が原因だったのかを検証します。

• アジャイルは二度死ぬ(Agile Only Live Twice)その５：時を超えた創造と”破壊”の原則
  • 『時を超えた創造の原則』というのは、前述の江渡氏による『パターン、Wiki、XP』の副題でもありますが、由来はクリストファー・アレグザンダー氏による『時を超えた建設の道』というエポックメイキング的な著作にあります。そしてこの本こそが若き日のケント・ベッグ氏やウォード・カニンガム氏に強烈な影響を与え、デザインパターン、Wiki、XPにつながる源流となりました。
  • しかし、この数十年にわたる『創造』の追求には、本来『創造』とセットで考えるべき、『破壊』の原則が抜けているように感じます。
  • 『創造』と『破壊』がセットになって初めて、『イノベーションのライフサイクル』が完結する、という考えをまとめます。

アジャイルは二度目の”生”を生きるべきだ

一連のエントリーのタイトルである、『アジャイルは二度死ぬ(Agile Only Live Twice)』は、平鍋さんにあやかり:-P、半分釣りです(笑。

おわかりの通り、００７のキッチュな名作『００７は二度死ぬ(You Only Live Twice) 』からとっています。

しかし、釣りは半分で、半分は自分の願望を表しているつもりです。

日本語タイトルだと、２回死ぬ、と言うところにフォーカスが当たっていますが、実のところ原題は『You Only Live Twice』であり直訳では、『人は二度しか生きることができない』となります。Wikipediaによれば、これは原作者イアン・フレミング氏が、

来日した際に「松尾芭蕉の俳句にならって」詠んでみたという俳句調の詩、「人は二度しか生きることがない、この世に生を受けた時、そして死に臨む時」に由来する。

wikipedia – 007は二度死ぬ

そうです。

アジャイルは、クリストファー・アレグザンダー氏による揺籃期から、ベッグ氏、カニンガム氏により生まれて一度目の”生”を生きてきたように思います。

しかし、その世間的な盛り上がりと反比例するような、自分が感じている閉塞感・違和感を脱却するには、アジャイルを超えた、イノベーションのライフサイクルを回すことにより、アジャイルが二度目の”生”を生きる必要があるのではないか？との思いから、このタイトルをつけました。

結果、アジャイルが『破壊』されるかもしれません。しかし、それは次のイノベーションのための『リサイクル』になるはずです。

実のところを言うと、私自身が、大規模プロジェクトの伝統的なマネジメントと、小規模アジャイル開発のマネジメントの間を行ったり来たりして、目指すべきところがよく分からなくなってしまったため、自分の方向性と業界の問題を整理するためにまとめたものでもあります。

そんな自分の整理のための文章を晒すのは恥ずかしいものですが、自分より若い人たちが同様の迷いを持ったときに、参考の一つになれば幸いです。

自分のバックグラウンドとポジション

この変なエントリーを書いた背景として、自分のバックグラウンドとポジションを記述しておきます。

いろいろな概念がぐちゃぐちゃと入ってくると思いますが、その原因というか理由がこれらのごった煮だと思われます。

• バックグラウンド
  • ITコンサルタント
    • 某ITコンサルティングファームで、コンサルタントとして過ごしてきました。
    • 戦略コンサルタントの人たちとタッグを組み、経営者、CIO、経営企画の方々とディスカッションを重ねてお仕事をさせて頂いてきました。
  • SEとしてのプロジェクト・マネージャー
    • 一方で、描いた戦略を、実際の現場に落とす際のシステム開発プロジェクトのプロジェクト・マネージャーとしてお仕事をさせて頂いてきました。
    • 私のメインキャリアはこちらの方になります。主に金融系で働いてきました。
  • フリー・ランサー
    • 2009年現在は、フリーランスのITプロジェクトマネージャーとして活動しています。
  • デザイン
    • 有限会社セン・スペースデザインという、『デザイン』の名が入った会社組織を作っています。
    • その名の通り、ITに関連した『デザイン』もやります。
    • クリストファー・アレグザンダー氏の建設に関する話などが好きな理由でもあります。
  • 生物
    • 大学・大学院と、分子細胞生物学の勉強をしていました。
    • ボトムアップからの創発（emergence）といった概念や、進化の多様性と破壊といったサイクルのことが頭から離れないのは、これが理由かなと思います。

• ポジション
  • アジャイル・Love
    • いろいろ、文句的なことを書いていますが、実際のところ、アジャイルLoveです。
    • 平鍋さんを始め、アジャイル関係の方々のエントリーや紹介される本、講演などからは非常に影響を受けてきました。
    • 私と一緒にプロジェクトをやったことがある人にとって、KPTシート、私がプロジェクトルームに大量に持ち込むホワイトボード、壁に貼られるポストイットかんばん、プロジェクターなんかはおなじみの光景ですww。
    • また、『XPエクストリーム・プログラミング入門―変化を受け入れる 第２版』の第２３章、「時を超えたプログラミングの道」で、ベック氏による『ソフトウェアでは、新たな社会構造を作る機会がある』という一文に、目頭が熱くなってしまうタイプの人間であることを告白します。
  • Ruby – Love
    • Rubyが好きです。
    • RubyKaigiにも毎年参加してます。最近はRubyOnRailsでいくつかツールを作って、SIerの金融系システム開発プロジェクトに適用すると言った、変則的なことをしたりしてます。
    • Rubyが持っている、アジャイルとイノベーションに適したパワーを、上手くビジネスに活かしていきたいというのが最近のテーマです。

このエントリーを書いたもう２つの理由

長くなりましたが、このエントリーを書き始めた裏の理由が、さらに２つあります。

◆ 経営戦略コンサルタントの人が、『アジャイル』と言い始めた

自分がよくつるんでいる、経営戦略コンサルタントのボスがいます。その人は、企業の経営層へのハイタッチ営業と戦略コンサルティングを得意とする人で、正直IT技術うんぬんというところに明るい人ではまったくありません。

いつも大抵、その人に『お前は馬鹿だアホウだ』とけちょんけちょんにされるのですが、その人が最近突然、『やっぱシステム開発はアジャイルじゃないとだめなんじゃないか？』と言い始めたのです。正直耳を疑いました。

◆ 企業の経営企画の方々が、『アジャイル』を欲し始めた

また、全然別のところで、大企業の経営企画の方々とお話しする機会がありました。その時、やはり『戦略的なプロジェクトはアジャイルに実行して、判断するということがしたいのに、IT部門は全然ついてきてくれない』という愚痴を聞きました。３ヶ月ほどの短期間、低予算でシステムを構築して、様子をみるという戦略を打ちたいのに、いざIT部門に見積もりを依頼すると、１年、億単位の見積もりが帰ってくるので、どの企画も軒並み潰れてしまう、というのです。

明らかに『アジャイル』は各方面から必要とされ、時代が来ていると思いますが、それがなかなか上手くかみ合って回っているとは言えません。

この引っかかりを何とかしたら、世界はもっと面白くなるんじゃないだろうか、と私は思うのです。

（その２へつづく）