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

更新日

投稿日

開発効率

【開発効率向上の重要性 連載目次】

 

前回の開発効率を上げるには(その5)開発効率向上、活動計画 2に続けて解説します。

5. 開発効率向上活動で考慮すべきこと

開発効率向上活動は企業のプロジェクト活動であり、予実やリスクの管理をしながら進めていくことは通常と変わりありません。ただし、ビジネスを側方から変えていくという点で考慮すべきポイントがいくつかあります。ここでは、そうした点について解説していきます。

 

(1)体制

A)活動メンバー

開発効率向上を進める上ではビジネスに使う技術を熟知している必要があり、かつ自分たちの業務改善であることから、技術者自身が関与していくことが望ましいのは言うまでもありません。一方、活動により通常の開発業務に使えるリソースが減る、開発にとってはある意味外乱になるということから開発メンバーとは別枠の体制をとるべきという考え方もあります。そのため、どのような体制を取るかは、次のいずれかの形(または両者を合わせた形)の得失を吟味して決めていくことになります。

 

①開発・設計部署とは別に、改善を進めるスタッフ部門を創設する

  • 開発・設計業務への外乱が少ない
  • 客観的な視点で、比較的大きな改善への投資ができる
  • 現場の問題意識とかけ離れた改善が実行されるリスクがある

 

②開発・設計部署のメンバーが、業務と併行し改善活動を進める

  • 現場の問題意識に根ざした即効性のある改善が期待できる
  • 局所最適な改善に陥りやすい
  • 開発・設計のリソースが削られる

 

B)活動する組織の範囲

開発効率は技術部署の業務に関するものですが、同時に、上流である営業・マーケッティング、下流である製造・サービス、管理機能である品証・技術管理などとも関係します。

 

そのため、改善活動を行う際は全社レベルで部署横断的に改善を進めるのが理想ですが、部署間の利害が相反する場合がある、部署横断の活動は管理体制が複雑、大規模な活動は失敗した場合のリスクも大きいなどの点を考慮すると、実施の難度はかなり高くなります。そのために基本的に開発部署内の活動を行ない、次のような場面が見えた時点で活動を上下流に拡大することが現実的です。

  • 活動を進める上で、外部とのインターフェイスの修正が必要
  • 活動の成果が、外部にとってもメリットがある
  • 外部で実施されている改善の活動と同期することで相乗効果がある

 

C)活動する組織の範囲

どの分野の改善でも言えることですが、活動には以下のような異なる側面についての知見を併せ持つリーダが必須で、そうでない場合は活動が特定分野に偏る、必ずしも最適ではない方向に活動が向かうといった弊害が現れます。

  • 広い分野の技術に対する理解
  • ビジネス活動(上下流を含めた開発プロセス、経営の意図など)の理解
  • 効率向上活動を進める論理的思考、問題解決力

 

これらを同時に満たす力のある方を専任でアサインすることは難しいと思いますので、その場合はそれぞれの役割をメンバーで分担する、識者に後見して頂く等の代替的な工夫が必要です。(識者は、当該ビジネス・技術分野の専門家というよりは、広い視野と論理性を重視した方が、活動の最適化を図りやすくなります。)

 

(2)活動成果の定着

A)リスクの回避

改善活動には不確定要素がつきもので、必ずしも想定した改善の成果が得られないことがあり得ます。そうした点から、次のような形でリスクを回避することを計画に含めます。

  • 複数の改善施策を併行して進めることで、個々のプロセスの効果に差があってもトータルとしての効果を確保する。
  • 開始段階では、小規模な活動からスタートし、成果を確認しながら活動を拡大する
    (特定の製品・プロダクトラインに限定、一部の開発機能に限定 など)

 

B)改善の水平展開

改善の成果を複数の機種、複数の部署に適用することができれば、等価的に改善効果を何倍にも向上させることができます。そのために、以下のように水平展開することを想定した活動を実施します。

  • 成果は積極的に外部に発信・共有する
  • 活動内容を検討する際には、自部署の効率向上について考えると同時に、それを一般化して他部署での効率化にも寄与できそうかを考える

 

