プロジェクトに正しくセーフティ（保険）を乗せるための考え方

プロジェクトの開始時に余裕をもったスケジュールをたてたのにも関わらず、 気づけばいつも崖っぷち、もしくはもう崖から落ちてしまっているといった経験はプロジェクトに関わる人ならよく見かける光景だと思います。せっかく顧客やプロダクトオーナーなどのステークホルダーに対して、プロジェクト開始時にあれやこれやと根拠付けをして少し罪悪感を感じるほど甘く見積もっているならば、プロジェクト後半や終了後に大いに顰蹙を買うでしょう。

この記事ではその余裕（"セーフティ"と呼称します。）がどうしてことごとく神かくしにあってしまうのか、計画時に潜む原因のひとつである「タスク単位でセーフティを乗せてしまう問題」の紹介と、その解決策のひとつである セーフティプール を用いる方法について述べています。

リスクを担保する手段としてのセーフティ

ソフトウェア開発に関わらず、プロジェクトをはじめるにあたって（アジャイルであろうとウォーターフォールであろうと）それがビジネスである限り計画づくりは必要なプロセスです。 計画づくりにあたっては、対応アイテムをタスクに分解し "工数見積もり" をすることになります。

さて、この "工数見積もり" ですが、どんなに優秀な人物であっても将来掛かるであろう工数を完璧に読み切ることはできません。 みなさんが毎朝会社に出勤するとき、会社までの道のりは毎朝同じなのにも関わらず、到着する時間が一定でないように、どんなに自分が気をつけていても、他の通行人がみなさんの通行を邪魔しないとは保証されていませんし、信号が奇跡的に毎日青信号であることはまずありませんし、みなさん自身の体調が常に整っているとも限らないからです。 それらは殊更ソフトウェア開発プロジェクトに関わっている方であれば言うまでもないことであり、どのような形であれ身を持って（しばしば痛い思いをしながら）経験されています。

さて、このような経験をされてきた開発者は、冒頭の "工数見積もり" をプロジェクトマネージャー（以下PM）から指示されたときにどのような検討をするでしょうか。 ここでよく見られるのは、分解されたタスク単位で数%のセーフティ、つまり本来必要と思われる工数に対して 何かあったときのための保険 を乗せることです。

図1：セーフティとは

セーフティは、リスクを担保するためのひとつの方法として有効です。 もし想定されていたリスクが発生しなかった場合は、その分ほかのことをやればいいだけですので、ここに問題はありません。 「保険」のためですから、リスクが発生しない場合でほかにやることがない場合は「あわよくば」前倒しで進めることができます。これはプロジェクトにとって大変嬉しいことです。

神かくしにあうセーフティ

しかし、このセーフティの乗せ方を間違えると、その「あわよくば」はほとんどの場合訪れることはありません。 現実、プロジェクトをはじめてみると、残念ながらタスクが前倒しで終わったという『報告』が来ることはほとんどありません。 それどころか気づいたときには、あったはずのセーフティがことごとく消えてしまっています。 そもそもセーフティは「保険」なのですから、それがことごとく無くなっているようであればそれは見積もりがまずかったということです。 しかしなぜセーフティが神かくしにあったかのように、ことごとくいつのまにか消えてしまうのでしょうか。

ここで「セーフティが足りなかったのではないか」という仮説をたてることができます。 もちろんリスクの見積もりが甘かったということであればそのようなケースはありえますので、検討の余地は常にあると言えます。 ただあまりこの仮説だけに偏って考えすぎると、セーフティにセーフティを重ね続けて しまうことになり、「見積もりの雪だるま式的な肥大化」を招いてしまいます。 このことはプロジェクトにかかるコスト増大、もしくは製品品質の低下を簡単に招いてしまうため注意が必要です。

しかし実は、タスクの前倒しは必ずプロジェクトのどこかで起こっています。 「何かあったときのための保険」なのですから、ほとんどの場合保険を使わないで良いはずですし、異なるタスクを実施しているといっても同じソフトウェアの開発をしているのですから関連性があります。 そのため、プロジェクトが進むにつれて生産性は上がり、前倒しが起きて当然なのです。 （往々にして見積もり時にはプロジェクト進行による生産性向上は想定されていません。）

問題は、タスクが前倒しで終わった、または終わりそうなとき、そのことが『報告』されないことです。 とはいえ、ここでは報連相の重要性をお伝えしたいわけではありません。 当初見積もっていた工数に対して、前倒しで終わったことを報告した場合に起こることを想像すると、その理由は明快です。

頑張ってはやめにタスクが完了した場合、せっかく頑張って浮かせた時間ですので、自学の時間に充てたり、ネットサーフィンをしたり、また優秀なメンバーであるほど複数プロジェクトを掛け持ちしていますので、別プロジェクトのタスクの対応をはじめて自分をさらに楽にさせようとします。 しかし予定より早く終わったことを報告してしまうと、ほとんどの場合そのあとに対応する予定だったタスクを前倒しで対応開始するよう指示されるか、遅れが出ている他メンバーのタスク肩代わりを指示される可能性があります。 つまり、早く終わったことをを報告しても、プロジェクトにとって利益はあれど、個人にとっては対応する必要のなかった仕事が増える可能性が高くなるため、多くの場合報告されることはありません。 これがセーフティが保険であるにも関わらず、ことごとく神かくしにあってしまう理由です。

