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

更新日

投稿日

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

   続きを読むには・・・


この記事の著者

川崎 響子

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

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


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

もっと見る
活動で考慮すべきこと 1 開発効率を上げる(その6)

【開発効率向上の重要性 連載目次】 製造業の生産性 開発効率向上の重要性 開発効率向上活動の考え方 開発効率向上、活動計画 1  ...

【開発効率向上の重要性 連載目次】 製造業の生産性 開発効率向上の重要性 開発効率向上活動の考え方 開発効率向上、活動計画 1  ...


製品設計:ミス防止対策(その5)

【製品設計:ミス防止対策 連載目次】 1.  お客様目線で行う製品設計、「未然防止の品質管理」 2.  過去のトラブル、フィー...

【製品設計:ミス防止対策 連載目次】 1.  お客様目線で行う製品設計、「未然防止の品質管理」 2.  過去のトラブル、フィー...


テーマのリスク分散 新規事業・新商品を生み出す技術戦略(その61)

◆ 失敗を許すR&Dテーマ  クライアント先の開発現場で次のような相談をされることがあります。 うちの会社は成功することが前提。失敗を...

◆ 失敗を許すR&Dテーマ  クライアント先の開発現場で次のような相談をされることがあります。 うちの会社は成功することが前提。失敗を...


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

もっと見る
ハイヒール型プルタブオープナー  異分野市場での事業化事例 (その1)

「部品技術の見える化」で、B2Bの部品からB2Cの完成品事業に成功したクライアントの事例を紹介します。A社は、金属加工の部品メーカーであり、田植え機、AT...

「部品技術の見える化」で、B2Bの部品からB2Cの完成品事業に成功したクライアントの事例を紹介します。A社は、金属加工の部品メーカーであり、田植え機、AT...


R&Dマネジメントの基本

【ものづくり企業のR&Dと経営機能 記事目次】 管理力より技術力を磨け 技術プラットフォームの重要性 手段としてのオープンイノベーション...

【ものづくり企業のR&Dと経営機能 記事目次】 管理力より技術力を磨け 技術プラットフォームの重要性 手段としてのオープンイノベーション...


システム設計7 プロジェクト管理の仕組み (その39)

 前回のシステム設計6に続いて解説します。    検証作業の基本は、考えたサブシステム構成に対してシステム要件の一つひとつに対してどのような...

 前回のシステム設計6に続いて解説します。    検証作業の基本は、考えたサブシステム構成に対してシステム要件の一つひとつに対してどのような...