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

更新日

投稿日

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

   続きを読むには・・・


この記事の著者

川崎 響子

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

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


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

もっと見る
『価値づくり』の研究開発マネジメント (その10)

 その8では「範囲の経済性」を、その9では「比較優位の原理」の解説をしましたが、今回はその両者と企業がオープンイノベーションを追求する意味合いとの関係性を...

 その8では「範囲の経済性」を、その9では「比較優位の原理」の解説をしましたが、今回はその両者と企業がオープンイノベーションを追求する意味合いとの関係性を...


体制について 技術企業の高収益化:実践的な技術戦略の立て方(その1)

   2020年、新型コロナウイルスの影響下、このような時期なのですが、中長期の技術戦略を立てたいという会社からの問い合わせを頂いています...

   2020年、新型コロナウイルスの影響下、このような時期なのですが、中長期の技術戦略を立てたいという会社からの問い合わせを頂いています...


製品設計における納入仕様書の役割(その2)

  【目次】   ものづくりにおいては、顧客や協力会社、自社内の部署間において、様々な「文書」を取り交わす必...

  【目次】   ものづくりにおいては、顧客や協力会社、自社内の部署間において、様々な「文書」を取り交わす必...


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

もっと見る
チーム力を活かす設計ルームのレイアウトとは

   今回は、金型メーカーに限らず、機械設備メーカーなども含め、設計室(設計ルーム)でチーム力を活かすレイアウトについて解説します。 &nb...

   今回は、金型メーカーに限らず、機械設備メーカーなども含め、設計室(設計ルーム)でチーム力を活かすレイアウトについて解説します。 &nb...


技術資源の有効活用: 事例紹介 (その1)

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...

 今回から2回に分けて、TRMによる活動の事例紹介をいたします。TRM(Technical Resource Management)は自社が保有する潜在的...


女性視点の製品アイデア発想事例

 「女性活躍推進」に優れた「なでしこ銘柄」と呼ばれる上場企業が、平成25年度で26社存在します。しかし、私もソニー時代からハードウェアエンジニアですが、モ...

 「女性活躍推進」に優れた「なでしこ銘柄」と呼ばれる上場企業が、平成25年度で26社存在します。しかし、私もソニー時代からハードウェアエンジニアですが、モ...