リリース判定基準・プロセス品質は開発実務と開発管理に分けて考える
リリース判定ではソフト開発のプロセス品質も見る
グータラ親父がソフトウエアのリリース判定を行う時に使ってきた４つの基準のうちの１つがプロセス品質という事はリリース判定のための４つの基準の記事で紹介しましたね。ソフトの品質を考える時にプロダクト品質とプロセス品質とう観点から考えると、品質を判定し易くなります。
プロダクト品質とプロセス品質とはソフトの品質を判定する上で大切な点ですが、何に重点をおくか、どうやって良し悪しを判定するのかは、市場や組織によって様々です。この記事では、グータラ親父がリリース判定の時にどうやってプロセス品質の善し悪しを判定してきたのか、経験を元に紹介していきます。
プロセス品質はプロダクト品質と対比すると判り易くなります
ところで、ソフト開発のプロセスって何の事でしょうか？プロセスという言葉は開発の現場でもよく聞くようになった言葉ですが、なんとなく漠然としていますね。 Software Development Process を日本語に訳するとソフト開発工程なのでプロセスとは工程という意味になります。要するにプロセスとは、ソフトの開発を行う時の設計や実装などの１つ１つの作業の工程の事です。
そして、プロセス品質というのは設計や実装等の１つ１つのの作業工程の品質の事です。作業工程のアウトプットそのものではなく、作業工程の品質という所に注意が必要です。まだ少し判り難いですね、プロダクト品質と対比して考えると判り易いので、例えば実装工程（Cording Process）を例にしてみましょう。
実装工程のアウトプットはソフトウエアのソースコードです、そしてソースコードそのもの品質（バグが入っていないか等）はプロダクト品質です。では実装工程 (Cording Process) の品質とは何かというと、バグが混入しないような良い実装作業の進め方をしていますか、という事です。例えば、古いソースファイルを間違えて使わないようなソースツリーの運用ルールになっていますかとか、コーディング規約に合わせてソースコードを書いていますかとか、決められた単体テストを終えていますかとか、実装作業の進め方そのものの善し悪しが、実装プロセスの品質です。
ソフトの開発プロセスには開発実務と開発管理がある
ソフト開発のプロセスには色々なものがあります。要件定義、構造設計、機能設計、詳細設計、実装、テスト設計、テスト実施、デバッグ、進捗管理、バグ管理、開発委託先管理、品質管理、リリース判定、保守、等ソフトのライフサイクルに渡って実施する必要がある作業工程の１つ１つがプロセスと呼びます。
グータラ親父が使ってきプロセス品質という言葉の指す具体的な内容については、別の記事分類を作って、何件かの記事で具体的に紹介していますので、詳しくはそちらをご覧ください。
開発実務プロセスと開発管理管理プロセス
ところで、ソフトのプロセスには開発実務プロセスと開発管理プロセスの２つがあります。先ほど例を挙げた中では、要件定義、構造設計、機能設計、詳細設計、実装、テスト設計、テスト実施、デバッグ、保守 などは開発プロセスです。そして、進捗管理、バグ管理、開発委託先管理、品質管理、リリース判定、などが管理プロセスです。
例えば、皆さんが開発プロジェクトのリーダになった時に何をするのか考えると、開発管理プロセスが判り易くなります。まず一番気になるのは納期を守るための工程管理ですね。開発日程を線表に書き表して進捗状況を確認し、遅れが出てきたら工程の挽回対策を行うのが工程管理です。工程管理とともに大事なのが品質管理ですね。必要なテストを実施して、検出したバグがちゃんと直っているかを確認してリリースまでにバグを無くしていく作業を管理するのが品質管理です。
このような、工程管理や品質管理もソフト開発にとって重要なプロセスです。ソフトそのものを開発するための設計や実装のプロセスである開発実務プロセスが、計画した目標を達成できるように順調に実施されているかを監視し、問題があれば対策を行う管理のための工程が、開発管理プロセスです。
ソフトウエアのプロセスは、このように開発プロセスと管理プロセスの２つのプロセスがあり、その両方が品質良く実施された初めて、良いソフトウエアが計画された日程でリリースされるようになります。
ソフトの開発実務プロセスは変化が激しいので良し悪しの判定が難しい
開発実務プロセスは開発の実務作業そのものですので、採用する技術によって注意すべきポイントも実務作業の善し悪しも変ってきます。設計であれば、どんな設計手法を使うのか、設計結果を表現する設計書の書式には何を使うのか、設計レビューの方法はどんな手法やツールを使うのか、など全ては開発リーダがその開発に最適の方法を決めて実行していく内容です。
ソフトのリリース判定時に、この開発実務プロセスの善し悪しを判断してリリース判定のための情報として使えれば良いのですが、残念ながら採用する技術によって判断の基準も判断の仕方も大きく変わってしまうので、一律に開発実務プロセスの善し悪しを判断できません。
グータラ親父も、自分がソフトの開発チームを率いて開発実務を行っていた時には、色々に設計手法や設計ドキュメントの書式を試みましたが、これが一番良いという汎用的なものは残念ならがありませんでした。開発手法も設計書の書式も、ソフトウエア技術の進展につれてどんどん変わっていきます。１年一昔、10年大昔のマウスイヤーを生きているソフトウエア開発者にとっては、開発手法や設計書の書式という開発の根幹部分でさえも、頻繁に変えていかざるを得ないといのが実態です。
リリース判定ではソフト開発実務の良し悪しは見ない
そんな訳ですので、ソフトのリリースを判定する時のプロセス品質の善し悪しの判定としては、開発実務プロセスの判定は除外しました。一律に善し悪しを判定できないのですから、そこはもう開発リーダの力量に一任して信頼するしか無いと、グータラ親父は腹を括る事にしました。 あ実際のところ、ソフト開発の成否の大部分は開発リーダの力量に大きく依存するので、新ためて腹を括るという程の事でも無いというのが実情です。
一方で、開発管理プロセスのほうは、それほど個々の技術内容に左右される事はなく、一般的な方法が使われる事が多いので、開発管理プロセスの善し悪しは判定ができます。そこで、プロセス品質については、主に開発管理プロセスの状態を確認してプロセス品質の善し悪しを判断していました。