日本でアジャイルが流行るには。
コメしたらコメ返信いただきました。
コメ欄では長くなりそうなので、こちらにて失礼致します。
id:ledsun さんの返信コメを読んでから（業務中に）真剣に考えてみました。
どうやったら日本でアジャイルが流行るのか。
そもそもどうしたら発注側が「アジャイルで！」と言ってくれる方向になるのか。
三匹目を産んでからは、SIer業界からはちょっと離れてしまったので、
いま現場にいる方とはまた感覚が違うかもしれません…。見当違いだったらすみません。
前半はよくわからない人向けに（自分の考えもまとめつつ）書きました。
よくわかっている人は後半からお読み下さい。
アジャイルってそもそも何なん？（システム開発のことがよくわからない人向け）
システム開発の進め方というか、スタンスのことですね。
対極にあるのが「ウォーターフォール」モデルと言われています。
イメージとしてはビル建設ですね。
用地確保しつつ設計図書きつつ予算と人員を確保したら、（システムでは要件定義段階）
土地を更地にして基礎工事をして（基本～詳細設計段階）
建物建てて（実装段階）
内装とか外装とかエクステリア整えたりとか（単体テスト）
で納品（受け入れテスト：UserAcceptanceTest）
の流れです。
一度設計図と予算に合意が得られたら、まぁ、内装段階で「この階のここ吹き抜けにして～」なんてことは無いんですよ。
が、システム屋さんの世界ではよくある話なんですよね。
UAT段階で要件定義が要望と違ってたとか。（わーいデスマデスマ
んで、それってナンセンスじゃない？ってのがアジャイル開発ですよ。
細かいことは抜きにすると、小さく作って大きく育てる、みたいな感じです。
今日はここのココ変えよう！よし終わった、じゃあ次だ！みたいな。
小さなサイクルをガンガン回してちょっとずつ進めます。
日本で流行らない理由（これもよくわからない人向け）
日本ではむかーしからウォーターフォールモデルでのシステム開発がメインで、
発注側がそっちに慣れてしまっている、というのが一番の問題。
「予算こんなでこんなん作って」→「いいよー」な世界なわけです。
適当にお願いすると、適当にそれっぽいものが出来上がってくる。
備品買うのと同じノリでシステムを作ってもらえるわけですよ（ウォーターフォールモデルならね！）
いくら受注側が「アジャイルのほうが…」と内心思っていても、
発注側は手軽で管理もしやすい（お金渡せばモノが手に入る）方を選んでしまうわけです。
ちなみに、自分たちのシステムを自分たちで作っているような会社では、
とっくの昔にアジャイルになっております。（ウォーターフォールのがめんどいもん）
じゃぁ、どうしたらいいんよ？（本題）
発注側が主体性をもってプロジェクトをコントロールしてくれるなら、
そして、自分たちのシステムをどうしたいか一番わかっているのは自分たちのはずです。
自分たちでコントロールするようしむけ…げふげふ…啓蒙しましょう。
受発注両側のトップで話がつけばいいんですけどねー。
話がつくようならこんなSIer丸投げなんて無いですよねー。
どうやって啓蒙するか。発注側メリットは何か
スピード感
ウォーターフォールでは発注段階～受け入れまで数ヶ月～数年の期間がかかる。
その間に環境は変化するが、システム側はそれを吸収できない。
が、アジャイルだと（たぶん基本的に）単一の課題解決だけに焦点を絞るので、
発注～受け入れまでのタイムラグが少ない。環境の変化に適応していきやすい。
予算管理もスコープ管理も視点を変えてしまおうよ
各課題解決ごとに、規模・時期・予算を小分けにできる。
発注側で優先順位をつけて、これは急ぎで、これは来年まわし、などのコントロールができる。
以下つぶやき開始：
この辺は受発注側でどういう契約になるかにもよるけれど、
例えば官公庁とかだと年度予算で今年度はここからここまでの案件をやりましょう、みたいな話ならできるんじゃないのかな？どうなんだろう？（バウチャー型契約）
官公庁だと大きなシステム全体で入札にかけるわけだけれども、プレゼン・見積もり段階で小分けにわけてしまえないかな？乏しい経験によると、年度毎に予算がでてて、各年度でここまで出来ている、というようなざっく りとしたポイントはあるわけで（無いなら作ろうよおかしいよ無いの）、それを担当者と合意のものさらに細分化するんだよー。できないかなぁ？
内製みたいに人×期間で今期分を決めてみたりとか（人月常駐型契約）
契約規模を小さく細かくする（全体でまとめたりしない！）のがポイントな気がする。
けど、大きなプロジェクトのプロマネは未経験だからなんとも言えない！どうしよう！
：つぶやき終了
途中経過を把握できる
都度都度細かく受け入れを行うから、今自分たちの持ち物がどうなっているのかが把握できる。
UATのようにまとめてガッツリ時間をいただくこともない。
範囲が小さいから確認も全体がわかりやすく・小さくなる。
引き継ぎも多分楽
プロジェクト単位が細かくなれば、引き継ぎも楽な上に資料もたくさん残るわけで。
そもそもプロジェクト途中で担当者変更とかわけのわからないことにはならないよね！
（全体が大きなシステムなら、細かくわかれたプロジェクトを管理するモノは別途必要。でもそういうのは開発側は日常的にやってる。受注側は発注側に提供なり紹介なりすれば良いんじゃないかな）
課題解決＝ビジネスに集中できるよ？
発注側が本当に求めているのはシステムではなく、それによってビジネスの課題が解決できることです。
システムを理解・管理する必要は発注担当者にはあまりないんですよ。
自社のビジネスと業務さえ理解していて、課題を見つけられるひとならいいんですよ。
解決法はSIerに任せればいいじゃない。プロなんだから。
（中にはロクでもないSIerさんもいるけど、小さい課題単位でプロジェクト組むならそこまで誤差ないと思う。むしろ大きなプロジェクトにするからわけがわからなくなる）
発注側は今の課題は何なのか、課題を解決することに注力できるわけです。
（経営者視点もしくは業務担当者視点をシステム担当者が持ってくれると割りと話が早いですよねー）
つれづれ
完全に受託するのではなく、ヒアリング段階から発注担当者を啓蒙できると、
「納品後はノータッチ」なことにはならないんじゃないかなーみたいなー。
なんかここまで書いていて思った。
結局大手SIerがちゃんとコンサルの立場に立ってないんじゃない…？
それに中小SIerが振り回されているんじゃない？
うーん。
発注側SE（やとわれ）→フリーランス→自社内開発な立場ばっかりだったので
受注側SE/PL/PMは横からしか見ていなかったしなぁ。
システムわからん、とにかくつくれってお客さんには、
わりとヒアリング段階でシステム的に重要なところは説明しちゃってたしなぁ。
というかその前段階でラポール積み上げるようにしてたしなぁ。
SIerの多層構造（子うけ孫うけひ孫うけ）はまた話が別だしなぁ。
まとめ。
結局のところ「発注側が主体性を持ってもらえるように啓蒙しよう。」が一番の解決策です。
発注者側のメリットは上記の通り。業務中に思いついたまま書いたから他にもあると思う。
アジャイルの説明に関するポイントは「小さく作って大きく育てる」です。
今の流行りからすると、「最近の加速するビジネス環境の変化についていけるシステム開発手法」です。
発注側のシステム担当に業務担当者や経営者視点が無い（まだそこまで育っていない）のなら、
受注側がコンサルとして内部に切り込んでいくしかない（そして手法を見せて育てる）のかなぁ。
相手が話きいてくれない・理解してくれないなら、ラポール積み上げて育てるしかないよねぇ。
お金にならないわ手間もかかるわだけど、そのほうが結果的に気持ちよく仕事できそうだしな。
ぉぉっと。まとめでもつれづれってしまったのでこの辺で。
全然まとまってなくてすみません。
