プロセス品質はビジネスにとって大切
プロセス品質が良いと計画どおりにソフトウエアが出来ます
プロセスという言葉は日本語では手順やルールを指す言葉です。そして、ソフトウエアの開発に必要なプロセスは開発プロセスと管理プロセスの２つに大きく分かれるのですが、これらのプロセスが良い、つまりプロセス品質が良いと何が嬉しいのでしょうか？ 実は プロセス品質 が良いと、常に計画どおりの日程で計画どおりの機能や品質のソフトウエアが出来上がって来るので、ビジネスを進めていく上で先の予測が経つのですごく嬉しいのです。 この分類では、プロセス品質の良し悪しを判断する方法やプロセス品質を良くする方法について紹介していきます。
プロダクト品質とプロセス品質
ソフトウエアの品質を保証したり評価したりする場面で、グータラ親父はプロダクト品質とプロセス品質のどちらの品質に該当するかを常に意識していました。ソフトウエアの品質には様々な側面があるので、何か大まかな概念を元に整理して考えていかないと、判りにくかったからです。
プロダクト品質とプロセス品質という考え方は、あまり広く使われているわけでもありませんが、ソフトウエアの品質を整理する上でなかなか使い勝手のよい概念です。簡単に言えば、プロダクト品質とはソフトウエアその物の品質で、プロセス品質とはそのソフトウエアを開発するプロセスの品質です。
ですので、普通にソフトウエアの品質という場合には、プロダクト品質を指します。一方でプロダクト品質の良し悪しを判断したり、プロダクト品質が良いソフトウエアを開発しようとした場合には、プロセス品質の良し悪しも関わってきます。そもそもプロセス品質ってどんな物なのか、グータラ親父なりに理解している事を紹介してみますので、参考にご覧ください。プロダクト品質については、こちらの記事を参照して下さい
プロセス品質ってなにでしょう？
プロセス品質とはソフトウエアを開発するプロセスの品質です。プロセスは日本語に訳すと作業手順というのが一番近いでしょうか。例えば設計レビューのプロセスとは、設計レビューを実施する作業手順の事です、この設計レビューを題材にもう少しプロセス品質を考えてみましょう。
設計レビューの作業手順の一例をあげると、a) 設計レビューを実施するかどうかを判断して、b) レビュー対象の設計書を準備して、c) レビューを会議やるのか資料回覧でやるのかレビューの方法を決めて、d) レビューの参加者を決めて、e) レビューを実施して、f) レビューで出た指摘事項を記録して、g) 指摘事項の対応をする、などですね。各組織でこのような設計レビューの作業手順が決まっていると思いますが、この一連の作業手順が設計レビューのプロセスです。
では設計レビュープロセスの品質とは何でしょうか、どんな項目を評価すれば、設計レビュープロセスの品質の良否を判断できるのでしょうか、ここでも例で考えてみましょう。例えば a) のレビューを実施するかどうかの判断ですが、 ①設計書に修正や追記があった場合には必ず設計レビューを実施する、としている場合と、②修正や追記が 1Page 以上の場合には設計レビューを実施する、としている場合と、③必要に応じて設計レビューを実施している、という場合があったとします。 ①だと設計書に追記や変更があった時には必ず設計レビューが実施されますが、③だと必要に応じてという不明確な判断で、多くの設計レビューが省略される可能性もあります。ですので、品質の良いソフトウエアを開発するためのプロセスとしては、① > ② > ③ の順に品質が良いと言えます。
簡単に言うと、プロダクト品質の良いソフトウエアを作るためにより効果のあるプロセスが、品質の良い開発プロセスです。残念ながら、プロセス品質の状況を定量化して絶対値と比較するような手軽な良い手法がまだ無いので、プロセス品質はこのプロセスよりあっちのプロセスのほうが良いというような相対的な評価になる事が殆どです。とはいえ、プロセス品質の良し悪しはやはり存在するので、できるだけ良い品質の開発プロセスを採用するに越したことはありません。なお、CMMI の手法を使えば開発プロセスの完熟度を定量化はできるのですが、作業工数がかなりかかるので、ソフトウエア開発監査で使うにはちょっと重たいです。
開発プロセスと管理プロセス
ところで、ソフトウエアのプロセス品質を考える時に、グータラ親父は開発プロセスと管理プロセスとに分けていました。開発プロセスとは、要求仕様設計、基本設計、詳細設計、実装、テスト 等の実際にソフトウエアを開発するためのプロセスです。一方で、管理プロセスとは作業進捗の管理やレビュー実施の管理やテストの管理のように、ソフトウエアの開発作業の管理をするためのプロセスの事です。
開発プロセスが良く無いと、良いプロダクト品質のソフトウエアができてきません。管理プロセスが良く無いと、決められた納期になっても、必要な機能や性能や品質を満たしたソフトウエアができてきません。
開発プロセスはどうして品質を判断するのでしょう
開発プロセスには設計からテストまで実際のソフトウエアの開発作業に沿って様々なプロセスがありますが、それぞれのプロセスの品質の良し悪しはどうやって判断すれば良いのでしょうか？ 開発プロセスとは作業手順です。作業の手順という事は、人が何かの作業をする事を前提としています。人が情報を集めて/考えて/その結果なにかの判断をする、というのが作業の手順です。そして、人が行う事なのでどうしても間違いやミスが混じりこむ危険性があります。
ですので、品質の良い開発プロセスとは、人の間違いをできるだけ軽減するような工夫が入っているプロセスの事です。まあ、簡単に言えば以下のような事ができるだけ明確になっているプロセスが品質が良いプロセスだと言って良いでしょう。
- そのプロセスを実施するか飛ばしても良いかの判断基準がはっきりしてる
- そのプロセスを実施する前準備の内容がはっきりしている
- そのプロセスの作業の手順がはっきりしている
- そのプロセスをレビューするタイミングや方法がはっきりしている
- そのプロセスの成果物がはっきりしている
- そのプロセスの成果物の品質の良否を判断する方法がはっきりしている
これらの事がはっきりしていれば、人の間違いをある低度減らす事ができるので、それが品質のよい開発プロセスだと思います。
管理プロセスはどうして品質を判断するのでしょう
管理とは、計画や目標を立てて、その計画や目標を達成するように作業の状況を監視して、計画や目標からズレそうなら対策を実施して計画や目標を守るようにする作業の事です。ソフトウエア開発で守るべき計画や目標とは、納期や開発コストや要求された機能や性能や品質など、いろいろな計画や目標があります。これらの計画や目標に対応して、それを守るための活動として工程管理や要求事項管理やテスト管理というような管理プロセスが発生します。
それでは、管理プロセスの良し悪しは何を見てどうやった判断するのでしょうか？ 管理とは計画からのズレをできるだけ少なくするための作業なので、簡単に言えば以下のような事ができるだけ明確になっているプロセスが品質が良いプロセスだと言って良いでしょう。
- 計画の作り方が具体的に決まっている
- 作った計画のレビューの仕方がはっきりしている
- 計画に対応する実績データの収集の仕方がはっきりしている
- 計画と実績のズレを確認する仕方がはっきりしている
- 計画からのズレがあった時の対処の仕方がはっきりしている
管理プロセスについて、これらの項目がはっきりとしていれば、その管理プロセスに沿って管理作業を進めていれば、計画からのズレを見つけてこれを修正する対策が効果的に実施され、その結果として計画からのズレが少ない状態で開発プロジェクトを完了できると思います。それが、品質の良い管理プロセスと呼んでよいでしょう。
プロセス品質の概要は判りましたでしょうか？
グータラ親父の考えるプロセス品質について概要を紹介してきました。世間一般でいう所のプロセス品質とは違いがあるかも知れませんが、まあこんな考え方もあるな～程度で読んでいただければと思っています。