完了予定も出せないから、いつまで経ってもお前のチームは社内受託なんだよ

はじめに

すまんタイトルは釣りだ。めっちゃ煽った

前提

• SaaS企業の内製開発
• 数十億円調達済みの大きめな会社
• スクラム開発をしている
• 相談者は社内受託感が強まっているのがご不満

ある日相談された

「壁の向こうから締切とプロジェクトが降ってくる」
「プロジェクトが降ってくるのはいいとして、着手前に密室でマネージャーだけで 勘と経験と度胸 ベースで完了目標の日付を決めるのはやめてほしい」
「ほぼ間違いなく、完了目標の日付をオーバーしてしまう。守れない日付をほぼ「締切」として指定しないで欲しい」
「期間とスコープを指定されるのは社内受託感が強い」

という相談を受けました。

前提として

• SaaSの内製開発をしているWeb企業である
• スクラム開発をしている
• 中期的な完了予定の予測を出すことはできない。まだスクラムチームはそのレベルにない

結論から言おう

さて僕からの答えはこれです

正確にいうとマネージャーも開発チームも悪い

経営陣/マネージャー側から見て

経営陣やマネージャーから見て「開発にかかる期間の見込み」とは「コスト」とほぼ同じ意味を持ちます。
たとえば10人で構成される開発チームを抱えている会社は120人月の総コストを使って1年間の開発計画というデッキを作るわけです。

ここで開発チームが担当するプロジェクトについて（スクラム開発をしているにも関わらず）、ある単位の開発について完了見込みをある程度の精度を持って予測できない場合
経営陣とマネージャーがすべきことは開発範囲とアサイン担当と開発期間を指定して一方的に開発チームに渡すことです。

なぜかというとチームが「開発期間を見積もれない」というのは、小売店で値段を売る側が言えないのと同じことです。
「レジでクレカを差し込んで、暗証番号を打ち込んでキャンセルできない状態になって初めて値段がレシートに印字されます」みたいなことなので。
そんな店で買い物をする阿呆はいません。

ではどうするかというとマネージャーたちで(勘と経験と度胸ベースであるにせよ)ある程度の妥当性のあるあたりを決めて「この値段で、これこれこういうものを作れ」と社内発注します。

小学生の夏休みの宿題と同じです。
判断能力のない子供相手に「どれくらいなら宿題できる？何がやりたい？期日は夏休みいっぱいなんだけど」と相談したりしません。
大人だけで会議して「まあこれくらいならこいつらでもできるだろ」という範囲を指定して一方的に範囲と締切を宣言するのです。

問題がないわけではない

• 自分のいない場所で決められた内容について責任感を感じるはずがない（サイダーハウスルール）
• 現場の人間のいないところで決めているため、見積の精度が低い。リスク見通しも甘い。
• 締切駆動になってしまうため、スコープや品質が妥協されがち。ユーザーの価値よりも締切にフォーカスが行きがち。
• 社内発注/社内受託なので、「社内での共創」にならない。むしろゼロサムになりがちだし、お互いを敵視する結果につながりがち

「スクラムでは開発チームが完了見込みを、自分で立てるんだぜ！」

スクラムガイドにもそう書いてありますね。
当然スクラム開発チームのメンバーもそういう意識を持ちがちです。

バーンダウンチャートを見れば現時点の完了見込みはだいたい予想がつきます。
これを見て未熟なスクラム開発者であっても「俺たちは、自分達で完了見込みを立てられる」と思い込むのです。

そのため開発チームは押し付けられた「締切」を チームの外の連中が勝手に決めたハリボテの締切
自分達で予想した完了見込みを 自分達で考えた本物の完了見込み
としてエンドに関する目標を二重管理する例も見られます。
その場合開発チームは、前者を偽物の終了予定、後者を本物の終了予定として扱います。
当然後者が重視され、前者は壁に貼られた落書き程度の扱いになります。

ですがこの完了見込み()は 「他人から見ても信頼できる完了見込み」 ではありません。

その完了見込みはズレていく

そういう開発チームが 本物の完了見込み と主張する日付はスプリントを重ねるごとに後ろにずれていきます。
今回の話でこういう前提が置かれているチームは、この日付を固定させる実力がないのです。

中期的な完了予定の予測を出すことはできない。まだスクラムチームはそのレベルにない

完了予定日は基本的に後方にズレる

完了予定日は何も努力しないと基本的に後方にズルズルと逃げていきます。
近づけば近付いただけ遠くに逃げる夏の「逃げ水」の幻のように。

これをある日付で固定するには実力が必要です。
またスプリントごとに後にズレていく完了予定日を、チーム外の人間が信頼できるエンドの予想として扱うことはできません。

まさかお前、「いつかはできるようになる」と思ってないよな？

今はできないけど、将来はできるようになる。だってスクラム開発はスプリントごとにカイゼンしていくやり方だから
小学生が無根拠に「将来は自分もなにものか大人物になる！」と夢見ているように、スクラム開発チームも特に根拠なくこう考えがちです。
（あるいはスクラム導入序盤の成功体験の余韻があるのかもしれません）

今はできないけど、そのうち実力が上がって完了予定日も固定できるようになるだろう、と
完了予定はそのうち後ろに逃げなくなり、それを信頼できる日付としてチーム外にも公表できるだろう

