1.新規技術開発

 多くの会社では、事業の拡大のために、新規開発を行っていると思います。

 しかしながら、多くの会社では新規開発の結果が芳しくない場合がほとんどです。

 当然のように新規開発の多くは失敗で終わる事が多いですが、ただ単に失敗で終わってしまうものと、失敗から開発の種が生まれて新しい開発に進んでいき、最終的に成功する場合があります。可能性は平等にあるにも関わらず、成功する会社と失敗する会社が出てきてしまいます。

 当然、予算がどのくらいあるかは大きな問題ですが、大きな予算が成功に導くとは限りません。

 成功確率が高い新規開発の方法が必要となっています。

課題

多くの開発において、失敗に終わってしまう原因には、以下のようなものがあります。

1.目的からのずれ

当初の目的から大きくずれてしまい、目的を達成できないものとなってしまう。実際に目的通りの開発を進めることは技術的な問題から難しい場合が多いです。そのために変更する部分が出てきますが、その変更に問題があり、目的から大きく外れてしまう場合があります。

2.必要な機能の考慮不十分

他社製品をベースに開発するときに多々見受けられます。製品の動作・構造は十分に調査しているにも関わらず、何のためにあるのかに対する理解が低いために発生します。機能には理由があります。理由を考えずに機能の実現のみを目指すために、間違った製品の開発になってしまします。

3.不適切な要素技術の適用

上記の機能に対する理解と関連があります。機能を実現する事のみに集中するあまり、その機能が存在する理由を忘れてしまい、実現可能性が高いだけで不適切な要素技術を採用してしまいがちです。不適切な要素技術を採用してしまうと、目的は実現できなくなります。

4.重要な開発要素が未着手

全ての開発項目に対して実施することは無理があるのは当然です。なので、選択して開発を実施するのが普通です。しかしながら、自分の開発に対して何が重要課題であるかを理解しないと、「XX社がXX可能な製品を開発したら完成です。」のような中途半端な開発になってしまいます。重要課題は何であり、実現の見通しがどのくらいあるのかを、十分に検討したうえで開発することが必要です。

対応できること

1.目的設定

開発を実施する目的の明確化
開発の根幹を決定する重要なフェーズになります。目的を明確に定義して、開発の方向のブレをなくすことが重要です。

誰のために開発するのか?

必ずエンドユーザーにしてください。
たとえ製品の部品を作る場合でも、エンドユーザーに利益をもたらすことが重要になります。
エンドユーザーが喜ばない製品は売れることはありません。
たとえ、安価な製品を開発する場合にも、エンドユーザーのために作ると考えてください。
エンドユーザーを考えずに製品を安価にしようとすると、必要な機能を削ることになり、最終的に安いだけで不必要な製品となってしまいます。
エンドユーザーを考慮しない開発は、ユーザーに訴求するものがなくなる可能性があります。

何を利益とするのか?

開発の際には、「XX技術関連の製品を開発してくれ。」のように開発項目が限定されている場合や、「XX技術を使った新規開発をしてくれ。」のように使用する技術が限定されている場合がほとんどです。
このような場合には、すでに開発項目が決定されているかのように見えます。
しかしながら、その開発でどのような利益をユーザーに与えるかを明確にすることが重要です。開発する製品は同じであっても、それがユーザーに利益をもたらさなければ、誰も購入しません。
ユーザーが「こうであったらうれしい。」と思える要望を明確にしなければいけません。その要望はひとつである必要性はありませんが、極力絞り込んだほうが、開発が発散しないのでよいでしょう。
けれども、みんなの要望を知ることは難しいです。一つの方法として自分(家族を含めて)の要望を考えるのも一つの方法です。

何を開発するのか?

目指すべきユーザー利益が決まっているので、それを実現可能な開発項目を規定していきます。

 
ユーザー利益と開発項目との間に、必ず整合性を取ってください。開発が与えるユーザー利益がすばらしいものであっても、開発項目と整合性が取れていない場合には、開発した製品がユーザー利益を与えないことになります。
開発項目が限定されている場合でも、どのような製品を作るかを明確に規定します。

2.構成検討

