コンサルティング事業 2021.01.26

“ちょうどよい”スケジュールバッファをとるために気を付けていること

こんにちは、コンサルティング事業部の米丸です。

■そのプロジェクト、バッファとりすぎてません?

※ここでのバッファとは、プロジェクトにおける納期に対して緩衝材となる、スケジュールの余白のことをさします。

WEB開発プロジェクトにおいて、スケジュールにバッファを用意するのは、納期遅れを避けるための常套手段となっています。前回の見積もりのブログで書いた通り、開発の工数見積もりには必ず幅があり、事前に正確な開発完了時期を定めることが難しいため、一定のバッファを設けることが有効になります。

一方で、バッファは諸刃の剣でもあります。当たり前ですが、バッファを入れすぎるとリリースも遅れることになります。変化の早い現代でプロダクトの市場投入を遅らせることは、ビジネスの機会損失を生むことと同義です。

つまり、プロジェクトには以下の二律背反する要求があるといえます。

・納期を確実に守るため、十分にバッファをいれた余裕のあるスケジュールにしたい
・機会を最大限活かすため、バッファを削ってできるだけ早くプロダクトをリリースしたい

前者は開発サイド、後者は運用サイドからの要求です。どちらも正しい要求のため、バランスを見て全体最適化されるべきですが、特に運用と開発が分断された組織では、バランスをとるのが難しいです。バッファが足りずタイトなスケジュールになってしまったり、過剰にバッファが入ったビジネス価値を下げるスケジュールになってしまったり。うーん、この。。

ここで冒頭の「バッファとりすぎてませんか?」という問題提起です。いや、上で書いた通りバッファはプロジェクトにおいて必要なもので、何も無理をしてバッファを削れと言いたいわけではありません。むしろ、バッファが適切に取れず、かつかつなプロジェクトのほうが世の中には多いだろうと思います。

ただ、そもそもどれくらいのバッファが適切かを明確な根拠のもと算出することは難しく、曖昧なものです。そして開発サイドの心理では、多めにバッファを置きたくなるものなので、条件が揃えば不必要なバッファが取られることも、無くはないのかなと。

ここで問題だと思うのはバッファを取りすぎたことには気づきにくいということです。バッファが少なすぎる場合は、炎上を招き問題が可視化されるので、適正化される力が働きます。一方で、バッファを取りすぎても、プロジェクトは期限通り完了し目に見えた問題にならないので、最適化に向かう力が発生しにくい。あるいは余裕すぎるスケジュールがエンジニアのパフォーマンスを下げる要因になり、バッファが人知れず食い潰されていて、一見するとちょうどよいバッファに見える、ということもあります。

どうでしょうか?世の中には「バッファをちゃんと取らなきゃ!」という論調の記事が多いなーと感じたので、あえての問題提起でした。

さて、「えらそうに!じゃああんたはうまくできているのか?」と思われるかもしれません。いや、私自身、ちょうどよいバッファをとれているかというとそんなことはありません。バッファが足りず、炎上しかけることが多々ありましたし、今も、「バッファたくさん入れて余裕をもたせたい!けどリリースそんなに遅らせられない。。」という二律背反する要求に挟まれて、試行錯誤する日々です。いや難しいっしょこれ。。

以降は私個人が、バッファを最大限活かすために気をつけていること、取り入れている技を、ご紹介します。誰かのなにかの参考になれば、幸いです。

■バッファはタスクから切り離す

バッファを以下のように、タスクごとのスケジュール内に含めていないでしょうか?

バッファはタスク内に含めず切り離し、バッファはバッファとして管理すべきと言われています。その理由は「学生症候群」「パーキンソンの法則」という人間の2つの心理的傾向にあります。

●学生症候群

エンジニアにバッファを含めた長めのスケジュールを提示してしまうと、「まだ時間に余裕がある」という気持ちのゆるみが生じやすくなります。それにより、前半はエンジンがかからず、締め切り間近になってやっと本気を出すため、バッファを含めていたはずなのに結局スケジュール通りに進行しなくなるということが起こってしまいます。これを学生症候群といい、学生の宿題でよく起こることなのでそう名付けられたそうです。(みなさんも、夏休みの宿題で体験した人は結構多いのではないでしょうか?)

