アジャイル開発が終わった後にアジャイルサムライを読んでみた

少し前ですが、3ヶ月ほどスクラムでのアジャイル開発を仕事で行っていました。
そして終わった後に今更感がとても満ちあふれる中「アジャイルサムライ」を読んでみました。
共感出来る事、ここはもっとこうすれば良かった等、読んで色々思ったのでちょっと感想を書いてみます。

※スクラムに関しては下記の資料が分かりやすくまとまっています。

Scrum in 10 minutes
http://www.slideshare.net/kawaguti/20110118-scrum-10-mins

ざっくりわかるScrum
http://www.slideshare.net/Ryuzee/scrum-14271224

■強烈なスポットライトを浴びている感覚

アジャイルに開発するというのは、これまで経験したことのないほど強烈なスポットライトを浴びてるみたいな感覚

アジャイルサムライでアジャイルな働き方の警告として上記のような表現がありました。

短いイテレーションの中でチームで出来ると言った結果を出し続けなければいけないので、
人によっては想像以上のプレッシャーを感じますし、
1人1人に一定以上の技術力やコミュニケーション力、チームとして動く意識が求められます。

ウォーターフォールであれば長い期間なので多少のリカバリーは効くとは思います。
(だいたいそれはデスマーチにつながる流れですけどね。。)
アジャイルだとそれが通じない、出来なかった場合はプロダクトオーナーに出来ませんでしたと言うしかない。

僕はこの表現を読んだとき、「良く言えばスポットライト、悪く言えばサーチライト」だなと思いました。

たぶんアジャイルに対し人によっては、
自分の力が求められるのでやる気が出るとか、
本当に短い期間で成果出せるのかどうか不安になるとか、
というポジティブな考えを持つ人とネガティブな考えを持つ人で分かれると思います。
この考えに良い悪いはなく、単純にアジャイルに向いているかどうかの違いになります。

アジャイル開発はチームの生産性、協調性、意思疎通がとても重要だと僕自身感じたので、
(これらがないと顧客、しいてはエンドユーザーを納得させれるものが作れなさそうだしチーム内のモチベーションも下がる)
そういう意味でもチームメンバーの人選は非常に重要だと思います。

■同じ仕事場で働くことがアジャイルではない

同じ仕事場で働くということは、
仕様などの確認がすぐ出来る、意思疎通がしやすいなど、多くのメリットがあります。
アジャイル開発はこのことが前提としてあります。

が、受託開発や複数のプロジェクトを抱えている等、
どうしても同じ仕事場で働けないということはよくあることです。
ではそういう場合、アジャイル開発は出来ないのかとなりますが、

僕もアジャイルサムライの内容も答えは出来るです。
たしかに同じ仕事場で働いた方が効率性はありますが、それを何かしらの手段で補うことも出来ます。

僕が関わったプロジェクトの場合、受託開発のためクライアントも含め同じ仕事場で働くことは到底無理でしたが、
まずイテレーション開始、終了時には全員が集まってキックオフMTG、振り返りMTGをするようにしていました。
(スクラムでいうスプリントプランニングとスプリントレビュー)
たぶんこれがないと意思疎通ややることの認識のズレが生じてしまったり、
チームとしてのまとまりもだんだん薄れてしまうと思うのでこれはやるべきだと思います。

そして、イテレーション内のコミュニケーションは、電話、メールに加えチャットワークを導入していました。

■クラウド型ビジネスチャットツール｜チャットワーク （ChatWork）
http://www.chatwork.com/ja/

仕様確認やこういうこと出来ますかね？のような簡単な確認をしたいケースが結構あったのですが、
電話だとお互いいる時間にしか出来ないしそもそもお互いがいる時間が不明瞭、
メールだとどうしてもかしこまった内容を書かなくてはいけなくて気軽に出来ない、
と今までのコミュニケーションツールだと気軽さとスピード感がなくてアジャイル向きではあまりなかったです。

チャットワークを導入したことによって、
チャット形式ということもあって気軽に書ける、
ログが残るのとスマートフォンアプリもあるのでいつでも確認、レスが出来る、
とプロジェクト内のコミュニケーションツールとして有効活用が出来ましたし、
受託会社⇄クライアントというコミュニケーションの距離もだいぶ近くなったと感じました。

電話→急ぎの要件などのコミュニケーションツール
メール→電話、チャットワークに当てはまらないコミュニケーションのツール
チャットワーク→仕様確認、相談事などの簡単な内容のコミュニケーションツール

のような使い分けをしたことによってある程度同じ仕事場で働けない事の補いは出来たと思います。

ので同じ仕事場で働けない→アジャイル開発が出来ないという訳ではないと感じています。
(とはいえ同じ仕事場で働いた方が効率性が全然違うのは強調しておきます。)

■アジャイル開発がベストな手法ではない

これはアジャイルサムライにも書いてますし、
僕自身、スクラムを終えた後に一番強く感じた事です。

今、結構ウォーターフォールが叩かれて、アジャイル開発でやろうぜ！みたいな流れになってる気がしてます。

ウォーターフォール=デスマーチみたいな印象になってるっぽいですが、
それはウォーターフォールが悪い訳ではなく、単純にそのプロジェクトに合わなかっただけだと思います。

そして、その状態を打破すべくアジャイルに乗り換えてると思いますが、
別にアジャイルになったからって何かが劇的に改善されるとかは思わない方がよいと思います。

たしかにアジャイルだとイテレーションが短く機能が分割されているためデスマーチになりづらいですが、
それ相応の生産性やコミュニケーションが求められる分、1人1人にかかる負担は大きいと思います。

また、ウォーターフォールは時間が経つごとに右肩上がりに忙しくなってきますが、
アジャイルは常に一定のラインで忙しいという感じです。

既存の手法にはどうしても長所と短所があるため、
あるプロジェクトに必要としているものを全て用意してある手法を
既存手法から見いだすことはほぼ出来ないと思います。

僕の関わっているプロジェクトはスクラムが終わってまたウォーターフォール的な流れに戻りましたが、
スクラムで培ったテスト駆動開発やチャットワークでの気軽なコミュニケーションは生かしたまま開発しています。
その方がコンテンツの品質を保てますし、引き続き気軽なコミュニケーションが出来るためです。

最適な手法を見いだすためには、
プロジェクトに最適な既存手法を見いだすだけではなく、
不足しているものを他の既存手法から補ったり、
もしくは独自で編み出したものを取り入れたり等、
常に手法を改善するために考え続けなくてはいけないと感じました。