スクラム開発が向くプロジェクト、向かないプロジェクト

ども、ひぐちぇです(=ﾟωﾟ)ﾉ

今日は、スクラムに向くプロジェクト、向かないプロジェクトって何だろうってことについて考えてみました。

以前、CSM（認定スクラムマスター）のトレーニングを受けた際、トレーナーの方は、『スクラムに向かないプロジェクト』として、

• 開発対象がコモディティ化された商品
• 開発期間が3ヶ月未満

を挙げられ、逆にこれ以外はスクラムでやることで成果が出るとおっしゃられておりました。

実は、昨日、少し会社の先輩とアジャイルやスクラムについて雑談する機会がありまして、その中でアジャイル開発（スクラム開発）の向き、不向きのプロジェクトについて語り、上記に挙げた事以外でもあるんじゃないか！？っと、改めて考えさせられたのです。

アジャイル（スクラム）開発のメリット・デメリット

アジャイル（スクラム）の他の開発手法と比べた際のメリット・デメリットについて、私のこれまでの知識と経験を思い返しながら、考え直してみました。

こんな感じになると思うのです。

開発手法	メリット	デメリット	注意点
アジャイル （スクラム）	・仕様の変更を受け入れ易い ・素早く開発してすぐにリリースが可能 ・トライ&エラーで実験的な繰り返し開発が可能 ・開発メンバーが働き易い環境になり易い	・チーム内のメンバーの増減/変更に弱い ・チーム数が多くなるとPO 1人の負担が増大してしまう（POは1人が推奨されており、チームの数分のPBI管理を1人で行わなければならないため） ・客、上司、メンバーが正しく手法を理解する必要がある ・高い生産性と高い技術品質を担保したチームを作り上げるまでに時間が掛かる	・他チームとのコミュニケーション ・統一したアーキテクチャ/技術品質の担保 ・やり方に対する指示出しにならないように注意が必要 ・客側の理解と協力関係が必要
ウォーターホールなどの開発手法	・分かりやすい ・開発メンバーは指示に従うだけで良い ・統一したアーキテクチャや技術品質が一定レベルになり易い	・仕様変更に対応しづらい ・想定外の事態に対応しづらい	・手戻りが起きないよう注意が必要 ・開発メンバーの残業や休日出勤が多くなり過ぎないよう注意が必要

スクラムは大規模開発に向かないのではないか？

これ、よく言われることですよね。。
CSMのトレーナーの方は、これについては強く否定しておりました。実際、ロケットを打ち上げる大規模プロジェクトでスクラム開発が使われ成功したという例があるとの事をあげておりました。

しかし、私はこの質問に対しては、ある意味、Yesであると思っています。

スクラムというのは「チームを長い目で見て育てないといけない」こと、「チーム数（または人数）が多すぎるとPOやステークホルダーレビューの負担も大きくなり、現実的に維持が難しくなる」という特徴があります。

つまり、大規模開発でも、長期的かつチーム（各チーム 7±2人程度で）数が多すぎない形でやっていけるプロジェクトにおいてはスクラムが有効であり、逆に短期的で多くのチーム数（大人数）になってしまう場合にはスクラムは辞めておいた方がよいという判断になるのではないでしょうか、、

アジャイル開発の向き不向きは、システムの目的や特性によるのでは？

最近、システムの目的や特性による分類として、『SoE（System of Engagement）：繋がりのためのシステム』と『SoR（System of Records）：記録のためのシステム』に分けることができるみたいなことが言われるのですが、そういった分類によって、アジャイル開発の向き不向きが判断可能なのかを考えてみました。

私は一概に、その切り口での判断は出来ないかなって思っています。

確かに、SoEだと、ユーザーなど人を対象にした繋がるためのシステムとなるわけで、UI的な拘りも後から出てくる可能性もあり、さらに、トライ&エラーでやってみたい場合も出てくるかもしれません。しかし、必ずしもそうだとは限らないと思ってます。
また、SoRだといっても、その内容が決まっていない（決めれない）場合もあるかもしれません、その場合はアジャイル開発の方が良いという選択になるかもしれません。

結局のところ、スクラム開発が向くプロジェクトって何だろう？

私が思うに、スクラム開発が向くプロジェクトというのは、まず前提として、『①長期的にチームを維持できる見込みがある』ということが必須になります。（CSMのトレーナーの方は、この期間を3ヶ月と言っていたわけですが、正直、私は3ヶ月で成果を出せる自信はないですね(´・ω・｀)最低でも1年はチームを維持できる見込みのあるプロジェクトでやりたいですね。。）

さらに、『②チーム数が、PO 1人で管理（PBIの完了条件の定義や、成果物受入れ、ステークホルダーレビュー的な意味で）出来る数である』ということも必須条件となるでしょう。

その前提を踏まえた上で、

③トライ&エラーで試しながらやりたい事があるか
④不確実性（市場の変化や会社の状況や政策など）の影響を受け易いか
⑤今は決めれない事があるか

のいずれかに該当する場合には、スクラム開発でやることで大きな成果が期待できると思っています。

つまり、論理式で書くと、

① & ② &（③ or ④ or ⑤）

といったところです。
今後の経験によって、私のこの考えが変わったり、ブラッシュアップされていくのだと思います。

まぁ、まずはこれを仮設として、今後の経験を積みながら検証していってみたいなっておもいます。

最後に

今私が考えてるのが、大規模開発などの場合とかで、ウォーターホール部隊と、スクラム開発部隊を作って、これまでに書いたことを注意しつつ、それぞれ同時に開発勧めるということは出来ないものだろうか。。さらに、スクラム開発部隊には、そのチームのまま開発後の保守をしてもらう事で、長期的なチームの維持を計るというのもいいかなって思うのです。

こんなことを漠然とですが考えてます。

そのスクラムチームは、不確実性への対応コストとして、メイン開発の見積もりとは別コストで捻出して貰いたいものなのですが、、現実的に難しいかなぁ。。。

まぁ、そういった事、提案する機会が、もしかしたらあるかもしれないので、そのためにもその体制で有効に運用するアイデアを考えて起きたいものですねぇ。。