なぜスクラムがつらいのか？開発現場が疲弊するのか？スクラムに対する違和感と共に原因を考えてみた

システム開発,仕事環境

今ではどこの開発現場に行っても、やれスクラムスクラムと、まるでスクラムでもやってれば全ての問題が解決するかのように取り入れられてます

そして不自然なほどにスクラム教の信者が多い気がするのですが個人的には違和感でしかないです

そんな経験からこの違和感の原因はなんなのか、なぜスクラムで現場が疲弊するのかを考えてみました

ちなみに以下の画像は「スクラム　つらい」でググった時に出てきた類似検索ワードです

スクラムに対する期待値の違い

スクラムって大体において、上の人（経営層、社長）や意識高い系の人から指示されて始めてることが多いと思うんですが、

そもそも各々のスクラムに対する期待値が違うんです

経営層や意識高い系は、

「スクラムっていうやつをやれば、開発効率が上がって生産性が高まるんだろ？」

って思ってます

でもスクラムって少なくとも開発効率を高めることを目的とした手法じゃないわけですよ

この時点でそもそも経営層と現場で食い違ってくるわけです

ご存知の通り、スクラムは対話を重視するのでMTGが多めです

すでに今のスクラムじゃないやり方かつ、最小のMTGで効率的に回ってるPJだとしたら、スクラムを導入したら高い確率で開発効率落ちますよ

だって今まで必要なかったMTGがやたらと増えるわけですから

そもそもほとんどの日本の開発現場にはスクラムが合わない

ソフトウェア開発で重要な要素って機能とか品質とか納期とか色々あると思います

が、日本の開発現場において一番重要なのはどれでしょうか？

はっきりと断言しますが、これは

納期です（ですよね？）

実際にソフトウェア業界で開発されてる方には納得してもらえるんじゃないでしょうか

いついつの期日までに機能を実装してリリース or 納品できる状態にまで持っていくことが最も重要なわけですよ

受託系のSIerはもちろんのことですが、なぜか自社サービスを持ってるような企業でさえも納期を最優先にすることが多い気がします

けどスクラムってコミュニケーションを重視するので、一般的には納期が伸びますよ

おそらくスクラムを考えた欧米人たちにとって、一番重要なものは納期じゃないんだと思います

アメリカのゲーム会社って当たり前のように発売日を延期しますよね？

つまり、彼らにとっては品質 > 納期なんですよ

けど日本はほとんど品質 < 納期となります

この時点でもう日本人とは思いっきり価値観（大切にしてるもの）が違うわけですよ

なのにその価値観は受け入れずに、開発手法だけ現場に押し付けてるわけですからうまくいくはずがありません

今までと同じかそれ以上の開発速度が上からは求められるのに、開発現場はスクラムによってMTGが増えて実装時間が減ります

その結果、内職してて誰も聞いてないMTGや、表面的な改善点しか出ないレトロスペクティブなどが出来上がるわけです

現場は大変ですよ

実装のための時間がスクラムによって大幅に減らされてるのに、期日は今まで通り守らなきゃいけないわけですから

っていうかあなたのPJってウォーターフォールですよね？

スクラムってアジャイル開発のための手法な訳ですが、そもそもあなたのPJってアジャイルで開発してますか？

僕の今までの経験上、日本のソフトウェア開発現場ってほとんどがウォーターフォールでした

決してウォーターフォールを否定してるわけじゃありません

僕が言いたいのは、

「事実上ウォーターフォールなのに、開発手法だけスクラムを取り入れるのって逆に効率悪いですよ」

って話がしたいだけです

ガンプラを作る例で比較してみる

例えば、ガンダムのプラモを作るPJがあったとします（そんなPJないけどｗ）

プラモを完成させるには、

ニッパーを使ってランナーからパーツを切り出す
パーツを組み立てる
塗装する

の３つの工程があるとします

ウォーターフォールで作る場合

全てのパーツについて１の切り出し作業をやってから２の組み立てを行い、最後に３の塗装するという一連のやり方になります

決して２の工程に入ってから1に戻るなどということは発生しません

