段階的開発法

ある電子機器メーカでの製品開発の例を紹介する。競合他社は少なく、開発している製品のマーケットシェアはトップである。しかし、この電子機器全体のマーケットは成熟しており大きな成長は望めない。そのため、他社のシェアをさらに奪うことで自社の成長を継続させるという戦略を立てた。この結果、開発グループに対しては製品開発期間を短縮し、新製品発売サイクルをより短くすることが要求された。このメーカーは、これまで他社よりも早く新技術を製品化することが強みだったのだが、これ以上の開発期間短縮の要求に応えるのは困難だった。無理に開発期間を短縮すれば、新技術の評価や検証が十分にできなくなり、これまでの強みを維持できなくなる可能性が高いと判断していた。したがって、要求に応えるための方策がない状態であった。

この組織に対するアセスメントを実施したところ、次のことがわかった。

• 新技術はハードウェア主体で開発を進めているが、新しいハードウェアはそのためのソフトウェアがないと評価、検証できない。
• ハードウェア開発担当はプログラムを作成することはできず、評価用のソフトウェアも含めすべてプログラム作成をソフトウェア開発グループに依頼している。
• このような状況であるにもかかわらず、ハードウェア開発グループとソフトウェア開発グループは完全に別部隊となっており、基本的にはハードウェアができあがってからソフトウェア開発が本格化するというような開発の進め方になっている。
• ソフトウェア開発グループは、ハードウェア開発グループからの種々雑多な依頼、そして、頻繁に起きる仕様変更によりハード担当に強い不信感を持ってしまい、ハード担当が作成する制御仕様に書いてあることだけをプログラムとして実現するだけになっている。

リスクの高い新技術を他社より早く製品化することと、ハードウェアとソフトウェアとがより整合性を持って開発を進める必要があることがわかったため、段階的開発法を導入することが有効であると判断した。段階的開発法により、早い段階から動くものを作るしくみを実現することで新技術採用のリスクを最低限に抑え、それを実現するためのハードウェアとソフトウェア担当との協力関係の再構築をねらった。

段階的開発法の導入は、開発プロセスを根本的に変えてしまうことになるため、無用な混乱や無駄なしくみ変更（手戻り）を極力減らす進め方をプランすることがポイントとなる。新しいしくみ作りが必要となる開発プロセスの幅広い領域に対して整合性の取れた対策を、効率よく実施できるようなシステマティックな実施計画を立てるということである。図（ソフトウェア開発プロセス革新実施計画）に、顧客との様々なディスカッションの結果、作成した実施計画を示す。

この実施計画では、段階的開発法の導入までに、プロジェクト体制の見直し、開発プロセスの標準化、メトリクス管理の実現、システムデザイン手法の確立、といった広範囲に渡るテーマを順序立てて並列に実施することになっている。開発プロセスを変えるという試みは、場当たり的、ボトムアップ的なアプローチでは成果を上げることはできないため、かなりの時間をマネジメントとのディスカッションに費やした。その結果、トップマネジメントに必要な要員や予算の確保を約束してもらった。このため、全体を１年半で達成するというかなりチャレンジな計画であったが、勝算のある実施計画となった。

実際の活動に当たって中心的な存在となったのは、プロセスグループとアーキテクチャグループというスタッフグループである。プロセスグループは、開発のしくみ（プロセス）に関係する活動全体に対して責任を持ち、アーキテクチャグループは共通のデザインや技術に対して責任を持つ専任のスタッフである。厳しい製品開発の中で、両グループのために専任の技術者をアサインしたマネジメント・デシジョンはすばらしい。当初はプロセスグループ、アーキテクチャグループ、それぞれ１名ずつで活動を開始し、３年目からはそれぞれ３名と２名という体制にした。

以下に組織を動かすには人を動かさなくてはならないことを紹介するが、人を動かすには、ねばり強い説得、関係者への気遣いや気配り、どこへでも行く軽快なフットワークなどが大切になる。プロセスグループとしてアサインされた担当者はこのようなパーソナリティを備えた人であった。この人選もよかった。

１年半というのはこの規模の改善活動の期間としては短い。そのため、次のようなことに注意しながら活動を進めた。

この組織の場合、既に述べたようにトップマネジメントが予算と人に関するデシジョンをしたことはすばらしいことである。しかし、予算と人を確保した後は、その担当者に全てを任せてしまい、当初、トップが活動に直接かかわるような体制にはなっていなかった。担当者への権限委譲という言い方はできるが、担当者の視野はトップと較べると狭いものになってしまい、一つのテーマだけに力と時間を注ぐことになってしまった。また、当事者である開発のメンバーもプロセスグループという一担当者が言うことは、真剣には聞き入れようとはしなかった。

