0. これはなに
こんにちは。レバテック開発部のもりたです。
じつはこの一年ほど、あるプロジェクトの開発側リーダーをしていたんですが、スケジュールを大きく遅延させてしまいました（2週間で終わる予定が1年を超えた）。
スケジュール遅延、嫌ですよねえ...。その嫌な気持ちをいったん傍に置いて、遅延が起きる要因を分解してみると、遅延要因は「もともと必要な工期を過小に見積もった」ことと「失敗で不必要に工期をかけてしまった」ことのふたつに分けられると思います。
特に前者の過小見積もりは場合によってはとんでもなく見当違いな見積もりを出してしまいがちです。今回はもりたの実体験をもとに、工期を過小に見積もるケースについてパターンをまとめていきたいと思います。
構成と記事のスコープ
構成と記事のスコープ
構成
以下のような流れで説明します。
- どんなプロジェクトだったか
- 工期遅延の基本的な考え方
- 要因
- 対策
- おわりに
最初にプロジェクトの解説をし、続いて工期が遅延するとはどういうことなのか整理します。
その後遅延要因と対策をご紹介する流れです。
スコープ
今回はスケジュール遅延要因のうち、「もともと軽く見積りすぎたケース」に絞って扱います。
なぜこれを選ぶのかというと、それはひとえに今回のプロジェクトでこの点が欠けていて大変苦しんだから。後述しますが、見積もりが過小なケースはそもそも必要な工程や関係するステークホルダーが抜けていて発生することがあり、工期が容易に2倍3倍となっていきます。
皆さんにはそんな経験をしてほしくないなという気持ちでまとめていきますので、お付き合いいただければ幸いです。
1. どんなPRJだったか
最初に今回取り組んだプロジェクトがどんなプロジェクトだったのか説明します。
今回取り組んだのは上記のようなプロジェクトです。当初は2週間くらいで終わりますよねーと事業サイドと会話していましたが、あれよあれよとスケジュールが遅延して、あっという間に一年が経ちました。
2. 工期遅延の基本的な考え方
というわけで、工期を過小に見積もる要因と対策についてまとめたいのですが、最初に遅延要因の概観を掴んでおきましょう。
工期遅延を考えるとき、問題点を「作業量」と「リソース」のふたつのパラメータに分解することが可能です。作業量が上振れたり、リソースが下振れると[1]工期遅延が発生します。
これを踏まえて、遅延要因を3つに分類しました。
「人が増えても早くならない」については一旦忘れてください
では遅延要因と対策を見ていきましょう。
3. 遅延要因のパターン
①必要な工程をまるっと見逃す
最初に挙げるのは「必要な工程をまるっと見逃す」です。これは作業量が上振れしたパターンのひとつで、そもそも想定していない作業が必要になるようなケースです。
今回のプロジェクトでは以下のような出来事がありました。
上流の工程を見逃した
まず、業務アセスメントから要件定義の工程を見逃しました。
今回のプロジェクトは前任者がおり、前任者から今回の要件を簡単に伝えられていました。プロジェクト着手時はその要件をもとに、あらためて依頼者とすり合わせをして進めればよいだけだと考えていました。
しかし、実際にプロジェクトを進めていくと、思わぬ業務影響が発覚し、さらに影響の出た業務に関する資料や知っている人もおらず、業務アセスメントの工程からやり直すことになりました。
ここのような事態を呼び込んだのにはいくつか理由があります。
- 対象システムが長らく塩漬けされており、対象業務に関する資料や知識のあるメンバーが存在しなかった
- 業務影響に対する感度もひくく、どの業務に影響があるのか、業務影響があった場合プロジェクトにどの程度影響がでるのか考えなかった
- 自分たちのシステムがどの業務に関係するのか考えていなかった
疎通テスト工程を見逃した
次に見逃したのは疎通テストです。
今回、機能修正するにあたり、Queuingサービスを導入しています。そういった新しいコンポーネントがシステムに導入される場合、それらコンポーネントが疎通できるか？ というレベルでの確認フェーズを用意してあげると安心です。
今回はそこを意識しなかったため、2週間近くテストに入れず、つなぎ込みの確認に追われました。
②工程はあったが工期が短すぎた
次に、「工程はあったが工期が短すぎた」パターンをご紹介します。こちらも作業量が上振れしたケースなのですが、工程を知った上で上振れしたケースです。
「初めて」の作業
工数の上振れはプロジェクトのすべての工程で発生しました。それらに共通する要素を見ていくと「初めて」やったことだったから、というのが目立ちました。
例えば以下の通りです。
- 初めての業務ドメインで要件定義
- →業務ドメインが初めての領域だったため、土地勘がつかめずに要件定義が思ったより進捗しない
- 初めての業務ドメインで開発実装
- →業務ドメインが初めての領域だったため、本来その業務ドメインを管理する他開発チームとの連携がうまく取れずに作業量が肥大化
- →さらに技術要件が発生し、次の「初めて」につながる
- 初めての技術要素を使った開発実装
- →初めての技術要素を取り入れたため、設計実装に時間がかかり、バグも多かった
- 初めての連携機構の利用
- →新規に連携機構を作成したため、テスト工程やリリースで時間がかかった
このように、「初めて」やることは見積もりがくるいがちです。今回のプロジェクトでも「初めて」要素の少ないプロジェクト終盤ではスケジュール遅延は発生しなくなりました。
③工程は認識していたがそもそも取り掛れなかった
最後に「工程は認識していたがそもそも取り掛れなかった」パターンです。これはリソースが下振れしたケースです。
リソースの問題って開発業務のなかでもちょっと泥臭いというかツラミの出やすい箇所なのでちょっと奥歯にものの挟まったような記述多めです。
リソースを確保できず着手できない
まず今回のプロジェクトは着手予定から一ヶ月ほど作業ができませんでした。
プロジェクト担当者としてアサインされつつも開発チーム内ではもっと優先度が高いタスクがあり、そのタスクがアサインされる、ということがありました。
他PRJとぶつかる
次に、開発部全体で取り組む重要度の高いプロジェクトが本プロジェクトの中盤にぶつかり、2ヶ月半作業がストップしました。
カレンダーを読み間違える
間抜けな過ちなんですが、カレンダーを読み間違えて作業できない日に作業予定を入れてしまうことがありました。
たとえば長期休暇であることを忘れて作業予定を入れてしまったり、祝祭日の見逃し、社内イベントとぶつけてしまうなどをやりました。
4. 遅延要因パターンに対する対策
ここまでがスケジュール遅延を引き起こす要因です。
続いて、そんな遅延を起こさないための予防策を考えていきましょう。
「①必要な工程をまるっと見逃す」への対策
工程を知る
必要な工程を見逃さないための第一歩は知識を持つことです。
たとえば『だまし絵を描かないための要件定義のセオリー』という上流工程に関する書籍を読んでみると、業務改善系のプロジェクトには「システム化企画、業務分析（アセスメント）、要求定義、要件定義...」みたいな工程があると書かれています。まずはその存在を認識することです。
工程を知っていても出来ない
では工程さえ知っていれば、工程を履行できるのでしょうか。おそらく、知っているだけではできないでしょう。
実際、わたしはそれらの工程を知った上で不要と判断して工程を抜かしました。具体的には、要件らしきものは最初に提示されており、要件は整理済みとして要件定義工程を簡易に済ませてしまいました。しかしのちに想定していない業務影響が判明し、アセスメント/要件定義からやり直しています。
なぜそのようなことが起きるのでしょう？ 答えは「潜在的なステークホルダーからの要件は定義しようがない」からではないかと思います。潜在的なステークホルダーを知るための作業が必要です。
ドメイン/ステークホルダーから整理する
潜在的なステークホルダーを知るためには、そのプロジェクトで取り扱うドメイン領域に目を向けることが大切です。それまでチームが扱ってきたドメインに手を入れるのであれば、だいたいのステークホルダーは分かっているでしょう。関係しそうなステークホルダーを列挙し、それぞれの観点でプロジェクトを見直してみることで、想定できていなかった影響範囲を考えることができます。
もし初めてのドメイン領域であれば業務自体を知るためのアセスメントが必要です。アセスメントを通してステークホルダーを洗い出し、プロジェクトとの関わり方を定義します。
また、他開発チームの資産に手を入れる場合、多くは初めてのドメイン領域であるでしょうから業務アセスメントが必要になりますし、その開発チーム自体がステークホルダーになりえます。
「②工程はあったが工期が短すぎた」への対策
小さく始める
要因の章で工期が短すぎるパターンでは「初めて」が多いと説明しました。
何事にも初めてはありまして、避けることはできません。しかし調査フェーズを入れたり段階的に取り組んだりするなど、小さく始めて見積もりの精度を上げていくことは可能なはずです。
このようにプロジェクトを進める中で少しずつ不確実性を削っていけるとプロジェクトは成功しやすいのかなと考えています。
「③工程は認識していたがそもそも取り掛れなかった」への対策
リソースをとりにいく
リソース問題って、はじめてぶつかるとどのように対応していいのか分からないですよね。それはひとえにメンバーレベルではリソースの調整をする発想がないからだと思います。
プロジェクトに取り組む時間がなかったり、他のタスクをアサインされてしまう場合、適切な意思決定者に働きかけることでリソースを確保する必要があります。それは開発チームのリーダーであったり、依頼者側のプロジェクトオーナーだったりするでしょう。プロジェクトに取り組む必要があるのに取り組めていないことを共有し、リソースを確保することが大切です。
おわりに
以上が工期を過小に見積もってしまう問題の要因と対策でした。
わたしの苦しんだ経験がみなさんの助けになることを願っています！
参考文献
-
だまし絵を描かないための要件定義のセオリー
- 要件定義に関する良い本。要件定義やプロジェクトマネジメントについてのオススメ本は以下にまとめました
-
今回はひとりプロジェクトだったのでリソース（投下時間）が減ると工期遅延すると単純化しています。複数人のプロジェクトだとまた違うはず ↩︎
Discussion