■旧来型SIerである弊社でアジャイル（スクラム）が上手く行っていない

弊社は未だにメインフレームの相手をしてCOBOLを書いているような、低技術力・プロマネ力偏重のSIer。

20代の若手SE(笑)である僕自身もウォーターフォールの経験しかなく、社内の99%も同じ。

最近興味があって近くにいる人とアジャイル開発の勉強をしていており、ジェフ・サザーランドの著書ほか何冊か本を読んだ、というだけのただのエンジニアワナビー。

最近近所で絵に描いたようなアジャイル失敗例があって、ちょっと誰かに聞いてほしくて書いてる。

この度、既存システムを刷新するプロジェクト（たぶん１億以上５億未満）をアジャイル開発でやることになり、先月くらいに最初のスプリントがスタートした。

アジャイル導入にはおそらく特に動機がなく、お客さんの偉い人たちが

・最近アジャイル？流行ってるんでしょ

・無限に要件変更できるんでしょ

・アジャイルにすると早く安くできるんでしょ

などと仰せになった結果だと聞いている。

そのスプリントが当初から大コケ。

最初のスプリントでスピードが出ないのはよくあることなのだろう。古事記にもそう書いてあった。

が、内容を聞いているとどうもそうは思えない。もっと根本的なところだ。

スクラムなのに、なぜか最初からウォーターフォールみたいなスケジュールがある

なので、開始直後から「遅れが…」とか言ってる

要件の範囲もなぜか最初から必達が切られている。ウォーターフォールかな。

なので進捗報告もウォーターフォールみたいに行っている

当然「ご報告資料」づくりもセット。

開発メンバーが開発できないらしい

どうも、開発メンバーがユーザストーリーを理解していないらしい。

それがなぜかというと、プロダクトオーナーとのコミュニケーションがとれていないらしい。

さらにそれがなぜかというと、プロダクトオーナーのユーザー部門の人がよそと兼業してて全然時間がとれない、そもそも別の場所にいて会うことすら難しいらしい。

ユーザーがしっかり参加するのがスクラムじゃないのか。

また、そもそも開発でかき集めたメンバーのスキルが、スクラムの要求するそれに届いていないという話もあるらしい。スクラムの要求する開発チームのスキルはおそらく自力で要件を解釈を解釈しコードまで落とせるレベルだが、弊社が旧来の手法で人売りから買ってきた「エンジニア」たちにそれを求めるのは酷だろう。

現場のプラクティスだけは導入している。デイリースクラム、スプリントレトロスペクティブ…比較的スタンダードに全部形から入ったらしい。表面だけとってきてスクラムと称しているが、サザーランド氏がつぶしたかった予測不可能を予測しようとする傲慢さとか、ユーザ不在のシステム開発とか、コミュニケーションと協調のない開発とか、マイクロマネジメントとか、一番重要なエッセンスを尽く省いているようにみえる。

お魚買ってきて、全部は食べられないね～って言いながら表面の皮とウロコだけ食べてる感じ。これで以て「アジャイルってお魚は、ウロコと皮しかなくて、おいしくないし食べづらい」って結論づけるんでしょ僕知ってるよ。

この件について、まあ弊社じゃこうなるよな。だったらここまでなんだけど、こんな駄文を書こうと思ったのは今回の顛末が不思議だったから。

本件のプロジェクトを率いているのは弊社でも指折りの有能PM。何度か一緒に仕事をしたり、指導を受けたりしたこともあるが非常に頭の切れる人で、社内での発言力も非常に強い。彼は「スクラムで」との命令を受けた後、当然スクラムについて勉強しただろうし、当然「何もしなかったらこうなる」とわかっていたはずだ。その政治力を使ってなんとかしようとしたはずだ。彼の周りについた弊社メンバーも、それぞれがスクラムの勉強をしていたし、みんなPMには劣るかもしれないものの頭の切れる人たちだ。

そんな知力と政治力の両方を備えた歴戦のPMが、こんなにもあっさりと、なんの策も打てずにウォーターフォールの悪いところをしっかりと引き継いだアジャイル(笑)をやって失敗するのか。これじゃあ、弊社じゃあずーーーーっと無理じゃないか。

Permalink | 記事への反応(13) | 22:18

ツイートシェア