はじめに
今年の途中まで、アジャイル型のプロジェクトを経験。
昔も、どちらかと言えばアジャイル寄りのケースが多かった。
今は、Web系でウォーターフォール寄りの開発をしている。
書きたい事は、すでにWikipediaにだいぶ書かれていた。
アジャイルソフトウェア開発-Wikipedia
なので、個人的な経験を中心に書きます。
機密保持の関係で、抽象的な表現が多くなりますが、お察しください。
「基本みんなコードを書く」文化からのカルチャーギャップは感じた
今主に担当している案件が、エンド（顧客）へのヒアリングや折衝、それを要件としてまとめて外国籍のブリッジSEに伝えるような仕事がメインなので、そこから先のシステムを設計してコーディングしてー という部分は他の人が担当することになります。
最初はもどかしさを感じた
今までは、コードやチケットさ仕様書といった文化も多かったので、細かい仕様書を用意して、自分は作らない・・・という部分で、自分ならすぐ改修できるはず。というもどかしさを感じた事も多々ありました。
各工程に専念するから、それぞれの担当パートでパワーを発揮できる面もある
もどかしさを感じた反面、開発が始まると進みが早い。
私は、顧客の考えを噛み砕いて案を出し、何を作れば良いかを導き出す事に専念する。
ブリッジSEは、その仕様を海外のプログラマが進めやすいように整理する。
海外のプログラマは、確実に動く物を作ることに専念する。
比較優位や最適化問題などの言葉も思い浮かぶ。
（それぞれの得意分野や、コストを考えたら誰が何をするかの解も出てくる）
このケースでは、積極的にアジャイルを採用する必要はなかった
以下のような事情もあった。
- 一部を除けば、仕様を固めてから開発する事ができた。
- 開発済の部分に与える影響は少ない。
- だから、部品事にドカンドカン作っていく方法を採用できる。
- 作る側に取っては、その方が作業しやすい事も多い。
-
メテオフォール影響の大きい仕様変更の危険が少ない。
口直しに、明らかにアジャイル型のチーム体制が向いているケースを
個人的には、やっぱり「運営中の」ゲームアプリなんじゃないかな？と思ったり。
- ソフトウェアが直接的に人命を危険に晒さない。 - 財布に致命的なダメージを与えるケースはあります。