C)活動の継続

企業の生産性の善し悪しは競合との相対比較で決まります。そのため以下のような状況下では「今までと同じモノを、今までと同じ方法で開発・製造」した場合は、時間とともにその相対...

開発効率

【開発効率向上の重要性 連載目次】

 

前回の開発効率を上げるには(その5)開発効率向上、活動計画 2に続けて解説します。

5. 開発効率向上活動で考慮すべきこと

開発効率向上活動は企業のプロジェクト活動であり、予実やリスクの管理をしながら進めていくことは通常と変わりありません。ただし、ビジネスを側方から変えていくという点で考慮すべきポイントがいくつかあります。ここでは、そうした点について解説していきます。

 

(1)体制

A)活動メンバー

開発効率向上を進める上ではビジネスに使う技術を熟知している必要があり、かつ自分たちの業務改善であることから、技術者自身が関与していくことが望ましいのは言うまでもありません。一方、活動により通常の開発業務に使えるリソースが減る、開発にとってはある意味外乱になるということから開発メンバーとは別枠の体制をとるべきという考え方もあります。そのため、どのような体制を取るかは、次のいずれかの形(または両者を合わせた形)の得失を吟味して決めていくことになります。

 

①開発・設計部署とは別に、改善を進めるスタッフ部門を創設する

  • 開発・設計業務への外乱が少ない
  • 客観的な視点で、比較的大きな改善への投資ができる
  • 現場の問題意識とかけ離れた改善が実行されるリスクがある

 

②開発・設計部署のメンバーが、業務と併行し改善活動を進める

  • 現場の問題意識に根ざした即効性のある改善が期待できる
  • 局所最適な改善に陥りやすい
  • 開発・設計のリソースが削られる

 

B)活動する組織の範囲

開発効率は技術部署の業務に関するものですが、同時に、上流である営業・マーケッティング、下流である製造・サービス、管理機能である品証・技術管理などとも関係します。

 

そのため、改善活動を行う際は全社レベルで部署横断的に改善を進めるのが理想ですが、部署間の利害が相反する場合がある、部署横断の活動は管理体制が複雑、大規模な活動は失敗した場合のリスクも大きいなどの点を考慮すると、実施の難度はかなり高くなります。そのために基本的に開発部署内の活動を行ない、次のような場面が見えた時点で活動を上下流に拡大することが現実的です。

  • 活動を進める上で、外部とのインターフェイスの修正が必要
  • 活動の成果が、外部にとってもメリットがある
  • 外部で実施されている改善の活動と同期することで相乗効果がある

 

C)活動する組織の範囲

どの分野の改善でも言えることですが、活動には以下のような異なる側面についての知見を併せ持つリーダが必須で、そうでない場合は活動が特定分野に偏る、必ずしも最適ではない方向に活動が向かうといった弊害が現れます。

  • 広い分野の技術に対する理解
  • ビジネス活動(上下流を含めた開発プロセス、経営の意図など)の理解
  • 効率向上活動を進める論理的思考、問題解決力

 

これらを同時に満たす力のある方を専任でアサインすることは難しいと思いますので、その場合はそれぞれの役割をメンバーで分担する、識者に後見して頂く等の代替的な工夫が必要です。(識者は、当該ビジネス・技術分野の専門家というよりは、広い視野と論理性を重視した方が、活動の最適化を図りやすくなります。)

 

(2)活動成果の定着

A)リスクの回避

改善活動には不確定要素がつきもので、必ずしも想定した改善の成果が得られないことがあり得ます。そうした点から、次のような形でリスクを回避することを計画に含めます。

  • 複数の改善施策を併行して進めることで、個々のプロセスの効果に差があってもトータルとしての効果を確保する。
  • 開始段階では、小規模な活動からスタートし、成果を確認しながら活動を拡大する
    (特定の製品・プロダクトラインに限定、一部の開発機能に限定 など)

 

B)改善の水平展開