ところが正しい運用の知識がない場合、100スプリント重ねたところでこの問題は解決しません

いつまで経っても完了予定日は後ろに逃げ続けます。
後ろに逃さないためにはいくつかの達成しないといけない事柄があります。
ゲームのスキルツリーで複数の前提スキルをアンロックしてからでないと、お目当てのスキルを使えるようにならないようなものです。

「逃げる完了予定日」はチーム外から見るとどう見える？

• マネージャーたちが指定した締切を公然と無視し、いつ終わりそうなんだ？と毎週聞くたび違う日付を答える。
• しかもその日付はどんどん後ろに逃げていく。
• その点について将来的に改善できると言うが、何ヶ月経っても改善されない。

そんな開発チームを一人前の開発チームとして扱う人間はいません。

権限移譲なんてできるわけがない

スクラム開発において、開発チームに権限を移譲する
スクラム開発者が大好きな言葉です。

彼らがいうには、締切を押し付けたりするな、自分たちの言う完了予定日を信じろという話なのでしょう。

しかし「毎回違う完了予定日を答える」では計画を全く立てられないも同じです。
計画を立てられない＝締切を自分で決められない人間に、締切に関する権限を移譲する阿呆はいません。
当然のことです。

開発チームから「完了予定についてもっと権限移譲してくれ」と言われたらこう返すしかありません。
「そうかい坊や。きみが大人になったらな」

開発チームへの権限移譲 について、こうも書かれていませんでしたか？ 信頼される開発チームになれ と。

締切決定に関する権限移譲は、信頼できる完了予定日の提示が前提

信頼できる完了予定日を提示できるようになるために開発チームは努力をする必要があります。

逆に言えばそれを自分で提示できないのであれば甘んじてチームの外から降ってきた締切を受け入れる他ありません。
「教科書」の都合のいいところだけ切り取って締切を押し付けるなと言われても経営者は困るのです。

権限と責任はセット。
責任を果たせないのに権限移譲を要求されても経営者には応えられるわけがないのです。
スクラム開発者が苦手な現実です。

「信頼できる完了予定日」を出すにはどうすればいい？

これも本当に教科書通りの話になります。

ベロシティを安定させるとともに、ポイントベースの見積や定期的なバックロググルーミングというプラクティスがちゃんと機能していること。
プロジェクトの最後に湧き出るボスラッシュみたいなユーザーストーリーやタスク追加を適切に扱えること。
開発期間の後半に入っても、後からだらだら追加でユーザーストーリーや作業が無限湧きしてバーンダウンチャートの残が次々積み上がっていくような劣悪な体制にないことが必要です。

これをできるようにしないと、いつまでたってもスクラム開発＋社内受託体制は変わりません

そしてそれだけでは足りない

ところがこれだけでは締切指定の社内受託体制を変えることはできません。
なぜなら開発チームだけが変わっても意味がないからです。

• 最初にざっくりとした開発期間だけ出す
  • 精度の高い完了予測が出てくるのは開発工数の30%を消費したあたり
• ユーザーストーリーベースでプロダクトオーナーがスコープを調整できる
  • ユーザーストーリーマッピングができていることは前提
  • 機能ベースのバックログとか論外
  • プロジェクト開始した時点でスコープは増えるけど減らないとかもきつい

社内発注に慣れていた人間が受け入れ難いこのようないくつかの条件を、開発チームとビジネスサイド、つまりアジャイルと非アジャイルの境界線で受け入れてもらう必要があります。

つまり難易度高すぎでは？

そうだよ（迫真）

現実は残酷

私の知る限りそこまでできる会社は稀です。

発注側からしたら、着手前に期限と開発範囲を指定して、あとは開発サイドが必死でどうにか帳尻を合わせるよう頑張らせたほうが楽だからです。

開発チームを信用せずともSaaSビジネスはできるし、社内受託だけで今までもビジネスは回ってきたからです。

そして転職へ

優秀なエンジニアほど引く手数多であり、職場を選ぶことはできます。
上記のような「楽な社内発注」にビジネスサイドが安住すると、私の知る限りでは優秀なエンジニアには逃げられやすくなります。
なによりエンジニアは「より高く、より速く飛ぶ」ことを求めがちです。
なんちゃってスクラムの現場と、本物のスクラムの現場を選べるなら、後者を取りがちです。
となると優秀層ほどエンジニアは流出しやすくなります。

スクラムはなくてもビジネスはできるよ

一方で時価総額数千億円の上場SaaS企業程度なら、ここで逃げるような優秀層のエンジニアがいなくても、「そこそこ優秀レベル」のエンジニアと社内発注/社内受託で回ってしまいます。

もちろん本物のスクラム開発ではないので「ユーザー価値にフォーカスして素早く価値を届ける」みたいなことはできません。
つまり小回りが効かず、またフロー効率も悪いです。
優秀層を集めて真のスクラム開発ができる相手が出てきたら小回りやフロー効率の差で負けるかもしれません

本物のスクラム開発はなくても上場くらいはできますが、ほかは同じ条件のできている企業とできていない企業がぶつかれば前者の方が圧倒的に有利でしょう。

ここから先、国内のアジャイル開発が発展する中でどこが勝ち残るのかはぜひ注視していきたいと思います。