スクラム開発の中途半端な導入で無駄にアウトプットが低下したお前たちに告ぐ

前振り

想定している客層

・Webサービスの内製開発
・スクラム開発を導入済み
・スクラム導入前は締切駆動開発だった
という条件で「生産性が上がっているように感じられない」という会社の話をします。
今日のテーマは「スクラム開発」と「むしろ下がった生産性」です。

スクラムの導入について

スクラム導入前は締切駆動開発という「会社の偉い人がやることと締切を指定してプロジェクトとして開発チームに渡す」という開発スタイルだった会社が、スクラム開発を後から導入したケースを前提としています。

まずスクラム開発の前提として

スクラム開発は前提としてスクラムガイドに則ったフルセットで実行した場合、週４０時間のうち１０時間を各種スクラムイベントで消費します。
週の１０時間がミーティングで潰れるわけです。

この「週に１０時間はミーティングで潰れる」という点は「開発チームが自分で計画を作れて、やることも決められて、完了見込も自分で出せる。高度に自律したチーム」であっても
あるいは「開発チームは開発計画も完了見込も提示できない。開発チームの外からやるべきこと締切をプロジェクトの形でインプットする必要がある、自律していないチーム」であっても変わりません。

ソフトウェア開発において開発期間はコストとほぼ同じ意味を持ちます。
完了予定とはチーム外から開発チームに指示されるか、あるいは開発チームが精度の高い完了見込の期日を自分で提示する必要があります。
これは以前に記事にしたことがあります。

余談：ミーティングに使う「週に１０時間 x メンバー数」の工数を惜しんだ場合どうなるか

非常によく見かけるアンチパターンです。
「スクラム開発における最小限のセット」をすべて忠実に実行すると週に１０時間のスクラムイベントに開発チームの前メンバーを参加させる必要があります。
これを削ろうとした場合、スクラムの必須要素を削ることになります。
つまり「スクラム開発ではない中途半端ななにか」に成り果て、スクラムの表面だけを中途半端になぞっているだけで恩恵は得られないという結果になります。

重要なのでここだけは覚えて帰ってください。
スクラム開発のイベントに「縮小均衡による黒字化」という概念はありません。

本題

先ほどの話をもう一度繰り返します

ソフトウェア開発において開発期間はコストとほぼ同じ意味を持ちます。
完了予定とはチーム外から開発チームに指示されるか、あるいは開発チームが精度の高い完了見込の期日を自分で提示する必要があります。

開発チームが低いレベルに留まっている場合、精度の高い完了見込みの期日を自分で提示できず、また次に何を開発すべきか？を自分で決めることができません。
自分で決められない開発チームに対してはチームの外から経営陣が「期日」と「なにをすべきか」をインプットする必要があります。
つまりチーム外から締切と一緒にプロジェクトを指示する開発スタイルになります。

この状態の問題

スクラム開発を導入したにもかかわらず
チームの外で経営陣が「次に何をやるべきか」を判断し、そのやるべきことを分解して開発期間を見積り、見積に基づいて締切を指示する
というチーム外の経営陣がやるべき手間はそのままです。

それでいて中途半端にスクラムを導入したものですから「週１０時間 x 開発メンバーの数」という莫大な工数が無為に消費されています。

開発チームが「次に何をやるべきか」を自分で判断し、そのやるべきことを分解して開発期間を見積り、見積に基づいて完了予定日を自分で提示する
これができるならスクラム開発の「週１０時間 x 開発メンバーの数」という莫大な工数も正当化できるでしょう。

しかしこのケースにおいてはそれができていないのです。
であればスクラム開発とは無駄に時間を消費するだけの効率の悪い開発手法に他なりません。
プロジェクトと締切を与えて開発チームのケツをぶっ叩く締切駆動開発の方が１００倍マシです。
すくなくとも締切駆動開発なら「週１０時間 x 開発メンバーの数」の無駄は発生しません。

どうするべきなのか

スクラム導入後、しばらくは
・チームの外で経営陣が「次に何をやるべきか」を判断し、そのやるべきことを分解して開発期間を見積り、見積に基づいて締切を指示する
・開発チームが「次に何をやるべきか」を自分で判断し、そのやるべきことを分解して開発期間を見積る。（ただし計画も見積も結果は信用できない）
という「１つの作業を２つの方法で判断し、見積り、計画を作る」という冗長な状態は必ず発生します。
スクラム開発の導入期間とはそういうものだからです。

スクラム導入前の締切駆動開発では
・チームの外で経営陣が「次に何をやるべきか」を判断し、そのやるべきことを分解して開発期間を見積り、見積に基づいて締切を指示する
という「１つの作業を１つの方法で判断し、見積り、計画を作る」だけでしたから、スクラム開発を導入すると無駄は増えてしまいます。

スクラム開発が安定しこのような状態になるのがベストな結末です。
・開発チームが「次に何をやるべきか」を自分で判断し、そのやるべきことを分解して開発期間を見積り、見積に基づいて完了見込みを自分で提示する。判断も見積も計画も経営陣にとって信用できる。
「１つの作業を１つの方法で判断し、見積り、計画を作る」だけですから、スクラム導入前同様に、判断/見積/計画の重複は発生しません。

しかしそうはならない

近年、よく見る問題

ところがスクラムを導入した後、導入期間のままで満足して、経営陣と開発チームが別々に判断/見積/計画を重複して行う「１つの作業を２つの方法で判断し、見積り、計画を作る」状態のままになるケースが多々あります。
スクラム開発の正しい成長後の姿を開発チームが認識しておらず、スクラム導入だけで満足してしまった場合に多々見られます。

