プロジェクトという形態は下火になり、プロダクト開発が台頭している。IPAの調査から

IPAによる海外でのアジャイル開発についての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 （非ウォーターフォール型開発の海外における普及要因編）」を紹介した昨日の記事「海外でなぜアジャイル開発が普及しているのか？ IPAが分析と提言」は、とても多くの読者に読んでいただき、ツイッターやブックマークなどでもコメントが多数寄せられました。

そうした反響の中で、この調査報告の作成に関わったアジャイル開発の第一人者である平鍋健児氏から「資料の付録にある海外でのインタビューが興味深いので注目してほしい」というメールをいただきました。

インタビューの中で「日本国内に限らず、海外でもアジャイル型開発の普及が進みにくい領域がある」という点を指摘部分は、アジャイル開発がどう位置づけられているのかをあらためて浮き彫りにしているように思います。主に、「リーンソフトウェア開発」シリーズの著者として知られるメアリー・ポッペンディーク氏の発言を中心にいくつかを引用します。

海外でもアジャイル型開発の普及が進みにくい領域がある

ポッペンディーク氏の最初の指摘は、同じ社内でもIT部門とビジネス部門に分かれてしまうとアジャイル開発は成功しない、という点です。

銀行、保険、テレコムなど15年以上前に作られた会社では、ソフトウェアに依存したシステムを持っており、技術部分を内部のIT部門に社内アウトソースしている（IT部門はコストセンターなのだ）。

IT部門の「技術の人」と、ラインの「ビジネスの人」はコミュニケーションが薄い。このITはさらに外部にアウトソースされることもある。こうなると、ITは全体ビジネスの一部にならない。

このような、ソフトウェア開発とラインのビジネスのギャップが大きい組織では、アジャイルやリーンは成功しない。また、（うまくいかなくても）ウォーターフォールがプロセスとして一般的には採用される。

「The Concise Executive Guide to Agile」著者のイスラエル・ガット氏は、日本に限らず下請け契約ではアジャイル開発が難しいことを指摘。

ヘルスケア、防衛、政府調達などの産業では下請け契約が多く、これは日本に限ったことではない。入札、契約、下請け契約を従来の契約でおこなっている。防衛では、情報セキュリティが重要なので、スクラム・マスターは機密取扱者としての人物調査が必要になる。政府調達では、監査用のドキュメントづくりなどに追われるし、ヘルスケアでも下請けが多く、既存手法を変えるのはむずかしい。

これらの場面では、発注者がアジャイルの採用に難色を示す。

デンマークのコンサルタント、ベント・ジェンセン氏も、レガシーシステムではアジャイルが難しいと指摘。

新規開発が多いが、銀行などではレガシーシステムの拡張がほとんど。ここでは、アジャイルが難しい。

プロジェクトという形態からプロダクト開発へ

ポッペンディーク氏は、ソフトウェア開発がビジネスのメインである最近の会社では、プロジェクトという形態からプロダクト開発という形態へと進化していることを指摘します。

ここ15年以内に創立した企業は、ソフトウェア開発はビジネスのメインの一部になっている。

これらの企業では「プロジェクト」という形態でなく、むしろプロダクト開発（サービス開発を含む）であり、ソフトウェア開発はラインのビジネスユニットの内側にある（例えば、銀行のIT部門とfacebookを比べてみると良い）。プロダクト開発はプロダクトマネジャ（マーケティングに強い）とテクニカルリード（技術に強い）のペアによって指揮される。

成功している企業は両方（マーケットと技術）のスキルを、プロダクト開発のリーダーのポジションにおく（1人もしくは2人ペア）。これらの会社では、初期製品を作って、それを成長させるため、開発と保守の区別もなくなりつつある（例えばGmailやfacebookは、一週間に2回デプロイされる）。

これらの企業は、Eric Riesの”The Lean Startup”（邦訳:『リーンスタートアップ』日経BP）のようなやり方で製品を成長させる。保守、というふうには考えておらず、継続拡張だと捉えている。これらの企業では、アジャイルはすでにここ数年で広く普及している。

そしてITの開発全体を見たとき、プロジェクトという形態は下火になって、プロダクト開発が台頭していると。

（米国では）「プロジェクト」という形態は企業のIT部門での開発がほとんどであり、しかもこの部分が下火になると同時に、プロダクト開発（サービス開発、スタートアップ）が台頭しているため、ITの開発全体を見た場合に、プロジェクト統計は今日ではミスリーディングである。

平鍋さんは新野宛のメールで、これらをまとめて次のように考察しています。

ビジネスの一部にITが使われている若い企業では、すでにアジャイルは当然だし、「プロジェクト」という形態すらも古くなっている。

逆に、ビジネスから外だしにされて「情報システム部門」というコストセンターを持つような企業（すでにエスタブリッシュされた企業、また、ソフトウェア以外に垂直性の高いコアビジネスをもっている企業たとえば、ヘルスケア、金融など）ではアジャイルがやりにくい。

つまりアジャイルをドライブしているのは情報システム部門というよりもビジネス部門であり、ビジネスそのものがソフトウェア開発を主導する（≒プロダクト開発をする）ときの方法論としてアジャイル開発を率先して使っている、といえそうです。