Zenn
🤔

不安とストレスから解放される見積りとスケジュール方法

2020/09/24に公開
プロジェクト
idea

はじめに

何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。

仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを考えてしまうので「不安」に満ちたものになりがちです。

また、不安なものに取り組むというのは大きなエネルギーが必要です。試験勉強をしている時などに、部屋の掃除をしたくなってしまって、気が付いたら時間がなくなっていたという経験を多くの人が体験したことがあるのではないでしょうか。人は、不安なものを直視することを無意識に避けてしまうクセがあるのです。

本稿では、プロジェクトにおける不安とはなんだろうか？を考え、できる限り不安を最小化させるということを主眼に置いたスケジュール立ての方法を考えていきます。

楽観的すぎる見積り、悲観的すぎる見積り

よくベンチャー企業などで企業へのコミットが高く、モチベーションも高いエンジニアを抱えているのに、「納期どおりに機能が完成しない」というような相談を受けることがあります。決して彼らの能力が低いわけでも、怠けているわけでもなさそうです。それは一つは見積りを楽観的に摂り過ぎてしまっているという点にあります。

また、SI出身のメンバーが見積りを過度に長くとってしまうといった話も良く耳にします。高い職業意識を持ち、技術力も低いわけではない。彼らは、なぜ悲観的に見積りをとってしまうんでしょうか。

前者は、ありあまるコミット意識があるため、見積りを短く設定し、それを努力目標としてしまうところがあるようです。後者は、納期に間に合わせることを最重要な職掌上のミッションとして捉えてしまい、見積りを長く保守的に取ることが多いようです。

そんな時に私が、経営者やプロジェクトの担当者に話すことは、「納期のズレが収束していくことを互いの目的に設定するのが良い」ということがあります。

これがまさに「不安」を中心にプロジェクトを捉えていくことでもあります。

不確実性コーン

不確実性コーンという言葉を聞いたことがあるでしょうか。以下にあるように、プロジェクトのスケジュールが、進捗するにつれて工数のブレが収束しながら、完了していく様子をグラフで捉えたものです。

Kobito.JYKKE7.png

引用：http://itpro.nikkeibp.co.jp/article/COLUMN/20131001/508039/

実際には、様々な要因によって綺麗なコーン状にはならないでしょうが、プロジェクト最初期であるほど不確実な要素が多く、徐々に低くなっていくといった変化を見せるということを示しています。

ソフトウェア開発は、それ自体が知的な創造性を要求することなので、「わからない」「やったことのない」ことに取り組むことも多い種類のプロジェクトです。

一方で、ソフトウェア開発の現場では、開発計画よりも上位の経営計画によって、日限が定められていることが多いです。これは、ビジネス上の要請があればある程度は仕方ないことです。

ですが、「もし、開発計画がNヶ月遅れることが、Mヶ月前にわかっていたら、なんらか対処はできますか？」と経営者やプロジェクト担当者に聞くと、おおよその場合答えは「YES」であったりします。

この場合の対処とはたとえば、プレスリリースを延期したり、関係者と調整したり、機能を減らしたり、人員を増員したりなどです。

これが意味するところは、不確実性の共有と早期対処が、プロジェクトを円滑に進め、かつビジネス目標を達成するために重要なことだということです。

不安と不確実性

プロジェクトにおいて、不安とは２つのタイミングで発生します。一つは、不確実性が、見えない時。もう一つは、見えない不確実性を見える化する作業に取り組む時です。

不確実性が見えないまま、プロジェクトを進めていくとき、人は確実なものから対処しがちです。その結果、見えない不確実性を心に秘めたまま日々を過ごすことになります。これは、じわじわと真綿で首を絞められるようにストレスを人々に与えていきます。

また、その不確実性を見える化しようと取り組むときにも高いハードルが存在します。人はできる限り不安を直視したくないからです。

この見えない不確実性に光を当てていくのが、プロジェクトリーダーやスクラムマスターの仕事だと言えます。

たとえば、デイリースクラムでは「その日にやるタスク」を宣言することで、メンバーは未来について思案することなく、その日に集中できます。

たとえば、バックロググルーミングやスプリント計画では、一人ではハードルを越えにくい「未来」についてメンバー全員で可視化を行うことができます。

また、それ以外にも様々な場面で発生する不確実性を明らかにし、減らしていくことでメンバーのストレス源を減らしていくことができます。

逆にこれができないと、スクラムなどのアジャイルプロセスを採用していても、ただ単に「１スプリントごとに納期があるプロジェクト」になってしまい、プラクティス自体がストレッサーに変わってしまいます。

時間とフィーチャーの境界線

Kobito.2POg2e.png

よくあるプロジェクトは、二つに類型化されます。一つは、「時間境界型プロジェクト」です。これは、ある一定の期日に達したら、リリースするといった類のプロジェクトです。もう一つが、「機能境界型プロジェクト」です。これは、ある一定の機能を実現したらリリースするという類のプロジェクトです。

実際には、時間境界型プロジェクトには、「スケジュールバッファ」が設定されていたり、機能境界型のプロジェクトには、「フィーチャバッファ」が設定されていたりします。

スケジュールバッファは、本当は10ヶ月後にリリースしたいが、完成予定を9ヶ月後に設定し、残り一ヶ月をバッファとして用意するようなものです。

フィーチャバッファは、各機能が優先順位でソートされているとして、本来はほしい機能と必要最低限の機能を分け、必要最低限の機能があれば、リリースできるとするものです。

Kobito.FNX0Ig.png

これらを重ね合わせてフィーチャバッファとスケジュールバッファをどちらも用意する場合があります。この場合は、それぞれが重なるポイントであればどの時点でもリリースできると考えます。

