最近スクラム開発をやってみてるのでその感想を。スクラム開発って何？って方は以下の図をごらんください。
via スクラムの概要を1分で理解できるイラスト【2018版】 | Ryuzee.com
…すこし本題とは逸れるのですが、この絵は実際に社内のスクラム推進派の人に見せられた絵です。なんですが、、、あのさ、、、これでなんなのかわかんなくね？
この絵に限らず、スクラム開発 - Google画像検索で出てくる画像はほとんど、スクラムの構成要素をただ書いていて、結局何が良くなるのか、つまり効果がわからないのです。この時点ですでに割と不信感ありますよね。良さをわかってもらおうという気があんまりみえない。わかってる人がわかってる人のために書く図。
閑話休題。
ま、単純に言ってしまうと、スクラムはバックログという要望集を、スプリントと呼ばれる固定時間（1〜4週間程度で選択）内で、リリース可能なレベルの成果物として実現することで、素早い価値提供を可能にするための方法論です。
エピックの実現を確認できる仕組みがない
一番違和感があるのがここ。エピックはスクラム用語でいう「おおきな要望」
スクラムの最大の特徴はスプリントが固定時間であること。開発単位が常に固定されてることで、固定時間中にどれくらいのストーリーポイント（工数規模とか要望規模を表すスクラム用語）を実現できたか（＝ベロシティ≒チームの開発力）も測れるし定期的なリリースも担保できる。バーンダウンチャート他、状況の見える化のためのツールもたくさんある。そこまでは良い。
じゃあ大きな要望で、スプリントに入り切らなかったらどうするのか？要望を細かく分解して複数スプリントに分けます。スプリントが最大の特徴で、スプリントが絶対です。
〇〇を実現したいというおおきな要望（スクラム用語で言うエピック）に対して、スプリント1ではデータモデルとAPIを、2では管理系UIを、3でユーザー用UIをといった具合に。それぞれのスプリントは効率的に遂行されるし、改善点を良くしていくような仕組みも備わってるし、スプリント単位でデモ会や受け入れ条件の確認といったプロセスがあるので間違いも起こりにくい、というロジック。
でも、おおきな要望（エピック）が実現できたかどうかはどうやって判断する？
ほとんどの商業ソフトウェアには、実現したいおおきな要望があるはず。たとえば、大きな機能改修を入れて、より広い顧客にアプローチできるようにするとか、KPIを達成させて利益確保できるようにするとか。ま、商売なんで基本は金ですよね。
ビジネスサイドが求めるのはエピックの確実な実現であって、開発チームの効率運用は副次的要素に過ぎない。でも、スクラムにはそのエピック実現確認の仕組みがない。一義的には、プロダクトオーナーが各スプリントレビューにおいて受け入れ条件を満たしているかを確認する、という事になってるが、全体のことを考えながらそんな事できる人は少ない。APIの実装内容をPostmanでデモしてもらって、それがエピックに対して適切かどうかどうやって判断できる？
素晴らしい方法論で過去最高効率で作られたコンポーネントであっても、エピックが実現できなければ意味がない。
ほとんどのソフトウェアにとって最も大事なのはエピックの実現だ。しかし、スクラム開発は開発方法論のためにそれをスプリントという単位に砕いて見えにくくすることを是としている。とても違和感がある。
アジャイルの利点をつぶしている
アジャイル開発で解決できる一番の課題はなんだろう。
「ひとは、解決手段が提示されたあとでないとその解決手段の問題点を認識できない」ではないだろうか。スティーブジョブズ風に言うと「多くの場合、人は形にして見せてもらうまで、自分は何が欲しいのかわからないものだ」か。
だから「あんなに要件定義したのに出来上がったあとに要望が山程くる」という事態が頻発する。
アジャイルはこれに対応するための考え方で、だからアジャイルフレームワークの一つであるXPなどは顧客自身をチームに加えるべきと提唱している。スパイラルアップやプロトタイピングも有効な対策だ。ともかく「もうできちゃったよ、文句あるんならもっと早く言ってよ」を何とかするためにアジャイルはある。
翻ってスクラムはどうだろうか。スクラム開発者は、スプリント中は顧客やステークホルダーの干渉を受けない。だから、「始まる前」にバックログをよく整備しておく必要があるし、チーム皆が目指すところを正しく理解していなければならない。スプリントの成果物はリリース可能な状態にしなければならないので、やり直しは効きにくい。（もちろんプロダクトオーナーがそのへんハンドリングすべきなのだが、毎回それやってると進まなくなってしまう）
スプリントでQAまでしっかり作り込むのもスクラムの特徴なので、まず仮で作って、正しいかどうか確認してもらう。だめならすぐ直す。そういうことができるように工夫する、というアジャイルの理念をつぶしている。
対話によって整備されたバックログは間違えることなどありえない、ということなのだろうか。
スプリントの遂行のみに注力しているように見える
スクラムのプラクティスはほとんどスプリントの中のものだ。スプリントを高効率で実現し、自己改善していくことに重きが置かれている。
スプリント外の要素もあるにはあるのだが、たいていの場合あいまいに書かれている。
「プロダクトオーナーは常にバックログを精査し、優先度や粒度を最新の状態にしなければならない」とか。いやいや大仕事すぎるだろそれ。プロダクトオーナーやスクラムマスターの仕事はかなり「対話」という言葉で適当にまとめられてる感もある。なにかあれば対話、対話で具体性がない。一方、スプリント内の作業は会議時間まできっちり決められてたりする。
良くいえば開発者の開発力を100%引き出す仕組みに見えるが、悪く言えばただコードを書いて喜びたい開発者が都合よくでっち上げた方法論のようにも見えてくる。
まとめ
問題点があるなら改良すればいいじゃないか、という意見もあるだろう。わたしが勉強不足で、改善するフレームもすでにあるのかもしれない。
でも、ここに上げた2つ「ソフトウェア開発の最重要指標であるエピックの実現をさしおいて開発効率化の仕組みを優先している」「アジャイル開発の最重要目的である要望元への確認プロセスを欠いている」ことはスクラム最重要特徴であるスプリントに起因する問題であり、致命的ではないだろうか。
スクラムが適用可能な領域はたくさんある。たとえばOSSなど、純粋に開発者力＝プロダクト力となるプロダクトにはいいだろう。FacebookやNetflixのように大規模で安定しており、山のようなバックログがあって、直せば直すほどよい結果になると皆が共有認識があるプロダクト（10000を10100にするような開発）ではよいだろう。開発チーム内のタスクマネジメントツールとしてつかうのも非常に良いと思う。
しかし、ソフトウェア開発方法論として全面的に採用するのは間違っているとおもう。繰り返しになるが、理由は2つで、「ソフトウェア開発の最重要指標であるエピックの実現をさしおいて開発効率化の仕組みを優先している」「アジャイル開発の最重要目的である要望元への確認プロセスを欠いている」から。
アジャイル開発とは（後編）スクラムとXPの調和 : 富士通ソフトウェアテクノロジーズによくまとまっていたが、スクラムはその本来の特徴を生かして機能の効率開発に注力し、要求の確認や分解はプロトタイピングなどを重視するその他の方法論と協調していくのが良いのではないかと思う。
ウォーターフォールを置き換えてスクラムを始める、というよくあるやり方には賛成できないし、スクラム開発方法論はそこまでうまく出来上がっていない。
