まずはじめに、2022/01/28のfreee Tech Nightを楽しみにお待ちいただいていた皆様、当日直前にLiveを延期してしまいまして、運営にかわりまして申し訳ございませんでした。この記事はLiveで話す予定の内容の一部を深堀りした内容になっておりますので、文字でもお楽しみいただければと思います。
Abstract
- 期日を決めることには様々な利点があるが、期日通りに終わらせるにはとてもじゃないが避けづらい問題が多すぎる。
- 特に期日を先々まで決めてしまうことで直近の期日さえ守れなくなる状態になる。
- 期日を決めず、優先順位を決め、短い間隔で機能や価値を出すことで、方針の柔軟さを確保し、ランダムに発生する事象に対応しやすくなる。
- 現在地と予測地点を確認するためにまずは「バーンダウンチャート」をつくって運用してみよう。
はじめに
なにか目指したい姿があると、その姿に対して何かしらの案を考え、それにむかうための方法を考えて、実際にその方法を実施し、その姿になっていくというのは自然な考え方だと思います。場合によってはなんとなくやってたらそれになっているということも人生の場面（特にキャリアとかでそうなったり？）ではあるかもしれませんが、基本的に社会人としてなにかの組織にいると計画性をもった立案は要求されることが多いと思います。会社には様々な制約（例えばお金）があるので、無駄を極力少なくするべく、ある期日を設定して進むことが多いかと思います。特に成熟した会社になってくると、期日を守って動くことで全体的な動きを保ち、様々なリソース効率を最大化して無駄を排除しようとする動きが出てくることもあります。会社内に限らず、外部のパートナーにも期日を守らせる事により、同じような効果を狙うこともできるかもしれません。
皆様こんにちは。freeeでスクラムマスターをやってます ichy こと Takeru Ichiiです。今回は freee Tech Night 「期日じゃなくて優先度を決めろ！悩めるスクラムマスターの本音」 で語る予定の「期日と優先順位」の話についてこの記事で詳しく深ぼっていこうと思います。どうぞよろしくお願いいたします。
事前に期日を設定すると何が起きるのか
期日を設定する理由としてはいくつかありますが、それは一旦おいておいて、期日を設定すると何が起きるんでしょうか。
期日を設定すると、カレンダーに予定を立てられることになります。つまり、「暇になるタイミング」がわかるようになります。会社を維持し続けるにはお金がかかるので、会社規模に応じて維持できる分の利益をあげなければなりません。なので暇なタイミングがあれば利益を上げるために、様々な機能や価値を提供しなければなりません。なので仕事の予定を更に立てます。
さて、基本的にはこの繰り返しをしてくことになるのですが、この更に建てる仕事にはその前の仕事からさらに考慮しなければいけない点があります。会社は概ね誰かの投資によって成り立つことが多いのですが、投資を行う側の人間にとっては会社は基本的に大きくなってもらわなければならないと思っていることが多いかと思います。ということは、最低でも維持または売上増を見込める機能や価値の提供を求められるでしょう。リソースをそのままにして売上増を達成できるのであればそれに越したことはもちろん無いのでしょうけれど、基本的には機能や価値を新たに生み出すためには何らかのリソースが必要になります。なので機能や価値を新たに生み出すためのリソースの他に追加リソースを確保するための労力が必要になります。これは例えば、人を増やすならば採用などがこれに当たります。さて、新たに生み出すための計画とそのための追加リソースが決定したらまた暇になるタイミングが来るので、更に新しい機能や価値を計画します。その計画を皆様は「マイルストーン」などの言葉で表現することが多いです。新しい期が来ようとすれば、その期に何をするかを前もって計画し、年間マイルストーンや目標などを建てるという定例行事は会社人として所属しているとよく遭遇する場面だと思います。そして、定例会などの形で、マイルストーンに対する実際の進捗を確認し、遅れていればそのマイルストーンを達成するための調整を行うことになります。
期日はなぜどうしても遅れることが多いのか
さて、期日というものはとても繊細なもので、いくら計画を綿密に立てようが基本的には期日ピッタリに終わることは難しいことはおそらく皆さんもよく体験されていることなのかもしれません。ピッタリと言わず、期日より先に終わることができれば嬉しいものですが、一番厳しいのは言わずもがな「遅れる」ことです。
私はもともとエンジニアとしてものづくりをやってきている人間なので遅れる要因はいくつか思いつきそうです。事前の設計では予期できなかった技術的に不可能なことや、既存機構が正確に把握できなかった事による想定外の手間の多さ、設計の切り戻し、予定外の欠員、突然の異動、、、、この仕事を長くやってると遅れる言い訳は色々出てきそうなのでここまでにしておきますが、とにかく色々あります。面白い（？）ことだと、同僚のPCがいろんな手違いでリモートでデータ抹消されるなんてこともありました。
計画が遅れることを見越してバッファ（予備日）を用意するなどの対策を行うこともよくある対応策ですが、バッファを食いつぶすこともよくあるのではないでしょうか。バッファが無くなりそうってなれば、残業してまで間に合わせるぞ！という方法もありますが、これも人間には酷な話です。一時のブーストを行うことはできてもそもそも会社人として数年先まで計画が埋まっているのであれば、これは長距離走と同じで一定の価値を生み出すほうが結果的には健康的ですし、成果の出方にムラがありません。ムラが無いほうが計画も立てやすいです。もしかしたらずっとブーストできる人もいるかも知れませんし、ブーストした結果燃え尽きた人を捨てるという判断ができる組織であればそれでもいいかもしれませんが、その場合は計画を遂行するために余計な採用労力が発生しますし、どんなに優秀な人でも会社に入ったばかりであればチームパフォーマンスは一時的に必ず低下します（これは「人月の神話」で紹介された「ブルックスの法則」として有名ですね）。そもそも日本においては、従業員をやめさせることはとてもむずかしいので、燃え尽きた人を捨てるという判断もほぼ使えないでしょう。とりあえず、少なくとも残業は悪です。やめましょう。
そして会社人として働いているとき、必ず外部の変化によって差し込みのタスクや緊急対応が入ってくることがあります。エンジニアであればユーザーからの問い合わせや障害の発生などが典型的なパターンです。これももちろん計画に入ってないことがあるのでバッファを用いて対処することになりますが、そのためのリソースをとることは案外難しいです。先に述べた話ですが、暇な時間があればなにか仕事をしてもらいたいのでやっている仕事を詰めていくことが多い傾向があるように思えます。計画している仕事の潜在的なバッファとして利用している会社は多いんじゃないでしょうか。しかしそれでも仕事は遅れますし、差し込みが多くなればそれがそのまま計画している仕事の時間を圧迫します。
そして、1つの計画が長ければ長いほど、これらの遅れる要因が発生する回数が高くなるはずです。これらの起こる要因は概ね単位時間当たりに発生する確率がほぼ一定という私の経験則です。
事前に期日や計画を立てすぎることの難しさ
期日が遅れる理由についていくつか考えてみましたが、たとえ期日に遅れなかったとしても期日を決めすぎること自体も辛いことがあります。わかりやすく言えば、期日を決めることは、様々な計画の変更を難しくしてしまいます。前述の遅れた理由にも通じますが、仕事をしていれば何かしら差し込みが入ってきてしまいます。軽微な差し込みであれば確かに予備日などのバッファで吸収ができるでしょうけれども、そもそも方向性の転換や、何かの機能や価値を優先せざるを得ないときに予定の組み換えやその準備の計画が一気に崩れます。そういうとき、「空いた時間でとりあえずこれをやってほしい」という方法もあるかもしれません。そうすれば確かにその追加した計画のみがずれて、それ以外の計画はそのまま進行できるでしょう。よく言われる「兼務」「兼任」「並行作業」みたいな話です。平行で行うことでメインのタスクに対する影響はちょっとぐらい遅れるかもしれないけどいけます、みたいなこともよく聞く状況です。
その昔、ワインバーグのシステム思考法という本がありまして、仕事のスイッチングに関する作業時間について考察している文章があります。以下の表はワインバーグの表と呼ばれる、並行作業の数と、各作業に割り当てられる平均的な作業量、そしてスイッチングコストの割合（後述）を示しています。
| 並行作業数 | 各作業の作業時間割合 | スイッチングコストの割合 |
|---|---|---|
| 1 | 100% | 0% |
| 2 | 40% | 20% |
| 3 | 20% | 40% |
| 4 | 10% | 60% |
| 5 | 5% | 75% |
ワインバーグの表によれば、並行している作業が1つ（つまり並行していない）場合は、もちろんその作業に当てられる時間は100%ですが、並行作業が2つになると、それぞれの作業には40%しか作業時間が当てられません。つまり20%がスイッチングコストと呼ばれる作業を乗り換える負担に費やしてしまっている状態になります。これが3つ,4つ,5つとなっていけば、各作業時間は20%, 10%, 5%となり、発生するスイッチングコスト（＝失われてしまう作業時間）は40%, 60%, 75%となってしまいます。こう考えると、並行作業にはなかなか馬鹿にならない代償が発生してしまいますね。
加えてそもそも事前に期日を立てすぎることはそもそも遅れる要因以上に期日を決めることの信頼性が低いという問題点もあります。以下の図は エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング で紹介されていた「不確実性コーン」を簡略化し書き写したものです。
期日を立てたい場合はその機能や価値を実現するのにかかる時間を見積もるというフェーズがほぼすべてのプロジェクトで発生します。プロジェクトの最初では終了見込みの時期の幅（つまり実際に終わる時期に対する見積もりのズレ）が0.25~4倍となり、プロジェクト完了の時期の不確実性はとても大きい状態です。プロジェクトが進むごとに、経験や見通しがよくなり、その不確実性が減っていき、プロジェクトの実際の半分になる頃には終了見込み時期の不確実性は半分以下になっています。
昔から反復して同じ作業をやっていれば見積もりの不確実性は少なく、期日そのものの信頼性はおそらく高いものになるでしょう。この不確実性コーンの幅が小さくなるような状態です。実際に建築する建物はおそらくですがソフトウェアほどアーキテクチャの頻繁な変更がなく、同じフローを建物の数だけ実施できるという意味で見積もりの信頼性はとても高いように感じます（もちろん天候やもろもろの事情ですべての建物が期日通り立ってるかというとそうでは無いとは思いますが）。
ところでなんで期日を設定するんだっけ
さて、しかしなぜ期日を設定したいのでしょうか。いくつか考えてみます。
プロジェクトの期日を先々まで決めておけば、それぞれのプロジェクトの戦略や戦術のクォリティが上がるかもしれません。深く考えた戦略や戦術は即興で考えたそれよりもより論理武装がしっかりしており、自信を持ってプロジェクトを進められることができるかもしれません。無駄を排して確実に成長する方法を綿密に計画したい人は結構いる気がしています。しかし、先々の期日を決めたところでやはり市場の変化や思わぬ体制の変化で計画がそのまま遂行することは困難を極めるのではないかと思います。
期日を先々まで決めることで先々に発生する様々なリソースを事前に時間をかけて準備できることで、計画の達成をしやすくできるというふうに考えているかもしれません。特に壮大なことを考えている場合においてはリソースの準備は大変です。物資も必要ですし、人材も必要です。ありとあらゆるリソースをプロジェクトの適切なタイミングでロスなく投入できるとプロジェクトの成功確率は高くなりそうです。しかし、期日が遅れていくことで準備したリソースはそのタイミングがくるまで在庫として抱えてしまう可能性があります。これが人ならば「いつかあなたが最高に活躍できるポジションを用意できる日が来るから、今はこの仕事をやっていてくれ」とお願いする事になり、最終的にはミスマッチとなって退職するってことも発生します（これは過去そういうことがあったという経験があります）。
お客様向けの方向で考えてみれば、期日や計画を提示することで「待ってもらえる」という効果もあるのかもしれません。見積もりを作り、いついつまでに出します、ということが言えれば、ものがない状態でも契約が締結でき、ひとまずの運転資金を回収できる可能性はありそうです。そうでなかったとしても、確実に売る相手を先に確保しておくことで、多少は安心して開発できることはあるかもしれません。しかし開発が遅れたらどうでしょう。顧客の信頼は失ってしまいますし、状況が悪ければ訴訟沙汰もあるかもしれません。
期日を設定しないといつまでも出せないという意見もあるかもしれません（これは自分の経験的にマネジメント層からよく聞く理由です）。プロジェクトは様々な不確実性と向き合いながら少しずつ進めていきますが、様々な判断の自由度を持ち合わせていることも多く、本質からズレたところで過剰な作り込みが発生することもしばしばです。プロジェクトマネジメントをしている側から見れば、いつまでも出ないのにコストは掛かり続けるみたいな状況を味わうよりは、期日を指定してとにかくまずここまでに出すという区切りをつけたくなるのもわかります。しかし前述の通り、期日通り開発すること自体困難を極めます。この場合は適切な理由があれば期日を伸ばすことや、スコープ調整などに応じることはあると思いますが、その説明をするストレスは説明回数が増えるごとに大きくなります。
期日より、優先順位を決めろ！
ここまでで期日を設定しすぎることに対する難しさを考えてきました。さて、これに対抗する方法はあるのでしょうか。私が考える一つの方法として、この記事のタイトルにもあるように「期日ではなく優先順位を決める」というのを考えてみました。ここで言っている「優先順位」は紛れもなく「順位」であって同じレベルの優先順位は一切ありません。
ここで重要なのは、優先順位を決めて、並行で作業を行わず、十分に小さい範囲で使える機能や価値を定義することです。期日を先に決めてしまうと、その期日まで仕事を伸ばす可能性（これはパーキンソンの第一法則「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」とか言われていますね）がありますし、先程のような期日が迫っている複数の問題を少しでも進めるべく並行作業をしてしまうことでスイッチングコストに多大なリソースを払ってしまう可能性があります。小さいストーリーやタスクを短い間隔でリリースすることでそれぞれの作業の間に遅延させる原因の発生回数をへらすことができます。
そして先々の期日を決めることで発生してしまう柔軟な計画変更が難しくなる問題は、期日を指定しないことで逆に計画のための準備がかなり難しくなるので、結果的に計画変更を行うコストはそれほど発生しないでしょう。先々の期日を決めるメリットで述べたリソース準備の一つに「採用活動」というものもありますが、期日を決めていると頭数を揃えるみたいな採用活動を実施してしまったり、その活動のためにマネージャー層が本来プロジェクトをすすめるために使うリソースを割り当ててしまうという問題があります。しかし、期日を決めないことで現状のリソースで物事が進むことが前提となり、「本当に採用したい人」を採用するということが幾分しやすくなると思います。
期日を決めないことで今のリソースで実現した機能や価値の実績をベースとして物事を考えることになるので、それぞれの機能や価値を実現するのに必要なコストを計算しやすくなります。先にも述べましたが、特に人的リソースを投下してもその人材が期待どおりのリソースを出すにはそれなりに時間がかかりますし、期待どおり出ない可能性もあります。今の実績ベースでリソースを計算することは、追加で投入されたリソースで計算するより不確実性が低いですし、追加リソースは「ボーナス」として取り扱うこともしやすくなるはずです（もちろんボーナスを活かすためのリソース投入は一時的に発生してしまいますが…）。
インターバルを短くすることで更に良い点がありそうです。短い期間で自分たちの行動を振り返りやすくなります。振り返りをすることで自分たちの行動の細かい部分で「こうすればさらによかった」という改善案があれば、それを次のインターバルで改善するチャンスが来るかもしれません。次のインターバルじゃなくても、いつかまた発生するときに過去に立ち戻って何が起こったか、何をすればよかったかを振り返りをまとめておくことで不確実性を少なくすることができるかもしれません。
重要なのは機能や価値を出すことです。期日を守ることではありません。
計画がほしい？実績と予測を活用できるようにしよう
でもそれじゃまるでいきあたりばったりじゃないか、次の準備さえできなくていろんなタイミングを逃してしまうという人もいるかも知れません。そんな方にも有用なメトリクスがあります。代表的なのはバーンダウンチャートです。
最初に価値や機能を実現するための作業量の見積もりを行い、イテレーションの実績に従って残りの機能や価値の作業量を減らしていくことでその時々の予測日や実績の偏差を使った最悪・最良予測日を予測することができます。ただし、これはその時々の状況に従って更新されること、見積もりの見直しや途中の優先順位の入れ替えによってこの予測日は全く変わってしまう可能性があること、この予測日にコミットメントするわけでは無いことに注意する必要があります。あくまで、現状の情報と実績に基づいた予測で有ることには代わりありません。しかしこれがあるだけで、進捗の具合や、終わりそうなことなどの状況は幾分把握しやすくなると思います。何より、実績を伴った予測は、事前に予測した進捗状況よりも信頼性はまったく違うでしょう。進捗具合に問題があるときに検知もしやすくなります。
これじゃまだ不安が拭えない？その気持もわかります。であれば、実際になぜこれが不安なのか実際に試して見ませんか？もしかしたら実際に運用することでもっと良いメトリクスに出会えるかもしれません。バーンダウンチャートはその第一歩だと思っています。先にも述べましたが、短いインターバルで繰り返しこの図とにらめっこすることで自分たちの行動や先々の行動に対する振り返りと改善を実施できるようになるはずです。
おわりに
そもそもなんでこんな話を書いたかというと、私自身、過去いろんな会社などでプロジェクトを経験している中で、期日を遅らせてほしいという場面に遭遇することが多かったからです。自分から言うこともありましたし、誰かが言うことに対するアシストをすることも多かったのですが、あの空気感、とてもじゃないですけど苦しいですよね。そして何度も「あー期日がなければいいのになぁ」と思いつつ、裁判にかけられる気持ちでその場に望むわけです。そしてまた新たな期日を設定し、そしてまた遅れる…
しかし期日で苦しめられるのは現場の人間だけでないことを見たとき、自分だけ期日を設定しないというより、全体として期日を設定しないことでより機能や価値をブラッシュアップし、全員がハッピーにならないかというところから出発してひねり出したのがこの記事になります。稚拙な部分や詳しく書かれていない部分があると思いますが、何卒ご容赦くださりつつ、この内容にご興味がありましたら、より実践的に書かれている開発手法として「アジャイル開発」というジャンルがありますので、そのあたりの理論を見ていただけると大変うれしく思います。
余談ですが、この記事はfreee Tech Night出演前日までに出すぞ！という期日を設定しつつ、2週間前から筆をとりかいて、初稿が当日の01:39にできるというまさにパーキンソンの第一法則を再現しつつ書かれました。皆様に置かれましてはこれを反面教師にしつつ素敵な開発ライフをお過ごしいただけたらと思います。それでは。
参考文献
内容的に直接というわけではなく、この記事を書くにあたってインスピレーションを得たものも入っています。
- 人月の神話
- ワインバーグのシステム思考法
- エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング
- Clean Agile 基本に立ち戻れ
- アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
- エッセンシャル スクラム
- スクラム現場ガイド スクラムを始めてみたけどうまくいかない時に読む本
- アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～
- More Effective Agile “ソフトウェアリーダー”になるための28の道標
- ザ・ゴール
freee Tech Nightのご紹介
2022/02/04 19:00よりYouTube liveで開催されますオンラインイベント freee Tech Night 「期日じゃなくて優先度を決めろ！悩めるスクラムマスターの本音」では今回この記事で述べたことを含めたスクラムマスターの日々の悩みをご紹介しようと思います。皆様ぜひConnpassで参加登録の上ご視聴いただければ大変うれしいです！アフタートーク枠で参加登録いただけますと、Zoom上で直接やり取りもできますので、率直なフィードバックもいただけるとうれしいです！
