初めての開発プロジェクトの日程見積り法 新規事業・新商品を生み出す技術戦略(その26)

更新日

投稿日

 
  技術マネジメント
 
 今回は、会社や組織で今まで取り組んだことがない初めて実施する業務をどのように見積もればよいか解説します。
 
 会社や組織が新しい開発プロジェクトを始めるか否かを決定する前に必ず日程の見積もりをします。今までの実績がある開発案件であれば、難なく見積もりができるかと思いますが正直、今まで通りに進まなそうな複雑な案件が多くなっているのも事実です。
 
 そんな時に使うと便利な見積もり方法があるので、ご紹介します。
 
 それは、「タスク(=業務)分割による見積もり方法」です。
 
 この見積もり方法の流れは5つです。
 
  • 過去の開発プロジェクトの中で共通点が多いプロジェクトを選ぶ
  • 過去の開発プロジェクトの実績の中から同じような業務を選ぶ
  • 選ぶ業務は3つとし、それぞれ容易、普通、困難といった難易度に分ける
  • 対象の開発プロジェクトの業務を分解し、難易度を当てはめ累積する
  • 開発人員の保有スキルや業務割合に合わせた定数を掛け合わせる
 
 この見積もり方法におけるポイントは3つめの「難易度別に3つの小さい業務を選択する」ことです。全ての開発ステップをまとめて過去の開発プロジェクトに当てはめると、見積もり結果と実際の進捗に大きな差が出ます。
 
 難易度に応じて3つに分けることで、管理可能な業務単位ごとに客観的に判断することができ、累積結果の信頼度が高まります。
 
 1年以上におよぶ、しかも未知の開発案件を一気に見積もることは難しいですが、開発者がイメージできる単位の業務に分割することで、一気に見積もりがしやすくなります。そしてもう一つのポイントは4つめの「対象の開発プロジェクトの業務を分解する」ことです。
 
 この方法についてリーダーに成り立ての開発者からよくこんな意見が出ます。
 
  • 「今まで経験したことがない業務を分解することは出来ない」
  • 「分解するだけでどれだけ時間がかかると思うんだ!そんな暇はない」
 
 などです。
 
 しかし、経営者や開発リーダーは全ての情報がなくとも判断することがどんなシーンにおいても求められます。
 
 過去の経験や事例などの事実を元に予測・判断スキルを上げることが近道です。ご自身がイメージできる業務単位に分解することを諦めないで実施してください。
 
 現実的には、突発的な環境の変化や課題が発生することで、見積もり結果通りに開発が進むことは稀です。しかし、「あくまで見積もりなので、途中で変わることが当たり前」と割り切る会社や組織は次第に信頼されなくなり、組織風土としてもよいとは言えません。
 
 見積もりに時間をかけすぎることはいけません...
 
  技術マネジメント
 
 今回は、会社や組織で今まで取り組んだことがない初めて実施する業務をどのように見積もればよいか解説します。
 
 会社や組織が新しい開発プロジェクトを始めるか否かを決定する前に必ず日程の見積もりをします。今までの実績がある開発案件であれば、難なく見積もりができるかと思いますが正直、今まで通りに進まなそうな複雑な案件が多くなっているのも事実です。
 
 そんな時に使うと便利な見積もり方法があるので、ご紹介します。
 
 それは、「タスク(=業務)分割による見積もり方法」です。
 
 この見積もり方法の流れは5つです。
 
  • 過去の開発プロジェクトの中で共通点が多いプロジェクトを選ぶ
  • 過去の開発プロジェクトの実績の中から同じような業務を選ぶ
  • 選ぶ業務は3つとし、それぞれ容易、普通、困難といった難易度に分ける
  • 対象の開発プロジェクトの業務を分解し、難易度を当てはめ累積する
  • 開発人員の保有スキルや業務割合に合わせた定数を掛け合わせる
 
 この見積もり方法におけるポイントは3つめの「難易度別に3つの小さい業務を選択する」ことです。全ての開発ステップをまとめて過去の開発プロジェクトに当てはめると、見積もり結果と実際の進捗に大きな差が出ます。
 
 難易度に応じて3つに分けることで、管理可能な業務単位ごとに客観的に判断することができ、累積結果の信頼度が高まります。
 
 1年以上におよぶ、しかも未知の開発案件を一気に見積もることは難しいですが、開発者がイメージできる単位の業務に分割することで、一気に見積もりがしやすくなります。そしてもう一つのポイントは4つめの「対象の開発プロジェクトの業務を分解する」ことです。
 
 この方法についてリーダーに成り立ての開発者からよくこんな意見が出ます。
 
  • 「今まで経験したことがない業務を分解することは出来ない」
  • 「分解するだけでどれだけ時間がかかると思うんだ!そんな暇はない」
 
 などです。
 
 しかし、経営者や開発リーダーは全ての情報がなくとも判断することがどんなシーンにおいても求められます。
 
 過去の経験や事例などの事実を元に予測・判断スキルを上げることが近道です。ご自身がイメージできる業務単位に分解することを諦めないで実施してください。
 
 現実的には、突発的な環境の変化や課題が発生することで、見積もり結果通りに開発が進むことは稀です。しかし、「あくまで見積もりなので、途中で変わることが当たり前」と割り切る会社や組織は次第に信頼されなくなり、組織風土としてもよいとは言えません。
 
 見積もりに時間をかけすぎることはいけませんが、意味のない結果を提示してあとで痛い目に合わないよう、見積もり精度をあげる努力は継続しましょう。
 
 継続することで見積もり精度は格段に上がり、会社や組織が顧客に与える信頼度がグッと高まります。そして開発者個人に依存することなく、会社や組織の保有スキルとしての見積もり方法を構築することで強い会社・強い組織を作りたいですね。
 

   続きを読むには・・・


