トレンドのスクラム開発をやってるグループを見た感想です。
スクラム開発って？
前に記事で書いたのですが、要件定義〜システム設計〜詳細設計〜プログラミングってやってくのが「ウォーターフォール開発」という昔からの手法です。
他の手法としてアジャイル開発というのがあり、簡単に言うと「まず動くものを作ってそれをブラッシュアップしていく」みたいな手法があります。
スクラム開発とは、アジャイル開発手法の一つです。
要件や機能を整理して、付箋などでホワイトボードに貼り付けます（この付箋をプロダクトバックログと呼びます）。
それに優先度や難易度をつけて、各人に割り振ります。
それをある決められた期間（スプリント）でやってみて、スプリントが終わったらまたプロダクトバックログの整理をします。
次のスプリントで、またプロダクトバックログを振り分けます。
というのを、開発期間中に繰り返すという手法です。
管理者はスクラムマスターとか、プロダクトオーナーとか言われます。
何がいいのか？
わからないことが多い開発には向いています。
色々曖昧なところが多いシステムには、まず見えているものでモノを作るので、問題点が見えてきやすいです。
ただ…学習コストがかなり高いです。
問題点が結構ある
ただスクラム開発自体の問題点も結構あります。
自社内サービス開発はともかく、お客さん向け開発には問題が多い（スクラム開発手法でも言われてはいますが）…。
手法自体というより、人に起因する問題が多いです。
・ゴールを見失う
ゴールの見えない人は、全体のゴールを見失ったまま進んじゃいます。
「スクラムマスターが管理しろよ！」って話ですが、といっても最終的なゴールって誰も見えないんですよね。そういう手法だから。
システムの完成形が見えないので、プロダクトバックログから想像できない人は「ただ言われた距離を走る」だけです。
そして、案外ゴール見えてない人が多い…。
・危機感が薄い
ゴールが見えないということは、「今どのぐらいの進捗なのか？」というのが見えません。なので緩い雰囲気になりがち。
スプリントをこなすのに夢中になって、スプリントの外のことを意識しにくいから余計です。
・イケてる人に偏る
スクラム開発講習を受けましたが、「各メンバーのレベルがある程度均一（実力が同じ程度で、得意分野が異なる）」というのが大前提になってるとしか思えない。
実際にはそんなわけないです。
必然的にプロダクトバックログの優先度、価値が高いのはデキる人に回されます。そしてデキない人には簡単なものしか行かない…。
・お金がかかる
動くものが出来上がるタイミングは早いのですが、無駄なことが多いです。
ですので、かかったお金に対して見ちゃうと、システムの完成度は低いです。
代わりに「途中で仕様変更聞いてもらえる」というのが利点ですが、それでも高くつくはず…。
・完成するとは限らない
スクラムはシステムの完成（＝お客さんの要件実現）をゴールとしていません。
正確には完成の定義は決めるのですが、最終スプリント内でできないものはできませんって感じになります。
そこらへんのハンドリングがかなり難しいです。
まとめ
個人的にはスクラムより、アジャイルチックなウォーターフォールがベストかなって思います。
暫定で仕様決めて、そこに向かって作っていって、その間に仕様変更を取り込んでいく形ですね。
多分スクラム開発はそういうのを目指していたのだと思いますが、かなりレベルの高い人材を集めないと実現できません。
流行りってだけで取り入れると痛い目見るし、学習コストがめっちゃ高いので、個人的にはオススメしません。
少数精鋭でやってみる形なら良いかもしれません。