図2：セーフティがなくなる理由

セーフティはプロジェクト単位やイテレーション単位で乗せる

それではセーフティを乗せることが悪なのでしょうか。

冒頭にもあるとおり、見積もり担当者がいくら優秀であっても完璧な見積もりを常に出し続けることはできません。 その要因として最も大きいのは、ソフトウェア開発のプロジェクトと、モノの生産ラインで最も異なる部分である、ソフトウェア開発ではまったく同じ成果物を繰り返し生産することが基本的にありえないことです。 そのため、ソフトウェア開発プロジェクトでは常に新しいことにチャレンジすることになりますので、当然そこには不測の事態、リスクが多めにつきまといます。

そのリスクを担保するためにセーフティを乗せることは悪ではありません。 むしろどんなタスクであってもセーフティを乗せようとしない人は、単純に見ればストイックでプロフェッショナルな人に見えるかもしれませんが、相当腕ききで経験豊富でない限りは限りなく適切に近いセーフティを乗せたほうがみんなにとって賢明に思えます。

問題なのは、セーフティをタスク単位でタスクに対してそれぞれ乗せてスケジュールを計画してしまうことです。 タスク単位で見積もってしまうからこそ、図2で示したように、合法的にセーフティを使いきってしまうのです。 1つや2つであれば大した問題ではありませんが、プロジェクトの規模が大きくなればなるほど複数箇所でセーフティの浪費が起き、 結果的にコストの増大やスケジュールの遅延、品質の低下につながってしまいます。

ではどう乗せればよいのかと言うと、一つの解決策として、 「セーフティをプロジェクト単位、または イテレーション の単位で乗せる」ことを推奨しています。 私はこのとき乗せたセーフティの集合を セーフティプール と個人的に呼称しています。

図3：セーフティプール

このようにすると、各タスクの担当者はそのタスクにかける工数をセーフティなしの工数を見て動きます。 つまりセーフティプールにてリスクは担保しつつもそのタスクに対してそれぞれセーフティが割り当てられていないため、セーフティを見てペース配分したり報告をあえて行わないなどの問題は起きにくく、完了の報告がより適切に届きやすくなります。 また、セーフティプールは原則プロジェクトチームの共有物になりますので、あまり消化してしまうとチーム全体に影響が及びます。そのため、コミットしたターゲットを守るということに対して、良い塩梅の緊張感を生むことにも繋がります。

セーフティはリスクに対して見積もる

次に課題となるのはセーフティの見積もりです。 私はセーフティは事前に洗いだしたリスク要因に対して見積もられるべきだと考えています。 私は現在チームに対して、プロジェクト開始時に「プロジェクトキックオフミーティング」を開催し、必ずメンバー全員が出席のもとアイテム/タスクに対してリスクの洗い出しをするように指示しています。 これはスクラム開発でいうインセプションデッキというフレームワークにて用いられる「夜も眠れなくなるような問題は？」いうセッションです。 ( 参考：インセプションデッキ | ネスケラボ )

リスクの例

• このタスクでは初めて使用するライブラリを用いる可能性があるため心配。
• このタスクではまだ技術的調査が必要なため、現時点では厳密な見積もりができない。
• ビルド完了しても、App Store の審査が通るかどうか懸念がある。

上記のような洗い出されたリスクに対して、どの程度のセーフティを見積もるべきなのかをチームで協議し、合意のもとセーフティプールに追加します。 しかし、リスクは解決方法が判明していないからリスクであるため、ある程度見積もりのファニーさは許容する必要があります。 （その精度を上げていくためには見積もりスキルの向上が必要ですが、この記事では言及はしません。）

最後は文化的アプローチ

この記事では、セーフティを適切にとることによって、プロジェクトを健康に遂行するための方法を提案させて頂きました。 この方法はあくまでもセーフティに対してのアプローチであるため、タスクがセーフティを除いた見積もり工数より前倒しで終わった場合、それが適切に報告されることを促進されるわけではありません。

私は正直、メンバーが努力なり工夫するなりして早く終わったのなら、浮いた時間は自由に使ってくれればいいと思っています。 ただ一方でもし後ろにより大きなリスクを抱えているようであればできるだけ前倒しすべきです。

そこで結局効果があるのはアジャイル開発でレフトウィングと言われる、朝会や日報などの「文化的アプローチ」です。 いわゆる鬼詰めする必要はありませんし常に疑ってかかる必要はありませんが、毎日定期的に報告の場を設け、可能な限り具体的な報告をして貰うようチームに促し、前倒ししたい場合は前倒ししたい理由をしっかりと共有しさえしていれば、メンバーはどういう形であれプロジェクトの成功を願っているわけですから、前向きに協力してくれるはずです。

逆に言えば結局どれだけ計画づくりを論理的にしても、ここを逃げてしまうとチームのていをなすことはないでしょう。

参考書籍

この記事を書くにあたって、エリヤフ ゴールドラット著の クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか? を参考にしています。 キーワードである「セーフティ」はこの本で用いられている用語です。

いわゆる「制約条件の理論(TOC理論)」と「クリティカルチェーンマネジメント」について物語調で学ぶことができますので、 プロジェクトマネジメントに興味のある方はぜひ一読をおすすめします。

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?