そこで、事業部長、開発部長、開発課長からなる会議体を設置した。２ヶ月に１回の割合で会議を持ち、必ず全員が参加するよう強力に進めた。たとえば、会議のための日程確保は、毎回、個別に一人ずつ連絡を付けて確保してあることを確認した。このようなことをしても、必ず全員が揃うとは限らなかった。ただ、テーマの関係者とトップである事業部長は必ず都合をつけて参加してもらうように説得、調整を繰り返した。そのため、事業部長は１年半は必ず参加してもらうことができ、会議での議論が中途半端になることはなく、毎回一定の結論を出すことができた。トップマネジメントが、常にソフトウェア開発プロセス革新に関心を持っているという姿勢を体現し、関係者のモチベーションを持続させるのに非常に重要な場であった。対策実施の対象となったプロジェクトにとっても、マネジメント全員からの定期的レビューがかかるという緊張感が良い結果につながったと思う。

実施テーマは広範囲に渡っているが、一つ一つのテーマに対して確実に成果を出すために、テーマごとに慎重にパイロットプロジェクトを決めた。原則として、一つのプロジェクトで一つのテーマとして負荷を最小限にしたつもりだったが、それでもプロジェクト側は実際の製品開発、つまり、予定したリリース期日を守ることが最優先であり、それを守るだけでも精一杯なのに改善活動を実施する余裕はないというのがプロジェクト側の反応であった。

しかし、パイロットプロジェクトの関係者の中には、開発の最初から最後まで忙しいわけではなく、開発後半になってそれまでには予想もしていなかったことが起きてバタバタすることが多いことを指摘してくれた人がいた。まず、この技術者を見方にし、開発の最初の段階で改善実施もプロジェクト作業の一つとして考えれば、実行可能な開発計画は作れるはずとの考えに賛同してくれる技術者を増やしていった。そして、そのような人を交えて徹底的に開発計画を議論した。そして、これまでのコンサルティングの経験から対策を実施をしても開発納期を遅らせることなく、生産性や品質を上げることができた例がたくさんあることを、いろいろな方法で何度も説明し、賛同者を増やしていった。このようなことを繰り返すことにより、改善活動として実施する内容への理解や、開発計画そのものの理解が進み、プロジェクト作業として改善活動を実施することができた。ただし、パイロットプロジェクトによっては、開発計画ができるまでに１ヶ月以上かかったり、リリース日程を調整することにまで至ったものもある。しかし、実施に当たってはすべて必要な議論だったといえる。

プロジェクトの運営や成果に対して直接の責任を持っているファーストラインマネジャーが本気で改善活動をやる気にならなければ、プロジェクトは改善を行う前のいつもの状態にすぐに戻ってしまう。日本の組織の場合は、課長レベルのマネジャーが実際のプロジェクト運営に対して強い影響力を持っており、そのため、課長レベルのマネジャーの中に強力な賛同者を作らなければ実施は難しい。この組織でも同じ状況であった。

課長の賛同を得るには、現状はひどい状況であると心から思ってもらうことだと考える。この組織の場合は、この製品の主要顧客の一つから、この製品、および、この組織の対応について現状のままでは将来は危ないということを言ってもらった。顧客からの直接のクレームというのはショック療法なのだが、問題意識を高めるには非常に効果的だといえる。主要顧客の中からこのようなことに協力してくれるところを見つけることとその調整は大変だったが、それだけの価値はあったと思う。

約一年半の活動の中には以上のこと以外にも様々なことがあったが、個別テーマはほぼ予定通りの実施ができた。しかし、全てのプロジェクトが段階的開発法を実施するまでにはならず、一つのプロジェクトで段階的開発法を実施することができたにとどまった。実施したプロジェクトでは結果は次のような効果があった。

• 新規開発生産性が約 30 % 向上した（600 NCSS から 800 NCSSになった）。
• ハードとソフトとの間のトラブルが激減した（約 500 件の不具合が 130 件になった）。
• 従来平均すると 20 % の開発遅延であったが、予定通りにリリースすることができた。
• 開発後期は不具合修正作業（実はコーディング）に追われるのが常だったが、評価作業が中心となった（テスト工数が開発工数全体の 45 % を占めていたが 30 % になった）。

また、段階的開発法を実施するまでに至らなかったプロジェクトについても、新規開発生産性は約 20 % 向上した（600 NCSS/MM から 740 NCSS/MM になった）。また、不具合密度も平均 25 件／KNCSS だったものが７件／KNCSS となった。

このような数値的な成果も重要だが、ハードウェア担当とソフトウェア担当との不信感やカベがほとんどなくなったことを大きな効果として最後にお伝えしておきたい。