アジャイル開発は常識だ

アジャイルサムライ著者のインタビューを読んで、心の琴線に触れるフレーズがいくつもあった。
感想をラフなメモ書き。

【元ネタ】
Jonathan Rasmusson さんインタビュー ( 前編 )

Jonathan Rasmusson さんインタビュー ( 後編 )

【1】Jonathan さんが「アジャイルサムライ」を執筆した動機の一つは、アジャイル開発をコーチングや導入する時に使いたいためだったらしい。
というのも、新たな会社にアジャイル開発を導入する時には、7冊のアジャイル本を読んでから説明しなくてはならなかった、と。
ユーザーストーリー、計画、見積りについても10ページの説明で十分だ、と。

「アジャイルサムライ」の良い所は、アジャイル開発の概略を網羅的に知ることができる点にあると思う。
「アジャイルサムライ」はXPやScrumにも触れているけれど、XPやScrumを全て説明しているというのではなく、現場で運用する時の方法やコツ、ノウハウを説明している。
絵もコミカルで読みやすい。

【2】欧米でアジャイル開発が流行しているのは何故？という質問に対し、Jonathan さんは「常識」だから、と言う。

ウォーターフォールやステージゲート型の開発プロセスが何故ソフトウェア開発で過去40年も使われてきたのか？
何故、フィードバックも変更も反復もないまま、ソフトウェア開発が続けられてきたのか？
むしろ、フィードバックを生かし、変更して、反復してより良い物を作る方が常識だろう、と。

「常識」と主張する彼の言葉にはとても意味深いものが含まれている。
我々の日常生活でも、営業でも、作業でも、最初は失敗したとしても、フィードバックを受けて修正して、方向を変えていく。
でも、何故か、ソフトウェア開発では、変更可能性をリスクと認識し、いかに変化させないように持っていくべきか、と言う方向で進んできた。

インタビューでは暗黙的な共有だけれども、過去のメインフレーム上の開発では、コンピュータリソースが貴重で、何度も実験して試行錯誤していく手法が許されなかったために、事前の計画を常識以上に重視する手法が主流になったのだろうと思う。

でも、今は時代が違う。
過去は年単位で要求を収集し、分析し開発していたけれど、今は月単位、日単位でリリースしなければビジネスのスピードに乗っていけない。

さらに Kent Beck がかつて XP で述べたような変更コストの曲線も触れている。
XPが生み出したTDD、CI、コードの共同所有、リファクタリングが当たり前となり、ソースの変更コストが減り、変更に合わせて開発することが可能になった。
そして、北米では、アジャイル開発を取り入れたいという企業が増えてきた。
1年がドッグイヤーと言われる時代では、特に、ネット企業はそうだろう。
6ヶ月もかけて要求を収集するよりも、6ヶ月以内にリリースする方がビジネス的に最重要になってきたのだ。

【3】日本と北米の違いは、受託開発における請負契約とユーザ企業中心のタイムアンドマテリアルな契約の違いでもある。
Jonathan さんは、IT業界は今まで、どのように期待を管理するかということだけに注力してきたのではないか、いかに素晴らしい製品を作るかということを忘れていたのではないか、と疑問を投げかける。
がんじがらめの契約を決めると、お互いが守備的になり保守的になり、責任のなすりつけ合いになる。

北米では、ユーザ企業が開発チームを持ち、内製化して開発していると聞く。
すると、1年間の予算はこれだけなので、その範囲内で開発して下さい、というスタイルになる。
逆に日本では、ユーザ企業はSIに丸投げし、受託開発における請負契約を結ぶのが普通だ。

この辺りは、アジャイル開発だけでなく、PMBOKでも同様に、日本と北米の違いが歴然とある。
PMBOKでは、発注者がプロジェクトマネージャも兼ねるのが前提なのに、日本ではプロジェクトマネージャが受託側にいるため、PMBOKをカスタマイズしないと日本の開発現場で矛盾が生じる、と。

日本のSIerは"フィックスドプライス"型契約から脱却できるか - ジャスミンソフト日記

ソフトを他人に作らせる日本、自分で作る米国：日経ビジネスオンライン

Twitter / akipii: PMBOKではプロジェクトマネジャが発注者にいることが前提になっている。日本ではIT企業すなわち受注者にPMがいることがほとんどだから、米国の手法を修整して取り入れないとうまくいかない。ソフトを他人に作らせる日本、自分で作る米国 http://business.nikkeibp.co.jp/article/tech/20121010/237890/?P=3&rt=nocnt …

Twitter / akipii: 日本は一括請負契約、欧米はTime&Material契約、つまり時間単価契約。日本の方が赤字プロジェクトになりやすい指摘が面白い。　日本のSIerは"フィックスドプライス"型契約から脱却できるか - ジャスミンソフト日記 http://yoshinorinie.hatenablog.com/entry/2012/11/26/095526 …