この記事の著者

川崎 響子

革新的なテクノロジー事業を最速&確実に量産まで立ち上げます。 世界No.1商品を創る企業を世の中に送り出し続けることが私の使命です。

革新的なテクノロジー事業を最速&確実に量産まで立ち上げます。 世界No.1商品を創る企業を世の中に送り出し続けることが私の使命です。


「技術マネジメント総合」の他のキーワード解説記事

もっと見る
政治の統治機構 普通の組織をイノベーティブにする処方箋 (その38)

        この連載では、将来の市場環境に大きく影響を与えるPESTEL(Political:政治、Ec...

        この連載では、将来の市場環境に大きく影響を与えるPESTEL(Political:政治、Ec...


何はなくとも戦略を作る 新規事業・新商品を生み出す技術戦略(その1)

   「あなたの会社、あなたの組織には戦略がありますか?」と質問をすると十中八九「当然、あります。」と答えが返ってきます。   ...

   「あなたの会社、あなたの組織には戦略がありますか?」と質問をすると十中八九「当然、あります。」と答えが返ってきます。   ...


聴覚 普通の組織をイノベーティブにする処方箋 (その157)

  前回までの4回で、視覚を活用して創造性を高めイノベーションを起こす能力を強化する方法について、考えてきました。今回からは、聴覚ついて考...

  前回までの4回で、視覚を活用して創造性を高めイノベーションを起こす能力を強化する方法について、考えてきました。今回からは、聴覚ついて考...


「技術マネジメント総合」の活用事例

もっと見る
トレーサビリティの保証 プロジェクト管理の仕組み (その45)

 前回のその44に続いて解説します。    ハードウェア設計の場合も、要件と回路ブロックの仕様(スペック)、回路ブロックのスペックと部品のス...

 前回のその44に続いて解説します。    ハードウェア設計の場合も、要件と回路ブロックの仕様(スペック)、回路ブロックのスペックと部品のス...


設計部門の仕組み構築(その1)

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...

【設計部門の仕組み構築 連載目次】 1. 設計部門の仕組み構築 2. 設計部門の仕組み構築(解決すべき根本原因) 3. 設計部門の仕組み構築(具...


顧客価値の理解を深めるには

 私は、日ごろ、ものづくり企業のR&D現場をフィールドとしたコンサルティングに取り組んでいます。その中で、価値、とりわけ顧客価値は、R&D...

 私は、日ごろ、ものづくり企業のR&D現場をフィールドとしたコンサルティングに取り組んでいます。その中で、価値、とりわけ顧客価値は、R&D...