知り合いのIT会社のすんげー偉い人の話を聞いたのでmemo
問題になったら消します。
【状況】
・某大企業でのとある大規模プロジェクトをagileでやった。開発人数は50〜80人。
・クリティカルでないシステムだったため、SI側/会社側もagileでやることをOKした。
→クリティカルなシステム（例えば携帯電話会社の料金システムのような、カットオーバー日をずらせないシステム）をagileでやるのは、先が読めないからいかんとのこと。
【問題発生】
/結局SI側もクライアント側もあまりagileを理解してなかった系
・今までウォーターフォール開発の進捗管理になれていた役員（意志決定者）が、プロジェクト開始後しばらくしても収束することのない将来予測に(((( ；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ！→怖いからやめた。
・必要とされるスキルに対して、個人のスキルが足りないケースが多かった。
→今までコーディングにオフショア使ってたため、従業員にコーディングのスキルが育たなかった。ところでagile＋オフショアは無理な組み合わせ？
/agile固有系？
・チーム人数が多いため、コミュニケーションがうまくいかない。
→これはagile固有の問題かな？ 既存のIT系人材のコミュニケーション能力の問題もある。
【どうすれば良かったか？（これは私の想像）】
・（相当無理かもしれないけど）ある程度終わりの見える進捗表で、意志決定者に説明する/ちゃんと納得してもらう/納得してもらった上でさらにフォローする
・最初から大規模PJTでagileするようなことはせずに、小規模PJTで実験したり、経験のある人を引き抜いて/契約して、きちんとagileが実施されるようにする。
→その場合、agile熟練者は従来のPMO的立場になるのか？それってagile熟練者がやりたい仕事なのだろうか･･･？
【ウォーターフォールだったらどうなってたか？】
いわゆるウォーターフォール用のフレームワークを使ってきっちりPJT管理していたら・・・
・当初にあり得ない予算が計算されて交渉が長引く＆コスト増加
・それなりに高い確率でカットオーバー延長＆コスト増加
・で、予定の予算を大きく超えて機能削られてるけど、一応カットオーバー。
・ただ、agileの経験値が蓄積されないので、今後もウォーターフォールにしがみつく。ま、ａｇｉｌｅで失敗してトラウマ作っても、結果的には慣れ親しんだウォーターフォールに戻るんだろうけどｗ
・ウォーターフォールを支えるフレームワークは経験の蓄積と共に肥大化する。肥大化したことが逆に頼もしく思えて、そのフレームワークに依存し続ける。イノベーションのジレンマ的展開。
めっちゃ参考
[システム開発][Agile開発]Agile失敗パターン三部作
[システム開発][Agile開発]痛い目に合わないとわからない