Kobito.1awsP6.png

フィーチャバッファは、「市場が最大の不確実性」という前提に立ったときに効力を発揮します。リリースするまで反応がわからないのだから、最小限の機能をリリースして不確実性を減らしていこうという考え方に基づいています。

スケジュールバッファは、「いつリリースできるのかが最大の不確実性」という前提に立ったときに効力を発揮します。リリース日が遅れた場合の機会損失や実契約上の損失などが重要で、スケジュールの不確実性を減らしていこうという考え方に基づいています。

現実のプロジェクトは、この両者が密接に絡み合っていることが多いです。それはマーケティング上の理由やビジネスパートナーとの関連などによって、市場での評価の成否が決まってしまう場合もあるからです。ですので、プロジェクトの性質しだいで、どの程度のフィーチャバッファを用意し、どの程度のスケジュールバッファを設けるのかということのコンセンサスが重要になります。

いずれにせよ、これらのバッファはプロジェクトが進むにつれて、小さくなっていくことが望ましいです。これによって不確実性が徐々に減っていき、それに伴って不安の量も減っていくからです。

不安の定量化

「スケジュールバッファ」を例に不安つまり不確実性の量を定量化していく方法を考えてみましょう。

そのために2乗和平方根法（SRSS法:Square Root Sum of Squares）という手法を用いてみます。

これは、それぞれのタスクに対して「平均」かかると見積もったストーリーポイント（時間でも良い）と「最悪の場合」にかかると見積もったストーリーポイントを洗い出します。

それぞれの差の和を計算し、平方根を取ってサンプル数の２で割れば標準偏差になります。それに２をかけたものは2σとなり、その区間でおわる確率が95%以上だと見なせる領域になります。

Kobito.LooAMT.png

このプロジェクトの場合、スケジュールバッファは「14.6」なので、1ストーリーポイントが１人日だった場合、15人日のバッファを取っておけば、ほぼ期間内に終わるだろうことを意味しています。

では、この計算をもとに不安量を最小化していくためにはどのような計画を立てたら良いでしょうか。そのためにはバッファ期間がプロジェクトが進むにつれて、短くなっていくように考える必要があります。

これには、不安量(max-ave)^2が大きい順番にタスクを完了させていくのがもっとも効率的です。

ここで、100個のランダムなタスクを例に

  • ランダムにタスクを完了させた場合
  • 不安量=(max-ave)^2が大きい順にタスクを完了させた場合

のスケジュールバッファの変化をグラフにしてみてみましょう。
Kobito.Ckhnmk.png

* タスクは正規分布
* 最悪値は、最大２倍の一様ランダム値

このように、不安量の高いものから対処することで、効率的にスケジュールバッファを小さくしていくことができます。プロジェクトの中盤にはすでにスケジュール不確実性が当初の1/4程度まで下がっていることがわかります。ランダムな順序でのタスク消化では、3/4以上の不確実性が残っています。

実際のプロジェクトでは、スケジュールの不確実性とフィーチャーの有効性を天秤にかけ、ビジネスニーズに適合していくことが重要ですが、このようにスケジュールの不確実性を元に優先順位付けをすることで、早期にスケジュールバッファを小さくしていくことができます。

スケジュール不安の大きいプロジェクトでは、このような方法も有効なアプローチです。

ストーリー分解による不安量の低下

では、タスクの順序だけが不安量を減らす方法でしょうか。もちろん違います。不安量が大きく、かつタスクのストーリーポイントも高いものは：

  • 使ったことのないミドルウェアの使用
  • うまくいくかわからないアルゴリズムの使用
  • 外部との連携
  • 詳細仕様が未決定

など、「不確実性」の元となる発生源が存在することが多いです。これを確実にしていくにはどのようにしたらよいかを別のタスクやストーリーに切り出すことで、ストーリーポイントの小さく不安量の小さいタスクに分解することができます。

これがある程度プロジェクト開始前にわかっている場合は、スプリントゼロなどを計画し、PoC( Proof Of Concept )のコードを書いてみたり、詳細仕様を詰めるなどの対応ができます。

また、プロジェクト中であっても、不安量の大きいタスクが生まれたらスクラムマスターやメンバー間で、どのように不安量を減らすことができるのかを話し合うことができます。

不確実性の取り除き

また、フィーチャバッファとの兼ね合いで、不確実性の高いタスクをあらかじめ取り除くこともできます。期待される効果が薄く、かつ不確実性の高いタスクは、プロジェクトにとってあまり取りたいリスクではないかもしれません。スケジュールの不確実性の可視化によって、こういったタスクをリリースプランからあらかじめ取り除くこともできます。

まとめ

プロジェクトには、不確実性がつきものです。これにはフィーチャバッファとスケジュールバッファを持つことで対処ができます。これらのバッファをプロジェクト進捗とともに収束させ、減らしていくことで「不確実性」が引き起こす「不安」や「ストレス」を取り除くことができます。

アジャイルな開発プラクティスにおいて、フィーチャバッファを中心とした計画が多く紹介されるため、誤解されがちですが、スケジュールセンシティブなプロジェクトであっても、問題なく扱うことができます。

スクラムマスターやプロジェクトディレクターは、不安のもととなる「不確実性」を効率的に取り除くことがその仕事をうまく進めるポイントです。

また、それによってプロダクトオーナーは、柔軟な二つのバッファ設計をビジネスの環境に合わせて選択することができるようになります。

この記事が皆さんのプロジェクトがストレスフリーになることへの一助になれば幸いです。

Discussion