炎上しているプロジェクトを、スクラム開発でなんとか鎮めるまで
こんにちは。ひらやま（@rhirayamaaan）です。
現在、フロントエンドエンジニアとしてWebアプリケーションの作成と、時折UIデザインの作成を生業にしています。
みなさんは炎上しているプロジェクトにアサインされたことはありますか？
こんな記事を書いているのでお察しかと思いますが、私にはその経験があります。しかもそれだけではなく、恥ずかしながら炎上させたこともあります。
炎上させているときは、まさか自分のプロジェクトが炎上しているなんて思いもしないわけです。実際には炎上しているのですから、当然忙しくしているわけで、目の前のやるべきことをただがむしゃらにやっている状態で、とにかく自分の手でなんとかしなければならないと思うばかりで、それをまさか「炎上」と呼ぶとは思えていないのです。
ただ、それを見兼ねて優秀な方々がサポーターとして入ってくださり、炎上していることを気付かされ、自分の無能さを噛み締めながらその方々とともに鎮めてきました。
私もこの業界に来て10年以上となり、様々なプロジェクトにアサインされて仕事をしてきました。私はよくリプレイスやリニューアルのプロジェクトにアサインされることが多く、それぞれのプロジェクトは、当然状況は違えど、似たような燃え方をしていました。
炎上したプロジェクトにはそれなりの共通した現象があり、それの鎮め方というのもまた共通したやり方があることが自分の中で体系化されてきました。
IT業界に勤める方の残業の軽減やメンタルヘルスのサポートができればと思い、この記事を書こうと思い立った次第です。
また、この記事は個人の経験を基にしている部分が多いため、偏った知識であることも理解しています。
なるべく一般化しながら書こうとは思っていますが、反例や反論等もちろんあると思いまので、その際はご指摘いただければ幸いです。
炎上と責任
まず、そもそも炎上しているとはどういう状態なのか、そして、炎上しているプロジェクトにはどのような責任が発生しているのかを見ていきます。
簡単なざっくりとした例を2つほど挙げて、深堀りをしていこうと思います。
例から見る「炎上」
まず1つ目の例として、とりあえずやりたいことのイメージを掴むための絵としてデザインモックがあり、それをあとは実装すれば良いと考えられているケースです。
デザインモックはあくまでもモックアップであり、その状態から仕様を固めていくのは非常に困難な状態にあります。表示する情報がないときにはどういう表示になるのか、見るユーザによって表示が変わるのか、そもそもサイト設計自体が適切かなども決まっておらず、そうなるとAPIの仕様も決められず、データベース設計すらもできないことになります。
目の前に絵があるとそれをとにかく作りたい衝動に駆られて作り始めてしまいう、やっていくうちにやるべきことがどんどん増えてき、気づいたらいつまで経っても終わらなくなっているということはよくあるのではないでしょうか。
2つ目の例としては、リリース日が明確になっていないことによって、永遠にリリースに持っていけないケースです。
作っていく過程の中で、もっとこうした方が良いプロダクトになると考えてしまうのは、ものづくりの人としてはよくある話だと思います。実際に手元で動かすともう少しデザインや挙動を調整をしたくなったり、コードを書いているとリファクタリングをしたくなったりします。
リリース日という期限がないからこそ、完璧にしたうえでリリースしたい欲が生まれ、いつまでもリリース日を延ばしてしまいます。
例に挙げた2つのケースのうち、まず課題として認識したいのは、どちらもリリースするスコープが決まっていないという点です。
2つ目の方は明らかで、自らスコープをどんどん増やしていることになります。なんとなくスコープを増やしたら、実はいろんなところで修正が必要になったり、もともと決まっていた仕様自体を見直さなければならないことになることもしばしばあります。
それに比べて、1つ目の方は2つ目よりかはスコープが決まっていそうですし、下手したらこの段階で見積もりまで出せていることもあります。しかし、結局はモックアップからものづくりを始めているという状況で、仕様がほとんど明らかになっていない状態です。実際に作業をしていく中でやらなければならないことが次々に明らかになっていき、スコープが想定より肥大化することとなり、見積もっていた値がいかに甘かったか思い知らされることになるのだろうと思います。
そのため、どちらの例でもどんどんリリース日を遅延させなければならない状態に追い込まれる可能性が非常に高いと言えます。
この例以外にも様々なケースがあるかと思いますが、基本的にはスコープが明確ではないということが発端となって問題となることがほとんどなのではないかと考えています。
遅延が生む責任
そもそも、納品という概念がないのであれば、リリース日を固定する必要がどこにあるのか？という意見も出てくると思います。
しかし、リリース日を遅延させるというのは、結局想定していたコストを大幅に上回ることになってしまいます。
例えば、1つのプロジェクトに6人いて、1人に対して30万の給料を支払っているとします。そのプロジェクトが1ヶ月リリースを遅延させるとしたら、最低でも180万円分のコストが余計にかかることになります。（実際は保険料の負担やオフィス・開発環境の維持費など、細かく算出するともっと増大な費用がかかってくるでしょう。）
では、その1ヶ月の遅延をさせたことで180万円分の価値を乗せたうえでリリースできるのかと問われると、正直思い悩むのではないでしょうか。
当然遅延させないと出せないので仕方がないのですが、当初予算を組んでいたとしたら、その予算を越えてでも遅延させないといけない理由だったのかどうかは熟考したほうが良さそうです。
リリースをしなければ永遠にビジネスの機会を後ろ倒しにしていることになります。割いた予算を取り戻す計画も踏まえたうえで、本当にリリース日を遅延させるべきかはしっかりと検討したほうが良いのかもしれません。
また、上記の例のような状態でなんとなくリリース日を遅延させていくと、シンプルに社内の信頼を失います。このプロジェクトは平気で自分たちが設定したリリース日を破るという認識になるはずです。
これも、自社でプロダクトを作っているだけだからそこまで信頼について考えなくて良いという考えになるのかもしれませんが、対外コミュニケーションを行う職種の方に大変な迷惑がかかることは容易に想像できます。
何かをリリースするということは、営業の方にとってはプロダクトの売り方が変わるでしょうし、CSの方にとってはサポートの仕方が変わるでしょう。
お客さま対応のために準備をして待ち構えている社内のメンバーがいる中で、自分たちが設定した約束した日にリリースできないというのは、それ相応の説明責任が発生します。
リリースできない理由を開発メンバーから説明されなければ、お客さま対応をするメンバーは全く持って納得がいかないはずです。
逆に、リリース日を勝手に決められてしまっていて炎上しているケースもあります。1つ目の例の状況で、自分たちがリリース日を決めたわけではないパターンです。デザインモックの状態でプロジェクトが承認され、あとは雰囲気でリリース日を確定されている状態です。
これはプロジェクトとしては不遇な状態かと思われますが、それでもプロジェクトを進めていく以上、説明責任を負わなければなりません。
工数を度外視したリリース日に、建設的にNOと言えるようなコミュニケーションの材料を揃えなければなりません。そして、その材料を持った上で、なぜ自分たちのプロジェクトはリリース日を延ばさなければならないのか、いつまで延ばせばリリースできるのか、なるべく早くリリースするにはどういう戦略を練ればよいかなどを考えていかなければなりません。
また、NOと言わないでリリース日に向けてとにかく突き進めば良いと考える方もいるかもしれませんが、人を増やしてもコミュニケーションコスト等がかかるため開発速度が倍増するわけではありませんし、それすらもせずに突き進めば過労を強いる最悪な環境を作り出してしまうだけです。
つまり、リリース日というものに対して向き合うというのはそれなりに緊張感があることで、さらにどんな状況であってもそこから逃げることは基本的には許させれないということです。しっかりと責任を持つ必要があります。
そのような状況下でやはり重要となるのは「スコープが決まっていない」ということに本気で向き合うことだと思います。リリース遅延の大きな理由として考えられそうなのでしっかりと考え抜きたいです。
ではスコープが決まらない状況をどう打破すればよいのか。
上述の例をもう一度振り返ると、その時折に必要だと思ったことをがむしゃらに対応していたら、スコープはいつの間にか広がり、気づいたら手につかない状況になっていそうでした。
ということは、そもそもスコープ自体を広げないようにしつつ、広がりそうかどうかを観測できるようにすれば良さそうです。
ではそもそもなぜスコープは広がってしまうのか。そこを考えていくとより議論は進みそうです。
スコープが広がる理由
ここからはより具体的に、なぜスコープが決まっていかないのか、なぜスコープが広がり続けるのか見ていきます。
端から広いスコープ
そもそも、最初のアイデア出しの時点からスコープが広すぎるケースがあります。
よくあるのは、古い技術が使われているから新しい技術へリプレイスをしようとしたときに、UI刷新までスコープに入れてリニューアルまでしてしまうケースです。「ついでによくしたい」の典型例です。
UI刷新をしようとすると、もともとの使い勝手から見直されるためUXの領域まで変える必要が出てくることがしばしばあります。そうなると仕様から変えなければならなくなり、結局は今あるサービスの基本機能は残しつつ、さらによりよいサービスを作ることとなってしまい、現状の仕様整理にプラスして新しい仕様の策定まで行う必要が出てしまいます。本当はリプレイスというマイナスをゼロにする作業だけで良かったのに、ゼロをプラスする作業まで入り込んでしまっている状況です。
その事に気づかずに、より良いものを作ることばかりに注力しすぎてしまって、本来必要であったマイナスをゼロにする部分の仕様整理をおざなりにしてしまい、作業が進んでからタスクを見直したらときにはもとの要件を満たせずリリースに間に合わなくなるなってしまうことがあります。
曖昧なタスクの量産
リプレイスやリニューアルに限らず大きめな機能開発を実施する場合、ひとまずざっくりとしたやることをタスク化していったら、予想以上に膨大なタスク量が出てきてしまって途方に暮れることがあります。
とにかく多くの作業が存在するので、ひとまず「トップページのUIデザイン作成」「トップページのフロントエンド実装」「トップページのAPI実装」というようなざっくりとしたタスクをひたすら切っていってしまい、それだけで満足してしまうこともしばしばあります。
でも実際には、まずはトップページの仕様を検討しなければならないはずです。それが終わらなければ、トップページにどのような情報を出すかわからず、デザインタスクも開発タスクもどんなことをすればよいかわかりませんし、その状態でそれぞれのタスクに1人日とつけたとしてもほぼ見積もりをしていないのと同じです。
つまり、そのタスクは曖昧すぎてほとんどタスクとしては洗い出せておらず、実際に取り掛かるとどんどんやるべきことが顕在化してしまい、スコープが増えているように見えるという現象が起きます。
傲慢な見積もり
また、仕様がわかっていない状態にも関わらず、今までの経験からなんとなく、しかも不明瞭に見積もりをしてしまうこともあります。
炎上しているプロジェクトではよく「このタスクはほとんど終わっていて、あと○○するだけ」や「ここはもう決まっていて、あと○○をやるだけ」というような曖昧な言葉を本当によく聞きます。（私もよく言っていました。）
その「○○」というのはその見積もった方の経験上、本当に些細な作業なのかもしれません。しかし、その些細なことが大量にあったら見過ごせなくなります。しかも、その些細だと思っていたことは、実はどんどん深堀りすると、全然些細なことではなかったということもよく起こります。
得意な領域の見積もりに対して、なんとなくこう作業すれば終わるだろうなという感覚を持つことは、私もエンジニア・デザイナーなので一定理解できます。
しかし、やることを書き出さずに経験則でなんとなく見積もった見積もりほど当たらないものはありません。なぜならタスクを洗い出せていないからです。タスクは実際に書き出して、目で確認しながら洗い出さなければ、自分たちが気づいていないタスクを発見することはできません。
そして、そのタスクが洗い出せていなければ、当然見積もりも正確なものにはなりません。
不明の未認識
ここまで、タスクを頭の中から外に出していき、そのタスクを詳細化していくことが重要であると述べてきました。
これができていないということは、つまり自分たちがどこまでわかっていないのかすらわかっていないということになります。
先ほどのトップページの例をとっても、「トップページの仕様を検討する」というタスクを切っておけば、自分たちは「トップページの仕様を検討できていない」ということを認識できるようになるわけです。
逆に、「ほとんど終わっていて〜」という発言は、その「ほとんど終わっている」とはどういう状態なのかを明確にできていない時点で「○○するだけ」という結論は導き出せないはずなのです。
どこまでわかっていないかをわかるだけで、自分たちの見積もりがどのくらい曖昧なのかを知ることにも繋げられます。「まだ曖昧だから少しバッファを設けたほうが良い」とか「曖昧さがなくなってきたから確実にリリース日を固定できる」というようなことを建設的に考えられるようになります。
こうすることで、不確実なことに対して立ち向かっていける体制を作っていけます。
ここまでのことを整理してみると、リリース日を遅延せざるを得ない状態にまで炎上してしまっている原因としては、そもそもやりたいことをてんこ盛りにし、大量なタスクから目を背け、タスクの詳細化を避け、自身の見積もりを疑わない態度から発生してしまっているように思います。
ここまで厳しいことを言ってきていると思っていますが、私はほとんどの人が悪気があってこのような状況にしているわけではないと思っています。リリース日をあえて延ばしてやろうという意志を持っている人は基本的にはいないはずです。カオスな状況下において、なんとか物事を前に進め、貢献していきたいと思っている人が多いでしょう。
しかし、カオスな状況であることを認識することに蓋をしてしまっているようにも見えます。目の前の忙しさに身を投じることで現状に甘えていない自分を演出し、本当はまずい状況にあることに対して気づかぬフリをして、実は現状に甘えてしまっているのではないでしょうか。
もしそのような状況であるなら、結局それは責任を放棄していることにしかならないです。
私は、意志を持って積極的に責任を放棄しようとしているとは全く思っていません。しかし、責任を持たない状態に自ら仕向けてしまっているのだろうと思うのです。
そのような状況を打破するためには、リリースに対してしっかり責任を負える状態を作っていかなければなりません。
これは意志に期待しても期待通りにはならないので、仕組みで解決していく必要があります。
タスク整理の実践
ここからは実際に、どのように炎上している状況を打破していくかを考えていきます。
今まで、リプレイスやリニューアルなどの大規模開発の話をしてきたにも関わらず、なぜ記事のタイトルに「スクラム」が入っているのかと疑問に思われた方もいるかもしれません。
この手の開発は、基本的にウォーターフォール開発が選ばれることが多いのかなと思っています。しかし、私はアジャイル開発の手法の一つであるスクラム開発をベースにした実践の仕方を提案したいです。すべてをスクラム開発に則ることは難しいですが、ウォーターフォール開発の考え方も取り入れながらスクラム開発で実践することで、炎上に立ち向かう一つの方法を目指していきます。
まずはタスク整理の方法から説明していきます。
スパイクタスクの活用
スクラム開発にはスパイクタスクというタスクの種類が存在します。もしかしたら正しいスパイクタスクの使い方ではないかもしれませんが、開発作業ではない、仕様を決めたり技術的な調査をしなければならないタスクはスパイクタスクとして切り出しておきます。
このようなタスクは意識して切り出していかないと、調査したり検討したりしなければならないことを開発タスクの中に入れてしまいがちです。メモとして「○○を調査したら実装予定」とだけ書かれてしまうこともあります。
しかしこれをしてしまうと、そのタスクを開くまで調査や検討が必要かどうかが明らかになりません。なので少しでもスパイクタスクとして切り出せそうなものは切り出して、誰かの目につきやすい状況を作ります。
また、基本的にタスクの特性上スパイクタスクが完了しなければ実装タスクに入れません。スパイクタスクがブロッカーになるため、調査・検討のような不確実なものを確実にしていくタスクの優先度が上がりやすくなります。
こうして、仕組みでどんどんプロジェクトの確実性を上げていけます。
ユーザストーリーの活用
本来のスクラム開発のように、すでにリリースされているプロダクトに対して、継続的なデリバリーをしていきたい場合に重宝されるのがこのユーザストーリーというタスクの切り方です。
「ユーザは○○することができる」というタイトルを付けてタスクを切るのが一般的で、その条件を満たすすべてのタスクをリリースできなければ完了にはなりません。
しかし、大規模開発においてはユーザストーリーのレベルでリリースすることが困難な事が多いです。私も必ずしもユーザストーリーを切らなければならないという考えは持っていません。わざわざユーザストーリー調のタイトルを付けることに時間をかけるくらいだったら、単なるタスクを切ったほうが良いと思うことも多々あります。
しかし、それでもユーザストーリーをあえて使うことで得られる利点もあります。
それは、一つの漠然としたやりたいことを分割できる点です。
例えば、eコマースサイトにカート機能という大きい機能を作るとします。
カート機能には、まず商品ページからカートに追加する機能を作る必要があります。そしてカートページには追加した商品が表示され、商品の数量の変更と値段の表示、そして合計金額の算出などがあります。このように少し考えただけでもいろんな機能があることがわかります。
この規模のものを、一つひとつタスクとして切り出していくのは相当難易度が高いです。各機能ごとにも仕様がありますし、もしかしたら各仕様が絡み合っている可能性もあります。タスクが漏れる可能性が十二分にあります。
この状況に対してユーザストーリーを作っていくと、かなりやるべきことが整理されていきます。まず「ユーザは、商品をカートに追加したい」というストーリーを切れば、その機能について必要な仕様を洗い出せば良くなります。また、その必要な仕様は、受け入れ条件として書き出していくことにより整理できます。
受け入れ条件とは、そのユーザストーリーが完了する条件のことです。例えば上記のストーリーの受け入れ条件は、「カートに追加できること、商品のバリデーションを選択できること、カート追加時に数量を選択できること、追加したらカートページに遷移すること…」というように、仕様を列挙することができます。
これを記していく作業をチーム全体で行うことも重要です。これはリファインメントと呼ばれる活動で行っていきます。PO（組織によっては PdM/PM）がユーザストーリーを作成し、それを開発者が実装作業をイメージしながら検査していき、ユーザストーリーの詳細度を上げていく作業になります。
そうすると、様々な専門性を持った人たちで確認していくことになるので、例えば上記の例をより深堀りすると「数量に数値以外が入力されていたらエラーにすること」というような受け入れ条件も足すことができます。
リファインメントという活動自体は時間がかかるものではありますが、メンバー全員で仕様を整理することで仕様自体も把握しやすくなり、仕様自体も洗礼されるため、逆にコミュニケーションコストが下がる効果が見込まれます。
もし、ユーザストーリーを切ることの方が大変になってしまう場合はタスクを切っていくのでも良く、完了条件が明らかになっている状態を目指せれば問題ないと思います。
カート機能というような大きい規模ではなく、ページ単位ごとにタスクを切る形で、そこまでタスクの抜け漏れが発生しなさそうであればその形のほうが時間がかからないですし良さそうです。
とにかくやりたいことは、ユーザストーリーを切ることではなくてタスクの明確化してとにかく不確実な状態をなくしていくことなので、その軸さえブレなければ問題ありません。
見積もり時の姿勢
ユーザストーリーによって完了条件をしっかりと洗い出せていると、各開発作業もより明確になります。
先ほどのカートへの追加機能の例で考えると数量の入力値のバリデーションの実装や送信機能が必要となることがわかっているため、ただページを表示するだけのページよりかは作業量が多いことが明確になります。
その小さい作業自体もなるべくサブタスクとしてとにかく切っていきます。あのタスクとこのタスクは実は重複してしまっているということもあるかもしれませんが、実際に作業するときに同時にタスクの進捗を管理すれば良いので、とにかく細かく切ることを意識していきます。
また、各職能がそれぞれのタスクを細かく切っていきます。職能関係なく、そのストーリーに必要なタスクを細かく切ることで、一つのユーザストーリーに対して作業を並列して行えることも見えてきます。このサブタスクは他と依存しないから先行して行えるというようなことも計画しやすくなります。
これが「カート機能の実装」というタスクの状態で、それに対して見積もっていたら、相当な齟齬が生まれるだろうと想像していただけると思います。
また、見積もるときにはサブタスク単位で見積もり、ユーザストーリーにならなかったタスクやスパイクタスクにも見積もったほうが良いです。タスクにサブタスクを入れている場合もそれらすべてを見積もります。これは継続的なデリバリーを期待している本来のスクラム開発とは相容れない考え方であることは理解しています。
本来のスクラム開発は、ユーザストーリーにのみ見積もりを実施し、ユーザのための機能開発を継続的にできているかを見るようにするようです。スパイクタスクやリファクタリングタスクのようなものにあえて見積もりをしないことで、スプリント（1週間または2週間程度の活動の区切り）が終了したときに完了したタスクの量として計上しないことを目的としています。
しかし、大規模開発においては、すべてのタスクにおいて人の工数を使うものとして見積もることで確実性の向上を図ります。そもそもスクラム開発自体が不確実性を考慮した開発スタイルなのに対して真逆の思想を展開してしまっていますが、継続的なデリバリーではなく指定されたリリース日までの必達を要求されている状況においては、まずは自分たちの状況を報告しやすくすることも期待して確実性の向上を優先させます。
見積もりの実践
さらに、見積もりの方法も通常のスクラム開発とは異なる方法を採用します。スクラム開発では相対見積もり（ストーリーポイントなど）という方法を取りますが、私は人日を使った絶対見積もりを推奨します。
相対見積もりは、なるべく見積もりに時間をかけないようにするための方法です。継続的なデリバリーを実践する上では詳細に見積もったところで日々状況が変わるため、リリースするものも変わりやすく不確実な状況になりやすいです。そのため詳細な絶対値を出すのではなく、複雑さ、リスク、不確実性を加味して表現しておきます。そして、以前にリリースした基準となりそうなストーリーを選んでおき、その基準ストーリーが例えば3ポイントという見積もりだったら、次に見積もるストーリーはいくつになりそうかというのを選んでいくやり方です。
これは継続的なデリバリーが可能な状況においては有効なのですが、炎上している状況からすると不確実性をそのままにしてしまうというのは不安が残ります。
そもそも炎上している状況で基準ストーリーを作るのはかなり難しいです。基準ストーリーを作るには継続的なデリバリーを実践していく中でその基準が妥当だったかを検証する時間が必要ですが、そんなことをやっている場合ではありません。
ただし、人日で見積もるにしても、あまりにも詳細な見積もりは行いません。詳細化するのはあくまでもタスクだけで、見積もり事態はそこまで正確でなくても問題ありません。
まず、見積もり方として意識することは見積もりの最小値を0.5人日にすることです。どんなに小さいタスクであっても0.5人日とします。作業者として見積もるとき、うっかり自分の作業時間しか見積もらないということがありますが、実はレビューの時間や確認の時間などで工数を取ることが多々あります。明らかに少ないだろうというものでも0.5人日にすることで、予期せぬタスクに対してのバッファを取り続ける作戦です。
また、上述の通りサブタスクがある場合はサブタスクに対して見積もっていき、最終的にユーザストーリー及びタスクの見積もりはサブタスクの合計値とします。そうすると結構大きめの数が算出されますがそれで問題ありません。見積もりをしているときはどうしても早くリリースしなければという責任感から小さく見積もりがちですが、むしろ小さく見積もってリリースできない方が責任を負えないので、合計値で大きく算出されるくらいがちょうどよいです。
ちなみに、なるべく小さい値で見積もらないようにすることだけは意識しつつも、なぜそこまで正確に見積もらなくても良いかというと、プロジェクトがオンスケジュールで前に進めているかをチェックするときに、最終的にはこの絶対見積もりの値を相対見積もりの値として扱うからです。
どのように相対見積もりとして扱うか、そしてなぜ相対見積もりとして扱うのにオンスケジュールであるかを確認できるかは後述します。
また、この見積もりの活動をメンバー全員で行っていくこともとても重要です。そうすることで見積もりの精度も上がっていきます。これは通常のスクラムと変わりません。誰かに見積もりをお願いするのではなく、少なくとも職能単位で見積もることで認識の齟齬がなくなります。一人で見積もるという状況を生むからこそ、どんどん見積もりの精度が下がっていきます。
さらにこの見積もりのタイミングでタスク自体が再度見直されて、タスクの漏れの発見につながることもあるので、大変ではありますが、なるべく端折らずに丁寧にやることをおすすめします。
そして、「見積もりの姿勢」でも述べた通り、すべてのタスクを見積もることに全力を注ぎます。最初は開発には入らずすべてのタスクを洗い出してすべてを見積もり、スパイクタスクに着手するとなってからスクラムを開始するくらいのがよいと思います。
これは賛否分かれるとは思いますが、見積もりを端折ったらリリース日に対してのコミュニケーションを取れなくなると私は危惧しています。私だったらまずはその時点で見えているすべてのタスクを見積もるところを目標にします。
段階的リリースの検討
そもそも、スクラム開発を採用しているので、段階的リリースに取り組みやすい形になっています。
タスクを整理していく中で、それぞれのリリースを疎結合にできそうなのであれば積極的に検討し、段階的に小さくリリースする戦略を取れるように試みてください。
どうしても大きくリリースして花火を打ち上げたいと考えてしまうかもしれませんが、それによって大きな事故が発生してリリース時にロールバックをせざるを得ない状況になったり、そもそもロールバックすらできない状況となったら元も子もありません。
リリースの単位は小さければ小さいほど事故が発生したときに元に戻しやすいです。ビックバンリリースをしないためにウォーターフォール開発を採用しないという考え方もあると思うので、可能な限り検討したほうが良いと思います。
ただし、小さくするための作業が大幅に発生することがあることも理解しています。そこはどちらが良いか天秤に掛ける必要があると思っているのため、段階的リリースの検討が必須というわけではもちろんありません。
リリース管理の実践
タスクを一通り整理したら、次は日々プロジェクトを進捗させていきながら、日々生み出されるタスクを整理して見積もり、さらにリリース日までオンスケジュールで進められているのかを日々観測しながら、確実にその日にはリリースできるようにしていかなければなりません。
その実践の仕方を説明していきます。
不確実性の継続的排除
ここまで述べてきている通り、私は詳細にタスクを洗い出していくことをとても重要視しています。ウォーターフォール開発的な考え方であると私も理解しています。
しかし、どんなにタスクをしっかり洗い出したとしても、間違いなく漏れが発生したり、進めていく中で修正が必要になったりと、想定していなかったことが次々に現れることも理解しています。
そのような自体に対処するために、スクラム開発をベースにしてた進め方を提示しています。
アジャイル開発はユーザに対して継続的なデリバリーを目指す開発プロセスであるため、ビックバンリリースになりやすい大規模開発との相性は良くないと考えられますが、一方でアジャイル開発は継続的に進め方のプランを柔軟に変更し続けられるという利点を持っています。
スクラム開発にはプランニングというイベントがあります。スプリントの開始時に、そのスプリント内でどのようなタスクを行うかをチーム全体で決める活動のことです。
この活動の良いところは、実装中にさらに必要なタスクが発生したり、リファインメントの実施により重要なタスクが発生したりした場合に、何か他のタスクの優先度を下げて、その必要なタスクを次のスプリントに差し込むことができる点です。時間に余裕があるからとリファクタリングのようなタスクをやろうとしていた場合も、そのリファクタリング後回しにして、その重要なタスクの作業から取り掛かれるように調整する機会を得られます。
次スプリントではなく今のスプリントに途中から重要なタスクを入れたい場合もあると思います。基本的にはプランニング時に完了可能な分をスプリントに入れていると思うので、なにか入れるなら何かを抜くのが基本ですが、プロジェクトの状況的に余力がありそうであればそのまま入れても良いと思います。
しかし、入れるかどうかの最終判断はPOに委ねるのが基本です。作業の優先度を管理するのはPOの役割なので、勝手に優先度を判断するのはプロジェクト進行に大きく影響が出ると捉えてよいでしょう。
リファクタリングのタスクをどうしても入れたかったら、POを説得する必要があるということです。
また、リファインメントはタスクを整理し終えたときに実施をやめるのではなく、継続していくつもりでミーティングを組むことをおすすめします。
調査や検討が発生した場合にスパイクタスクを切った方が良いというのは上述の通りです。そのスパイクタスクの中身を話すタイミングは、もちろん関係者で話すこともあるでしょうけども、リファインメントを活用することが多いです。
リファインメントはユーザストーリー等を扱う場なのでプロジェクトメンバーが全員参加しているはずで、そこで全員が認識しておいた方が良い調査・検討内容を扱うことが多いからです。
とにかくリファインメントは不確実な状況をクリアにしていって、開発タスクにまで落とし込んでいく場と捉えてください。
このリファインメントを怠ることが一番リリース遅延につながると言っても過言ではありません。
この活動をやめたら、人日の増減を管理することができなくなり、最終的にリリース日を守る約束をできなくなってしまいます。常に必要なタスクがすべて見積もられている状態を作り続ける必要があり、それを行うのがリファインメントです。
日々の進捗管理
ユーザストーリーからサブタスクを切る際に、それぞれの職能のタスクを切るとお伝えしましたが、これをやっておくと日々の活動の中で職能ごとの連携もとてもしやすくなります。
スクラムにはデイリースクラム（以下、デイリー）というイベントがあります。これは日例とか朝会、夕会などと呼ばれるものと捉えていただいて構いません。
デイリーでは毎日進捗を確認したり、困りごとなどを解消するために実施されるものですが、ここで作業者ごとに報告してしまうとただの報告になってしまって、相談まで生まれづらくなるという課題があります。自分のターンが回ってくるまで話さなくて良いという雰囲気になり、他の方の相談事を聞けないという事態が多く発生します。
それをユーザストーリー及びタスク単位で話すようにすることで、人ごとに話す番が回るのではなくその事柄ごとに話すようになり、みんなでそのユーザストーリーを完了させにいくという流れになるため、自分がタスクを進められていないという劣等感を感じづらくなり、協力しやすい環境をつくることができます。
炎上しているプロジェクトでは、各職能・領域ごとに仕事を完全に任せてしまっていて、最終的にすべてを結合しようとしたときにタスクが大量に残っていたことに気づくという事態が発生しやすいです。
これは単に言えばコミュニケーションを取れていなかっただけなのですが、コミュニケーションを取る仕組みがなかったと捉えることもできます。
このように、進捗管理の対象を人にするのではなく事（タスク）にするだけで、一気に進捗の透明性が上がるため、この実践だけ採用してみるだけでも効果が出ると思います。
リリース日の確定方法
ここからは今回の記事の要の部分となります。リリース日を確定するためのその他すべての活動なので、ここの話はぜひ読んでいただけると嬉しいです。
スクラム開発では、プロジェクトが安定して開発を進められているかをチェックするために、ベロシティという値を活用します。
ベロシティとは、1スプリントにおいてどのくらいのストーリーポイントを消化できたかを計測し、数スプリント分（大体6スプリント程度）の消化数の平均値のことを指します。
例えば、今回のスプリントが13ポイントの消化量で、ベロシティの平均値が20だとしたら、今回のスプリントはあまりリリースができなかったと捉えることができます。
このように毎スプリントのポイント数がベロシティから離れてしまっている場合に、見積もりが甘いのか、プランニング時のタスクの乗せ方が甘いのか、とチームの活動を見直していき、ベロシティの値と1スプリントのポイント消化量が安定することを目指していきます。
なぜ消化量の安定を目指すのか？
それは、ベロシティを使うとリリース日を確定させられるからです。
なぜ相対見積もりをしているのに具体的な日付まで確定させられることができるのか不思議に思う方もいらっしゃると思うので、説明していきます。
例えばベロシティが20ポイントで、1スプリントの消化量が安定した状態で、かつ必要なタスクの見積もったポイント総数が100ポイントだった場合、あと5スプリントで作業を終わらせられると言えます。
そして、1スプリントが2週間だった場合は10週間かかるということになるので、リリース日は10週後と言い切ることができるのです。
これが、相対見積もりをしていても、適切にリリース日を伝えられるロジックとなります。
ただし、正確なベロシティは何スプリントか回してみないと安定してこないため、すぐに算出できる値ではありません。
それにもかかわらず炎上しているプロジェクトとしては、リリース日を算出を急かされる場合もあります。
なので、まずは人日で見積もった値を元にガントチャートを引きます。ウォーターフォール開発と同様に、リソース状況をベースに各機能の実装の並列化を試みながら引いていき、バッファもしっかり設けた上で線を引いていきます。実はこのために人日で見積もっています。
そして、ひとまず仮置きのリリース日を算出して報告します。その仮置きのリリース日が、工数度外視で出されたリリース日を越えている場合はいくつかの機能を削る相談をこの時点で行うことができます。しかし間に合いそうであれば、そのままその仮置きのリリース日を守ることを重視しながら進めていくことになります。
つまり、この段階でのリリース日は確定事項ではないので、建設的なコミュニケーションを取れる場を用意しておいたほうがよいです。
例えば、実際にオンスケジュールかどうかをビジネスサイドと確認する会を、リリースするまで定期的に設定することが望ましいです。
そして、その仮置きしたリリース日を確実に抑えに行けるかどうかのチェックを、スクラム開発のやり方で行っていきます。
私は「見積もりの実践」で「最終的にはこの絶対見積もりの値を相対見積もりの値として扱う」と述べました。
これは、人日で見積もった値を最終的にベロシティとして算出することで、スプリントの日々の消化量から逆算して、仮置きしたリリース日に対してオンスケジュールかどうかをチェックするためです。
例えば、メンバーが6人いるとして、1スプリント2週間としたら10営業日なので60人日分だけタスクを完了できることになります。ただし、メンバーの職能は全員が同じなわけではなく、各職能のタスクがきれいに10人日分に分けられているわけではないので、確実に60人日分だけ完了にできるかは怪しいです。そのためにガントチャートでバッファを設けるわけですが、例えばバッファを1.3倍で設けていた場合は60÷1.3≒46人日と計算できるため、できればベロシティを50ポイントくらいで安定できるとかなり安心できそうです。
（たまたまですが、ちょうどPO1名分くらいの工数を考慮した形になりました。デザイナー分を抜きたいとかあれば、メンバーを1名分減らして考えてから様子を見るのも良さそうです。このあたりはガントチャートの引き方にもよりそうです。）
実際に50ポイントのベロシティで安定してくれば、先に述べた算出方法でリリース日にはオンスケジュールと自信を持って述べることができます。
もしオンスケジュールにならないのであれば、どの機能を落とせばオンスケジュールになるか、またはリリース日をどのくらい延ばせばリリースできるかを確認会のような場所で建設的に議論できるようになります。
スクラム開発の流れ
最後に、まとめとして私が提案する全体的な流れを説明していきます。
まずはリファインメントをひたすらに実施します。今見えているタスクをあらゆる手を使って洗い出し、メンバー全員で仕様を明らかにして見積もっていきます。検討・調査が必要な場合はスパイクタスクを切ってその工数を見積もり、作業自体はスクラム開発を開始するまで後回しにします。
一通り見積もりが完了したら、今度はプランニングをしてスクラム開発を始めます。実際にプランニングをするときには上記の例で考えると50ポイント分を超えるくらいの量をスプリントに乗せてみて、まずはすべてのタスクの完了を目指していきます。スプリントのタスクをすべて完了することはスクラム開発において重要なことです。
そこからデイリーで日々の消化量を見ていき、50ポイントくらいの消化で収まればそのままプロジェクトのやり方は継続し、50を下回るようだとプロジェクトとして何か策を打つ必要があります。スプリントを閉じる際に残タスクがある場合にはレトロスペクティブでしっかりを振り返りをして次のプランニングに活かしていくという流れになります。
また、リファインメントは別軸で常に実施していきます。次のプランニングでスプリントにタスクを入れられるように、常に作業を見越してリファインメントをしていくのをおすすめします。
その作業の中でタスクが増えていくこともあります。その場合は生まれたタスクを必ず見積もり、残りの残タスク工数からベロシティで割り算をしたときに、オンスケジュールであるかを常に見直していく必要があります。
もしそれでリリース日が延びそうな場合は、建設的に報告ができ、リリースまでにどういう策を取るのかを考えられるようになっていることでしょう。
このようにして、スクラム開発をベースにしながら、しっかりと対外コミュニケーションを取れるようにしつつ、自分たちが過度な労働をしないようにコントロールしながら、健全な大規模開発に挑むことができます。
大規模だからといってわからないと諦めず、しっかりと数字でコミュニケーションを取れる環境を作ることが心理的安全性の向上につながるのだと思います。
ぜひ、参考にしていただけたら嬉しいです。
さいごに
ここまで長文にお付き合いいただきありがとうございました。
さいごにもう少しだけ文章を添えたいと思います。
まず私は、スクラムマスターの資格を持っているわけでも、PO/PdM/PMの経験が豊富なわけでもありません。そのため、解釈に誤りがあったり、雑な解釈があったりするかと思いますが、そのあたりはぜひご指摘いただけますと幸いです。
私はなかなかの回数の転職経験があり、それなりにいろんな文化の中で、さまざまなプロジェクトの炎上を見てきました。
そういうプロジェクトを見るたびに、もっとこうすれば…と思うことが多かったのですが、嬉しいことに私のこの考えを積極的に取り入れていただいたプロジェクトがあり、もちろん私だけの力ではありませんが、しっかりと炎上状態から抜け出すことができ、一定の実績があってこの文章を書いています。
このやり方がすべてのプロジェクトに当てはまるとはもちろん思いません。正直、炎上状態から抜けたプロジェクトも完全にこの方法を取っているわけではありません。
また、グロースフェーズのプロダクトにこのやり方を実践して当てはまらなかった経験もありますし、社内の状況的に受け入れていただけなかった経験もあります。
文化的に合わないとか、フェーズ的に合わないとかいろんな変数がありますので難しいのですけれど、やはりいろんな方と話す中で、ベースの考え方としてはとても良いよねといってくださる方もたくさんいました。
また、このやり方のベースとなる考え方を持ったスクラムマスターの下で仕事ができたという経験も今の私の自信につながっています。
スクラムというキラキラした手法に懐疑的で、かつ大規模リプレイスを何度も失敗した経験がある私に対して、これだけ泥臭いスクラムを教えてくださったそのスクラムマスターには感謝してもしきれません。
こういう方法論は、一定のネガティブな反応を生むことは理解していますが、いろいろ見てきた中で、やはり無理をしなくとも一生懸命頑張りながら健康的に働くことができると信じているので、震えながらも投稿することにしました。
炎上という言葉をストレートに使うことにも一定悩みはしましたが、変に隠すのもよろしくないかと思いこのワードを使っています。
また、全体的に文章が厳しくなってしまっていることも十二分に理解しております。自戒の意も込めているためストレートになってしまっているのですが、もし傷ついてしまった方がいらっしゃいましたら本当に申し訳ありません。
ここまで読んでいただいて本当にありがとうございました！