アジャイルとScrumは実践にこそ価値がある、と当たり前のことを反省した@DevLOVE

先日、2010/11/18(木)に、DevLOVEの「DEVLOVE AGILE DEVELOPMENT IN ACTION」へ参加してきました。
そのタイトルに違わずアジャイル開発を実践されている、藤原大さん、永瀬美穂さんのお二人のお話を聞けました。

実践している方たちのお話を聞いて、「アジャイルもScrumもやはり実践だな」と反省されられました。

私がアジャイルに触れたのは2年ほどまえで、Scrumというアジャイル開発の手法を学ぶことから始まりました。
Scrumには、ソフトウェア開発の現実に対応するためのシンプルなフレームワークがあることに、私は魅力を感じていました。

アジャイル開発を実践しないままに認定スクラムマスター研修を受けるなど座学により知識を増やすなかで、Scrumの根本、源流となっているアジャイルという概念にだんだんと惹かれてゆきました。
そして、アジャイルへ惹かれていった結果、私のなかには、アジャイルへの称賛よりも、現状への否定的な感情がつくりあげられていきました。

初期にすべてを計画して一括契約を行うことにより、顧客と開発の双方が、スコープ、スケジュール、コストにがんじがらめになっている現実。

顧客とエンジニアががんじがらめになったために、スコープもスケジュールも変えられないまま、非現実的だと思いつつもプロジェクトを前進せざるを得ない現実。

がんじがらめのプロジェクトにおいて、長時間労働を続ける忍耐力と契約を守ろうとする責任感を持った顧客とエンジニアが消費されるという現実。

契約に縛られ、価値のなくなった要件を変えようとしてもできないという顧客の現実。

システムを使用する顧客が近くにいないことで、本当のシステムの価値を知ることのないまま内向きに仕事をせざるを得ないエンジニアの現実。

その結果、使わない機能が生み出されお金を無駄にするスポンサーの現実。

ソフトウェア開発の現実には、おかしな部分がたくさんあるのです。
何よりも現実のおかしな部分は、多くの人々がおかしいと思いながらも、おかしな部分を変えることができず、同じような失敗や苦労を負いつづけていることです。

セミナーやコミュニティの勉強会に参加したり本を読んだり座学に励んだ結果、頭の中で現実のおかしな部分を否定し、冷ややかに見る日々を過ごしていました。

そうして、具体的な行動を起こさずに頭のなかだけで現実を否定し続ける日々を過ごし、ついには自分の情けなさに気付かされました。
「変化を包容し」「あらゆる状況において最善をつくす」こと標榜するアジャイルを志しながら、自分では何一つ事をなしていないという現実。

これこそが、まず最初に改められるべき現実のおかしな部分であると気付かされたのです。

この気づきをもとに、社内勉強会を開催したり、コミュニティのスタッフをしたり、実際のアジャイル開発手法を用いたプロジェクトに参加するのかなで、さらに気づきを得ることになりました。
その気づきとは、私のやりたいことは、
アジャイル開発ではなく、顧客を含めたプロジェクトチームのアジリティをあげること
なのだ、ということです。

では、アジリティとはなにか。
わたしは、英単語を和訳した意味のまま「俊敏さ」と捉えています。

プロジェクトの変化に対応する俊敏さ。

経営の変化に対応する俊敏さ。

外部環境の変化に対応する俊敏さ。

なによりも、俊敏さを維持するために、可能なかぎり不確定な要素をなくし、変化させないように働きまわる俊敏さ。

状況の変化に対応するアジリティをプロジェクトチームが持つことこそが、おかしいと思う現実を少しでもよくするための重要な要素だと思い至ったのです。

アジャイル開発でとりあげられる朝会も、プロダクトバックログも、ペアプログラミングも、CI(継続的統合)も、目的はプロジェクトにとりくむチームのアジリティをあげることなのです。

重要なことは、アジャイル開発のプラクティスを取り入れるだけでは、短納期、低コストのプロジェクトにより、高品質なソフトウェアに直接はつながらない、ということです。
それは、アイジャル開発のプラクティスをとりれたことにより、プロジェクトチームがアジリティを身につけた結果なのです。

アジャイル開発のプラクティスは、短納期、低コストのプロジェクトにより、高品質なソフトウェアを生み出すアジリティの高いチームを生み出すための知恵、方法に過ぎないのです。

なぜなら、多くのプラクティスを取り入れたとしても、そのプラクティスを実行しつづける技術力や知識がなければ、プロジェクトチームのアジリティを上げることはできないからです。

そして、アジャイル開発をやり通すためには多くの、そして高い水準の技術や知識が必要とされます。
それはアジャイル開発のみならずプロジェクトに関わるエンジニアも顧客ももつべきものです。
しかし、現実はアイジャル開発に取り組めるような多くの、そして高水準の知識や技術を持つエンジニアは多くありません。

アイジャルは、そうした現実をも認め、すこしずつ理想なプロジェクトチームへ向かうための知恵と手法を提示しています。

プロジェクトチームは、チームのメンバーの成長をも視野に入れたアジャイル開発の要素を活かしながらアジリティを高めてゆくことで、最終的に、短納期、低コストのプロジェクトにより、高品質なソフトウェアを生み出すに至るのです。

ここにあるものこそ、本来のプロフェッショナリズムをそなえたエンジニアと顧客によるソフトウェア開発の姿なのだ、と思い至ったのです。

だからこそ、実践者のお二人の話には心が揺さぶられました。
私が頭の中でだけ思い描いていた、現状のおかしい部分を否定し、「すこしでも現場をよくしよう」「ソフトウェア開発の未来をよくしよう」という思いを、アジャイル開発をつうじて実践されているからです。

アジャイル開発を導入した結果として、うまくいったことも、うまくいかなかったこともお二人は話してくれました。

それが現実でしょう。

アジャイル開発を行えばソフトウェア開発の問題がすべて解決できわけではないからです。

アジャイル開発には、現実の過ちを発見するための観察力、観察によって発見された過ちを認める勇気、そして過ちを修正しチームを前進させるための知恵や方法を提供してくれるだけです。

お二人のお話は、現実のおかしな部分をと認めたうえで、アジャイル開発の知恵と方法を利用して、おかしな部分を良くしようと行動した現実なのです。

プロジェクトチームがアジャイル開発が提供する知恵や手法を使い、失敗を失敗と認め、プロジェクトチームが抱える問題を解決する。
少しでも現状を良くして行こうと考える積極的な思考に基づいて、俊敏に変化に富むプロジェクトに対応する。

このようなことを現実におこなったプロジェクトのお話は、私のような実践経験に乏しい人間には何よりも響きました。

座学ばかりで、実践に乏しい自分を恥じる一方で、「なぜ、私がScrumを学びアジャイル開発をやりたい」と考えたのか。

自分が学び始めたときの思いを思い出させてくれた勉強会であると同時に、
Scrumを学び、アジャイルを標榜するのであれば、

「アジャイル開発をできない」という現実に俊敏に対応してみせろ

と私の心に熱を注いでくれた講演でした。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中


%d人のブロガーが「いいね」をつけました。