●パーキンソンの法則

上記の学生症候群にはかからず、スケジュール開始線から全力で構築を始めた場合は、本来は余裕をもって構築が完了するはずです。しかし、エンジニアは往々にして、完成が近づいてきたところで、自分が納得のいくプログラミングをしようと細かいところを微調整するようになります。「もっとシンプルに書きたい」「ここのコメントわかりづらいな」「他のエンジニアに見られてもいいように通っぽい変数の名前にしないと」などなど。細かい調整に時間をかけて、結局バッファを含めたスケジュールを使いきってしまうといいうことが起こりがちです。これをパーキンソンの法則といいます。

バッファが食いつぶされないよう、個別のタスクにはバッファを含めない現実的なスケジュールを提示するのが良いといわれています。

■バッファはプロジェクトの最後方にまとめる

タスクから切り出したバッファはどこにどう入れるべきでしょうか。一つは「プロジェクトバッファ」という方法があります。

●プロジェクトバッファ

各タスクのバッファを合計した、プロジェクトの最後に置くバッファのことです。

各タスクは、バッファを除いた現実的なスケジュールを引いておきます。各タスクで遅れが発生した場合は、最後に切り出したバッファから少しずつ消費していくようにします。このバッファの消費具合をはかることで、プロジェクトのスケジュールを管理するのが、プロジェクトバッファの考え方です。例えば「今、全体の半分の機能が開発できたのに対して、プロジェクトバッファを60%使ってしまっているので、やや進捗が遅れている」といった具合です。

■クリティカルパスの死守にも使う

クリティカルパスを守るための合流バッファというものがあります。

●クリティカルパス

「機能Aができてからでないと機能Bが開発できない」ような関係性がある場合に、従属関係にあるといいます。この作業工程上の従属関係を考慮したときに、最も時間がかかる機能の線が、プロジェクトには必ず存在します。他の機能がどれだけ早く開発ができても、このクリティカルパスの機能が遅れてしまうと、プロジェクト全体が遅れることになります。そのため、プロジェクトの進捗管理では、特にこのクリティカルパスの状況をつかむことが大事です。

●合流バッファ

クリティカルパスを死守するため、クリティカルパス内の機能と従属関係にあるクリティカルパス外の機能は、極力早めに開発ができると安心です。そういった場合に、可能であれば、合流バッファとして、余白を持たせるようにします。例えば、商品検索と商品購入の機能がクリティカルパスとなっている場合を考えます。この時、クリティカルパスではないものの、商品購入には会員登録機能も先に開発が必要だとします。会員登録の構築完了が商品購入の構築開始のぎりぎりにできる予定を組んでしまうと、少し遅れるだけでクリティカルパスを遅らせることになります。会員登録の構築開始を早め、会員登録と商品購入の間にバッファを設けよう、というのが合流バッファの考え方です。

■リソースの競合はシンプルに考える

同じリソースを使う複数のタスクがあった場合に、片方がクリティカルパスの機能であれば、他機能の遅れでクリティカルパスも遅れることはないようにしたいです。「この人でなければこの機能は開発できない」といったリソースの制約がある場合は、リソースを考慮したバッファを置くようにします。(これをリソースバッファと呼びます)

・・・ただ、作業工程の従属関係とリソースの競合の両方を考慮するのはかなり複雑で難易度が高いと思います。私が行っている工夫として、クリティカルパスを担当する人は極力同じ人になるようにアサインします。そうすることで、リソースの競合を考慮しなくてすむようにします。シンプルイズベスト!

■終わりに

・どれくらいバッファをとるべきか、など、プロジェクトの曖昧なところを、他者にも説明できるように根拠を持つことが大事だと思っています。ただ、今回言語化してみると、自分でも曖昧にやっている点があることに気づかれます。。というか、言語化自体がむずい。バッファムズイ。

●参考図書

この記事をシェアする
事業について詳しく知る

コンサルティング事業について詳しく知りたい方はこちら

コンサルティング事業部SDPグループマネージャーエンジニア

RECOMMEND

おすすめ記事