スクラムで作る場合

まず１で右腕の部分だけを切り出して、２の組み立てを行い、３の塗装をする

次のスプリントで左腕について1->2->3を繰り返す

次のスプリントで胴体について1->2->3と繰り返す、、、

（以下全てのパーツが完成するまでループ）

最後にそれぞれ完成したパーツ同士を組み合わせる

となるかと思います

ちなみに事実上ウォーターフォールな場合、デプロイ（リリース）のタイミングはどちらも全てが完成した後です

どっちの方が効率が良いと思いますか？

これが仮に本当にアジャイルで開発してて、各スプリントが終わるタイミングでリリース/納品まで込みってことなら、スクラムでも良いのですよ

問題は最終的なリリース/納品は結局全てが完成した後ってことです

バーンダウンチャートと言う名のリーサルウエポン

スクラムによって最も多くの戦死者を出す要因、それがバーンダウンチャートだと思ってます

リーサルウエポン、またの名を開発者大量殺傷兵器とも言います

まず、そもそもがタスクに割り振るストーリーポイントって、「大体これくらいだろう」っていう少々乱暴に言えばインチキな値なわけですよ

そのインチキな値をベースに完成日の予測を立てるのがバーンダウンチャートです

不確実性コーンをご存知の方ならわかると思いますが、スプリントプランニングの時点で行う見積もりってかなり精度が低いんですよ

しかも、この時のMTGの参加者はだいたい開発エンジニアだけなので、みんなで、

「まあ、あくまで今決めるのは大体の目安値だし、このくらいで大丈夫だよね？ね？」

って言う合意のもとで決めるので、エンジニア間では問題が起きないです

ところが、スプリントが回り出してバーンダウンチャートが見えるようになると、PMとかがビジネスサイドにこのグラフを見せるわけです

本来であれば、この時に「このバーンダウンチャートは大雑把な見積もりのストーリーポイントを元にしてるので、大体の目安として考えてください」

的な補足が絶対に必要なわけですよ

スクラムガイドにもそう書いてありますしね

にもかかわらず、そんな超重要な補足説明をせずにチャートだけ見せるとこれを見たビジネスサイドや経営者は、

「よし、このままいけばこの日（○月○日）にリリースできるんだな！」

と思い込むわけで、エンジニアにとってはここから地獄が始まるわけですよ

いろいろな理由がありますが大体のケースにおいて、バーンダウンチャートの予定日より実際の日数は増えます

ストーリーポイントを決めるときは「大体でオッケーだよね〜♩」とばかりに和気あいあいと楽しくエンジニアがプランニングポーカーで決めてたのに、それによって知らない間にリリース日がFixされて休日出勤徹夜イエッサーな日々が待ってるわけです

スクラムガイドにも説明がありますが、バーンダウンチャートの予想なんて、初期のエンジニアの見積もりの「うーん、大体3ヶ月くらいっすかね…」って言うような説明とたいして変わらないくらいの精度でしかないわけです

スクラムを忠実に実行してない

んで、だいたいが、

「スクラムをやって開発効率を改善しよう！」

とか言ってる奴に限ってスクラムを忠実に守ってないんですよ

スクラムガイドの価値基準という項目にはこう書かれています

スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。
確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

この中でとりわけ重要なのが集中です

スクラムはなるべくタスクの多重度を落として、可能な限りそのスプリントのタスクに集中する前提が必要です

にも関わらずですよ

「スクラムやろうぜっ」

っていうくせにここは無視してますよね？

実際問題、PJの開発中にはいろんな他のタスクが割り込んできます

お客さんからの問い合わせ、過去に実装した機能に関する技術的な質問、突発的な調査タスク、評価期間、~~くだらない~~研修、などなど

あなたのチームのスクラムマスターはこんな割り込みが発生した時に、あなたを割り込みから守ってくれますか？

「いや、彼は今このスプリントに集中してるので、そのタスクはやらせません！」

と勇者のように勇ましく言い切ってくれますか？

体を張って会社と戦ってくれますか？

そんなことはしてくれませんよね？