2010-10-02

たばこの吸えるスタバより

アジャイル開発の本質とスケールアップ を読んだ. 本書は前半がアジャイルの復習, 後半が大きなプロジェクトへのアジャイルの適用を扱っている. 前半は網羅的なぶん記述が bullet listive になりがちで面白くない. 後半が本題を扱っている. 著者のレフィングウェルは様々な大規模プロジェクト, 特に IBM/Rational での 開発を通じて得た大規模開発の知見をアジャイルの言葉で説明しようとする. まずチームの分割, 役割分担の話. それからイテレーション, リリースの話に続く. そのほか分散開発やアーキテクチャ, 組織のありかたについても章を割いている. 私はなりゆきから大き目のプロジェクトに参加しており, おかげでこの本は興味深く読めた. ただ不満な部分もあった.

扱っている話題は他人事じゃない. 大きなプロジェクトでの頻繁なリリース. 国をまたいだ分散開発. 機能別チームの足並み合わせ. CI の困難. どうすれば上手くいくのか. 先人の知恵を預れるのはすばらしい.

一方で話が遠くに行ってしまったようにも感じた. もともとアジャイルは各プログラマが主体になってとりくめるものだったのに, この本は管理よりの人間に向けられている. チームに主体性をと言い聞かせる相手がチームメイトでない矛盾. それが書き手のせいだとは思わない. 規模の大きいプロジェクトは形を保つだけで一仕事. 専任がいる. レフィングウェルはそんな専門家にメッセージを送ったのだろう. けれどプロセス保守が専任でない参加者(私とか)にもできることはあってほしい. コードを書くだけが仕事なのは少し悲しい. ミーティングはいやだけど...

もう一つ, スケールに向けた妥協によって もともとのアジャイルがもつ切れ味を損ねているように見えた. その妥協が悪いとは思わない. スケールのために必要なのはわかる. けれど, スケールにあわせて書き換えたプロセスをなおアジャイルと呼ぶのは 受け手の期待を裏切るかもしれないし, アジャイルの名前によって判断が歪むことだってあるかもしれない. 言いがかりじみた主張なのはわかっているけれど, 腑に落ちなさは残った.

スタバとストーリー

そのあとたまたま読んだ ストーリーとしての競争戦略 は, スケールするアジャイルに感じた座りの悪さをうまく説明してくれた.

著者の楠木建がいう <ストーリー> とは, ある企業がたてた経営戦略や方針が互いに噛み合っている様子を指している. 楠木建は世に流布するベストプラクティス主義を批判し, たとえ個々のベストプラクティスが合理的な裏付けを持っていたとしても, それをただ戦略として並べるのは 筋(=ストーリー) が悪い, お互いが組み合わさることで威力を発揮する戦略が望ましいと主張する.

本書はいくつもの <ストーリー> を紹介し, その威力を示していく. 中でもスターバックスが話は印象に残った.

スタバは, 家でも職場でもない, くつろげる第三の場所を提供しようとしている(らしい). そしてこのコンセプトを実現するための戦略を持っている. くつろぎを感じられるよう店舗は照明は落とし目で落ち着いた感じにして, 住宅地よりストレスやテンションの高い人が多い都心の一等地に出店, また土地/場所の印象とブランドを紐づけるために同じ場所に数軒クラスタ化して店をだしたり, 短時間で食事を済ませる慌しい人を遠ざけるため食事を貧相にしたり. 全席禁煙にしたり.

個々の戦略/工夫は中心となるコンセプトに寄与するからこそ効き目があるとした上で, 中でも単一では悪手になるようなアイデアこそが コンセプトから始まる全体の <ストーリー> を支える競争力の核になる. 楠木建はそう主張する.

スタバの場合, フランチャイズでなく直営の店舗を持つのが核だという. 多くのコーヒー屋チェーンは高くつく直営を避けフランチャイズを使っているが, スタバは自分で店舗を持っている. フランチャイズにすると客の回転率をあげようと店主が努力してしまい, 売りである雰囲気を損ねてしまう. だから売り物である雰囲気を守るには直営せざるをえない. 一つでは悪手だが文脈の中で威力を持つ手札は真似がしにくいため, 競争力になる. 本書はそう説明している.

ストーリーとしての XP

この話を読んで私が真先に連想したのは eXtreme Programming だった. アジャイルの始祖たる XP は無茶なプラクティスでもよく知られている. たとえば "オンサイト顧客" なんてのはいかにも無理がある. けれど先のストーリー主義史観では, この無理難題こそが XP の核だと考えることができる. もともと XP のプラクティス同士は強く相関しており (図, 引用元), XP 教徒は "だから全部やれ" と説く. 相互関係の力を謳う先のストーリー論と瓜二つだ.

一方で XP の実現が難しい理由もストーリー史観で説明できる気がする. おそらく XP が生まれたプロジェクトは, より大きなストーリーがプロジェクトを取り巻いていた. 例えばオンサイト顧客に抵抗がないエンドユーザや, 気のいい Smalltalk プログラマ, そもそもスケールする必要のないゴールなどが XP というストーリーを生んだのだろう. 弁の立つアジテータ Kent Beck 自身も ストーリーの一部かもしれない. XP の教科書はソフトウェア開発の棚より ビジネス書の棚が似合うようにすら思えてくる.

ストーリーのないところにプラクティスを持ち込むのは多難だ. アジャイルについて書かれた本は終章で企業をアジャイルに変えようと説くことが多いが, それはとても大変なことに思える. たとえるなら船橋のコーヒー屋が "俺達もスタバ化したいから銀座に店を移すぜ" と意気込むのを 見ているような辛さがった.

レフィングウェルの議論からうけた違和感にも同じ根がある. 文脈がないところにストーリーの断片をあてはめようとする歪み. <スケールするアジャイル> は <煙草の吸えるスタバ> に似ている. それスタバやないタリーズや...と揚げ足をとりたくなる.

しらをきるふてぶてしさ

タリーズが駄目という話じゃない. (神保町ならマクド隣のスタバより IIJ 下のタリーズのほうが好きです.)

たぶんタリーズはスタバの真似から始まったろうけれど (Wikipedia いわく,) そのことに少しは後ろめたさがあると思う. タリーズの社長が公然で "弊社はなるべくスタバと同じでありたい" と言う姿は想像できない. むしろできるものなら差別化したいと考えるのが普通だ.

ソフトウェア開発者も少し意地を張っていい.

アジャイル好きな人が集まると, 自分達がいかにアジャイルかの自慢, あるいはアジャイルでない自分の告白へと, つい話が向かう. 私もそういうものだと思っていたけれど, 最近宗旨替えした. ソフトウェア開発者にとって名詞としてのアジャイルはもうだいたい 常識になっただろうから, その話ばかりしても飽きてしまう. アジャイル発祥のアイデアは全力でぱくりつつ, それは脇に置いて自分達が切り開いたアイデアを語ってほしい. アイデアに名前を, ストーリーに表紙をつけて, そのクールさを説いてほしい.

誰かのようであろうと模倣に終始するするのではなく, 外から目をそらし自分の中に閉じ込もるのでもなく, どこかで書かれたページを切り抜き 自分のストーリーに書き換えてしまうふてぶてしさがチームや製品に個性と強さをもたらす. 最近はそう考えるようになった.

というのは前置きで, 仕事で参加している新参ブラウザのプロジェクトがどんな感じなのか, 連中はコーヒー屋どころかアブサンバーじゃないか説が本題のつもりだったけれど 長くなり過ぎたのでつづく(予定).