改善の成果を複数の機種、複数の部署に適用することができれば、等価的に改善効果を何倍にも向上させることができます。そのために、以下のように水平展開することを想定した活動を実施します。

  • 成果は積極的に外部に発信・共有する
  • 活動内容を検討する際には、自部署の効率向上について考えると同時に、それを一般化して他部署での効率化にも寄与できそうかを考える

 

C)活動の継続

企業の生産性の善し悪しは競合との相対比較で決まります。そのため以下のような状況下では「今までと同じモノを、今までと同じ方法で開発・製造」した場合は、時間とともにその相対的な価値が低下していきます。このことは、改善活動を単発的に実施した場合は、一時的に成果が得られても、徐々にその効果が薄れていくことを示しています。

  • ビジネスでは競合に先んじて新しい機能を創っていくことで優位性が保てる
  • 製品はコモディティ化する方向であり、何もしなければ付加価値が低下する
  • 開発や製造の技術は常に向上し、従来のやり方では相対的に価値が低下していく
  • 組織のルールは、時間が経過するにつれて複雑化して効率性が損なわれる

 

逆に、改善活動を継続した場合は価値を保ち続けると同時に、前年度で得られた効率向上によるリソース増加を次年度の価値創出や効率向上活動に再投資できるという複利効果が得られ、徐々に組織の生み出す価値を増加させる方向に働きます。このため、開発効率向上活動は、基本的に常に継続実施することを前提とすべきです。

次回に続きます。

 

【ものづくり セミナーサーチ】 セミナー紹介:国内最大級のセミナー掲載数 〈ものづくりセミナーサーチ〉 はこちら!

 

   続きを読むには・・・


この記事の著者

山本 裕之

個々の課題に最適な改善プロセスを適用することで、企画・開発業務の生産性を効果的に向上させるお手伝いをしています。

個々の課題に最適な改善プロセスを適用することで、企画・開発業務の生産性を効果的に向上させるお手伝いをしています。


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

もっと見る
類似-1 普通の組織をイノベーティブにする処方箋(その100)

   現在、KETICモデルの中の「知識・経験を関係性で整理する」について解説しています。前回は「協調」について考えましたが、今回は「類似...

   現在、KETICモデルの中の「知識・経験を関係性で整理する」について解説しています。前回は「協調」について考えましたが、今回は「類似...


整理の為に考える要素、その中の物理量の選択 普通の組織をイノベーティブにする処方箋 (その70)

 前回のその69に続いて解説します。  現在、収集した知識・経験をイノベーションに向けて整理するフレームワークを解説していますが、今回も前回に引き続...

 前回のその69に続いて解説します。  現在、収集した知識・経験をイノベーションに向けて整理するフレームワークを解説していますが、今回も前回に引き続...


経済に関する5つのフレームワーク 普通の組織をイノベーティブにする処方箋 (その39)

        この連載ではマクロ環境分析の解説をしていますが、今回は、PESTEL(Political:政...

        この連載ではマクロ環境分析の解説をしていますが、今回は、PESTEL(Political:政...


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

もっと見る
仕組み見直しとグローバル化(その2)

◆「気づき」能力向上のカギは製品開発経験の活用    前回のその1に続いて解説します。「気づき」能力は、擦り合わせ型開発を行う上で技術者が備...

◆「気づき」能力向上のカギは製品開発経験の活用    前回のその1に続いて解説します。「気づき」能力は、擦り合わせ型開発を行う上で技術者が備...


先行技術テーマを企画段階で評価するには

1.先行技術開発    イノベーション、すなわち価値創造がものづくり企業におけるR&Dのミッションとして期待される中で、それを実現す...

1.先行技術開発    イノベーション、すなわち価値創造がものづくり企業におけるR&Dのミッションとして期待される中で、それを実現す...


品質の仕組みとは1 プロジェクト管理の仕組み (その27)

 製品開発を行っている組織において、設計・製造の仕組みを構築したり見直したりするというとき、品質向上に貢献することが何らかの形でゴールのひとつとなっている...

 製品開発を行っている組織において、設計・製造の仕組みを構築したり見直したりするというとき、品質向上に貢献することが何らかの形でゴールのひとつとなっている...