工数の集計と評価 「設計工数の見える化」から始める業務改善(その2)

投稿日

&nb...
 
 前回のその1に続いて解説します。
 

3. 設計工数の集計と評価

 
 これまで述べてきたように、「設計工数の見える化」は設計部門にとって必要な活動です。しかし、設計工数の集計作業が大きな負担となり、継続できないというケースがよくあるようです。
 
 初めて「設計工数の見える化」に取り組むのであれば、1日数分程度で終わるぐらいのシンプルな集計方法から始めることです。以下私自身も行っていた集計方法です。
 
 まず、設計部門の業務を「設計業務」「設計付帯業務」「設計外業務」に分類します。次に、それぞれの設計テーマごとにNo.をつけます。各テーマは設計管理者が工数の見積りを行った上でスタートします。
 
表3 設計業務テーマ一覧表
技術マネジメント
 
 設計者は集計表に自分が手がけている設計テーマのNo.を記入し、それぞれの設計テーマで使った時間を一日ごとに記入します(図1)。時間はあまり細かく記入する必要はなく、15~30分を最小単位とします。
 
技術マネジメント
図1 設計者の工数集計表
 
 一つの設計テーマが完了したら、設計工数をすべて集計し、見積り工数と実績値の比較や、想定より工数を要した工程などを洗い出します。必要に応じて設計プロセスの見直しなど、業務改善を進めます。
 
 一定期間ごとに、設計部門全体、各設計者について、設計業務、設計付帯業務、設計外業務の比率を明確化します。設計付帯業務や設計外業務も重要ではあるが、設計者が業務の半分以上を問合せ対応に費やしているようであれば問題です。Q&A資料を拡充する、設計者以外が対応するなどの対策が必要です。
 
 このように設計業務とそれ以外を明確にすることによって、様々な改善策を講じることができます。
 
 集計を継続するためのポイントは、毎日記入を行うことです。週末にまとめてやろうと思うと、なかなか思い出せず記入が進まないのです。それがストレスとなって集計が続かなくなってしまいます。
 
 私も設計者時代に図1のようなフォーマットに毎朝記入していましたが、必要な時間は5分程度でした。自分の仕事の整理にもなるので、特にストレスを感じることはありませんでした。
 
 

4. 「設計工数の見える化」は、組織作りに必要不可欠な活動

 
 パーキンソンの第一法則「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する[1]」にもあるように、見積り工数自体が実際の工数に影響を与える可能性があります。
 
 また、設計業務の中で工数管理・日程管理が最も難しい仕事の一つであるというのも私の実感です。しかし、それが「設計工数の見える化」をしない理由にはならないのです。
 
 「設計工数の見える化」は、よい製品や高い利益を生み出す組織を作るために必要不可欠な活動であると確信しています。
 
【参考文献】
 [1]「パーキンソンの法則」 Wikipedia
 

   続きを読むには・・・


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

もっと見る
研究所主導の新商品開発プロセスとは

     高収益な商品開発をするためには、顧客の困り事:課題を把握する必要があります。顧客の困り事には、様々なものがあります。「◯◯できない...

     高収益な商品開発をするためには、顧客の困り事:課題を把握する必要があります。顧客の困り事には、様々なものがあります。「◯◯できない...


技術戦略  研究テーマの多様な情報源(その39)

    良いアイデアを創出するための大きな枠組みには『発散』と『収束』を繰り返すがあります。前回は収束思考の解説をしました。今回は、また...

    良いアイデアを創出するための大きな枠組みには『発散』と『収束』を繰り返すがあります。前回は収束思考の解説をしました。今回は、また...


メトリクスによる開発のプロジェクト管理とは 【連載記事紹介】

       メトリクスによる開発のプロジェクト管理、連載記事が無料でお読みいただけます。   ...

       メトリクスによる開発のプロジェクト管理、連載記事が無料でお読みいただけます。   ...


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

もっと見る
追求するのは擦り合わせ能力を活かすマネジメント(その3)

 前回のその2に続いて解説します。図15は製品開発(設計)における調整の仕組みを詳細化したものです。「可視化」「分析」「視点切り替え」3つの要素から成り立...

 前回のその2に続いて解説します。図15は製品開発(設計)における調整の仕組みを詳細化したものです。「可視化」「分析」「視点切り替え」3つの要素から成り立...


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

 前回はシステム設計を、開発工程上はシステムエンジニアリングと、ハードやソフトなどのサブシステムのエンジニアリングの両方と定義しました。ここで、システムエ...

 前回はシステム設計を、開発工程上はシステムエンジニアリングと、ハードやソフトなどのサブシステムのエンジニアリングの両方と定義しました。ここで、システムエ...


製品開発部へのカンバン導入記(その2)

        前回からの続きです。前回は製品開発部がカンバンを導入するに至った簡単な経緯と、最初の問題点(...

        前回からの続きです。前回は製品開発部がカンバンを導入するに至った簡単な経緯と、最初の問題点(...