旧来型SIerである弊社でアジャイル（スクラム）が上手く行っていない
弊社は未だにメインフレームの相手をしてCOBOLを書いているような、低技術力・プロマネ力偏重のSIer。20代の若手SE(笑)である僕自身もウォーターフ...
旧来型SIerの会社ではアジャイルは難しいですね。
簡単に理由と、それでもアジャイルを成り立たせるための方法を書いていきます
■仕事の受注方法の問題
大体発注するほうの会社さん（以後顧客と表記します）は発注時に稟議をかけるじゃないですか。そういった手順で契約が決まるような顧客の仕事なんかアジャイルでできるわけないです。
納品物が決定していないと稟議なんか通りません。で、稟議抜きで契約しない会社なんてほとんどないです。
まああるとすれば、完成してもお金払ってくれるかどうかわからないようないい加減な会社くらいです。
■アジャイル向きかどうか
開発メンバーが悪ければ、悪いなりに作業進めればよいのでアジャイル向きだと思います。
メンバーの能力が高かったらウォーターフォールの方が良くないです？
作るもの決めて、予定通り作ればいいんだから。
基本能力やマンパワーが足りないことが多くて、その条件でも最大の結果を出そうというのがアジャイルじゃないのでしょうか？
この記事を書いた方なんですがそのあたりがわかっていないんだから、文中で出てくる切れ者のPMとかいう情報自体が怪しいです。
■アジャイル開発をやりたいなら
自分が協力会社と仕事するときにはアジャイルでやります。
最初の稟議の時点で納品物、納期なんかが決められちゃうのですが普通はこのあたりは予定通り進まないことが多いです。
じゃあどうすればいいのか。目標である「A」という成果物があってを作ろうとしていて「A」に足りない「Aダッシュ」を作っちゃうと自分の会社から怒られます。
自分の会社からするとなんで想定通りのものじゃないんだったって言われます。
自分の指示が悪いのなら自分が怒られればいいし、作業内容が悪いのなら相手の会社を詰める形になるかと思います。
でも大概はどっちも悪くないことが多いですよ。想定外のことが起きているだけ。
適当な作業見込みで始めるだけ始めさせて、想定外のことが起こったら現場に責任取らせるのなんてくそだけどね。
昔の低レベルの開発ならそういったものを徹夜とかでどうにかするのでしょうが、いまどきそんな対応でどうにかなる仕事はないですよ。
■じゃあどうすればいいのか？
だからって喧嘩しててもしょうがないのでそういう時の対処方法。
「A」から「Aダッシュ」にするからいけない
「A」から「B」にしちゃう。
納品時にいきなり「Ｂになりました！」だと怒られるので、このままいくとAに達しないなと思ったら早めにBへの方向転換をする。
会社側にはＢに変更するための説明をする。
その際にAよりも良いものになる、作業工数は落ちていない、ということをうまく説明する。
これができていれば大概は問題なく収まります。
覚書の再提出とか必要になることもありますけどね。
最初にAを作ろうとしている段階で、工数が足りなくなったら移行できるプランＢやＣを持っておくのが重要。
最初から最高のA案を作ることは難しいですが、ある程度制作が進んだ段階でより工数が少なくてよい仕様になるプランBを構築するのはそんなに難しくないです。
後は信頼ですかね。
仕様を変えます、って言って結果うまくいったことが多ければ通ります。
変更したあげくに失敗すると目も当てられないので、そこは注意が必要です。