開発目的を実現するための構成の明確化

 開発目的の要求を実現するために要求が何によって構成されているかを明確にして、その要求の構成の各々に開発機能に割り当て、機能をどのようなモノを開発して実現するかを明確にします。

要求の分解

目的を実現するための要求を分解します。
つまり、目的を実現するために「どのような事ができることを必要とされるか?」を考えることです。
必要とされる要求事項は、多岐にわたりますが、そのうちで現状の技術のみで実現されていることは、新規開発の要求から外れます。
残った要求が、重点開発要求事項になります。
この要求分解の過程は、概略であっても理解できるように資料にまとめておく必要があります。
なぜならば、これらの各要求を個別に開発することになった場合に、個別の開発が要求からずれてしまって役に立たなくなるような事態を防ぐためです。

要求の構造化

要求を機能に変換します。
次のステップで技術を当てはめる必要性がありますので、技術割り当てができる程度に機能を分解する必要があります。
要求を実現する方法は、一つだけであることはありません。
多くの可能性がある機能を検討して、用いる機能を決定しなければなりません。

要求を実現する技術の検討

前のステップで分解した機能に、技術をわりあてます。
技術の課題を明確化して、開発の可能性(開発目的との適合性・開発のしやすさ・技術の発展性など)を検討して、開発する技術を決定します。
実際の作業では、前ステップの「要求の機能化」とこのステップの「機能を実現する技術の検討」は一体のものであり、この二つのステップを繰り返しながら、機能と技術を決定していくことになります。

3.課題検討

課題の明確化と課題の優先順位の確定

 構成の明確化の技術決定においてあげられた課題の重要度と技術的難度を検討し、また、同様に自主開発項目か否かを検討し、各々の課題の位置づけを明確にするとともに、対応の順位を明確にします。

課題の重要度と技術的何度の検討

まず、課題の重要度を検討します。
重要度は、それがなければ目的の達成が難しいものが最も高く、それがなくても目的の主要な部分は実現可能なものを最も低く評価します。つまり、未達成となったときに、「まったく魅力の無い製品」となるか「制限はあっても魅力ある製品」となるかを基準に考えます。
次に、技術的難度を検討します。
実際に開発を始めてみないとわからない点もありますが、現有技術としてまったく存在しない技術を高く、現有技術の用途変更もしくは少しの追加で実現可能な技術を低く評価します。
この評価は決定したらそのままで用いるものではなく、必要に応じて変更して開発資源(人材を含む)の割り当て変更をしていく必要があります。

課題を自主開発とするか委託とするかの検討

各々の課題の開発をどこが実施するかを検討します。
各々の課題のうち、重要度が高いものは自主開発するに越したことはありません。
たとえ、商品化を行うときに外部に出すこととなったとしても、仕様書を作成するときには、開発した知識が役に立つからです。
しかしながら、開発予算や開発期間および開発人員の問題からすべてを自主開発することは難しいことです。
重要度が高く、技術的難度が高いものは極力内部開発し、重要度が低く、技術的難度が低いものは外部開発にするとして、その間を自社の「保有技術」および「強化を推進したい技術」を考慮して決定することが望ましい方法です。

課題管理の優先順位の決定

個々の課題の管理の優先順位を決定します。
主要機能に関連する課題は、全て高いプライオリティになります。これが完成しないと製品の意味を成さないものであるので、必ず完成させなければなりません。そのために管理をしっかりしておく必要があります。
それ以外の課題の管理の優先順位の決定ですが、「目的の明確化」で決定した目的に沿って決定しなければなりません。
すなわち、ユーザーへの利益が減る度合いが大きいものは優先順位が高く、それほど減らないものは優先順位を低くします。
このときに、この課題が解決できなかった場合にどのような商品なるかをイメージしておく必要があります。
これを実施しておくことによって、開発予算や開発期間および開発人員の問題で計画を変更する際に、コンセンサスを得られやすくなります。

4.計画作成・計画変更

計画作成と作成された計画の変更および解決された課題を元にした目的変更と全体に影響する重要事項

 策定した開発の方向性を実現するためには開発計画を作成する必要があります。また、諸事情により計画の実施中に計画を変更する必要もあり、場合によっては、解決された課題をシーズとして、新しい目的を目指した開発を実施する場合もあります。

 また、開発を進めていくために重要となる実施事項もあります。

