Updates

新着情報

コラム

Automotive SPICE(プロセスアセスメントモデル)の功罪

Automotive SPICEを使われている方が多いと思いますが、活動は問題なく進んでいるでしょうか?Automotive SPICEをはじめとしてプロセスアセスメントモデルは、うまく活用できれば組織に大きな利益をもたらしますが、使い方の難しいモデルでもあります。 皆さん、下記の事例がいくつ当てはまるでしょうか? アセスメントでドキュメントが無いと指摘され作ったが、誰も活用していないドキュメントができてしまっている 定義した組織(あるいはプロジェクト)のプロセスに、Automotive SPICEのプロセス名が使われている プロセス改善活動の目的がAutomotive SPICEの能力レベルになっている 組織のトップは、「レベルを取れ」とはいうが、日々の活動に関与してこない 改善活動に熟練者をアサインしてくれない プロセスは、Automotive SPICEで指摘されたことを取り組むだけで、生産性や品質の向上につながる活動は実施されていない 定義したプロセスは、Automotive SPICEプロセスと呼ばれ、Automotive SPICEを顧客が要求しているプロジェクトだけが、このプロセスを使用している アセスメントをするたびに、どんどんプロセスが重くなっている Automotive SPICEのBPをそのままプロセス定義している プロセスグループとプロジェクトグループとの関与がほとんどない 3つ該当すれば要注意、5つ以上該当する場合は重症だと思われますので、すぐに私たちにご連絡ください。きっとお役に立つアドバイスができると確信いたします。 プロセスアセスメントモデルと長く付き合ってきた我々の教訓をご紹介します。 従来の開発プロセスを尊重する 部門長、マネージャが率先して活動に取り組む 実現したいビジョンを確立して、計画およびリソースにコミットする Automotive SPICE(プロセスアセスメントモデル)の心を理解する 各プロセスの目的を理解する 誰が実施しても同じようにできるようにする プロセス間、能力レベル間のつながりを理解する 全プロジェクトとプロセスグループが協力しあう 継続できる改善施策を捻出する ツールを最大限活用する ただし、担当者にストレスを感じさせないツールとする 品質はただでは得られない 継続的なプロセス改善への投資を必要とするが、他の選択肢より安く済む 私たちは、開発の立場および品質保証部門などのスタッフの両方の立場で、開発活動とプロセス改善を両立してきました。成功体験もあれば、数多くの失敗も重ねてきました。アセスメントモデルは、アセスメントする側の観点で作成されていますので、「何ができているか?」ということをプラクティス(BP/GP)として定義したものであり、「どのように作業するか?」というものではありません。従って、アセスメントが終わって改善作業をする場合に、アセスメントモデルを参照するのではなく、作業の順番などを標準化してあるISO/IEEEなどの標準書を参考されると良いと思います。また、プロセスアセスメントモデルは欧米の慣習に基づいて作られており、日本独自の文化に合わせた対応をすることが重要です。 必ず私たちの経験が皆様の困りごとのお役に立てると信じています。お悩み事があれば、お気軽にお声がけください。 日吉昭彦

コラム

ソフトウェアドキュメント間のトレーサビリティについて

ソフトウェア開発で作成するドキュメント間のトレーサビリティについて悩まれている方が多いと思います。 本コラムでは、ソフトウェアで作成すべきドキュメントの構成を簡潔にまとめました。ソフトウェア開発現場では、日々エンジニアの方が多くの課題に立ち向かっています。 納期に追われ設計ドキュメントの作成が後回しになる 他のエンジニアが作成したソフトウェアを修正すると予想しない問題が発生する テストを十分したつはずなのに、顧客の受け入れ試験で多くの問題を指摘されるなどなど。まずは、ソフトウェア開発で文書を残しておく重要性を、簡単な図で理解していただきたいと思います。