製品開発において他社に勝ち続けるための開発プロセス改善の進め方

開発プロセス改善の進め方について解説

　ソフトウエア開発、ハードウエア開発を問わず、製品のライフサイクルはどんどん短くなっています。また、新興国の台頭やインターネットの普及により、安くても品質のよい製品が巷にはあふれかえっています。日本が技術大国として君臨していたのは過去の話で、どのような製品も激しい競争にさらされています。このような現代、私たちが生き残っていくためには、グローバルな競争にも勝っていかなければなりません。

　製品開発において他社に勝ち続けるには、技術面はもちろんですがクオリティ（Ｑ）、コスト（Ｃ）、デリバリー（Ｄ）の面で他社を一歩リードしていく必要があります。つまり、開発の進め方を常にアップデートしながら良い製品を低価格でタイムリーに提供していかなければならないということです。

　そのためには、まずは問題を明確にし、その問題点に関して改善を行っていくことになります。今回は「開発プロセス改善の進め方」について説明していきます。

改善の狙いを明確にする

　ここから説明するのは、クオリティ（Ｑ）、コスト（Ｃ）、デリバリー（Ｄ）つまりＱＣＤの問題についてです。技術的な問題やマネジメントの問題については、とりあえず置いておきます。
製品のＱＣＤの問題とは、最近リリースした製品について次のような問題がなかったか、ということを考えます。

１．リリースした後に動作不良などが多数報告され、お客様に迷惑をかけた
２．開発が遅れてしまい、予定したリリース日を守れなかった
３．開発当初の見積もりが甘く、開発が進むにつれ工数が不足し後で開発者を大量投入した

　このような問題の中から特に影響度の高い問題を取り上げて「改善の狙い」を設定します。2項の「開発が遅れてしまい、予定したリリース日を守れなかった」ということが最も影響度が高かったのであれば、「顧客納期に対する遅延ゼロ」を改善の狙いとして設定します。

プロジェクトの弱みを知る

　次に自分たちの開発プロセスについてモデルを使ってプロセス診断し、プロセスのどこが弱いかを明確にします。今回は開発のモデルとしてCMMIを使ってプロセス診断する方法をご紹介致します。

　CMMIは開発プロセスの成熟度をレベル２からレベル５と改善を進めながらレベルアップしていくモデルです。開発プロセス全体はいくつかのプロセス領域に整理されており、各プロセス領域には数個から十数個のプラクティスがあります。プラクティスごとにプロジェクトのアウトプットを確認し、CMMIのモデルに対して弱みとなる箇所を特定します。

例）開発計画策定の診断結果

改善の狙いに対する施策を決める

　プロジェクトの弱みから改善の狙いを達成するのに有効なものをリストアップします。例えば改善の狙いを前述の「顧客納期に対する遅延ゼロ」とする場合、施策として以下のようなものが上がってきます（例）。

１．レビューでの指摘漏れを減らしてバグの流出を減らす
２．進捗管理において進捗率と遅延日数を常に監視し遅れを早期に検出する
３．開発の生産性を向上し、開発スピードを上げる

PDCAを回す

　PDCAを回す際のポイントは、改善の狙いをベースに回すのではなく、施策ベースで回すということです。なぜかということをこの例で説明すると、改善の狙いは「顧客納期に対する遅延ゼロ」です。目標が達成できたかどうかが分かるのは製品をリリースしたとき、つまりプロジェクトが完了した時点となります。この結果をフィードバックして次の改善につなげますが、これでは1回のPDCAのループが大きすぎて、ゆっくりとしか改善が進みません。

　もっとPDCAのループを小さくして、改善を速く回しながらプロジェクト進行中でも目標に対して効果が出ているかどうかを確認して活動をコントロールしていく必要があります。

例）レビュープロセスの改善

P（計画）

　まずは改善の計画を立案します。ここで一番重要なのは各施策について指標と目標値を設定するということです。定量的な指標に対して数値目標を設定し、随時目標に近づいているか（施策の効果）を監視しながら活動できるようにします。上記の例なら以下のような指標と目標値（例）になります。

　また、これらの指標を測定（Ｄ）した結果、評価（Ｃ）、改善（Ａ）をどう回していくか、担当者と日程を決めて計画とします。

D（実行）

　計画が立案出来たら、実際の開発プロジェクトの中で、施策の指標を測定していきます。測定した結果を目標と比較できるように記録していきます。

C（評価）

　測定結果と目標値が乖離しているかどうかを評価し、もし乖離しているなら原因を分析します。分析する際は、測定結果の内訳を分類する、乖離する要因から根本原因を特定するなど、統計手法や品質管理手法等を活用すると良いでしょう。下記は分析結果の例です。

　例えば、テスト工程で検出した流出のバグの発生源を調べた結果「インタフェース設計の問題のが最も多かった」というようなことが分かってきます。

A（改善）

　分析結果を基に、開発プロセスの改善案を策定します。前述の例で説明すると以下のようになります。

次のPDCAに向けて

データの測定は継続的に行い、立案した改善案を実施し効果が出始めるころに改めて分析、改善を行うような計画を立てて活動を継続します。このようにしてPDCAを2回、3回と回しながらプロセスを目標に近づけるような活動を継続し、最終的には改善の狙いで立てた目標「顧客納期に対する遅延ゼロ」を達成します。
また、このようなプロセス改善活動の効果を測定したいのであれば、活動から1年くらい経過した時点で、最初に行ったプロセス診断をもう一度行ってみるのも良いと思います。各プロセス領域の実施状況をレーダーチャートで表してみると、1年前よりチャートが大きくなって改善が進んでいることが分かるようになります。

改善に終わりはありません。更に高い目標を設定し、改善を継続していきます。

• Twitter
• Facebook
• Pocket
• B! はてブ
• LINE