NO IMAGE

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

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

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

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

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

改善の狙いを明確にする

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

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

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

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

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

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

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

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

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

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

PDCAを回す

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

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

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

P(計画)

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

施策指標目標値
レビューでの指摘漏れを減らしてバグの流出を減らすテスト工程で検出した流出バグ3%以下
進捗管理において進捗率と遅延日数を常に監視し遅れを早期に検出する毎週の進捗会議で確認する各グループの遅延日数遅延日数3日以内
開発の生産性を向上し、開発スピードを上げる従来の生産性ks/月との比較従来比10%向上

 また、これらの指標を測定(D)した結果、評価(C)、改善(A)をどう回していくか、担当者と日程を決めて計画とします。

D(実行)

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

施策指標目標値測定結果
レビューでの指摘漏れを減らしてバグの流出を減らすテスト工程で検出した流出バグ3%以下7%
進捗管理において進捗率と遅延日数を常に監視し遅れを早期に検出する毎週の進捗会議で確認する各グループの遅延日数遅延日数3日以内詳細設計で5日間の遅れ発生
開発の生産性を向上し、開発スピードを上げる従来の生産性ks/月との比較従来比10%向上従来比0%

C(評価)

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

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

施策測定結果分析結果
レビューでの指摘漏れを減らしてバグの流出を減らす7%インタフェース設計の問題が全体の4%
進捗管理において進捗率と遅延日数を常に監視し遅れを早期に検出する詳細設計で5日間の遅れ発生詳細設計の工数が見積と実績で4日分の差があった
開発の生産性を向上し、開発スピードを上げる従来比0%開発ツールを刷新したが使い方に慣れていない

A(改善)

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

施策分析結果改善案
レビューでの指摘漏れを減らしてバグの流出を減らすインタフェース設計の問題が全体の4%インタフェース設計の仕様を標準化し、開発者はインタフェースの内部構造を知らなくても設計できるようにする
進捗管理において進捗率と遅延日数を常に監視し遅れを早期に検出する詳細設計の工数が見積と実績で4日分の差があった要件が曖昧な部分がある時期に見積もった工数をベースに作業を行っているので、システム設計完了時に開発計画を見直し見積をやり直す
開発の生産性を向上し、開発スピードを上げる開発ツールを刷新したが使い方に慣れていない動画コンテンツ等も活用して開発ツール操作の習得スピードを上げ、次のフェーズで再測定し効果を確認する

次のPDCAに向けて

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

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


クオリゲート合同会社 市原クオリゲート合同会社
市原 嘉之

講座監修者・コラム執筆者のプロフィール

富士通でシステム開発を18年、設計・製造の「カイゼン」支援を10年経験し、2017年に独立。現在は首都圏はもちろん、地方でもコンサルティングやセミナーの実施に飛び回りながら活動している。現場の仕事の進め方を改善することに重点を置く「プロセス改善」を軸に、人材育成やプロセス標準の確立から定着まで最後まで支援。なぜなぜ分析セミナーやIoT&AIセミナー実績多数。


プロフィールの詳細はこちら
カイゼンベースの公開セミナー情報
カイゼンベースのオリジナル動画制作サービス
>人材教育を加速させる法人会員サービス

人材教育を加速させる法人会員サービス

年間120万人が利用中!ご利用ユーザー数No.1カイゼン情報サイト「カイゼンベース」。製造業を初めとした”現場”を持つ企業に欠かせない人材教育ツールとしてご活用頂いております。「忙しくて教育ができない」という悩みから脱却できます。

CTR IMG