ソフト開発プロセスは開発実務プロセスと開発管理プロセスに分けて品質を改善する
ソフトの開発プロセスを改善するには何をすればいい？
ソフトの品質にはソフト開発プロダクトの品質とソフト開発プロセスの品質があります。メーカが保証し改善しないといけないのは、製品に搭載されるソフトのソフト開発プロダクトの品質ですが、ソフト開発プロダクトの品質を良くするにはソフト開発プロセスの品質を良くする事が必要です。そしてソフト開発プロセスは、開発実務プロセスと開発管理プロセスに分けてそれぞれのプロセスの品質を良くする活動を進めると、効率よくプロセス品質の改善を進める事ができます。
ソフト開発プロセスの品質改善についてネットを検索すると様々な情報が見つかります。プロセス改善の指導書やCMMI の入門書は色々とあるのですが、どれも書いてある事が立派すぎて何処から手を付けて良いのか迷う事も多いですね。でも実際には、ソフト開発は全てが開発エンジニアと呼ばれる人間が作業している「泥臭い」作業の塊なので、実際に開発エンジニアがやっている作業を見て、改善の手が付け易いところから少しずつ進めていけば良いのです。このプロセス品質のカテゴリーの記事では、グータラ―親父がソフト開発プロセスの改善について実施してきたポイントを、できるだけ具体的な開発作業に沿って紹介していきます。
ソフトの開発プロセスは開発実務プロセスと開発管理プロセスに分かれる
ソフト開発プロダクトとソフト開発プロセスの違いについては、こちらの記事でも紹介していますが、大まかには以下の図のようになります。図の下半分がソフト開発プロダクトで上半分はそれらを作成するためのソフト開発プロセスです。
ソフト開発プロセスとソフト開発プロダクトの図（クリックすると PDFファイルが開きます）
この図の上半分に書いてあるソフト設計、設計レビュー、コーディング、テスト設計、テストレビュー、テスト実施、リリース判定 という一連のソフト開発プロセスは図の下半分のソフト開発プロダクト（成果物）を作成するためのプロセスです。これらのプロセスはもう少し詳しく表現するとソフト開発プロセスの中の開発実務のプロセスです。そしてこの図には書いていないのですが、ソフト開発プロセスにはこれらの開発実務のプロセスが計画どおりに進んでいるかを管理するための、工程管理、品質管理、コスト管理、納期管理 等のソフト開発に関する開発管理プロセスがあります。
ソフト開発プロセスの改善では、この開発実務プロセスと開発管理プロセスの両方について、ひとつひとつのプロセスの品質を改善していきます。
開発実務プロセスの品質を良くするために最初に考えておく４つのポイント
ソフトの開発実務プロセスには、上の図にあるソフト設計、設計レビュー、コーディング、テスト設計、テストレビュー、テスト実施、リリース判定 の他にも要求仕様設計、アーキテクチャ設計、コードレビュー、テスト結果レビュー、デバッグ、等があります。個々の開発実務プロセスの品質を改善する時のポイントについては、このプロセス品質のカテゴリーの個々の記事で順次紹介していきますが、個々の開発実務プロセスの改善とは別に、開発実務プロセスの全体を通して品質を改善する時に注意すべきポイントとして以下の４つがあります。個々の開発実務のプロセスの品質改善を考える時には、まずこれらの４つのポイントがちゃんと出来ているのかを検討するのが良いですね。
（１）開発実務のプロセスにどのプロセスモデルを使うのか
ソフト開発プロセスのプロセスモデルには、フォーターフォールモデル、インクリメンタルモデル、アジャイル開発モデル など様々なプロセスモデルがあります。ウォーターフォールモデルは昔からある最も一般的な開発プロセスモデルで、企画、設計、実装、テストと上流から下流に水が流れ下るように開発を進めていきます。インクリメンタルモデルでは、開発の要件を小さな塊に分割して、一つ一つの小さな要件の塊ごとに設計・実装・テストを繰り返しながら少しずつ機能を付け加えていって最終のソフトに近づけていきます。アジャイル開発モデルは比較的新しく定義もまだ完全に固まってはいませんが、開発要件を小さく分割して、各々の小さな要件毎に熟練エンジニアの小規模チームでソースコードを作り上げていきます。
どの開発モデルが良いのかは開発するソフトや開発組織の経験によって変わってくるので一概には決められませんが、今回のソフト開発ではどの開発プロセスモデルを使うのかは、ソフト開発の開発実務プロセスの根幹なので一番最初に決めて置く必要があります。
（２）ゲートプロセスとしてどのプロセスを使うのか
ゲートプロセスとは、そのプロセスが完了していなければその次のプロセスには進まない、というように決めたプロセスの事です。例えば、設計レビューが完了しなければ次のコーディング作業は始めない、というように決めたのであれば設計レビュープロセスがゲートプロセスになります。或いは、XXX基本機能の安定動作が確認される迄は個別機能の設計・コーディングを開始しない、と決めたのであればXXX基本機能の完成がゲートプロセスです。なお、どんなソフト開発でも、最後のゲートプロセスはリリース判定になります。リリース判定プロセスでリリースの承認が下りなければ、ソフトのリリースという次のプロセスには進んではダメなので、リリース判定は最後のゲートプロセスです。
ゲートプロセスは開発状況が見えにくいソフト開発プロジェクトを管理するためにとても有用なプロセスです。ゲートプロセスとしてどのプロセスを使うのかも、プロセスモデルの選択と同じように開発するソフトや開発組織によって変わるのですが、これもまた最初に決めておく事が必要です。
（３）他社に開発を委託した部分のソフトの品質をどうやって確保するのか
全てのソフトを自社内で開発する場合には、自社内で開発したソフトのプロダクト品質だけを意識していれば良いのですが、ソフトの大規模化によってソフトの一部分の機能や開発の開発実務プロセスの一部分を他社に業務委託する場合も多くなってきました。この場合には、自社のソフト開発プロダクトの品質が、業務委託して開発したソフト開発プロダクトの品質に大きく影響される事になります。他社に開発業務を委託した部分は、自社とは異なる他社の開発実務プロセスや開発管理プロセスで開発されたソフトの開発プロダクト（成果物）なので、その品質を確保するための手段を予め明確にしておく事が大切です。
要求仕様やソフトの設計書のレビューに参加する事で品質を確保するのか、ソフト開発監査を行って品質を確保するのか、業務委託先で実施してもらうテストの内容をレビューする事で品質を確保するのか、自社に納品されたソフト開発プロダクト（成果物）を自社で受け入れ検査をして品質を確保するのか、さまざまな方法が考えられるのですが、どの方法で開発委託をしたソフトの品質を確保するのかは、最初に決めておく必要があります。
（４）重要なレビューとテスト＆デバッグは漏れなく・確実に実施する
ソフトの開発実務は全て、ソフトエンジニアが頭の中で考えた結果を、設計書やソースコードやテスト結果などのソフト開発プロダクト（成果物）として書き出す事で成り立っています。ソフトエンジニアという人間がやる事なので、そこには必ず勘違いや記憶違いなどによる間違いが入り込みます。この間違いを見つけ出して修正する事が、ソフト開発プロダクトの品質を良くする唯一の方法です。そのように考えると、設計やコーディングの間違いを見つけだす設計レビューやコードレビュー、実行プログラムの間違いを見つけ出すテスト＆デバッグはとても重要です。せっかく見つけ出した間違いを漏れなく修正するためには、判り易い記録と対策終了までの確実なトラッキング（追跡）が大切です。これらの活動が着実に行えるようになっているか、レビューやテスト＆デバッグのプロセスは特に注意しましょう。
開発管理プロセスの品質を良くするために最初に考えて置く４つのポイント
ソフトの開発管理プロセスには、この記事の前の方で紹介した 工程管理、品質管理、コスト管理、納期管理 の他にも レビュー管理、バグ管理、テスト管理 等があります。個々の開発管理プロセスの品質を改善する時のポイントについては、このプロセス品質のカテゴリーの個々の記事で順次紹介していきますが、個々の開発管理プロセスの改善とは別に、開発管理プロセスの全体を通して品質を改善する時に注意すべきポイントとしては以下の４つがあります。個々の開発管理のプロセスの品質改善を考える時には、まずこれらの４つのポイントについてちゃんと出来ているのかを検討するのが良いですね。
（１）今回の開発プロジェクトで何を重点して管理するのかを決める
ソフトの開発管理は大切なプロセスなのですが、実は管理をしてもソフトのプロダクト品質は良くなりません。大雑把な言い方になりますが、ソフト開発実務プロセスを良くすればソフトのプロダクト品質は良くなり、ソフト開発管理プロセスを良くすれば開発計画どおりにプロダクトが出来上がるようになります。例えば、納期管理のプロセスを良くすれば、計画した日時にソフトをリリースできるようになり、コスト管理のプロセスを良くすれば計画したコスト以内でソフトが完成するようになります。
でも、納期管理やコスト管理をしても、設計書に潜む問題点やソースコードに潜むバグが減る事は無いので、ソフトのプロダクト品質が良くなる訳ではありません。とはいえ、納期やコストはソフト開発プロジェクトにとって品質と同じく非常に大切な事なので、必要に応じたソフトの開発管理プロセスを実施する事が大切です。今回の開発プロジェクトで重要視されている点について計画がしっかりと実現できるように、どの開発管理プロセスを採用するかを開発プロジェクトの最初に決めて置くことが大切です。
（２）開発管理に使う指標（メトリクス）とその目標値を決める
管理するとは ①目標を決めておき ②現状を監視して ③目標と現状との差異を確認し ④差異が大きい箇所についてリカバリ策を実施する という４段階の活動を繰り返して行う事で「最初に立てた目標を達成できるようにする」事です。この４段階の活動の中で一番大切なのは ④のリカバリ策の実施 なのですが、リカバリ策の実施にはコスト（人件費や機材や時間）が掛かるので、効果的なリカバリ策に焦点を絞って実施する事が大切です。
ですので、開発管理を効果的に運用するには ③の目標と現状の差異 が許容値を超えそうかどうかをブレ無く確実に判断して、本当に必要な部分に対してリカバリ策を実施する事が重要になってきます。確実な判断をするには、管理する品質を定量的に把握できるメトリクスを定めて、そのメトリクスを使った目標値を決めておくのが良い方法です。ただしメトリクスは、品質や管理状況のある一面だけを取り出した数値なので、１つのメトリクスだけにあまり注目し過ぎるともっと重要な箇所を見落としてしまう危険性もあるので、常に複数の視点で見るように心がける事も必要になります。
（３）開発管理の頻度と監視からフィードバックまでの仕組みを決める
管理して「最初に立てた目標を達成する」には、現状の監視・差異の確認・リカバリ のサイクルを繰り返し回す事が大切です。この管理サイクルをどの程度の頻度で実施するのか、週１回か、隔週か、月１回かは、開発管理の最初の段階で決めておく必要があります。管理サイクルの頻度は開発プロジェクトの規模や期間によっても変わりますが、大切なのはリカバリ策の効果が得られる程度の頻度に設定する事です。 小規模・短期間の開発ではあまり管理サイクルを回す時間も取れない事が多いですが、少なくとも３～５回は開発管理のサイクルを回せるように管理の頻度を決めるのが良いでしょう。
管理サイクルの頻度と共に大切な事は、リカバリ策を実施するための仕組みです。リカバリ策にはコスト（人件費・機材・時間）が必要になるので、コストを使う権限を持っている開発リーダなどにリカバリ策の必要性を認識してもらい、リカバリ策を実施してもらう事が必要です。そのための仕組みとして、開発監視で発見した目標と実績の乖離状態を、報告書として開発リーダに提出するのか、開発管理会議を開いて開発リーダに直接状況を伝えるのか、どんな方法でも構わないので不開発リーダへのフィードバックの仕組みを明確にしておく事も大切です。
（４）重要な要件管理、レビュー管理、リリース判定はしっかりと行う
開発管理はその開発プロジェクトにとって重要な点にそって管理を実施する対象を選ぶのが良いのですが、要件管理、レビュー管理、リリース判定 の３つはソフト品質にとって重要なプロセスなので、どんな場合にでも開発管理の対象プロセスとしておくのが良いです。
要件管理はソフト開発の一番大元になる「どんなソフトを作るのか」を開発チームが正しく把握できているかどうかの管理です。開発要件の記述に過不足は無いか、要件の内容を開発チームが正しく認識できているか、等を確認するための市場調査や要件の洗い出し、開発要件を取りまとめた企画部門とソフト開発部門とのクロスレビューなど、適切な要件管理プロセスが実施されている事をしっかりと管理しましょう。
レビューはソフトの設計やテストやコードの不具合を見つけ出す唯一の方法です。レビューの実施状況やレビュー方法やレビュー指摘事項のトラッキングなどは、レビュー管理はソフトのプロダクト品質に直接影響を与えますのでしっかりしたレビュー管理が大切です。 そして、完成したソフト開発プロダクトを世の中にリリースするリリース判定は、ソフトの品質を保証するための最後の砦なので、実施状況やチェック項目についてしっかりと管理しましょう。
ソフト開発プロセスの品質改善の進め方は色々です
この記事ではグータラ親父の考えるソフト開発プロセスの品質改善について概要を紹介してきました。世間一般でいう所のプロセス品質の改善とは違いがあるかも知れませんが、まあこんな考え方もあるな～程度で読んでいただければと思っています。
なお、グータラ親父の考える個々のソフト開発プロセスの改善のポイントについては、個別の記事で順次紹介していく予定です。記事が書けたら、この下に具体的な記事のリストが見えるようになりますので興味のあるかたはそちらもご覧ください。