計画作成

まずは大計画を作成します。

大計画は、主要な技術的課題または全ての技術的課題が、いつまでに解決する計画であるかについて記載します。
あわせて、それらの技術的課題が解決した結果実現できる機能について記載します。
その大日程を元に、技術的課題および実現できる機能について分解して、順次詳細な日程を作成していきます。
詳細な日程に関しては、全てを作ることは困難です。重要度が高いものを優先して、できるところから作成していくことが重要です。
新規開発においては、今までの経験的に得られている工程の見識とはずれることが多々あります。
後から変更しながらでも作成して、状況を把握する事が重要です。
新規開発では、日程は変更しながら作成していく事が多く発生します。
そのためにも、PERTが作成できるソフトウェアを用いて作成し、日程上の問題点を早く把握するとともに、変更をすばやく確認できることが重要です。

計画変更

 開発が順調に進んでいる場合や、開発が遅れているが遅れが許容されている場合は、特に計画を変更する必要はありません。
しかしながら、先行開発においては当初の目論見に反して問題が発生し、計画の変更を余儀なくされる場合が多々あります。このような場合には計画変更が必要となります。①日程もしくは予算の関係で全ての開発が達成できない場合
 多くの新規開発においては、着手後に一定期間・一定予算の枠の中で開発を進めて、期間満了時の成果を確認した上で、継続開発をするかを決定します。
新規開発において、期限までに成果を見せることはもっとも重要な項目です。
そのためにいくつかの課題の開発を先送りして、開発物の機能を削減したものの開発に重点を置く必要があります。
その際には必ず目的明確化のフェーズまで戻って、削減する機能が大きく新規開発の魅力を減じていないかを確認するに必要があります。
②想定していない技術的課題の表面化
開発を実施していると、想定していない技術的課題が表面化する場合があります。
このような場合には、構成の明確化のフェーズから開発を見直して、整合性をとる必要があります。
また、見直した結果、開発期限に間に合わないと判断した場合には、①に沿って計画変更を実施します。
目的変更
 新規開発の中で開発を進めていた「技術」および「機能」を、他の目的での開発に利用する場合です。
開発において、他の新規開発のために開発していた技術を、他の新規開発に用いることはよくあることです。
しかしながら、「ただ使える」だけで適用してもよい製品とはなりえません。
必ず、ユーザーに喜ばれる商品になりえる可能性があることを確認してから適用する必要があります。

5.その他の重要事項

開発を進めるにあたって、今まで記載してきた内容以外にも、基本的な重要項目があります。これについて記載します。

週次(出来たら日次)の打ち合わせ
できるだけ密接に打ち合わせを持ってください。
順調に進んでいる場合は問題がありませんが、担当者が自分の問題を抱え込んでしまう場合があります。
極力、ほかの部分を担当している技術者を交えて、いろいろな角度から解決の方法を検討することが必要です。
打ち合わせは、日程からの遅れを指摘する場所ではなく、遅れの解決策をみんなで考える場所であると認識してください。
また、全体の状況を知らせることにより、各担当者がシステム全体の俯瞰から自分の担当部分を見られるようになります。
報告書
計画作成、設計、試作、試験の各段階の中で、作業に対応する報告書を作成することは重要です。
開発中は得てして開発作業に集中するあまり、報告書が作成されない場合が多々見られます。
報告書は開発中に変更を行った理由や、不具合を解消した考え方を残すために重要です。必ず記載する必要があります。
開発計画の更新
開発中に必ず開発実態と計画の比較を実施して、計画を更新してください。
技術的課題を解決した際には、その技術的課題を解決済みにするなどの更新が必要です。
そして、更新時には必ず更新履歴を記録してください。
更新履歴をつけることにより、②の報告書と日付を比べることにより、更新を実施した時の状況および理由を確認することができます。

最低限、以上の作業をすることにより知識の蓄積が可能となり、たとえ失敗したとしても後につながるものとなります

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

12 − 9 =