経営陣から見た問題点

経営陣から見ると以下の課題意識が出てきます。
・チームの外で経営陣が「次に何をやるべきか」を判断し、そのやるべきことを分解して開発期間を見積り、見積に基づいて締切を指示する
という作業は何一つ変わっていない。

手間は減っていないし、開発チームに何かを移譲できた気もしない。
一方で開発チームは多くの工数を「オレオレ見積/計画を作る会議」に費やしており、この会議の意義が分からない。

会議の時間をもっと減らしてコードを書いてほしい。

開発チームから見た問題点

とにかくスクラムイベントは楽しい。自分達で何かを決めて、その決めた内容に沿って行動するのは楽しい。

一方で経営陣から降ってくる「プロジェクトの締切」は納得できない。
締切の日付通りに終わる試しがない。WBSなど高度な見積手法を使っていないので締切の精度は粗い。リスクの見落としも多い。
現場を知らない人が勘と経験と度胸で決めたも同然の締切の意義が分からない。

自分達は十分に力を尽くしているという意識もあるので、過早な日付に設定された締切を無視したいという意識も強い。
自分達は十分に力を尽くしている。全力で力を尽くした結果完了する日付が完了実績日なのだから、締切よりこちらを重視してほしい。

視野の違い

経営陣は完了前に計画の完了予定を出すことを重視します。
そうしないと複数のチームを同期して行動させるための計画が立てられないし、計画が遅れているのかどうかも分からないからです。

未熟な開発チームは完了予定を軽視します。
計画を立てる力が弱いために、完了予定を推定する力も弱いからです。一方で機能しているチームほど「自分達は全力を尽くしている」という意識が強いため当てにならない「押し付けられた締切」や「自分達が出した当てにならない完了予定」よりも「実際に完了した日」の正しさを重視します。

自分達は全力を尽くした。３ヶ月で終わったプロジェクトは、３ヶ月かかるプロジェクトであったに違いない。
トートロジーじみた理屈であり、終わった後に言い出されても経営陣としては呆れる他ありません。
ですがそれだけ「自分達は全力を尽くしている」という意識は強いのです。

どうすればよいのか

先述した通りこうなればOKです

スクラム開発が安定しこのような状態になるのがベストな結末です。
・開発チームが「次に何をやるべきか」を自分で判断し、そのやるべきことを分解して開発期間を見積り、見積に基づいて完了見込みを自分で提示する。判断も見積も計画も経営陣にとって信用できる。
「１つの作業を１つの方法で判断し、見積り、計画を作る」だけですから、スクラム導入前同様に、判断/見積/計画の重複は発生しません。

しかし当然時間もかかります。
感覚的に言って、士気が高く基礎知識を備えたメンバーと、「正しいあるべき姿」を認識しているスクラムマスター。
そしてスクラム開発導入に伴うもろもろの変化を受け入れる準備のできた周囲の環境が必要です。
約半年の導入と移行期間が必要になります。
これは最速で、です。
実際にはもっとかかるケースもあるでしょう。
それほど正しく機能するスクラム開発を導入するは難しいのです。

正しく仕上がったスクラム開発チームをめちゃくちゃにする方法

開発チームが「次に何をやるべきか」を自分で判断し、そのやるべきことを分解して開発期間を見積り、見積に基づいて完了見込みを自分で提示する

これができる状態になってなお、会議室で偉い人が勘と経験と度胸で決めたプロジェクトの締め切りを渡し続けると
開発チームは一度はできていた自律的な判断をしなくなります

自律的な判断はかなり真剣な作業で苦労を伴います。
それにもかかわらず、チームの外から降ってくる判断でオーバーライドされてしまうなら自分達で決めた内容は無駄になります。
わざわざ無駄になる作業のために真剣に苦労したいと思う人間はいません。

真剣に苦労してでも自律的なチームを作りたいという人間は転職しますし、自律的であることを重視しない人間は自分の脳みそをHowを考えることだけに集中する社内受託に安住します。

つまり自律的なチームは、自律的な判断を尊重し信頼しないとすぐ壊れてしまうのです。

What と Howを考える開発チーム

機能する自律的なスクラムチームはWhatとHowを同時にチームが考えます。
Whenはある程度調整可能なパラメータとして扱われます。
プロダクトマネージメントの経験があれば、WhenはWhatとのトレードで調整可能になることは分かると思います。

逆に締切駆動開発や社内受託のような、開発チームはHowを考えることに集中してほしい場合は「週１０時間 x 開発メンバー全員」の工数をイベントで消費してしまうスクラム開発はオーバースペックです。
むしろアウトプットを低下させてしまう弊害すらあります。

なぜそんなにスクラム開発は難しいのか

正しく機能する高度な開発手法はすべてそうです。
ウォーターフォール開発もそうでしょう？

そんなことないよ！かんたんだよ！それでいてメリットたっぷり、生産性爆上げ！と言ってくるのは詐欺師だけです。
リスクを背負ってきっちりコストを払えばメリットや効能が享受できます。

リスクやコストの支払いを拒否すればなんちゃってスクラムという形骸化した対して役に立たないなにかが残るだけです。
（スクラム導入コンサルタントはあなた方の払ったフィーでたっぷり儲けられるかもしれませんが）

中途半端にスクラム導入してしまったあとに残った残骸たち

これもいつか語りたいですが、文章が長くなってしまったので今日はここまでとします。