つまり、北米では、プロダクトオーナーがユーザ企業にいて、ユーザ企業の内部にいる開発チームと距離感がないのに対し、日本では、プロダクトオーナーがユーザ企業の一人の権限に集中せず、ナントカ委員会のような合議制のために不在で、かつ、開発チームも受託側にいるために、ソフトウェア開発がビジネスと遠く距離が離れているのだ。
そのために、変更に合わせて開発することが難しく、機敏に修正することが難しい。

【4】要求収集から分析、設計までのプロセスで厳格なレビューを多く行うことで高い品質が達成できる手法についても、Jonathan さんは疑問を投げかけている。
「適切なものを作っているということはどうやって分かるのでしょうか。 バグフリーだけど誰も使いたがらないシステムができるかもしれません。」の言葉は辛辣だ。

エンタープライズアーキテクチャ(EA)やSOXについても厳しい意見を述べている。
EAでは、企業としてのITの方針をトップダウンで決めるが、 時代の流れはとても速く、技術もどんどん陳腐化していく。
ビジネスゴールや戦略が目指す方向とEAの方向が同じでない場合、対立が起き、不毛な議論が続く。
そこで必要なのは、プロジェクトの最初で絶対に行うべきことの一つであるアジャイルサムライのインセプションデッキを使うべきだ、と。
プロジェクトの最初に、関係者を部屋に集めて議論を行い、全員のゴールを合わせるべきだ、と。

また「SOX は、時間のムダ、ひどいものだ。 ひどい。」という意見も辛辣だ。
SOXは、ソフトウェア開発を促進するために使われるのではなく、無駄な管理作業が増えて、開発スピードやビジネスのスピードを落とすことに注力されるために使われているからだろう。
(もちろん、SOXやコンプライアンスの重要性は分かっているし、Jonathan さんも文章を読めば理解されている)

【5】12年前に生まれたアジャイル開発は熱狂を失ったのか、と言う質問に対し、Jonathan さんは、常識になったから戦うものがなくなった、と言う。
Jonathan さんはアジャイル宣言について教えることはないと言う。
今の若い世代にとって、プロセスよりも人々、ドキュメントよりも動くソフトウェアは常識だから、自然な開発スタイルだから、と。
新世代は贅沢なことにWFを知らない。だから、戦うものはないし、チームで反復型開発するのが自然だから、と。

【6】「アジャイルサムライ」では、Scrumのようなプロダクトオーナーやスクラムマスターという役割は中心的ではなく、プロジェクト管理者、顧客、アジャイルコーチなどのように、従来の役割でアジャイル開発を回すための工夫が説明されている。
Jonathan さんによれば、その理由は、彼がXPからアジャイル開発を知ったので、XPが提唱した技術的側面を重視したかったことと、スクラムの導入の難しさとしてスクラムの役割をいきなり導入できない現場もあるから、従来の開発コミュニティの人達でも安心してアジャイル開発ができるように役割を提示したかったから、と。
その意味では、「アジャイルサムライ」はとても実践的な本だと思う。

【7】Jonathanさんのモットーである「共有し(Share)、学び(Learn)、成長する(Grow)」はとても意味深い。
「自分が学んだことを他の人たちに教え、共有する」ために、BlogにiPhoneアプリ開発をたくさん書いたりする。

ソフトウェア業界の特徴の一つは、一度高い能力が得られてもそれを完全にやり直さねばならない点がある。
Cobolで一流であったとしても、JavaやC#のプログラミングは一流とは限らない。むしろ、オブジェクト指向の概念を知らない可能性も高く、オブジェクト指向の初心者かもしれない。
Javaを知っていても、RubyやiPhoneやAndroidアプリは初心者かもしれない。
様々な言語を学び、共通部分があったとしても、技術の変化によって常に立場は悪くなり、完全に分かったという状態にはならない。
また一から勉強して成長しなければならない。

この内容は、馬場史郎さんの本「SEを極める50の鉄則」を思い出す。
SEは常に、新しいプログラミング技術、アーキテクチャ設計、プロジェクト管理や顧客との交渉のようなビジネスマンとして鍛えられた経験が必要になるのに、そういう経験がなかったために、5年おきに落第する人が多い、と。
常に新しい技術、マネジメント、設計などのトレンドを取り入れて、ゼロベースで勉強しなくてはならない。

【8】「アジャイルサムライ」の執筆では、最初の原稿は捨てて、2年かけて最初から書いたらしい。
インセプションデッキの部分が100ページもあったけれど、40ページに削り、それが成功した、と。
「短いものを書くのに多くの時間を要します」という言葉は、僕も実感する。
最初に言いたいことをたくさん書き、そこから削って、端的な文章になって初めて完結する。
本を書くのは創造的な仕事なのだ、という言葉は僕も賛成する。

このインタビューは「アジャイルサムライ」の背景だけでなく、Jonathan さんの考え方も書かれていてとても参考になった。